Archive for May, 2007

Sydney Siebel Meetup

For any Sydneysiders reading, Andy Simon of Cubic Resources has organised drinks for Siebel-types next Thursday. In his own words:

I specialise in the recruitment of Oracle Siebel CRM professionals for Cubic resources and intend once a month to hold a networking evening here in Sydney. The first of these will be held at the following address on Thursday 7th June at the – we have the bar from 5pm until Midnight.

Senate Bar
GPO Sydney
1 Martin Place
Sydney

The reason for these evenings are for me to get to know everyone within the Siebel market so that I become a definite specialist within the Siebel Arena. I feel that best way to get to know people would be to do it in an informal relaxed environment.

There will be a tab set up behind the bar so that the first 2 or 3 beers will be for free.

The capacity of the Senate Bar is limited, so if you plan to attend then drop Andy a line on ASimon at cubicresources.com.au.

My personal view is that anything that help foster a better local community around Siebel is to be encouraged. Compared with other similar-sized technology specialisations, Siebel has always lacked somewhat in peer support structures.

Plus, there’s free beer…!

May 30, 2007 at 9:04 am

Editing XML in Workflow

Talking about the Echo method the other day I mentioned that you can use dot notation to get at property set elements, but this is such a useful tactic that I think it’s worth revisiting.

Dot notation is what Siebel call your fairly standard ‘parent.child.grandchild’ notation. Imagine a workflow with a hierarchical process property called Employee, which has assigned to it a property set with the properties Login and Password. What dot notation allows you to do is access that Login property directly, by reference to Employee.Login. Simple enough.

This notation works both ways – so you can both retrieve and set properties. To set a property using the Workflow Utilities.Echo method, you need to have the top-level hierarchical process property assigned in the first input variable and then child properties in following variables. As an example: we want to set up the simple Employee Property Set above. We already have the LoginString in a process properties and want the Password ‘geenoos’. Create a Workflow Utilities.Echo step and assign the input variables:

Input Argument Type Value Property Name
Employee Process Property   Employee
Employee.Login Process Property   LoginString
Employee.Password Literal geenoos  

Next – as I’m sure you’ve worked out – if your Employee property set has a child property set, lets say a child PS with a type of Address and properties Street and Postcode, then the Employee’s Street can be accessed with Employee.Address.Street. You can also get at the Property Set’s Value argument, using the notation property.<Value>, which also works at all levels of the hierarchy.

This is all great, useful stuff, but the real kicker comes when you’re working with XML. XML hierarchies in Siebel are just property sets, with attributes as properties and elements as <Values>. By using dot notation in input arguments, output argument and Echo steps, you can construct and edit XML hierarchies on-the-fly, something that previously was impossible without scripting.

The one limitation of dot notation is the 75-character limit to a workflow step argument. This can kick in fairly quickly when you’re dealing with all the ListOfBusinessComponent hierarchies. The workaround is to assign a sub-hierarchy to a secondary process property, do your manipulation, then assign it back in.

May 22, 2007 at 9:37 am

Extract all repository tables

A really quick and simple tip…

When you’re running a Database Extract job for a developer, set the Extract all repository tables parameter to True to preload the database with the entire contents of the repository. This saves the developer doing a full ‘Get’ of all projects after initialising the database.

Hardly groundbreaking stuff, but one of those things that I can remember not knowing, and I can’t remember how I first found out. Maybe somebody else will find out here…

May 16, 2007 at 8:57 am 1 comment

Manipulating Workflow Process Properties

There’s every chance you’ve never heard of the business service Workflow Process Utilities method Echo. It’s under-documented, under-used and under-rated. I’d built a whole bunch of complex workflow processes before I came across it, now I ‘Echo’ stuff all over the place.

All the method does is reflect back the input arguments. Big deal, eh? The thing is, the input arguments can be expressions or business component fields or property set values or functions or anything you can usually reference from a workflow. So you can manipulate process properties without taking any other action, or you can get a current business component field value without doing a query, or you can get at property set child elements using dot notation – all things that I’d struggled to do previously without scripting.

Plenty of good examples on SupportWeb under a search of ‘Workflow AND Echo’. Note that in early versions of Siebel 7 the display name of the method is ‘Return Property Values’, plus there’s a fixable bug in 7.0.

May 8, 2007 at 9:08 am 3 comments

Detecting when a WriteRecord is New or Updated

Nathan’s enthusiatically followed up on his first contribution to eulogise about a couple of new Runtime Events…

This one is relatively simple but it is worth pointing out. Sometimes its the little things that make you weep for joy as a developer.

In the bad old days of Siebel (i.e. before 7.7), the world was running around clubbing each other over the head, saying “ugh” a lot and wearing animal skins. Then the light shone upon the world and we were given:

WriteRecordNew and WriteRecordUpdated.

These are Runtime Events that I noticed just recently. Many many times in config, you need to do something when a record is written. You place code on the WriteRecord event (so that you can avoid having to worry about the user doing Undo, stepping off a field and recorrecting etc). But then you need to do different things depending on whether the record is new or updated.

Usually what you needed to do was set some global variable when the NewRecord event fired, test that variable in WriteRecord, then clear the variable. It usually worked, but it was not elegant. I have seen implementations where the code on the WriteRecord event runs into the thousands. But we won’t mention those.

Now, the great and glorious Siebel gods have seen fit to now provide us with Runtime Events that distinguish between New and Updated records! Hallelujah brother!

May 1, 2007 at 9:17 am


Feeds