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.

Configurable settings and endpoint replacements

There are multiple approaches to define configuration settings for the composite which can be changed at run time.

Configuration Settings

DVM
Pros

• Stored in MDS
• Changes are independent of deployment
• Nice UI for update

Cons

• Hard to modularize per Composite
• If managed via both UI and SVN, it can quickly can get out of sync in multiple environment.
• Not too sure about what level of caching is done

DB Lookup (may be with custom XSL)

• Probably a bit more overhead vs having things in memory

AIA Configuration Properties (More info: http://chintanblog.blogspot.com/2012/10/aia-configuration-and-dynamic.html)
 Pros

• MDS stored
• Changes are independent of deployment
• Different level of modularization - System/System Module/Service

Cons

• No UI to make changes - hopefully in future release

Preference along with config plan (More info: http://chintanblog.blogspot.com/2012/06/bpel-preference-11g.html)
Pros

• Run time changes via Mbean browser and changes can withstand server restart

Cons

• Modularization is not flexible (e.g. two composite cannot share same property)
• Changes via MBean are still temporary. Deployment will overwrite changes from composite (or config plan).
• Have to keep config plan in sync with UI changes

Code migration and reference to end point URL
Custom search/replacement
Pros

• Much better control, as it is raw search and replace

Cons

• Custom scripting
• Unless it is highly sophisticated, search term has to be known in advance

Configuration Plan
Pros

• OOTB, and it is xpath based replace so no need for search term

Cons

• have to manage one per env
• If composite is constantly changing, it is really hard to manage multiple plans
• No support for runtime URL change

Dynamic Partnerlink Lookup (DPL) - using AIAConfig (More info : link)
Pros

• Centralized config for all end points (and preference) - better governance
• OOTB functions for lookup and merge during deployment
• Just one MDS stored file

Cons

• Changes requires MDS update via script and reloading via AIA console
• No UI to make changes - hopefully in future release
• Only supported in AIA, if not AIA, need to have custom XSL function to support same functionality

Oracle Service Registry (OSR)

• It's dead, man, get over with it.

AIA Configuration and Dynamic Partnerlink Lookup in 11g

All AIA functions are documented at : http://docs.oracle.com/cd/E23549_01/doc.1111/e17364/apndxxpaths.htm, however to deal with AIA config file, I think three functions comes most handy:  

• aia:getSystemProperty 
• aia:getSystemModuleProperty 
• aia:getServiceProperty  

Properties in AIA Configuration file are modularized at three levels and there are three separate functions to retrieve those properties. Below is example:


Preference can be stored at System, System Module or Service level. Endpoint URLs for specific composite are usually stored at Service level, however it can be stored at Module or System Module level for a specific use case.

Here is BPEL code to read the configuration:

    <assign name="Demo_Assign_AIAConfig">
      <copy>
        <from>aia:getSystemProperty('Routing.ActiveRuleset',true())</from>
        <to>$SystemProperty</to>
      </copy>
      <copy>
        <from>aia:getSystemModuleProperty('ErrorHandler','COMMON.ERRORHANDLER.IMPL',true())</from>
        <to>$SystemModuleProperty</to>
      </copy>
      <copy>
        <from>aia:getServiceProperty('{http://xmlns.oracle.com/TestApplication/AIAConfigurationPOC/AIAConfigurationProcess}AIAConfigurationProcess','MyServiceProperty',true())</from>
        <to>$ServiceProperty</to>
      </copy>
    </assign>

For Dynamic Partnerlink Lookup:

    <assign name="Assign_EndpointURI">
      <copy>
        <from>aia:getServiceProperty('{http://xmlns.oracle.com/TestApplication/AIAConfigurationPOC/AIAConfigurationProcess}AIAConfigurationProcess','Routing.helloWorld.EndpointURI',true())</from>
        <to>$helloWorldEndPointURI</to>
      </copy>
    </assign>
    <invoke name="InvokeHelloWorld"
            partnerLink="HelloWorld" portType="ns1:SyncBPELProcess"
            operation="process" inputVariable="HelloWorldInput"
            outputVariable="HelloWorldOutput" bpelx:invokeAsDetail="no">
      <bpelx:toProperties>
        <bpelx:toProperty name="endpointURI" variable="helloWorldEndPointURI"/>
      </bpelx:toProperties>
    </invoke>

To update the value in AIAConfigurationProperties.xml:

• update the value and upload to MDS using usual script 
• login to http://host:port/AIA -> Setup -> AIA Configuration -> Reload