Wednesday, September 14, 2011

Infopath Integration with Siebel

I have worked out the front half of the integration with Infopath: the creation, prepopulation and launching of the infopath form. I'll write about that in a separate article. However, I've been scratching my head on the back half of the integration: saving the form and updating Siebel.

The basis of the workflow is to use Siebel as workflow and assignment. Data capture will take place in InfoPath:  the number of data capture points is very large and subject to complex rules - a perfect fit in my mind. The interesting part is how we want to push the data capture in two directions:
  1. the XML document that is generated will be stored in a Sharepoint document repository (but linked to via a SR attachment url)
  2. data captured in the form should drive elements in Siebel such as Service Request Due Date (commit time) and priority. In addition, if the data capture indicates multiple followup steps (they almost all do), then activity plans should be attached to the Service Request.
While InfoPath has a very rich object model and supports C# coding, adding any code immediately requires the form to be digitally signed. Do-able but not fun, and I don't want to start messing around with certificates, especially if non-programmers are going to be designing the forms primarily. Thus my objective with InfoPath is to be "code-free" and base all of the logic on the built in rules-engine for decision making logic.

The one limitation of the InfoPath rules when calling secondary data sources is that we are limited to setting values on nodes, not creating nodes. So for example - I have a Siebel Service Request Integration Object that has a ListOfActivityPlan node with a one to many relationship with the child activity plans, I can't create additional activity plan nodes from within the form rules, I would have to resort to code thus violating my rule above.

I thought about this one quite a while and considered a number of options:
  1. http posting the entire InfoPath form into Siebel and then writing a complex business service, or workflow to handle the logic of deciding what activity plans need to be attached.
  2. send the form to an asynchronous middleware system which could do the necessary transformations into a Siebel SR Integration object. I didn't like this one because the user might be disoriented that the plan didn't generate synchronously. This would be frustrating for the user if they had to reassign an activity but had to keep re-querying the applet until the plan(s) was/were attached.
  3. write a very simple web service interface for Siebel based on a custom (simple) external schema that allowed for one activity plan to be attached per call.
I decided on the last approach as it was the simplest and still kept the business logic in the form beside the data that drives the logic. (I'm sure there are arguments to externalizing the logic but this was the direction we went in) The one downside is that if there are multiple plans to attach, then multiple web services have to be called with the resultant performance hit. I'm willing to take it on the chin for that given the other trade-offs.

This is what I have so far:
InfoPathServices.xsd - this holds the request/response pairs for the web service. I consider this to be a contract-first approach that is in line with how Siebel is architected.

These were then added to Siebel using the new object dialog:
Then I used the Integration Object Builder. I picked a project and then I used the EAI XSD Wizard to import the integration object from the xsd file.
Pick the element that you want to import, give it a unique name in the repository, click next a couple of times and you will have some new entries in you integration object list.

I'm using a workflow for my web service, so I defined the in and out process properties to be the integration objects I just created. The image below shows what I have so far; it isn't complete because I need to create the outbound object, but it's close and it simulates well.

Note: I used the Workflow Utilities.Echo method to get the values out of the integration object. This was tricky because of the 75 character limit for "dot" notation. I used the Alias data type to define the XPath-ish retrieval pattern and I was able to get my properties.

I also know that I could have used the transformation engine to create an integration object, but that was more work than this approach. If my inbound object had more than a couple of fields I would have either used the DTE or xslt to do a transformation.

No comments:

Post a Comment