siebel

The following is a cross-post from my co-worker Jeroen Burgers, who shares his experiences as an Oracle Implementation Advisor on his blog with the same name . In one of his recent articles, Jeroen picked up the topic of Siebel Predefined Queries (PDQ) and the impact they can have on performance. I am pleased that he agreed to publish his findings on Siebel Essentials. *** Ever had to deal with PDQs which required to fetch based on date functions such as Year-to-date or Month-to-date (or any related�)? I came across an implementation where a customer became very creative trying to resolve this. But the end-result was a terrible performance. Why? Because the PDQ could not be completely be executed as SQL. A generic implementation flaw in queries written by Siebel configurators or business analysts: misusing calculated fields to be used in e.g. search Expressions and PDQs. It can (or will) hammer performance. A lot. For example: Provide me all the Opportunities YTD. This was the original...

“In any collection of data, the figure most obviously correct, beyond all need of checking, is the error...” Check, Double-Check, Recheck is the mantra while depolying on production in order to avoid any goofups. Despite any technique being used for deployment including ADM or EIM a thorough sanity should be done after deploying the artifacts on the production envirnoment. This becomes quintessential in multi-project environments where roll out is in phases. Every body has its own strategy based on the environment to perform a sanity check. However the one i have been using is to perform a count of records across the environment along with ADM to deploy artifacts. While ADM ensures that artifacts have been deployed successfully the count helps in confirming that nothing is missed from the source environment. Here is sample query which can be customized based on the specific artifacts which gives us the count of records from multiple tables such as Personalization rules, runtime events...

As the chineese saying go "Ink is better than the best memory", documentation is key to success for any project. UIS,LLD, HLD are generally part of Document deliverables. We will not discuss these specs here rather this blog will focus more on getting extract from siebel tools for future reference. This tip may be useful for LLD spec. For most of the objects siebel gives direct export from tools. But consider a scenario when you want export of columns/controls which are mapped to applets. Direct export from list Columns or controls will give you all columns available in the applet and not the mapped one. An export from applet Web Template item will only give columns which are mapped but not the other desired properties like pickapplet or mvg applet. Following SQL will help to extract list columns which are mapped to list applet in edit list mode. Anybody can change the name of Applet in the query for which columns need to be extracted. select D.NAME, D.AVAILABLE_FLG, D.DISPLA...