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.
Wednesday, September 1, 2010
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
Try compiling and deploying the process. It should work fine now !
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 !
Tuesday, August 31, 2010
Date formats in SAP and Inverted date format
People doing integrations with SAP R/3 system must be aware that SAP R/3 takes in/out date fields with format of YYYYMMDD (This is their internal date format). However there is a special date format called Inverted date which is used to store some date fields in SAP tables.
If you work on Currency Exchange Conversions (TCURR table) the Date Field (GDATU) stores date in Inverted date format. So what exactly is this Inverted date format and how can you convert it to normal date format of YYYYMMDD which can be later used in your integration.
Inverted date is nothing but the 9's complement of the real date. In other words the conversion logic will be something as shown below
99999999 – (GDATU) = actual date in yyyymmdd format
Example: 99999999 – 79899168 = 20100831
There are conversion exits in ABAP which does this date conversion like CONVERSION_EXIT_INVDT_OUTPUT -- Conversion exit routine for inverted date (OUTPUT)
However if your SAP BAPI gives you data in inverted date format you can use the logic mentioned above in your BPEL/XSL at Fusion layer to convert it into actual date format.
If you work on Currency Exchange Conversions (TCURR table) the Date Field (GDATU) stores date in Inverted date format. So what exactly is this Inverted date format and how can you convert it to normal date format of YYYYMMDD which can be later used in your integration.
Inverted date is nothing but the 9's complement of the real date. In other words the conversion logic will be something as shown below
99999999 – (GDATU) = actual date in yyyymmdd format
Example: 99999999 – 79899168 = 20100831
There are conversion exits in ABAP which does this date conversion like CONVERSION_EXIT_INVDT_OUTPUT -- Conversion exit routine for inverted date (OUTPUT)
However if your SAP BAPI gives you data in inverted date format you can use the logic mentioned above in your BPEL/XSL at Fusion layer to convert it into actual date format.
Monday, August 30, 2010
SOA 11g : EM Console fails with HTTP 404 error ; JspServlet error
After restarting servers (admin and managed) found that EM console isn't coming up and it shows below error either on browser or Admin server log files:
"JspServlet error: Servlet unable to dispatch to the following requested page: java.io.FileNotFoundException: /targetauth/asLogin.jspx"
On further checking the directory targetauth was missing from <MW_HOME>/user_projects/domains/<domain_name>/servers/AdminServer/tmp/_WL_user/emcore/28c293 location. This directory has the asLogin.jspx file.
You can copy this directory from a different domain but that would still give errors like
"JspServlet error: Servlet unable to dispatch to the following requested page: java.io.FileNotFoundException: MDS-00013: no metadata found for metadata object "/targetauth/asLogin.jspx"
Solution :
1. Stop the Admin server
2. Rename <MW_HOME>/user_projects/domains/<domain_name>/servers/AdminServer/tmp/ directory to tmp-old
3. Restart the Admin server. The tmp directory will be recreated again.
Open EM Console.It should work now !
"JspServlet error: Servlet unable to dispatch to the following requested page: java.io.FileNotFoundException: /targetauth/asLogin.jspx"
On further checking the directory targetauth was missing from <MW_HOME>/user_projects/domains/<domain_name>/servers/AdminServer/tmp/_WL_user/emcore/28c293 location. This directory has the asLogin.jspx file.
You can copy this directory from a different domain but that would still give errors like
"JspServlet error: Servlet unable to dispatch to the following requested page: java.io.FileNotFoundException: MDS-00013: no metadata found for metadata object "/targetauth/asLogin.jspx"
Solution :
1. Stop the Admin server
2. Rename <MW_HOME>/user_projects/domains/<domain_name>/servers/AdminServer/tmp/ directory to tmp-old
3. Restart the Admin server. The tmp directory will be recreated again.
Open EM Console.It should work now !
Monday, August 23, 2010
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
TO
Similarily if you are referring to ProviderABCS from EBS composite.xml of EBS will look something as below
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"> .. ..
Saturday, August 21, 2010
HTTP Binding Adapter in SOA 11g
With the release of SOA Suite 11gR1 Patch Set 2 (PS2)! Oracle has added support for HTTP binding (helpful when we want to do away with SOAP and looking for simple GET and POST).
I had a requirement recently where I had to integrate with an external vendor which supported HTTP(s) posting of files. So I started looking at ways to post a XML file to the HTTP(s) location. Luckily with Jdeveloper 11g (11.1.1.3) version we have a HTTP binding adapter available which can be made use of.
You can drag the HTTP binding from component palette into your composite and configure it to post XML data to a HTTP(s) endpoint. Incase you are using HTTPS you would require the certificates to be installed on the SOA server if it is server authentication and your certificates need to be installed on vendor side if its mutual authentication. Apart from that it should be similar to HTTP.
For more details on how to configure the HTTP binding adapter wizard please follow the below blogpost from Edwin Biemond where he has illustrated this with screenshots.
Http Binding Adapter Configuration In Soa Suite 11g
I had a requirement recently where I had to integrate with an external vendor which supported HTTP(s) posting of files. So I started looking at ways to post a XML file to the HTTP(s) location. Luckily with Jdeveloper 11g (11.1.1.3) version we have a HTTP binding adapter available which can be made use of.
You can drag the HTTP binding from component palette into your composite and configure it to post XML data to a HTTP(s) endpoint. Incase you are using HTTPS you would require the certificates to be installed on the SOA server if it is server authentication and your certificates need to be installed on vendor side if its mutual authentication. Apart from that it should be similar to HTTP.
For more details on how to configure the HTTP binding adapter wizard please follow the below blogpost from Edwin Biemond where he has illustrated this with screenshots.
Http Binding Adapter Configuration In Soa Suite 11g
Friday, August 20, 2010
Unit testing Oracle SCA Composites
With Oracle SOA 11g we have a unit testing framework available for testing the individual components. This enables us to test the components in isolation without any external dependencies like availability of target services. This in turn helps during integration testing as we already have well tested low level components.
The framework allows :
1. Definition of Tests, assertions and emulations via Jdeveloper
2. Deployment of test cases along with deployment of SCA composite
3. Execution of test cases from EM console.
A typical testcase may contain an initiated message, an emulation which defines message/error
returned by an external reference/service and/or an assertion which is primarily used for comparison against expected results.
Below I have shown an example where I tested a component (AIA RequestorABCS) which had a DB adapter as initiator of process and called an external target service like SAP R/3. Now for unit testing this piece I used an initiator message in my test suite and an emulator to define a response message from SAP R/3. This way I don't have to depend on availability of actual target system at time of unit testing my ABCS code.
The test suite can be created from Jdeveloper :
It creates a copy of the composite.xml as shown below.
Once completed, deploy the test suite along with normal SCA deployment from Jdev/ant scripts and execute it from EM Console as shown below.
The framework allows :
1. Definition of Tests, assertions and emulations via Jdeveloper
2. Deployment of test cases along with deployment of SCA composite
3. Execution of test cases from EM console.
A typical testcase may contain an initiated message, an emulation which defines message/error
returned by an external reference/service and/or an assertion which is primarily used for comparison against expected results.
Below I have shown an example where I tested a component (AIA RequestorABCS) which had a DB adapter as initiator of process and called an external target service like SAP R/3. Now for unit testing this piece I used an initiator message in my test suite and an emulator to define a response message from SAP R/3. This way I don't have to depend on availability of actual target system at time of unit testing my ABCS code.
The test suite can be created from Jdeveloper :
It creates a copy of the composite.xml as shown below.
Once completed, deploy the test suite along with normal SCA deployment from Jdev/ant scripts and execute it from EM Console as shown below.
Subscribe to:
Posts (Atom)