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.
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.
I thought I’d quickly cover off posting Siebel EAI messages onto our new, outbound MSMQ. It is a very straight forward process and involves a simple Workflow:
This example takes a Contact record and:
- Generates an internal integration object instance (I’ve used the vanilla ‘Contact IO’)
- Uses a Data Map to produce an external integration object instance (simple map, once again using ‘Contact IO’ as the target)
- Generates XML from this external IO
- Pops the XML onto our new MSMQ.
The key Business Service step is labelled ‘Send to MSMQ’:
Businesss Service: EAI MSMQ Transport
This Business Service takes the following inputs:
- Value – the XML process property from the generate XML step
- MsmqQueueMachineName – the name of the machine on which our MSMQs reside
- PhysicalQueueName – the name of our private MSMQ (private$\siebeloutbound)
Run the Workflow and you should see a message appear in your queue:
You can verify the contents by double clicking the message item and selecting ‘body’:
That’s all for now – next, we’ll look at processing inbound MSMQ messages via Workflow.
Have you ever come across a Workflow process that looks something like this:
There seems to be a popular misconception amongst some developers that Siebel Workflow can only have a single ‘End’ instance. Similarly, some developers believe that they can only have one instance of their ‘Error Logging’ Business Service step. The result is that every end point and every exception branch criss cross their way across the screen. A small but dedicated group of developers don’t even believe that steps and branches, especially condition branches, need to have meaningful or relevant names… The result can be a Workflow process that is very difficult to maintain and understand.
So remember: you can have as many ‘End’ or ‘Stop’ steps as you wish. You can invoke your Business Services from as many steps as you want – you don’t have to use a single step. Make good use of connector and step naming and use the ‘Text Forward’ and ‘Text Backwards’ shortcuts (CTRL + f and CTRL + b respectively) to move branch labels to a sensible place:
A well structured Workflow is much easier to understand and maintain.
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.