Defining Workflow Process Properties
March 3rd, 2008
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 Add your own
1. Graham | March 3rd, 2008 at 10:26 pm
Well the In, In/Out, Out and None flags are really only used “in anger” when defininf web services as this is what the wizard looks at when defining the WSDL.
So if you look at a Siebel web service and think there’s a bunch of arguments that are in there that shouldn’t be exposed, that’s because the developer hasn’t understood, or has been to lazy, to set these appropriately. conversely, if something is missing, that’s the first lace to look!
As the industry as a whole, and Siebel in particular is moving towards “web services for everything” it should be a best practice for these parameters to be set correctly for every workflow process, otherwise you’re storing up problems for the future! The argument “we don’t need it now so I’m not doing it doesn’t wash with me… that’s laziness talking”.
2. Mike M. Lin | March 15th, 2008 at 7:46 am
A couple caveats about data types of process properties:
1) Always using ‘String’ can lead to undesired results when using comparison operators like ‘less than’ or ‘greater than’ (think: alphabetical vs. numeric comparisons) – which you probably already knew.
2) Here’s something you might not have known… If you correct any existing processes that have the wrong data type defined, you must delete and recreate any decision branches that refer to those properties. The reason is that the decision branches themselves store process property criteria differently depending on the data type. This is evident from the database schema or the xml schema of a workflow export.
Be careful out there, because It’s a Mad Mad Mad Mad World!
3. stuandgravy | March 17th, 2008 at 12:07 pm
Great point, Mike, thanks for the info.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed