Thursday, September 9, 2010

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.

Friday, September 3, 2010

Targets for MySAP : No targets configured for this adapter.

This is a common error when configuring/working with SAP adapter. The error is seen while running composite BPEL processes which try to connect to SAP or from the iwafjca page.
http://hostname:port/iwafjca/service.jsp

Targets for MySAP
No targets configured for this adapter.

If you have SAP Channels configured for inbound events from SAP to BPEL then you may see errors like below :

SEVERE IWAFManagedConnectionFactory com.iwaysoftware.afjca15.AbstractResourceAdapter endpointActivation(194) An Exception was caught while activating the endpoint
java.lang.IllegalArgumentException: Channel 'SalesOrder_Channel' not available for adapter 'MySAP'.
at com.iwaysoftware.af.container.ChannelManager.checkConfig(ChannelManager.java:421)
...
...
Make sure your ra.xml file under SOA_HOME/soa/thirdparty/ApplicationAdapters/iwafjca.rar/META-INF directory has config properties IWayHome and IWayConfig set correctly. The above errors indicate that the adapter is not able to read the information in repository (file/db).

Check in your configuration folder SOA_HOME/soa/thirdparty/ApplicationAdapters/config/YourConfigName/ if there are multiple files like repository.xml1, repository.xml2 etc in addition to repository.xml. Similarly check if there are multiple st_repository files like st_repository.xml1, st_repository.xml2 in addition to st_repository.xml.

In that case, you might have done some CRUD operation when the iwafjca.rar is deployed and running. When ever you are doing CRUD operations in iwae, please make sure the iwafjca.rar is not deployed or is in inactive mode especially when you are using file repository.

To fix the errors :

1. Make sure your repository.xml contains correct target information.
2. Then redeploy the iwafjca.rar from admin console
3. Restart the managed server. It should work now !

Wednesday, September 1, 2010

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 !