A requirement I’ve come across time and again with clients is to automatically generate correspondence via a Workflow or eScript. When automation is the key time and money saver, it’s frustrating for users to have to manually generate correspondence merges using eDocument – why can’t it be automated?
Oracle have made things difficult by driving the generation and submission process from Applet class methods: OnGenerateHTML and OnSubmitHTML. The UI context implied by these methods and their Applet class (CSSFrameListFulfilment) all point to a lack of support for automation.
Generating and submitting a request, with logging turned up on the eDocument component, reveals some interesting information. Specifically, the document server invokes a number of methods on a “Document Generator” Business Service. Now, Oracle state that this is an undocumented Business Service and that it’s use outside of the OnGenerateHTML and OnSubmitHTML methods is “unsupported”. But we’ve never let that stops us messing around, have we?
Invoking the Business Services “OnGenerateHTML” method on its own kicks off the document generation process but immediately crashes the Object Manager. However, closer inspection of the eDocument component log shows an invocation of a parameterless “Start” method, prior to calling any other methods. In our Workflow, calling this prior to the other methods seems to prevent the crash and allows us to generate requests without user intervention:
Automate Correspondence Generation in Workflow
Note that the “OnGenerateHTML” method has a single required parameter that is the ROW_ID of a “Correspondence Request” record. Simply use standard Siebel Operation steps in the Workflow to create a record, retrieve the Id and pass it to the method.
There are some great features in Siebel that can make life easier for the developer and improve the experience and ROI for the customer. It’s a real shame that Oracle chooses not to expose and document these for us to take advantage of in a supported solution. Still, it makes the discovery of these little gems all the more satisfying!
Good exception handling shouldn’t just be limited to eScript – it can and should be applied to Siebel Workflow too.
A good example is in using the new NextRecord operation step to process a set of records returned by a Query operation step. You can, as with eScript, capture and handle an exception against a particular record, log some useful output, then proceed with the remaining record set.
Just remember that exception branches don’t always have to go straight to an End step – handle the exception, do something useful and allow your application and users to carry on.
Many, many Siebel professionals will tell you that Siebel Workflow Processes trump eScript every time. From your first days at Siebel Bootcamp, you’ll be told:
- Workflow before eScript!
- Declarative before imperative!
- Simplify upgrades!
- Be a better person!
Now, I’m not wholly against Siebel Workflow and I believe that it has it’s place. It has many advantages over eScript that I’m not going to go into. However, having recently worked on a really Workflow heavy piece of development, I have some gripes that I thought I might share.
I’d love you hear your thoughts, retorts and experiences!
1. Workflow in Siebel Tools is BUGGY
Working with complex, multi-tier Workflows in Siebel Tools is an absolute nightmare: Siebel Tool 8.x is just so buggy! Some examples: ever run the Simulator on a complex Workflow only to be instantly told ‘Simulation Complete’ or ‘XML Parsing Error’? If so, you’ve hit a common Tools bug – too many decisions steps (8? 16? 42?) cause this and there is no fix as of 18.104.22.168. Ever renamed a Workflow branch only for another branch to be updated instead? Bug. Ever closed and opened a Workflow only to find all your connectors missing or in the wrong place? Bug. Ever lost your watch windows and had to wipe the registry to get it back? Bug. Create an exception step and forget to name it? Tools won’t tell you – it just won’t let you create any more connectors. BUG! Over a decade of development and the Siebel Tools component probably gets the least attention from Oracle when it comes to fixing bugs.
2. Workflow is often difficult to debug
This is the worst issue for me. Using the simulator to step through simple Workflows is fine; stepping through complex Workflows, using aliases, eScript Business Services and sub-processes is just painful. Aliases don’t appear in the watch windows, so you can’t tell if your xpath is right or wrong. The Workflow Simulator will not invoke the eScript debugger, so scripted business services can’t be debugged in parallel. There is no ‘step into’ mechanism to debug sub-processes so there’s no way to step through an entire process. The /s spool switch is ignored so you have to use environment variables to debug the SQL output. In it’s defence, Workflow Instance Monitor is a brilliant piece of functionality but it really just sits in the background. The Tools debugger should be better.
3. Workflow behaviour can be confusing
Query context and BO / BC context is easy to visualise and manage in script; it is much harder to manage within Workflow. Call a sub-workflow in a child recordset loop within a parent Workflow and watch what happens if you tinker with the parent BC: the child record pointer resets and you end up in an infinite loop. Amend a record the wrong way in a child record loop, which conflicts with the child search spec, and watch the record pointer reset again. Try working with mutliple instances of the same BO, for example to replicate ‘deep copy’ across multiple child BCs and see how far you get. Workflow will also make you go against everything you learned about performance by forcing you to use ForwardBackward in Query steps if you want to do anything with the records returned. Building sub-workflows for re-use is a great idea, but be wary of the impact of context on the calling Workflow. I’m not saying there’s anything wrong with how Workflow manages the scope of objects or query contexts, it’s just that understanding what’s happening in the big picture is, I find, much easier in eScript.
4. Workflow can lead to Run Time Events
Run Time Events are not my favourite mechanism for triggering Workflow. These things are, generally, a nightmare: set one to trigger on SetFieldValue and try creating a new record. The RTE will fire with no actual record context (as the record hasn’t been created yet) and pass null to the Object Id of the Workflow you’re calling. Not good if you then try to do anything with the values from the created record. And don’t be tempted to set the ‘Event’ property of the start connector on your Workflow: this will create an RTE who’s name is the ROW_ID of the deployed Workflow instance. Nothing like hunting down ROW_IDs when trying to figure out why functionality is being triggered. Stick with Workflow Policies if you must go down this route. Again, I guess RTE’s can have their place (I’ve just yet to find it) but at least you know where you stand with the scripting event model.
5. Workflow is still not as feature rich as eScript
With the introduction of the NextRecord step in Siebel 8, Oracle have narrowed the functionality gap between Workflow and eScript somewhat: at least now you can loop through recordsets. Oracle are also starting to provide and document more and more out of the box Business Services to use in your processes, though a number of popular ones are still strictly undocumented. However, powerful eScript features such as access to clib, custom BC methods such as SetAdminMode, Assoc and Pick and other scripting constructs still draw me to script solutions. I have very rarely been able to completely implement highly complex functionality through declarative Workflow alone – if nothing else, I’ll end up writing code in a Business Service that will form part of the overall Workflow.
So, my rant is over. Please share your thoughts in the comment box or simply vote using the buttons below!
A couple of posts back, we set up an Enterprise Profile that is used by our Server Component to dispatch inbound MSMQ messages to a Workflow. Such a Workflow will look something like this:
Nothing here should surprise you, as this is a pretty standard inbound EAI workflow that:
- Takes the XML text, from a Process Property named XML, and converts it into an Integration Object instance
- Uses a Data Map to map the external IO to the internal IO structure (I’ve used Contact IO again here, just for simplicity)
- Uses the EAI Siebel Adapter to apply the internal IO instance to the business layer
In terms of MSMQ, there is one crucial aspect of this that I need to highlight:
The Process Property ‘XML’ should be a binary type and have a default string value of ‘<Value>’ – this will ensure that the component passes in the MSMQ message text (the XML) to the correct process property
Testing this is straight forward, once the Workflow has been deployed to the server database. We can simply:
- Take the XML from the siebeloutbound queue that we worked on previously
- Use an MSMQ test harness to put the XML message on the siebelinbound queue
- Watch our new server component pick up the message, pass it to the Workflow which will then insert a new contact
As you can see, using MSMQ to handle message delivery is really quite straight forward. It sits comfortably along side the standard Siebel EAI components and functionality, meaning it takes very little additional effort to employ it in your infrastructure.
If you have any questions or comments about this, please let me know.
Another odd piece of configuration cropped up the other day:
I can see the developers thinking but the decision step is not limited to two branches. A far neater solution would be:
Siebel Workflow can be really powerful but Workflow Processes can become cumbersome and complex very quickly if developers don’t put some effort into streamlining.