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 8th, 2007
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 1st, 2007
A first contribution from elsewhere! Outstanding. Nathan kindly offered this note in return for ‘getting famous’. Not sure I can help with that, but everyone has to start somewhere…
I did this trying to prototype a problem I had for an interface I was working on. When you setup a Workflow Process you must assign it a Business Object, or else a whole heap of functionality within that Workflow Process does not work i.e. you cannot select Business Components etc.
My Workflow Process was triggered by a Runtime Event, and all was fine for the UI contexts where the business component of the Workflow action matched the primary business component of the UI. However, when I was in a different business object, the Row Id passed was that of a different Business Component and so my workflow did not “flow”.
For example, upon creation of a Contact in “My Contacts”, the Row Id passed in was the Row Id of the Contact. However, when you create a Contact in Account->Contacts, then the Row Id passed in is that of the Account record.
Well, there is a simple way around this, ready for it?
Are you sure you’re ready?
Okay, here it is…
In the Runtime Event, you need to set a Profile Attribute to the current Row Id to pass into the Workflow. You can then put as many Runtime Events on as many business objects as you require, as long as it always sets that Profile Attribute for the Row Id.
Too easy. A gentle warm-up from Nathan, there’s more to come…
April 12th, 2007