Select Page

Aspect User Properties

While researching a requirement to pre-default a field value based on the applet, without cloning the underlying BC, I came across “Aspect User Properties”. I’ve never come across these before but they are a really useful tool in the configurators arsenal to accommodate user requirements while avoiding eScript.

Aspect

You can find more information in Siebel Bookshelf, but the premise is really straight forward: you define BC / Field level Aspect User Properties (AUP) that encapsulate some sort of functional requirement:

BC: Action
Field: Type
Field User Property
Name: Aspect Default Value: MyDefault
Value: LookupValue(“TODO_TYPE”,”My Default”)

You then refer to that property from other aspects of the UI, for example via an Applet User Property:

Name: View Aspect: My Activity List View
Value: MyDefault

It’s a simple as that – control of the BC functionality via UI objects, without the need to clone or use scripting.

I’m going to dig further into the capabilities of AUPs in the coming weeks and will post any additional findings for your viewing pleasure.

Siebel Constants – COM and Java

As a big fan of the COM interfaces and the Siebel Java Data Bean, I’ve messed around a lot with invoking Siebel methods from outside the application. The type libraries supplied with Siebel make this very straight forward, but something that isn’t captured in there are the ‘Siebel Constants’.

SiebelConstants

I’d always assumed that anything that was effectively true or false could be translated as 0 or 1 respectively. Others, such a ViewMode, I just remember form the old days as being 0 to 3, 3 being ‘AllView’. One mistake I’ve made is assuming that ForwardOnly was 1 – not the case!

A quick look in Siebel Bookshelf reveals the true values of the Siebel Constants:

ConstantInteger Value
ContinueOperation1
CancelOperation2
ForwardBackward256
ForwardOnly257
NewBefore0
NewAfter1
NewBeforeCopy2
NewAfterCopy3
SalesRepView0
ManagerView1
PersonalView2
AllView3
OrganizationView5
GroupView7
CatalogView8
SubOrganizationView9

I’ve had to make a hasty update to my C# and Java Tools – I wonder if the performance of my Repository Analyser was affected by an invalid ExecuteQuery invocation?

Ideally, Oracle should ship a static class with these constants predefined: perhaps in Siebel 9.0? If you can’t wait that long, you can download a Class definition for C# from The Siebel Store!

Exception Framework

A fellow Blogger, Jason, recently posted an article on creating an Exception Framework. I’ve also just started on a new engagement where my colleagues are building such a framework themselves. I still struggle to understand why Oracle haven’t built this into core Siebel yet!

ErrorLogOpenUISmall

Anyway, I thought this would be an ideal opportunity to demonstrate the true potential and purpose of the Siebel Store – to commoditise Siebel code and configuration.

As such, I’ve put together a very simple Exception Handling Framework for Siebel 8.x. The solution comprises a custom table, BC, BO, Applets, a View and Screen and a Business Service to provide a basic framework for logging and management of unexpected behaviour or debugging in your Siebel solution.

The package comes with a SIF file to import, a COM loader ready to load LOVs and some simulator files to test it all out in your environment. The idea is that it’s a complete package of functionality that you can bring into your Repository and use it immediately.

ErrorLogOpenUIStore

I’ve taken the unprecedented step of adding this to the store as a paid for download – the mighty sum of 49 Great British pennies (that’s 78 US cents or 60 Euro cents). A bargain, I’m sure you’ll agree, but more an interesting experiment to see if anyone really does want to spend money on Siebel code.

 

Workflow Process Properties and Data Maps

Data Maps are brilliant – anyone familiar with the eScripting required to do any sort of IO mapping in the days of Siebel 6 will surely agree!

Data Maps are also really flexible and offer more features than you might be familiar with. Something I had to do recently was directly pass in a process property from a calling Workflow and use that value in the Data Map. Here’s how it’s done.

Workflow Process

  1. Define a Process Property in your calling Workflow, for example TestValue
  2. In your call to the EAI Data Transformation Engine.Execute method, pass your process property in as an Input Argument.
    • You’ll have to manually enter the input argument as it obviously isn’t available in the drop down

Data Map

  1. In the Data Map Editor, create the IO and IC mappings as usual
  2. Create your IC field mappings as you normally would
  3. Now, where you want to refer to the Process Property that’s been passed in, simply use the notation: [&PropertyName]

Easy peasy!

Siebel Gateway Comparison

Something that has always bothered me about Siebel (apart from Workflows) is that migrating Enterprise Configuration between environments is a real pain. The pain can, of course, be mitigated by stringent Configuration Management control of changes to the environment via Server Manager scripts. However, in some cases we have to resort to the UI – for example, for some reason you cannot define a sub-system full name or description via srvrmgr, and we lose control of changes made in environments.

As part of a Siebel 8 upgrade, I came across a useful tool that’s installed with the Siebel Server – cfgmerge.exe. It’s a horribly named application but what it basically does is to compare two SIEBNS.DAT files and generate a srvrmgr script to make up any differences.

It has it’s share of problems but we’ll get to those.

Usage is straightfoward:

For Enterprise level differences:

cfgmerge.exe -l <LANGUAGE CODE> -i <OLD SIEBNS>,<NEW SIEBNS> -e <OLD ENTERPRISE>,<NEW ENTERPRISE> -o <OUTPUT FILE>

For Server level differences:

cfgmerge.exe -l <LANGUAGE CODE> -i <OLD SIEBNS>,<NEW SIEBNS> -e <OLD ENTERPRISE>,<NEW ENTERPRISE> -s <OLD SERVER>, <NEW SERVER> -o <OUTPUT FILE>

The output file is a well annotated list of srvrmgr commands to bring your new Enterprise in line with the old.

However, and this is a major issue for me, it will only compare component and profile definitions that already exist. That is, it will not generate create component statements for your target environment if components from the source are not there already. I don’t know why, as this would make migrating Enterprise Config as part of an upgrade project a doddle. As it is, you have to at least create the component and profile / sub system definitions in the target enterprise before you run the commands.

Perhaps now is the time to dust off those srvrmgr scripts and get everything up to date…