AIA 11g Infinite loop - Running instances

We saw very strange behavior in Composite generated using AIA constructor where instance were having very similar behavior as they were in Infinite loop and using lot of server resources. This problem can be very well replicated in non AIA environment but with AIA it becomes highly visible due to AIA service constructor.

Scenario 1) Polling BPEL process



With AIA service constructor, following composite XML structure is already created



If process is polling process and it has following transaction properties:

    <property name="bpel.config.transaction">required</property>
    <property name="bpel.config.oneWayDeliveryPolicy">sync</property>

It puts process in transaction and if there is any error during processing, transaction will roll back. But with polling process transaction roll back will cause message to to go back in the source (file/jms, etc), and therefore a new instance of BPEL process will get created. This behavior will cause infinite loop scenario.

The simple resolution is to just remove these properties but in case we need transaction to work, we need to make sure that appropriate error handling is done.

Scenario 2)

Regardless of process is synchronous or asynchronous, AIA error handling fault policy is always integrated for AIA process. We had configured AIA fault policy to go human intervention after CompositeJavaAction was executed. Synchronous process needs to be completed transaction timeout but if there is any error, due to fault policy it will end up in Running state.

We saw that every time we restart the server, it somehow wakes up the running instance, and invokes AIA error handling again.

I guess for this particular scenario, it was the Fault Policy in Sync process causing the issue, but we have seen many other scenarios were instance can get stuck in Running state.

OSB Reporting with Co-releation

OSB reporting seems to have performance impact as mentioned by Ahmed. However, there are not not many options when it comes to report/tracing in OSB. Alerts and logs both are file based, a bit hard to search relevant info. We wanted to report start/exit and exception activity in OSB, and to check any way to co-relate all reporting actions which are related to same instance flow.

If we have co-relation id in all request messages payload, we can probably log that, but even body variable gets overwritten with fault or response, and it becomes very hard to co-relate different reporting entry which belongs to same instance.

Here the approach which worked out for us:
Basically we used OSB's messageId as correlation id for all reporting activity.

fn-bea:inlinedXML(fn:concat('<corelationid>',$messageID,'</corelationid>'))

Now we can use corelationid in any activity we want.

At the run time, we can see correlation, and from any event we can find corelationid and then search the entire trace with any corelationid.

Composite Fault vs Soap Fault

Nothing new, but just something for my own reference as it is bit confusing how composite faults gets mapped to actual soap fault. For the majority of the Runtime Faults, SOA 11g provides following structure:



With three main attributes, summary, detail and code. If you throw fault and test it from Soap UI or any WS client, you get following result. Between composites or through fault policy, you get full access to composite fault, but it looks quite different from WS client.



Below shows how SOA engine is converting Composite Fault to SOAP fault. Basically composite.summary goes to faultstring. detail goes to exception with sub elements. Fault code in composite is simply ignored.




Fault code is in soap fault is set as env:Server. Probably http://www.w3schools.com/soap/soap_fault.asp explains this.

To understand on how it works on custom fault, I created custom fault in XSD, and exposed in WSDL in synchronous process.  Upon testing from soap ui, we can see entire Fault gets mapped to child of Soap Fault [detail]. Fault code gets populated as name of the process. Faultstring and Faultfactor shows empty.



I guess it would be better to have full control over the entire fault message.