Siebel Essentials

Most valued readers of my blog at blogs.oracle.com.

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:

focus yourself

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...

...welcome back to Part II of our tour de workflow

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

Recently, I had to do some prototyping for typical requirements which led me to the Siebel Workflow framework as a solution.

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.

Just wanted to share a link to a most useful resource with you:

once and for all

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

This is an update to a previous post on data lineage in Oracle BI EE.

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.

Introduced in Siebel 7.7 and greatly enhanced in 7.8, the Quick Print feature allows end users to bring the data they see in the Siebel view to paper (or Excel, HTML or - if a pdf writer is installed - to PDF).

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

Change

After giving good ol' Free Download Manager (yes this is an official editor's choice recommendation for really cool freeware - see below for more kudos) a sleepless night, I was able to embark on a rather ritual ride of uninstalling the old version of my typical 3-pack of Siebel Developer Web Client, Sample Database and Tools (that is 8.1.0 - dot zero) and replacing it with the latest (8.1.1 - dot one) to have a first sniff.
There are some remarkable differences between those two versions which I would like to share with all you early adopters out there.

Given the fact that 8.1.0 was never released under general availability, only a few selected humans might ever had an eye on it. Another fact is that 8.1.0 was available under certain limitations for selected customers for example to prepare an upgrade to 8.1 or to evaluate the revamped Loyalty module (now the fourth pillar of Siebel CRM among Sales, Service and Marketing).

I also downloaded the fresh-from-the-oven 8.1.1 bookshelf and made my way through some very recommended literature, the "What's New in this Release" chapters of the guides that are relevant to you (e.g. Installation Guide).

These are the first details I am posting on 8.1.1 and I am quite sure that more posts will follow.

SIA (Siebel Industry Applications aka Verticals) and SBA (Siebel Business Applications aka Horizontals) released separately

The Network Image Creator, which you still need to launch after unpacking all those .jar files does not allow you to choose between SBA and SIA. The package you download from edelivery.oracle.com is limited to one of the two. 8.1.1 is a SIA release (containing the Loyalty pillar).

Oracle Universal Installer for Developer/Mobile Web Client and Siebel Tools

The first thing you will have to say "Hello" to is the oui.exe which launches Oracle Universal Installer. OUI now takes care of installing and configuring the Siebel Developer/Mobile Web Client and Siebel Tools. Not too weird as it prompts for the same parameters as the old Installshield wizard did. However oui leaves a mark of several directories in the client's and tools' installation folders.

Oracle Universal Installer busily installing Siebel Developer Web Client, the ad to the right is for Database 11g, not for the Client ;-)

Actuate replaced by BI Publisher

When I browsed through the Installation Guide for Windows, I noticed a statement that left me somewhat worried:

"The Actuate products formerly provided as Siebel Reports Server are no longer shipped with or supported by Siebel CRM version 8.1 or later. Reporting functionality is now available using Oracle Business Intelligence Publisher."

This two-sentence statement means a lot of work ahead for all those customers who invested (sometimes heavily) in Actuate reports. Oracle announced its decision to say goodbye to Actuate quite early and version 8.1.0 actually supported both reporting tools side by side.

But this short-lived and rarely known coexistence is now over and I feel a little worried about the projects with hundreds of heavily scripted Actuate reports given the fact that an automated migration from an Actuate rol/rod/bas/rox mix to a BI Publisher template is highly impossible. If anyone has more positive news on migrating from Actuate to BI Publisher please share your knowledge in a comment.

[Update 2]: The Siebel CRM 8.1.1 Planned Features/SOD document (login required for metalink3) states the planned availability of an Actuate to BIP Migration Tool as part of the BI Publisher server. Stay tuned for updates on that.

[Update 3]: As Anonymous points out in his/her comment to this post, Actuate is still supported for existing Siebel customers. I hope there will be more official clarification on that as there might be the need for some extra patches for existing customers (as the installers from edelivery have no Actuate binaries with them - neither for the Mobile/Developer Web Client nor in form of the Siebel Report Server). As the Siebel CRM 8.1.1 Planned Features/SOD document (login required for metalink3) points out, there will be support for Actuate 8 until end of 2009. The document mentions "Post-2009", see below. Customers with earlier Actuate versions will need to upgrade to Actuate 8.

I haste to state that I'm a big fan of BI Publisher and consider it the ideal choice but maybe the decision to cut the support for Actuate so quickly was a bit hasty.

In version 8.1.0 it was possible to set the System Preference ReportEngineType to BOTH (which is still the default setting in the sample database for 8.1.1) but in 8.1.1 there are no Actuate binaries available, so BIP is the only thing left to create reports.

The already obsolete ReportEngineType System Preference is still set to BOTH in the sample db.

Let me conclude this post with two more statements from bookshelf and join me in saying farewell to the Siebel Update Server and the CTI simulation.

"Siebel Update Server and Siebel Update Client are no longer shipped with or supported by Siebel CRM version 8.1 or later."

"Siebel CTI Connect is no longer supported as of the current release. CTI Simulation, which used the CTI Connect driver and configuration data, is also no longer supported."

Casey Cheng is no longer able to demonstrate CTI functionality, note the error message

It has been a view years or Siebel versions that a nice little feature named "Rapid Unit Test" has been introduced. If memory serves me correctly it was 7.5.3.2xx. The feature allows you to start a compile in Siebel Tools while the Developer Web Client (siebel.exe) is still running.

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