AIA 3.0 : Service Constructor support for DB adapter and JCA adapters.

As per the AIA developer's guide
"Currently the Service Constructor supports only services that have an exposed interface and cannot yet directly invoke JCA adapters such as the File or DB adapter."

Incase you want to invoke DB adapter in your ProviderABCS or receiving DB records in your RequestorABCS, the Oracle recommended way is to create the adapter as a separate composite and use the same in your AIA Service Constructor.

I came across a similar situation where my RequestorABCS had to be kicked off when SAP sends an idoc (via SAP Channel) or if I had to poll records from a DB table. In both cases I had to create the SAP adapter/DB adapter as a separate composite and invoke the RequestorABCS wsdl from there.
This approach also ensures reusability of the adapter composite code incase other ABCS want to use it.

AIA Error Handling: Trace Logging feature

Trace logging in AIA is enabled via configurations in the AIAConfigurationProperties.xml file located in <AIA_HOME>/aia_instances/$INSTANCE_NAME/AIAMetaData/config directory.

Logging can be set at the system or service level. The logging property set at the service level overrides the property set at the system level. To enable trace logging for the entire system follow below steps:

1. Access the AIAConfigurationProperties.xml file.
2. Set the TRACE.LOG.ENABLED property at the system level to true.
3. Update the file back to MDS
4. Reload updates to AIAConfigurationProperties.xml from configuration page of AIA Console.

In the BPEL code, trace logging is added by inserting Java Embedding activities. These activities basically call the AIA trace logging functions : isTraceLoggingEnabled and logTraceMessage. If you are using AIA Service constructor for ABCS development, this piece of code is auto-generated for you.

The Oracle AIA trace and error log files can be accessed from EM Console or directly from file system:
$MW_HOME/user_projects/<domain_name>/servers/soa_server1/logs/aia-error.log
$MW_HOME/user_projects/<domain_name>/servers/soa_server1/logs/aia-trace.log

The logging level like logLevel Severe, Warning, Info, Fine, Finest etc. can also be configured from EM Console.

AIA Error Handling : WSDL messageType "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage" is not defined

In my next couple of posts I will be covering AIA Error handling and trace logging features. Below screenshot depicts how a typical AIA fault handler section looks in ABCS(BPEL). We have catch blocks for handling partner link errors like remote/binding fault and we have a catch-all block which deals with non-partner link errors.

Now remote/binding faults are fault-policy driven. These fault policy files have specific actions defined like ora-retry and ora-java-action which take care of retrying the error and sending error emails. (More details in my next post) During an invoke activity, when a binding/remote fault occurs , the underlying fault management framework of the Oracle SOA catches the fault and performs actions as defined in the associated fault policy and then rethrows the fault back to the catch blocks. Now, the catch activity in the BPEL should process the fault and as part of fault processing it has to rethrow the fault back inside the catch block,so that transaction roll back happens correctly and instance appears as faulted in console.

A common error seen while trying to compile ABCS code after adding fault handlers is :

Error(90): unresolved messageType
WSDL messageType "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage" of variable "SystemFaultVar" is not defined in any of the WSDL files. Make sure the WSDL messageType "{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage" is defined in one of the WSDLs referenced by the deployment descriptor

To get rid of above error follow below steps:

1. import oramds:/soa/shared/bpel/RuntimeFault.wsdl into your process.wsdl

<wsdl: import namespace="http://schemas.oracle.com/bpel/extension" location="oramds:/soa/shared/bpel/RuntimeFault.wsdl"/>

2. Create a variable(SystemFaultVar) based upon the messagetype RuntimeFaultMessage in this wsdl.

<variables>
<variable name="SystemFaultVar" messageType="bpelx:RuntimeFaultMessage"/>
</variables>

3. In the catch branch use the RuntimeFaultMessage as the Fault Variable

<faultHandlers>
<catch faultName="bpelx:bindingFault" faultVariable="SystemFaultVar">
...

4. Also make sure in your composite.xml, you import the RuntimeFault.wsdl before importing the process.wsdl

Try compiling and deploying the process. It should work fine now !

Dependent SCA composites fail with "503: Service Unavailable for url" after server restart

We often design composite applications that invoke other composite applications. A typical use case would be AIA artifacts where RequestorABCS calls EBS which in turn calls ProviderABCS.

If these are not configured correctly then after restarting SOA server the one having dependency does not work any more. Basically issue is with the order in which SOA server re-deploys these composites. You may see the below error message in EM console

The composite SalesOrderRequestorABCS (1.0) is not available. This could happen because either the composite has been undeployed or soa-infra has not yet loaded this composite.
[JCABinding] [SalesOrderRequestorABCS/1.0]Unable to complete load due to: Error in getting XML input stream: http://hostname:port/soa-infra/services/default/SalesOrderEBS/SalesOrderEBS_ep?WSDL: Response: '503: Service Unavailable' for url

The recommendations to avoid dependencies between composites are :

1. In the composite.xml of the calling composite have the import refer to an abstract wsdl and
not a concrete one to avoid loading issues.
2. Make sure you refer to the MDS location for common XSDs, WSDLs and deployed composites.

For example in case of RequestorABCS if you are having references to end point URL of EBS(obtained from EM console after deployment of EBS) then make sure you change that to oramds location for abstract WSDL.

FROM

<import namespace="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2" location="http://hostname:port/soa-infra/services/default/SalesOrderEBS/SalesOrderEBS_ep?WSDL" importType="wsdl"/>
<reference name="SalesOrderEBS" ui:wsdlLocation="http://hostname:port/soa-infra/services/default/SalesOrderEBS/SalesOrderEBS_ep?WSDL">
<interface.wsdl interface="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.interface(SalesOrderEBS)"/>
<binding.ws port="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.endpoint(SalesOrderEBS_ep/SalesOrderEBS_pt)" location="http://hostname:port/soa-infra/services/default/SalesOrderEBS/SalesOrderEBS_ep?WSDL"/>
</reference>

TO

<import namespace="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2" location="oramds:/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/SalesOrder/V2/SalesOrderEBSV2.wsdl" importType="wsdl"/>
<reference name="SalesOrderEBS" ui:wsdlLocation="oramds:/apps/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/SalesOrder/V2/SalesOrderEBSV2.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.interface(SalesOrderEBS)"/>
<binding.ws port="http://xmlns.oracle.com/EnterpriseServices/Core/SalesOrder/V2#wsdl.endpoint(SalesOrderEBS_ep/SalesOrderEBS_pt)" location="http://hostname:port/soa-infra/services/default/SalesOrderEBS/SalesOrderEBS_ep?WSDL"/>
</reference>

Similarily if you are referring to ProviderABCS from EBS composite.xml of EBS will look something as below

<reference name="SalesOrderProviderABCS" ui:wsdlLocation="oramds:/deployed-composites/SalesOrderProviderABCS_rev1.0/SalesOrderProvABCSImpl.wsdl">
..
..

Configuring MDS in AIA 3.0

AIA 3.0 or AIA 11gR1(rechristened name) brings along with it a lot of changes in comparison to earlier AIA 2.x releases, the most prominent being the way to access AIA artifacts. I have worked on AIA FP 2.x and accessing artificats like WSDLs , XSDs inside the code from Enterprise Object Library or Enterprise Business Service Library was done using http urls eg: http://hostname:port/AIAComponents/EnterpriseObjectLibrary/core/EBO/Invoice/V2/InvoiceEBO.xsd. When migrating between instances i.e Dev to QA to Prod we had to make sure the deployment scripts changed the partner link bindings in bpel.xml to change the http urls.


Now when I started development on AIA 3.0 the first thing I wondered was how to access these artifacts inside code because the AIAComponents folder was no longer hosted on http. I hadn't explored the new concept of MDS(Metadata Service) yet and hence thought of using a workaround. I created a war file out of the AIAComponents folder jar -vcf AIAMetaData.war $AIA_HOME/AIAMetaData/AIAComponents
I then deployed this war file into my weblogic server as an application and Enabled Index Directory. Now I was able to access the entire AIAComponents folder from URL again. 


However I started to think about the maintenance aspect of the above approach. If I had to modify any artifact or add a new one later then I had to place the file in relevant location under AIAComponents, regenerate the war and redeploy it to WLS. Secondly during code migration between instances I had to repeat this task on each server and also make sure my deployment scripts ensure proper URL replacement. Definitely doesn't sound like an Oracle recommended approach which made me search for better alternatives and I then stumbled across the concept of centralised repository called MDS. The MDS is metadata store which stores all AIA artifacts under AIAComponents folder and these are accessed inside code using oramds protocol.


In this post I would like to cover the details of how to setup Jdeveloper to create SOA-MDS connection, how to go about accessing the artifcats inside code and how to update/add artifacts into MDS.


Setup in Jdeveloper :


1. Create a database connection to connect to the repository with either DEV_MDS or equivalent user (prefix_MDS).
2. Then from resource palette create a new SOA-MDS connection. Make sure it uses the DB connection in step1 and also the partition is soa_infra.
3. Once completed you should be able to browse and choose the required AIAComponent files from MDS. These will be shown under /Apps/MetaData.
4. Next you have to update the adf-config.xml file in your Jdeveloper, application home (directory where .jws file exists). This will be used at design time to access files from MDS using oramds protocol. This is located in directory named .adf/META-INF.
    
  Make sure you add the below sections:
      <metadata-namespaces>

          <namespace metadata-store-usage="mstore-usage_2" path="/apps" />

      </metadata-namespaces>

     <metadata-store-usage id="mstore-usage_2">

-        <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">

         <property value="DEV_MDS" name="jdbc-userid" />

         <property value="welcome1" name="jdbc-password" />

         <property value="jdbc:oracle:thin:@hostname:port:sid" name="jdbc-url" />

         <property value="soa-infra" name="partition-name" />

     </metadata-store>

     </metadata-store-usage>

Thats it! You can now start accessing the artifacts like WSDLs, XSDs etc using oramds. Eg: oramds:/apps/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/core/EBO/Invoice/V2/InvoiceEBO.xsd

How to update/add artifacts into MDS:

These have to be repeated every time new/modified files are to be loaded to MDS.

1. source AIA_HOME/aia_instances/instance_name/bin/aiaenv.sh

2. Modify the AIA_HOME/aia_instances/instance_name/config/UpdateMetaDataDP.xml

<?xml version="1.0" standalone="yes"?>

<!-- Do not modify the contents of this file manually -->

<DeploymentPlan component="Metadata" version="3.0">

        <Configurations>

                <UpdateMetadata wlserver="fp" >

                        <fileset dir="${AIA_HOME}/AIAMetaData">

                             <include name="AIAComponents/EnterpriseObjectLibrary/Core/Custom/EBO/Invoice/V2/*"/>

                        </fileset>

                </UpdateMetadata>

        </Configurations>

</DeploymentPlan>

NOTE:

 The path in "include" tag has to be relative to what is given in "fileset" tag. 

3.Run the below command to load the files to MDS from AIA_HOME/Infrastructure/Install/scripts

ant -f $AIA_HOME/Infrastructure/Install/AID/AIAInstallDriver.xml  -DDeploymentPlan=AIA_HOME/aia_instances/instance_name/config/UpdateMetaDataDP.xml -DPropertiesFile=AIA_HOME/aia_instances/instance_name/config/AIAInstallProperties.xml