Posts filed under 'Workflow'

Workflow to process multiple rows

There’s no standard loop construction (For/While/Do) in Siebel Workflow, but there are still a couple of ways to have a Workflow Process handle multiple rows.

Update Operation

For a simple update to a child entity use a Siebel Operation. When a Workflow Process has a Business Object then a Siebel Operation Update step defined for a child Business Component will update all records that are children of the selected record in the Primary Buisiness Component. The update can be filtered to specific records by specifying  a SearchSpec on the Update.

This technique can be expanded through the use of Runtime Events: define an Event on the child BusComp to catch a simple update operation and trigger further processing of the record.

Siebel Update Workflow

Bear in mind that for this to work then the Object Id process property must specify a valid record in the Primary Business Component. Also, watch out for this gotcha if you’re trying to dynamically update a field.

Sub Process SearchSpec

An alternative way to process more complicated actions is to call a sub-process for multiple rows. In this case a Workflow Process is defined as normal to act on a single record specified through the Object Id. Then to have this workflow run for multiple rows, define a new ‘wrapper’ workflow and add a Sub Process step to call the original process. To this Sub Process step add the Input Argument SearchSpec, supplying a search specification through the Value in the normal way.

When the wrapper workflow is executed, the SearchSpec is applied to the primary Business Component of the sub-process and the child workflow is run once for each row returned.

Siebel Sub Process Workflow

9 comments August 6th, 2008

Defining Workflow Process Properties

Okay, time for a rant. This is bugging me.

I spend a lot of time with Workflow: EAI work kind of forces that on you. Any moderately complicated workflow process always ends up needing a stack of workflow process properties. The vanilla processes Siebel provide are good examples of this phenomenon. This is understandable, and equivalent to a scripted function justifiably defining a bunch of local variables. So here’s the thing: when working with processes, why do I always see all the process properties defined to be ‘In/Out’? This is equivalent to a scripted function putting every local variable into the function definition. Crazy talk!

For those who don’t know, the In/Out parameter on a process property defines the purpose of the property. The values are In for input properties, Out for outputs, In/Out (the default) for properties that both accept and return a value, and None for those variables just used internally by the process. Pretty clear cut. Setting this parameter properly makes the workflow easier to understand – particularly helping when calling the workflow as a sub-process. Leaving it as the default In/Out value is lazy config, and I’ve seen too much of it. So there. Someone pass the message on to the developers inside Siebel, please.

P.S. While we’re at it: how about using process property types other than ‘String’ and ‘Hierarchy’ – and that ‘Integration Object’ parameter is pretty useful too…

3 comments March 3rd, 2008

Synchronous Wait Steps

This one caught me out just recently while I was building a business process to poll a service every couple of seconds. Seemed simple enough: add a Wait Step to my flow, set MeasureUnit to Seconds and duration to 1, then call my service and loop back to the Wait under certain conditions. In my example I want the flow to fail if the service doesn’t complete after half a dozen attempts, so I set the Maximum Iterations property on the service step to 6 and handled the error that occurs on the 7th attempt. The workflow should run synchronously in the Application Object Manager, with the UI waiting for a response.

According to all documentation this should have worked, but instead the workflow was immediately returning a response to the UI the first time it hit the Wait Step. The workflow was continuing on exactly as expected in the background, but it appeared that Siebel was automatically persisting the workflow, making the flow asynchronous.

Took a bit of digging around, but the solution was to change the Mode of the business process. In Interactive Flow or Service Flow mode the Wait step causes the flow to move out of the UI context, but in good old 7.0 Flow compatibility mode it works as expected, blocking the UI until the workflow completes.

Doesn’t fit in very well with Siebel’s mandate of not creating new 7.0 Flows, but what can you do when there are bugs..?

August 17th, 2007

Order of Events

A quick list, for reference:

  • Runtime Applet.PreInvokeMethod
  • Browser Applet_PreInvokeMethod
  • Server WebApplet_PreInvokeMethod
  • Runtime BusComp.PreInvokeMethod
  • Server BusComp_PreInvokeMethod
  • Runtime BusComp.InvokeMethod
  • Server BusComp_InvokeMethod
  • Runtime Applet.InvokeMethod
  • Server WebApplet_InvokeMethod
  • Browser Applet_InvokeMethod

Essentially, the Runtime Event occurs before the equivalent server script event for the same object, plus the Applet browser script events ‘wrap’ all server side events.All of which makes perfect logical sense, but it’s sometimes handy to see it written down in a list.

4 comments July 19th, 2007

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.

3 comments May 22nd, 2007

Previous Posts


January 2015
« Aug    

Posts by Month

Posts by Category