Warning: Declaration of Suffusion_MM_Walker::start_el(&$output, $item, $depth, $args) should be compatible with Walker_Nav_Menu::start_el(&$output, $item, $depth = 0, $args = Array, $id = 0) in /DISK2/WWW/plsql.cz/www/wp-content/themes/suffusion/library/suffusion-walkers.php on line 0
Jul 022012
 

Tak to nakonec vypadá, že nechám plavat certifikaci v Sieblu – ačkoliv je ve hře scénář si “to prostě zkusit”, podle těch jejich certifikačních testů jsem nebyl moc daleko ;). Proč? Buďme upřímní – se Sieblem jako produktem to nevypadá dobře a jedno burzovní pravidlo řiká: “nákupy rozmýšlej, ale ztráty realizuj rychle”.

Každopádně zde dávám ke stažení výpisky jako přípravu na ceritifikaci v Sieblu. Jsou to hinty a psány jazkym pro mne, na gramatiku či úpravu zapomeňte. Text obsahuje i nějaké ty nepřesnosti a možná i semtam nějakou chybku - na stranu druhou je to 30 stran hardcore drillu. Na certifikaci to bohužel nestačí, ale základ imho velice solidní, enjoy.

Certifikační drill k Sieblu
Certifikační drill k Sieblu
 Posted by at 21:29
Nov 192011
 

Na školení Oracle vám řeknou dost jasně - neupravujte data pod Siebel aplikací, dokonce vám to dají písemně v materiálech ke cvičení. Nicméně mimo záznam vám i v Oracle řeknou, že je možné upravovat data přímo v PL/SQL pod Sieblem – přicházíte tím o dost věcí, včetně “záruky”.  Programátor tím však získává (za podstupující riziko) vcelku dobrou možnost jak rychle a efektivně upravovat data takže se tento přístup hodí především pro případy, kdy firmu něco hodně trápí a musí to být ASAP (a levně), rozhodně to nesmí být systémové řešení.

Pokud upravujete hodnoty v LOV (list of value), riziko je poměrně nízké, nicméně chce to dodržet nějaká základní pravidla (vždy updatovat na row_id, upravovat db_last_upd a jiné nutné datové systémové sloupce, vše pečlivě logovat atd..)

A co takový  INSERT? Především by to chtělo pro svůj záznam získat unikátní ROW_ID, tak aby bylo zaručeno, že se vám nikdy nepotkají ze Siebel aplikací. Kolegové tomu řikají MAGIE, já jsem se rozhodl podrobit generování rowid nějaké vlastní analýze:

V knize Oracle Siebel 8 CRM Developer Handbook jsem narazil na krátkou poznámku, kde je odkaz na tabulku SIEBEL.S_SSA_ID, ze kterých si Siebel bere ROW_ID.

Nad tabulkou kupodivu není žádný trigger, nicméně existuje na ní jeden závislý objekt a tím je S_SEQUENCE_PKG, tento package obsahuje jednou jedninou funkci a ta se jmenuje : get_next_rowid, což ukazuje na vítěze mého pátrání. Ano, zde patrně SIEBEL generuje ROW_ID.

A zde máme celou package:


PACKAGE BODY s_sequence_pkg IS
MAX_ROWID_SIZE CONSTANT INTEGER := 15;
g_node_prefix VARCHAR2(15) := NULL;
g_node_prefix_len INTEGER := 0;
g_delimiter CHAR(1) := '@';

FUNCTION get_next_rowid
RETURN VARCHAR2
IS
suffix VARCHAR2(15);
row_id VARCHAR2(15);
totlength INTEGER;
BEGIN
IF g_node_prefix is null THEN
raise_application_error (-20001, 'Unable to find row in S_SEQUENCE table.');
END IF;

SELECT s_sequence_s.nextval
INTO suffix
FROM sys.dual;

totlength := length (suffix) + g_node_prefix_len + 1;
IF totlength > MAX_ROWID_SIZE THEN
raise_application_error (-20005, 'Row_id VAL is too large for max rowid size.');
END IF;

row_id := g_node_prefix || g_delimiter || suffix;
RETURN row_id;
END get_next_rowid;

BEGIN
SELECT corporate_prefix
INTO g_node_prefix
FROM s_ssa_id;

IF g_node_prefix is null THEN
raise_application_error (-20003, 'Node prefix is NULL.');
END IF;
g_node_prefix_len := length (g_node_prefix);
EXCEPTION
WHEN no_data_found THEN
raise_application_error (-20001,
'Unable to find row in S_SEQUENCE table.');
END;

Po krátkém prohlédnutí funkce, to vypadá následovně :

1) První část ROW_ID je

g_node_prefix je patrně prefix každého z mobilních klientů (0- pro sadmina, 1- pro enerprise)

2) Druhá část ROW_ID je

g_delimiter je oddělovač mezi první a druhou částí.

3) Poslední část ROW_ID je

g_surffix je generované z Oracle sekvence s_sequence_s.nextval

A nyní test:

SELECT SIEBEL.S_SEQUENCE_PKG.get_next_rowid from dual;
1@41;

Super? Nikoliv – funkce se pouze odkazuje na tabulku a veskutečnosti slouží imho na generování ROW_ID mobilních klientů, nikoliv Sieblu jako takového. Tedy to rozhodně není, to co hledám.

Co tedy updatuje ten jediný řádek v této tabulce?  Čas pro auditování tabulky S_SSA_ID:


ALTER SYSTEM SET audit_trail=db_extended SCOPE=spfile;
AUDIT SELECT,INSERT,UPDATE, DELETE ON SIEBEL.S_SSA_ID BY ACCESS;
-- po (restartu a) vložení záznamu v Sieblu následoval select:
SELECT SQL_text,timestamp,sql_bind FROM DBA_AUDIT_TRAIL where action_name='UPDATE' order by timestamp desc;
-- výsledek:
UPDATE SIEBEL.S_SSA_ID SET DB_LAST_UPD_SRC = 'User', DB_LAST_UPD = CURRENT_DATE, LAST_UPD = '11/19/2011 16:33:36', LAST_UPD_BY = '0-1', MODIFICATION_NUM = 634, NEXT_SUFFIX = 3TCH WHERE ROW_ID = 0-11 AND MODIFICATION_NUM = 635;

Dle předchozích transakcí tam surfix ROW_ID updatuje patrně některá část Object Manageru, bohužel ani prohledání ALL_SOURCE (a ostatních systémových tabulek) mi nepřineslo uspokojivou odpověď jak jsou vlastně ROW_ID generovány. Dohledat něco, co je generováno někde v Object Manageru (či buhví kde), takže následovalo auditování všeho:

AUDIT ALL BY SIEBEL BY ACCESS;

A ani po té lze nelze vyčíst nic, podle čeho by se dalo rozklíčovat jak jsou ROW_ID generovány. Další nápad, který jsem dostal je trošku burtální ;) Ale tak proč, ne? Zkusit se má všechno – co S_SSA_ID tabulku dropnout? ;) Něco mi prostě vyhučí na chybě a ta bude pravděpodobně hodně blízko toho co hledám. Ne – počkat! dropnout tabulku S_SSA_ID rozhodně nechci, podle AUDIT TRAIL je před UPDATEm této tabulky následující select:


SELECT
T1.CONFLICT_ID,
T1.DB_LAST_UPD_SRC,
T1.DB_LAST_UPD,
T1.LAST_UPD,
T1.CREATED,
T1.LAST_UPD_BY,
T1.CREATED_BY,
T1.MODIFICATION_NUM,
T1.ROW_ID,
T1.CORPORATE_PREFIX,
T1.NEXT_FILE_SUFFIX,
T1.NEXT_PREFIX,
T1.NEXT_SUFFIX
FROM
SIEBEL.S_SSA_ID T1

A ten by se měl ideálně provéci, nejlepší by bylo, aby s chybou skončil až daný update – což se dá zařídit triggerem:

CREATE OR REPLACE TRIGGER trg_S_SSA_ID BEFORE UPDATE
ON S_SSA_ID FOR EACH ROW
DECALRE
d date:=sysdate;
BEGIN
d:=:new.NEXT_SUFFIX;
END;

Pointa je doufám vidět – trigger při update vyhučí na chybě – nepujde přiřadit SURFFIX (varchar2) do datové proměnné a z logu snad vyčtu nějaké další informace nebo alespoň stopy.

Nápad dobrý, výsledky dobré nejsou – po té co jsem znemožnil update tabulky S_SSA_ID se již nelze nalogovat do aplikace Siebel ;) Uf, trošku mi polilo horko, ale po disablování triggeru Siebel naštěstí pracuje spokojeně dál.. a po restartu tlustého klienta ;)

Nicméně z toho lze vyčíst alespoň jednu novou informaci a tou je, že se opravud nové ROW_ID kešují (údajně až 100) na začátku každé session a podezření je na soubor diccache.dat, který byl v chybové hlášce, když jsem se nemohl do Sieblu nalogovat (patrně čas hexaeditoru)

Každopádně (pro zatím) uznávám svou porážku nad aplikací Seibel a přiznávám, že generování ROW_ID je magie.

 Posted by at 17:50
Nov 182011
 

Siebel, se přiznám, není úplně moje nejsilnější stránka – nicméně jsem se rozhodl, že si udělám certifikaci – konkrétně Síebel Consultant Expert ;-) Částečně mi k tomu vyprovokoval kolega a částěčně to bylo mé rozhodnutí, inu proč ne-e, je to šikovný papír a po absulovaném školení s tím snad tolik práce také nebude.

Po té, co jsem si doma vyzkoušel založení Buisness Component, Buisness Objektů, Appletů, View jsem se rozhodl pokročit a zkusit si i nějaké joiny a MVG.  Po založení dvou Buisness Component jsem vytvořil přes Siebel Tools -> File -> New Objects -> New Table novou Intesection tabulku a pokračoval dále vytvořením joinu,  List Appletů, Form Appletů atd. Po té následovalt test a :

An error has occurred preparing a Sql statement. Please continue or ask your systems administrator to check your application configuration if the problem persists.(SBL-DBC-00108)

Jako PL/SQL programátor bych prvně asi šáhnul pro auditování v Oracle (BY ACCESS WHENEVER NOT SUCCESSFUL),  nicméně v rámci cvičení jsem použil parametr /s “c:\spool.txt” ;) Koukám na chybný select :


SELECT
T2.CONFLICT_ID,
T2.LAST_UPD,
T2.CREATED,
T2.LAST_UPD_BY,
T2.CREATED_BY,
T2.MODIFICATION_NUM,
T2.ROW_ID,
T2.JMENO_SKOLY,
T2.ZACATEK_SKOLY,
T2.KOKNEC_SKOLY,
T1.ROW_ID,
T1.MODIFICATION_NUM,
T1.CREATED_BY,
T1.LAST_UPD_BY,
T1.CREATED,
T1.LAST_UPD,
T1.CONFLICT_ID,
T1.CX_AA_AZOR_BC2 Foreign Key,
T1.CX_AA3_AZR_SCHL Foreign Key,
T1.CX_AA3_AZR_SCHL Foreign Key,
T1.CX_AA_AZOR_BC2 Foreign Key
FROM
SIEBEL.CX_PL_SCHL_IN T1,
SIEBEL.CX_AA3_AZR_SCHL T2
WHERE
T1.CX_AA3_AZR_SCHL Foreign Key = T2.ROW_ID AND
(T1.CX_AA_AZOR_BC2 Foreign Key = '1-3LH9')

Co je špatně bylo vidět na první pohled – “Foreign Key” nemá v selectu, co dělat.  Vyníkem je v Siebel Tools objekt tabulka, který měl definované sloupce s názvem “CX_AA_AZOR_BC2 Foreign Key a CX_AA3_AZR_SCHL Foreign Key”, k mému zděšejí dokonce takovéto sloupce jsou založeny v databázi – co je ale problém selectu, jsou chybějící uvozovky, které je třeba použít, pokud název tabulky obsahuje speciální znaky, včetně mezer.

Zkusil jsem změnit název sloupců v Siebel Tools a vygenerovat si DDL script, protože mi zajímalo, co bude pro tento případ vygenerováno – odpověd? Nebylo vygenerováno nic a navíc Siebel Tools vyhučely na chybě, která byla patrně způsobena tím, že vygenerovaný script byl prázdný.

V jednu ráno se mi opravdu nechtělo vztekat ze Siebel Tools, tedy následoval zásah, který by v Oracle asi neradi viděli ;) :

ALTER TABLE SIEBEL.CX_PL_SCHL_IN RENAME COLUMN "CX_AA_AZOR_BC2 Foreign Key" TO CX_AA_AZOR_BC2;
ALTER TABLE SIEBEL.CX_PL_SCHL_IN RENAME COLUMN "CX_AA3_AZR_SCHL Foreign Key" TO CX_AA3_AZR_SCHL;

Bingo, tak zde je muj první vzah M:M v Siebel Tools (mimo školení) :

Siebel Tools - první intersection tabulka

Až na to menší vztekání s názvem slopců tabulky a těch spoustu překlepů, které vidím až nyní, vcelku spokojenost s hotovým dílem. Odnáším si z toho ponaučení, že je třeba dávat pozor na mezery v názvech sloupců tabulek v Siebel Tools.

 

 Posted by at 00:50
Sep 062011
 

Po vytvoření nového workflow v Sieblu (narozdíl od jiných objektů v Siebel Tools) není workflow zkompilován do .srf souboru ale je umístěn v tabulce S_WFA_DEPLOY_DEF ve schématu <siebel>.

Na vypsání všech aktivních workflow v Sieblu si stačí jen do této tabulky šáhnout:

select NAME,busobj_name,db_last_upd_src,mode_cd from SIEBEL.S_WFA_DPLOY_DEF;

V administraci Sieblu, lze pak výsledek ověřit:

“Administration-Business Process -> Workflow Deployment -> Active Workflow Processes”

 Posted by at 21:21