Due to various reasons (one of them being an Oracle employee), I decided to start my blog on blogs.oracle.com. I am still an employee (just in case you might get this down the wrong throat) of course.

However I will not continue to blog on this server

Please update your bookmarks, favorites and whatnots to

http://siebel-essentials.blogspot.com

have a nice day

@lex
http:

glad to have found a quick solution for a possibly common requirement.

Users are trained to use the Account name field in the opportunity list to search for opportunities. However, when they use ALT+Q to enter query mode, the first column in the list has the focus, so they have to tab to the Account column. They want to have the cursor in the Account column once they enter query mode, irrespective of the placement of the column.

Here is a simple way to implement this. It introduces the DefaultFocus Applet User Property, which, if memory serves me correctly, has been introduced in Siebel 7.8.

First we add a new Applet User Prop to the Opportunity List Applet.
We use DefaultFocus_Query = Account to define the default focus column for the Query Mode.

Note that you can use DefaultFocus_Edit for Base, Edit and EditList mode and DefaultFocus_New for the New mode.

After compiling the .srf file, we can run a test....

And voilá, click Query and you find the focus on the Account column. So you can speed up your work by simply entering the search string and hitting the ENTER key.

There also was another requirement to have the focus on the Query button. However, using DefaultFocus_Edit = NewQuery did not yield the desired result. The funny thing was that the Query button only got focus after pressing ALT+ENTER (or invoking the ExecuteQuery command). Maybe the answer to that problem is somewhere out there...

Let's reiterate the requirement #2

Retrieve total opportunity revenue for an Account
Sum up the revenue of the current Opportunities for an Account and write the result to an Account field.

This is the prototype workflow. As in part I, Siebel 8.1 was the implementation platform.

The workflow itself has the following properties:

Business Object: Account
Process Properties created: CurrentRevenue, LastRecord, RecordCount, TotalRevenue

Get Oppties Step:
Business Component: Opportunity
Operation: Query
Search Spec Expression: "[Account Id]='" + [&Object Id] + "'"
Output Args: TotalRevenue = BC Oppty.Primary Revenue Amount
RecordCount = Output Argument NumAffRows

Decision Step Last Record?
yes = Process Property LastRecord = true
no = Default

Go to next Oppty Step
BC: Opportunity
Operation: NextRecord
Output Args:
CurrentRevenue = Opportunity.Primary Revenue Amount (1)
TotalRevenue = Expression: [&TotalRevenue] + [&CurrentRevenue] (2)
LastRecord = Output Arg: NoMoreRecords (3)
Note: Numbers in brackets indicate the sequence of the output arguments

Update Account Step
BC: Account
Operation: Update
Field Input Arg: Revenue = Process Property TotalRevenue

Note #1: The workflow operates on the Account Business Object with Account BC as the primary BC and Opportunity as a child BC.

Note #2: Despite Note #1 it is still necessary to execute a query to get the Opportunites associated with the Account.

Note #3: The fairly new Siebel Operation NextRecord (along with its siblings PreviousRecord and QueryBiDirectional) has been introduced in Siebel 8.0. It is the first version that allows us to loop through a record set in a workflow without being outwitted by the complexity of looping. The NextRecord operation has an output argument of NoMoreRecords (true or false) which must be used in a decision step to determine whether the loop has to end or not.

Pitfall #1: Adding up the revenue amount requires two process properties. One to get the field value from the BC and the other one to serve as the accumulator. Note the sequence in the NextRecord operation to fill them in the correct order.

Hope you enjoyed this small workflow series. If you want more, drop a comment ;-)

@lex

As indicated in a previous post, workflow processes (along with the business services they call) account for almost every piece of functionality and automation in Siebel CRM). So in general it is a good idea to have an eye on workflow when it comes to automation solutions.

However, there are some pitfalls for the novice developer that often lead to frustration and even refusal of using workflow.

In this and a following post, I will describe two workflows that should serve as examples how to solve common problems in Siebel.

These are the requirements

1. Update multiple records (this post)
Users should be able to enter a search string to retrieve a list of Accounts and the target value of the Account Status field. The system should then update the Account Status field of all records in the result set to the target value.

2. Retrieve total opportunity revenue for an Account (future post)
Sum up the revenue of the current Opportunities for an Account and write the result to an Account field.

I implemented both requirements on Siebel 8.1.0.0

Let's have a look at the solution to requirement #1.

To be honest, I was surprised at the simplicity of the workflow. It is a really nice example, how the Siebel framework works.

The workflow is configured as follows:
Business Object: Account
Process Properties created: QueryField, Querytext, RecordCount, TargetValue

The first Siebel Operation step is configured as follows:
BC: Account (No Link)
Operation: Query
Search Spec Expression: "[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"
Output: RecordCount = NumAffRows

The second Siebel Operation step is configured as follows:
BC: Account (No Link)
Operation: Update
Field Input Argument: Account State = Process Property: TargetValue

Pitfall #1: Too complicated approach
Siebel Operations inside a workflow which operate on the same BC inherit the context of the previous step, so all you need is one query operation and then the update operation will update all records in the query result set. That's it.

Pitfall #2: Problems with the primary BC
There is strange behaviour to report when the Siebel Operations use the primary BC of the workflow's Business Object (Account, that is). I used the Account (No Link) BC instead and it worked like a charm. Please don't ask why ;-)

Pitfall #3: Externalize the query string
How in god's name can someone figure out the query string if she/he is not a complete geek?

"[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"

is built as follows:

1. Parenthesize the value of the QueryField process property in square brackets

"[" + [&QueryField] + "]"

2. Append the LIKE operator

"[" + [&QueryField] + "] LIKE"

3. Append an asterisk to the value of the QueryText process property and parenthesize it in single quotes

"'" + [&QueryText] + "*'"

4. Bring all together

"[" + [&QueryField] + "] LIKE '" + [&QueryText] + "*'"

Not too difficult - but devilish

Note that the Siebel Operations have an output argument which is useful to get the number of affected records.

Several tests showed that the workflow updated several hundreds of records in short time.

Hierarchical picklists in Siebel CRM... It's a long story. There are numerous approaches (even in the standard repository) and myths out there how to implement them. A hierarchical picklist is one that allows a user to pick a value for the first field and then shows only values for the second field that are dependent on the first one and so on.

Here is a cookbook style example (tested on Siebel Industry Applications 8.1) how to implement a hierarchical picklist with indefinite levels:

1. Create the list of values data

Use the Siebel Web Client to enter the data for the picklist. You should use the same TYPE and distinguish the levels using the Parent field.

Note that the first level does not have a parent

2. Create the business component fields

Create one field for each level. For all levels but the lowest set the property Immediate Post Changes to true (for resetting the lower fields when changing the value in the applet).

3. Create picklist objects

Use the Picklist wizard to create a static bounded picklist object for the new fields. Create separate picklist objects for the first level and all subsequent levels (you will use 2 different picklist objects). When the wizard is finished, navigate to the picklists and make the following changes manually:

For the first level picklist, change the Business Component property to PickList Hierarchical and set the Search Specification property to [Parent Id] IS NULL.

For the second (and subsequent) level picklist, change the Business Component Property to PickList Hierarchical.

PickList Hierarchical is a standard BC used for example in the BC Service Request to implement the Product, Area and Sub-Area hierarchy.

4. Edit pick maps

Navigate to the Pick Map specifications for the new fields and set the following:

For the first level field add pick map records for all dependent fields and enter Dummy as the picklist field. Dummy is a calculated field (evaluating to an empty string) in the PickList Hierarchical BC.

For the subsequent fields add the Dummy mapping for all remaining dependent fields and add an additional record for the upper level field where you set the Picklist Field to Value and the Constrain flag to true.

Do not add a dummy mapping for the last field in the hierarchy. The screenshot should give you the general idea:

5. Expose the new fields as controls/list columns in an applet

Do the UI work as usual and test.

The dropdown for field 1 should only display the highest level values and lower level fields should be constrained to the child values of the higher level field value. When changing an upper level field, the lower level fields should be reset to empty strings. Users should not be able to select values in "wrong order".

have a nice day

@lex

As Erik Eckhardt describes in his blog, there is a not so widely known - and unsupported(!) - command line feature in the Oracle BI Administration Tool.

It can be used to automate activities such as creating rpd files, importing physical layers, updating connection pools, exporting subsets from projects (which is used during installation of Oracle BI Applications btw) and more.

As described in my post on Oracle BI data lineage, we have to export a csv file in order to get data we can use.
Here is a way to use the admintool.exe /command syntax to automate this.

1. Create an input file with the following content. Save the file on your drive (example: D:\input.txt)

Open samplesales.rpd Administrator Administrator
Hide
DescribeRepository D:\samplesales.csv UTF-8
MessageBox "Repository description exported successfully"
Close
Exit

This file contains commands to Open the samplesales.rpd using Administrator as username and Administrator as password.
The Hide command hides the Administration Tool window.

The happy command is DescribeRepository which triggers an export of the rpd metadata to the D:\samplesales.csv file in UTF-8 codepage. This is similar to using the Administration Tool utility manually.

The MessageBox command is just given as an example.
Then we Close the file and Exit from Administration Tool.

2. Open a command prompt and type (or write the following into a shell script):

D:\OracleBI\server\Bin\admintool /command d:\input.txt

and execute the script.

The admintool.exe will now open the input file and execute the commands, thus producing a metadata export file in an automated manner.

In Erik's post you can find more commands.

You can also run the Metadata Dictionary export using the GenerateMetadataDictionary command. The syntax for the input file is:

GenerateMetadataDictionary

Please note that using the /command switch is not documented and obviously not supported by Oracle Support, so please use it carefully and at your own discretion.

Quick Print seems to be somewhat neglected in most projects, as it comes with default settings that are not very attractive. The screenshot below shows the result of pressing the Quick Print toolbar button in the Account > Orders view.

Not very impressive indeed, but let's set the user preferences for Printing as follows (note that we use HTML output which also allows to print form applets; Excel output is only supported for list applets).

Now you're talking

As we see, Quick Print is capable of producing a fully featured report-style printout of the entire view, even if it contains HTML icons or side-by-side applets.

Hierarchical list in quick print

Side-by-side applets in quick print

Have fun

The effect is such that the browser closes and siebel.exe releases the srf. When the compile process completes, siebel.exe starts up again from its suspended mode (gray icon in the system tray becomes colorful again) and the browser launches AND navigates to the previously opened view.

So developers can continue testing without having to shut down the Siebel client and restart it, hence "Rapid Unit Test".

So far so good.

Then - out of a sudden in version 7.8 - a bug prevented this feature to work. Most of us are familiar with the gruesome error message of wrong username and password.

I am not sure if the bug has been fixed in the latest patch release, but there is a generation of developers who either do not know about that feature or have a version running which contains the bug.

I have developed a workaround (it is nothing more) which goes as follows (the following being a script you can run on your windows workstation after applying the correct installation folders):

rem rename sscfsaodbc.dll to sscfsaodbc.dll.orig
ren %SIEBEL_INSTALL_DIR%\client\bin\sscfsaodbc.dll sscfsaodbc.dll.orig
rem make a backup copy of sscfsadb.dll to sscfsadb.dll.backup
copy %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll.backup
rem rename sscfsadb.dll to sscfsaodbc.dll
ren %SIEBEL_INSTALL_DIR%\client\bin\sscfsadb.dll sscfsaodbc.dll

Basically, we have to swap the database connectivity dll files.

All I can say is that it works for me, you have to try it for yourselves and of course download and install the latest patch.

have a nice day

@lex

• New: Fusion Applications: eCommerce and eSupport
• New: BI Publisher Integration for Reporting
• New: Gateway Name Server Authentication
• New: Contact Center Chat
• New: Helpdesk Integration with Oracle Enterprise Manager
• New: Siebel Management Framework API
• Enhanced: PRM View Visibility and Web Services
• Enhanced: Sales Forecasting
• Enhanced: Global Account Hierarchy
• Enhanced: Integration Objects (EAI)
• Enhanced: ST Script Engine – Script Performance Profiler
• Enhanced: Siebel Workflow and Task UI
• Enhanced: Marketing Automation
• Enhanced: Siebel Loyalty
• Enhanced: Application Deployment Manager (ADM)

Being a Siebel guy, BI Publisher was a new product to learn when I ramped up upon Oracle BI EE 10g, the successor of Siebel Analytics. I really love the integration between the "classic" BI EE and BI Publisher.

As some of you might recall, Siebel had it's own version of pixel-perfect reporting with Siebel Analytics 7.8.4. In that version, Actuate was integrated with Siebel Analytics and some parameters in instanceconfig.xml are quiet reminders of those times, which of course are over now.

Recently, I was preparing a demo for the BI Publisher integration. It is a quick task and I use to do this demo on the fly - just to impress the customer, how easy it is, even I can do it ;-)

But I wanted to to something more than just to create a new dashboard page, drag in the BI Publisher Report object and link to the sample report provided with the sample application (be it paint or Sample Sales).

So I decided to show how stunningly easy it is to bring an interactive pivot report into a BI Dashboard.

BI Publisher incorporates a shy but powerful interactive Analyzer which you can invoke when you are in the BI Publisher Enterprise portal and viewing a report. Just click the Analyze button and you are in the midst of a drag'n'drop pivot-style tool.

Cool, I'd say.

What's even cooler is that you can save your Analyzer report as a new template, so it adds to your reports layout options. You can then use that template and direct the output to all formats supported (like HTML, PDF, PPT, etc...).

These templates are .xpa (Xml Publisher Analyzer) files which can be downloaded, customized (they're plain xml) and uploaded again.

Now let's do the trick and click the Link to this report link in the upper right corner. This feature allows you to create a direct URL to that report, maintaining the current layout options. You can do this for any option you choose, so if you're currently viewing a PDF output, you'll get a URL which allows you to download the PDF report (voice from off: "Alright, they got it now.")

Next we can use the Embedded Content object in the dashboard editor and paste the URL there and save the dashboard layout.

The result: A dashboard page which allows an end user to interact with the data using simple drag and drop pivot patterns.

Cool, I'd say again.

Have your Oracle BI EE instance started? Ready to explore something new? Here we go:

1. Go to Start > Programs > Oracle Business Intelligence > Systems Management

2. Log in as oc4jadmin. If you can not remember the password, here is a blog post describing how to reset it.

3. Click the Applications tab. This is the place where you find all registered applications in your OC4J, such as good ol' xmlpserver (also known as BI Publisher), bioffice (the BI Office integration, which - funny enough - is only supported on OC4J, not on IIS), analytics (Presentation Services) and - the focus of this post - Oracle BI Management

4. Click the icon in the Application Defined MBeans column for Oracle BI Management.

5. Spend the next 10 minutes exploring this page. What you see here are the management beans for Oracle BI services. You can view and modify all parameters for Oracle BI Server and Oracle BI Presentation Server as well as see some performance information.

You can use the search option to query for specific parameters.

What is exceptionally nice, is that almost every parameter possible is shown (which is not the case in NQSconfig.ini or instanceconfig.xml) and sports a useful description.

When you set a parameter, you have to click the Apply button and restart the respective service. The MBean changes the respective .ini or .xml file for you, but does not restart the service or refresh it's cache.

Why the tour?

Hope this promotes the idea of a centrally managed BI enterprise environment.

Have a nice day

To put it short, what they wanted was: Data Lineage for Oracle BI metadata
The design - and later implementation - included the following

• Oracle BI Usage Tracking (standard module)
• combined with presentation catalog metadata
• combined with rpd metadata

First, the Oracle BI rpd file is, well, a file and the data is not accessible like in a relational database. A fact which has been subject to criticism in recent times. The same holds true for the presentation catalog which has its information spread across thousands of small xml files.

To overcome this, we used the Repository Documentation utility of the Oracle BI Administration Tool. This allows you to create a flat csv file with the dependencies of all objects from presentation layer, business model and mapping layer and physical layer. The screenshot shows the file after the insertion of a primary key column, which is a necessary task if you wish to connect to it as a data source in Oracle BI. In the project we used an import package to load the file into a MS SQL Server database.

You can do the same with the presentation catalog using the Create Report option in the Tools menu of the Catalog Manager.

Both tasks are purely manual and up to this moment I have not found an automation solution for it (if you did, please drop a comment), which is the main reason why data lineage for Oracle BI is a little bit cumbersome. Whenever the rpd or catalog content changes, an administrator must manually extract the csv files and (ideally) load them into tables in a relational database.

As one commenter to this post has found out, there is an execution plan named Data Lineage in the current DAC repository (as created by the installer for Oracle BI Applications 7.9.5). A short investigation reveals that there are indeed table definitions which supposedly hold the data from the rpd and presentation catalog. At the moment this is only in the DAC repository and there is no accompanying ETL mapping in the Informatica repository. I would be so glad to be wrong here - if so, please add your comments below.

Data Lineage subject area (inactive by default) in DAC

Now comes the knitting, which means that you have to create complex (physical) joins to glue the rpd metadata together with the presentation catalog data. For a first test you can use the presentation layer object names (table and column) to get first results in Answers. (This post does not deal with the creation of the business model and presentation layer in the rpd file to access the data).

The S_NQ_ACCT table holds the valuable data from Oracle BI Usage Tracking, it has a column which contains the request path which allows us to join it to the presentation catalog data.

Now we have a somewhat complete data lineage tool. Below is a screenshot from one of the first dashboard prototypes of the a/m project which allowed us to visualize the benefits of caching.

There would be more to tell and maybe I find the time to post more on this, but let's dream with me a little more...

What about bringing in the DAC repository, the Informatica repository, the Siebel CRM repository (right-click on a Siebel applet and see a report which describes all BC fields, columns and tables and their mapping to Oracle BI)...whoa...just woke up

have a nice day