FOTY0001 and logfiles roulation

A certain person named, or used the alias of, Vivek wrote a few years ago some interesting articles on his blog [ref: OracleD] about Oracle SOA Suite 10g. He experienced many flaws in Oracle OC4J Application Server and recommended the OTN discussion: Oracle BPEL + Oc4j + Jdeveloper = brain damage. Clearly he was not so happy with the features in the 10g version of Oracle SOA Suite...

He referred also to the so-called FOTY0001 errors, these often occur during XRef calls and XSL Transformations. More information about this FOTY0001 can be found in the OPMN log files. For example, a typical error is the following:
subLanguageExecutionFault - XPathExecutionError
  XPath expression failed to execute.
  Error while processing xpath expression, the expression is "ora:processXSLT('myTransformation.xsl',bpws:getVariableData('myInputMessage'))", the reason is FOTY0001: type error.
  Please verify the xpath query.
This error occurs e.g., when in JDeveloper the transform activity is opened and closed immediately. There was no time for the messagePart to be loaded, so it will be missing in the code leading to this FOTY0001 error on runtime. The proper syntax in the code is ora:processXSLT('myTransformation.xsl',bpws:getVariableData('myInputMessage','myMessagePart'))
To prevent this either click cancel in JDeveloper or wait for the message parts to load completely.

To view the FOTY0001 errors in detail the obvious way is to view them using Enterprise Manager. But an easier way is to view them directly by opening the logfiles on filesystem. Depending on the logging level the server logfiles can quickly become pretty huge. In the opmn configuration the roulation can be configured as follows, open $SOA_HOME/opmn/conf/opmn.xml and make the following changes:
<ias-component id="soa_group" status="enabled">
  <process-type id="oc4j_soa" module-id="OC4J" status="enabled">
    <module-data>
      <category id="start-parameters">
        <data id="java-options"
          value="-server
Add here the following parameters:
          -Dstdstream.filesize=10 - File size in MegaBytes
          -Dstdstream.filenumber=50 - Number of files
To separate the output and error messages add the following data element with oc4j-options inside the same category:
<data id="oc4j-options" value="-out $ORACLE_HOME/opmn/logs/oc4j_soa.out -err $ORACLE_HOME/opmn/logs/oc4j_soa.err"/>
To view the FOTY0001 error details simply open (in a good text-editor) the *.err file containing the timestamp of the error.

ORABPEL dehydration store purge scripts

By default all BPEL instances (messages) in the SOA Suite are persisted in the internal database, the so-called dehydration store. Good practice is to purge older messages, to avoid database sizing problems and to increase performance.

Unfortunately the original Oracle scripts were not sufficient to do the task, so many (consulting) companies created their own purge scripts. The good news is that Oracle realized the need and offers improved purge scripts, which are available to download from Oracle. Please take a look at the Oracle 10G FMW purge strategy whitepaper [ref: note ID 1286265.1], this document also contains the BPEL database schema.

For example, the second option from the whitepaper, multi-threaded purge can be found at Oracle Note: New BPEL 10g Purge Scripts From 10.1.3.5 MLR#2 [ref: note ID 1110833.1]. This script can be scheduled with e.g., crontab, or any other scheduling tool. The start parameters can be configured like

• P_OLDER_THAN := sysdate-21; (purge instances older than 21 days)
• P_ROWNUM := 10000000; (purge up to 10 million instances)
• P_DOP := 3; (use three threads in parallel)
• P_CHUNKSIZE := 1000; (commit per 1000 rows)

This last note contains all three scripts mentioned in the whitepaper:

• SINGLE THREADED LOOPED PURGE PROCEDURE
• MULTI THREADED LOOPED PURGE PROCEDURE
• CTAS (Create Table As Select) PROCEDURE

Afterwards if needed you can fine-tune this script a little.
Tips:

• Create a script for all state instances to purge dev and test environments, modify INSERT INTO temp_cube_instance, change WHERE state >= 5 into WHERE state >= 0
• When purging all instances older than the configured days, it might be handy to keep the process history a little longer, like one year, modify DELETE FROM process_log, change WHERE event_date < p_older_than into WHERE event_date < SYSDATE - 365
• When sensor data is used you might want to include this data in the purge script:
  DELETE FROM activity_sensor_values WHERE creation_date < p_older_than;
DELETE FROM fault_sensor_values WHERE creation_date < p_older_than;
DELETE FROM variable_sensor_values WHERE creation_date < p_older_than;
• When using AIA ErrorHandler you might want to prevent the carthesian product by adding a max to the script. The AIA Error Handler doesn't use unique conversation id's, modify INSERT INTO temp_invoke_message, change FROM temp_cube_instance tci into FROM (SELECT MAX (cikey) cikey, conversation_id FROM temp_cube_instance GROUP BY conversation_id) tci

For the ORAESB schema the scripts can simply be found at $SOA_HOME/integration/esb/sql/other.

Overload leads to timeout errors

Sometimes integration scenarios can receive a bulk load from an application, especially when the source application uses batches as the trigger for sending out messages. This load can lead to the following non-retryable SOAP errors in the ESB:
Fault message:
Failed to enqueue deferred event "oracle.tip.esb.server.dispatch.QueueHandlerException:
Context lookup failed "[CONFIGURATION ERROR] Invalid Destination "Topics/ESB_JAVA_DEFERRED" :
javax.jms.InvalidDestinationException: Looking up java:comp/resource/esbRP/Topics/ESB_JAVA_DEFERRED:
javax.naming.NameNotFoundException: No resource named 'esbRP/Topics/ESB_JAVA_DEFERRED'found.
Please verify configuration of adminobject or the lookup string."
Make sure the topic is mapped to a jndi tree"

This behaviour is described in an Oracle note [ref: note ID 1173584.1] with the following solution: increase the timeout settings. Together with two other Oracle notes describing how to avoid BPEL errors due to adapters response time and what timeout settings in SOA can impact AIA [ref: note ID 1074227.1 and 885114.1] this leads to the following timeout settings:

• xa_timeout in $SOA_HOME/integration/esb/config/esb_config.ini
  Default: 60; recommended setting: 3600
• jms_receive_timeout in $SOA_HOME/integration/esb/config/esb_config.ini
  Default: 30; recommended setting: 300
• Also according to another Oracle note [ref: note ID 752385.1] you might want to set PingCount and PingInterval to 30 in $SOA_HOME/integration/esb/config/esb_config.ini
• syncMaxWaitTime in $SOA_HOME/bpel/domains/default/config/domain.xml
  Default: 45; recommended setting: 600
• transaction-timeout in $SOA_HOME/j2ee/oc4j_soa/application-deployments/orabpel/ejb_ob_engine/orion-ejb-jar.xml (change this value for all 6 occurences of transaction-timeout in this file)
  Default: up to 3000; recommended setting: 3600
• transaction-timeout in $SOA_HOME/j2ee/[container]/config/transaction-manager.xml (change this value for all containers: e.g. home, designtime and runtime [oc4j_soa])
  Default: from 300 to 3600; recommended setting: 7200
• Timeout in $SOA_HOME/Apache/Apache/conf/httpd.conf
  Default: 300; recommended setting: 300, this option specifies the amount of time Apache will wait for a GET, POST, PUT request and ACKs on transmissions. The default is 300 (seconds) however this may need to be increased.

The settings in the $ORACLE_HOME/integration/esb/config/esb_config.ini file apply to all ESB instances in the Oracle Home. One small bonus feature: if you have many BPEL processes deployed and you experience long waiting times in the ESB Console: put a lazyLoad property in the esb_config.ini file and the waiting time is gone [ref: Bug 7720420].
esb.console.services.lazyLoad.Allowed=true
It's a little confusing regarding the file orion-application.xml, different notes say different things, one note mentions the location in application-deployments which overrides esb_config.ini, another note mentions the location under applications which overrides esb_config.ini. Just to be safe and consistent check the orion-application.xml file in the following locations and if they are present and not commented out apply the values mentioned above for the xa_timeout, jms_receive_timeout, PingCount and PingInterval:
$SOA_HOME/j2ee/[ESB_RUNTIME_CONTAINER]/application-deployments/esb-rt/orion-application.xml
$SOA_HOME/j2ee/[ESB_RUNTIME_CONTAINER]/applications/esb-rt/META-INF/orion-application.xml
$SOA_HOME/j2ee/[ESB_DESIGNTIME_CONTAINER]/application-deployments/esb-dt/orion-application.xml
$SOA_HOME/j2ee/[ESB_DESIGNTIME_CONTAINER]/applications/esb-dt/META-INF/orion-application.xml

The above changes also take care of the following errors in the container logfile from $SOA_HOME/opmn/logs:
ORABPEL-05002
ORABPEL-02182
JTA transaction is not present the transaction is not in active state
Message handle error

Instead of increasing the timeout settings for the BPEL processes a more durable solution would be to throtte the inbound flow. There is an activation agent (bpel.xml) property (since 10.1.3.1), which can be used to control the speed at which the adapter posts messages to BPEL [ref: note ID 1178163.1 or Oracle® SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0) E10971-01 December 2007]
...
    <activationAgents>
      <activationAgent partnerLink="JmsDequeuePL" ... >
          <property name="minimumDelayBetweenMessages">1000</property>
      </activationAgent>
    </activationAgents>
  </BPELProcess>
</BPELSuitcase>
This setting ensures that there at least will be 1000 milliseconds delay between two consecutive messages being posted to this BPEL process.

Actually this last best practices guide provides many valuable tips, like

• Performance tuning guidelines.
• Answers to frequently asked questions about threading.
• Answers to frequently asked questions about transactions.
• How to optimize the JVM heap. The heap size controls the amount of memory the JVM can use.
• How to relieve the dehydration store by making BPEL processes synchronous.
• Description of performance persistence parameters in bpel.xml.
• WSIF binding (localhost) and EJB binding optimization.
• The relationship among some performance settings
• The objectives and best practices for creating the BPEL cluster.
• Increasing the instanceKeyBlockSize to 100,000. Doing so decreases the frequency at which Oracle BPEL Server visits the dehydration store.

Some best practices should be considered during design and development time, like the BPEL parameters that are configured per BPEL component, whether a BPEL process should be synchronous or asynchronous and whether it should participate in a transaction or not. Other best practices are SOA Suite wide and should be part of the overall configuration, like the start-up memory settings.

Updated June 6, 2011 with LazyLoad, PingCount and PingInterval, another location of the orion-application.xml file and jms_receive_timeout to 300.

Instance wide XML manipulations

If the input file is a plain xml file without namespaces declared the following error occurs (at least when xml validation is set to 'strict'):
<invalidVariables xmlns="http://schemas.oracle.com/bpel/extension"><part name="code">
<code>9710</code></part><part name="summary">
<summary>Invalid xml document.
According to the xml schemas, the xml document is invalid. The reason is: Error::cvc-elt.1: Cannot find the declaration of element 'TestXSD'.
Please make sure that the xml document is valid against your schemas.</summary></part></invalidVariables>

Solution: create in the consumer routing service (the component after the file-reader, postfixed with _RS) the following transformation, first check if the wanted namespace is included in the namespace declarations, otherwise map one field to get all the namespaces declared. Then add the following code in the xsl:
<xsl:stylesheet version="1.0" xmlns:test="http://www.mydomain.com/TestXSD">
<xsl:template match="*">
  <xsl:element name="test:{local-name()}" namespace="http://www.mydomain.com/TestXSD">
    <xsl:apply-templates select="@*|node()"/>
  </xsl:element>
</xl:template>

This code is based on the "identity" template, which was introduced with an example in the XSLT Recommendation itself [ref: www.w3.org]:
<xsl:template match="@*|node()">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

Some explanation here: "node()" is shorthand for child::node(). That is node() matches all nodes (element, text, comment, processing-instruction) being children of other nodes but not attributes since they are not considered children of their parent element. To find all nodes in order to copy them, we need to match both nodes being children of other nodes, node(), and attributes, @*, that is: match="@*|node()".

This template copies everything recursive from source to target, all the attributes and nodes. Copying everything in itself is no fun but becomes very useful when we add exceptions or conditions to the copying. Here two transformations that copy all the nodes and attributes if:

• They have content: RemoveEmptyNodes.xsl
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="@*|node()">
    <xsl:if test=". != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>
• They have content or the node contains an attribute with content: RemoveEmptyNodesKeepAttributes.xsl
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="@*|node()">
    <xsl:if test=". != '' or ./@* != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
</xsl:stylesheet>

These templates can replace one of Oracle's best practices [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009], adding the RemoveEmptyNodes transformation after the main mapping fulfills:

Transformation logic and XPath should be designed with the possibility of missing or empty elements
<xsl:if test="normalize-space(Line3/text())">
  <Line3>
    <xsl:value-of select="Line3/text()"/>
  </Line3>
</xsl:if>

The above templates can save you the time-consuming conditional mapping per element. Just don't forget if the mapping contains empty placeholders (like EBMHeader/EBMTracking/ExecutionUnitID) then fill these first with an assign before calling the RemoveEmptyNodes. Also the element EBMHeader/DataArea/[verb] is a required field. This can be solved with both templates:

• RemoveEmptyNodes.xsl: include in the template an exclusion of this element (the [verb] is Create here):
  <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:corecom="http://xmlns.oracle.com/EnterpriseObjects/Core/Common/V2">
  <xsl:template match="@*|node()">
    <xsl:if test=". != ''">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
      </xsl:copy>
    </xsl:if>
  </xsl:template>
  <xsl:template match="corecom:Create">
    <xsl:copy-of select="."/>
  </xsl:template>
</xsl:stylesheet>
• RemoveEmptyNodesKeepAttributes.xsl: fill an optional attribute of this field, although not the most elegant solution...

Sending an email from BPEL

Sending an email message from a BPEL Component is described in the Oracle BPEL guide [ref. Oracle® BPEL Process Manager Developer’s Guide 10g (10.1.3.1.0) B28981-03 January 2007]. But here are two different methods described: sending an email with a body and sending an email with two attachments. How to send an email with both a body and an attachment? The solution here is to use the second method (two attachments) and empty the BodyPartName of the first attachment, this attachment will then become the body of the email:
xmlns:notifsrvc="http://xmlns.oracle.com/ias/pcbpel/NotificationService"

<partnerLinks>
  <partnerLink name="NotificationService" partnerRole="NotificationServiceProvider" partnerLinkType="notifsrvc:NotificationServiceLink"/>
</partnerLinks>

... (population of varNotificationReq/EmailPayload)

<assign name="Remove_BodyPartName">
  <copy>
    <from expression="string('')"/>
    <to variable="varNotificationReq" part="EmailPayload" query="/EmailPayload/notifsrvc:Content/notifsrvc:ContentBody/notifsrvc:MultiPart/notifsrvc:BodyPart[1]/notifsrvc:BodyPartName"/>
  </copy>
</assign>

<invoke name="InvokeNotificationService" partnerLink="NotificationService" portType="notifsrvc:NotificationService" operation="sendEmailNotification" inputVariable="varNotificationReq" outputVariable="varNotificationResponse"/>

AIA configuration properties

AIA brings us a very nice solution for maintaining variables in one global AIAConfigurationProperties.xml file (kind of ini-file) which are used at runtime. This is the perfect place for e.g. the systemID (application system id) which is used in the code to identify the application for DVM and XRef translations. Also is this systemID used to populate the EBMHeader Sender segment with information from the BSR (Business Service Repository) when the EBM is created in the BPEL RequesterABCSImpl component.

All the aia functions are described and explained in the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009].

Creation of the EBM Header in the transformation xsl file:
<xsl:variable name="serviceName" select="'{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]'"/>
<xsl:variable name="systemID" select="aia:getServiceProperty($serviceName,'Default.SystemID',true())"/>
<xsl:variable name="senderNodeVariable" select="aia:getEBMHeaderSenderSystemNode($systemID,'')"/>
<xsl:variable name="messageIdVariable" select="orcl:generate-guid()"/>

<corecom:EBMHeader>
<corecom:EBMID>
 <xsl:value-of select="$messageIdVariable"/>
</corecom:EBMID>
<corecom:EBMName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}SyncObjectListEBM</xsl:text>
</corecom:EBMName>
<corecom:EBOName>
 <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseObjects/Core/EBO/Object/V1}ObjectEBO</xsl:text>
</corecom:EBOName>
<corecom:CreationDateTime>
 <xsl:value-of select="xp20:current-dateTime()"/>
</corecom:CreationDateTime>
<corecom:VerbCode>
 <xsl:text disable-output-escaping="no">Sync</xsl:text>
</corecom:VerbCode>
<corecom:Sender>
 <corecom:ID>
  <xsl:value-of select="$senderNodeVariable/ID"/>
 </corecom:ID>
 <corecom:Description>
  <xsl:value-of select="$senderNodeVariable/Description"/>
 </corecom:Description>
 <corecom:IPAddress>
  <xsl:value-of select="$senderNodeVariable/IPAddress"/>
 </corecom:IPAddress>
 <corecom:Application>
  <corecom:ID>
   <xsl:value-of select="$senderNodeVariable/Application/ID"/>
  </corecom:ID>
  <corecom:Version>
   <xsl:value-of select="$senderNodeVariable/Application/Version"/>
  </corecom:Version>
 </corecom:Application>
 <corecom:ContactName>
  <xsl:value-of select="$senderNodeVariable/ContactName"/>
 </corecom:ContactName>
 <corecom:ContactEmail>
  <xsl:value-of select="$senderNodeVariable/ContactEmail"/>
 </corecom:ContactEmail>
 <corecom:ContactPhoneNumber>
  <xsl:value-of select="$senderNodeVariable/ContactPhone"/>
 </corecom:ContactPhoneNumber>
</corecom:Sender>

The configuration properties can also be used to retrieve the service-endpoints, pretty convenient when you'll have to deploy the code to other environments with different endpoints. When the CAVS framework is not used in your organization you can remove the whole CAVS endpoint javacode in the BPEL sourcecode which was generated by the ABCS Service Constructor. Set a webservice endpoint as follows:
<variable name="EndpointReference" element="wsa:EndpointReference"/>

<assign name="SetServiceEndpoint">
  <copy>
    <from>
      <wsa:EndpointReference xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
        <wsa:Address/>
      </wsa:EndpointReference>
    </from>
    <to variable="EndpointReference"/>
  </copy>
  <copy>
    <from expression="aia:getServiceProperty('{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]','Routing.[PartnerLinkName].EndpointURI',true())"/>
    <to variable="EndpointReference" query="/wsa:EndpointReference/wsa:Address"/>
  </copy>
  <copy>
    <from variable="EndpointReference"/>
    <to partnerLink="[PartnerLinkName]"/>
  </copy>
</assign>

Besides populating the BSR with the application information to populate the EBM Sender elements, by logging into the /AIA site, go to Setup and then tab System, the key field here is System Code = systemID. The properties mentioned above have to be configured in the AIA file before lookup:
$AIA_HOME/config/AIAConfigurationProperties.xml, just above the </AIAConfiguration> tag:
<!-- [ABCSName] -->
<ServiceConfiguration serviceName="{http://xmlns.oracle.com/ABCSImpl/[Application]/Core/[ABCSName]/V1}[ABCSName]">
 <Property name="Default.SystemID">APPLICATION_01</Property>
 <Property name="Routing.[PartnerLinkName].EndpointURI">http://[HTTP_HOST]:[HTTP_PORT]/webserviceaddress</Property>
</ServiceConfiguration>
In the transformation source code (xsl) only the serviceName has to be specified, not the systemID (APPLICATION_01). This systemID gets retrieved from the AIAConfigurationProperties xml file. After editing this file don't forget to reload the AIA Configuration properties: log in the /AIA site, go to setup, go to configuration and after scrolling down you'll find the Reload button.

It's worth to mention that this AIA Configuration Properties file contains environment-specific properties, like partnerlink endpoints. Use the same procedure here as you have for managing connection pools and other physical endpoints/jdbc urls/id's per application per environment.

BPEL instance title in BPELConsole

For monitoring purposes it's a good practice to set the BPEL Instance title with an unique and descriptive meaning. For example: for order and invoice messages you might want to see the orderNumber in the instance title, like OrderNumber - [orderNumber].

To achieve this use the following code in the BPEL process:
<variable name="Title" type="xsd:string"/>
and
<assign name="GetTitle">
 <copy>
  <from expression="concat('OrderNumber - ',bpws:getVariableData('InputMessage','InputPart','/msg:rootElement/msg:orderNumber'))"/>
  <to variable="Title"/>
 </copy>
</assign>
<bpelx:exec name="SetTitle" language="java" version="1.5">
 <![CDATA[setTitle((String)getVariableData("Title"));]]>
</bpelx:exec>

Next it might be useful to search for all instances related to this ordernumber, for this a small fix is needed to automatically search with wildcards in the BPELConsole Instances:
Modify the following file: $SOA_HOME/j2ee/oc4j_soa/applications/orabpel/console/ngInstanceList.jsp
Replace
// construct where condition step 4: instanceTitle
//
String instanceTitleQ = request.getParameter( "instanceTitle" );
if ( instanceTitleQ != null && instanceTitleQ.length( ) != 0 )
{
  buf.setLength( 0 );
  tmpWhere.setClause( buf.append( n++ > 0 ? " AND " : "" )
    .append( SQLDefs.AL_ci_title )
    .append( " = ? " )
    .toString() );
  tmpWhere.setString( 1, instanceTitleQ );
  where.append( tmpWhere );
}

with

// construct where condition step 4: instanceTitle
//
String instanceTitleQ = request.getParameter( "instanceTitle" );
if ( instanceTitleQ != null && instanceTitleQ.length( ) != 0 )
{
  buf.setLength( 0 );
  tmpWhere.setClause( buf.append( n++ > 0 ? " AND " : "" )
    .append( SQLDefs.AL_ci_title )
//Start search with wildcards
//    .append( " = ? " )
//    .toString() );
//  tmpWhere.setString( 1, instanceTitleQ );
    .append( " LIKE ? " )
    .toString() );
  String wildcard = "%";
  instanceTitleQ = wildcard.concat(instanceTitleQ.concat(wildcard));
  tmpWhere.setString( 1, instanceTitleQ );
//End search with wildcards
  where.append( tmpWhere );
}

Now you can search by the ordernumber in the 'title'-field and the BPELConsole returns all instances with this number somewhere in the instance title.

How to determine the SOA Suite MLR version?

There are many ways to determine the MLR (SOA Bundle Patchsets - Merge Label Request) version of the SOA Suite, here are three ways to find your servers MLR version:
1. Go to $SOA_HOME/bpel/bin and run obversion.sh
./obversion.sh
*****************************************************************************
Oracle BPEL Server version 10.1.3.4.0
  Build: 0
  Build time: Sun Mar 07 17:51:49 PST 2010
  Build type: release
  Source tag: PCBPEL_10.1.3.4.0MLR10_GENERIC_RELEASE
2. Similarly, you can see this same information in the $SOA_HOME/bpel/domains/<domain_name>/logs/domain.log OR $SOA_HOME/opmn/logs/default_group~<container_name>~default_group~1.log file. Upon startup, the log file will contain the build information and MLR number entries similar to the output above.
3. Third way, look for the patches in opatch lsinventory: OPatch/opatch lsinventory |egrep '8372150|8589928|9317334'
Patch 8372150: TRACKING BUG FOR CUMULATIVE MLR#8 ON TOP OF 10.1.3.4.0
Patch 8589928: TRACKING BUG FOR CUMULATIVE MLR#9 ON TOP OF 10.1.3.4.0
Patch 9317334: TRACKING BUG FOR CUMULATIVE MLR#10 ON TOP OF 10.1.3.4.0

EBMTracking stamp both in BPEL as ESB

According to AIA [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009] the messages get Tracking Information added within both the BPEL and ESB components. Below you find some updated code to get this EBMTracking segment populated (the Sample EBM here is of type SyncObjectEBM):

The transformation within the BPEL Component RequesterABCSImpl (xsl) which creates the EBM:

<xsl:variable name="ServiceName" select="'{http://xmlns.oracle.com/ABCSImpl/[SenderApplication]/Core/[ABCSName]/V1}[ABCSName]'"/>

<corecom:EBMTracking>
 <corecom:SequenceNumber>
  <xsl:value-of select="position()"/>
 </corecom:SequenceNumber>
 <corecom:ExecutionUnitID/>
 <corecom:ExecutionUnitName>
  <xsl:value-of select="$ServiceName"/>
 </corecom:ExecutionUnitName>
 <corecom:ImplementationCode>
  <xsl:text disable-output-escaping="no">BPEL</xsl:text>
 </corecom:ImplementationCode>
 <corecom:ActivityDateTime>
  <xsl:value-of select="xp20:current-dateTime()"/>
 </corecom:ActivityDateTime>
</corecom:EBMTracking>

After the transformation the ExecutionUnitID gets populated in the BPEL code with the following assign:

<assign name="Assign_InstanceID">
 <copy>
  <from expression="ora:getInstanceId()"/>
  <to variable="SyncObjectEBSReqMsg" part="SyncObjectEBM" query="/objectebs:SyncObjectEBM/corecom:EBMHeader/corecom:EBMTracking/corecom:ExecutionUnitID"/>
 </copy>
</assign>

The following transformation has to be created inside the ESB Component, the population of the ExecutionUnitID is described in the Best Practices Guide [ref: Oracle® SOA Suite Best Practices Guide 10g Release 3 (10.1.3.3.0) E10971-01 December 2007].
Tip: first let JDeveloper create the transformation and map one field to get all the namespaces populated, afterwards copy/paste the following code:

<xsl:template match="/">
 <ebo:SyncObjectListEBM>
  <corecom:EBMHeader>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMID"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMName"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBOName"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:CreationDateTime"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:VerbCode"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:MessageProcessingInstruction"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Sender"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:Target"/>
   <xsl:copy-of select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:BusinessScope"/>
   <xsl:for-each select="ebo:SyncObjectListEBM/corecom:EBMHeader/corecom:EBMTracking">
    <xsl:copy-of select="."/>
   </xsl:for-each>

<corecom:EBMTracking>
 <corecom:SequenceNumber>
  <xsl:value-of select="position() + 1"/>
 </corecom:SequenceNumber>
 <corecom:ExecutionUnitID>
  <xsl:value-of select="ehdr:getInstanceID()"/>
 </corecom:ExecutionUnitID>
 <corecom:ExecutionUnitName>
  <xsl:text disable-output-escaping="no">{http://xmlns.oracle.com/EnterpriseServices/Core/Object/V1}ObjectEBS</xsl:text>
 </corecom:ExecutionUnitName>
 <corecom:ImplementationCode>
  <xsl:text disable-output-escaping="no">ESB</xsl:text>
 </corecom:ImplementationCode>
 <corecom:ActivityDateTime>
  <xsl:value-of select="xp20:current-dateTime()"/>
 </corecom:ActivityDateTime>
</corecom:EBMTracking>

  </corecom:EBMHeader>
  <xsl:for-each select="ebo:SyncObjectListEBM/ebo:DataArea">
   <xsl:copy-of select="."/>
  </xsl:for-each>
 </ebo:SyncObjectListEBM>
</xsl:template>

Last thing: add the following property to your esb component:
name:    enableAccessBusinessEvent
value:   true

Tips to start SOA Suite developments

In order to have all the interfaces in Oracle SOA Suite developed in an uniform way there is a need for coding standards and naming conventions. Oracle delivers the Application Integration Architecture, which includes a canonical model, a test-framework, coding standards, naming conventions and more.

Some tips when starting with Oracle SOA Suite:

• Stick to one version or patch-level for all environments. Only if a new version or MLR (patch-bundle) is needed, for example to fix a showstopper, start a project to upgrade/patch all your environments.
• Developers must have read the AIA Development Guide [ref: Oracle® Application Integration Architecture - Foundation Pack 2.5: Integration Developer's Guide Release 2.5 Part No. E16465-01 December 2009] or taken an AIA course. As for some the AIA Development Guide is not an easy and fast read, a good practice is to create a summary for those developers :) Add to this summary company-specific coding standards and naming conventions.
• Implement the components in either BPEL or ESB technology based on their purpose. All ABCSs in BPEL, all EBFs in BPEL, all EBSs in ESB, all non-soap communication with applications use ESB adapters.
• Use the AIA Service Generator for the BPEL components (ABCSs). This takes care of code for AIA ErrorHandling, CAVS test framework and sets instance title etc.
• Automate the deployments using scripts or e.g. the osbs - Oracle Soa Build Server by Marc Kelderman [ref: http://orasoa.blogspot.com/2009/04/new-oracle-soa-build-server-osbs.html]
• Set xml validation to strict on the development and test environments (except while executing stress-tests).
• Define ownership for all the EBO customizations, DVMs, XRefs, AIA ConfigurationProperties and system-wide parameters.
• When DVM or XRef technology is used for other purposes then intended, prefix the name with for example Z_.
• Define ownership of all the applications within the SOA Suite, especially naming (name per application or per module within, name the middleware communicating with or the application behind), ApplicationObjectLibrary and connection details.
• Define appropriate Service Groups in the ESB System AIASystem, for example one service group per application.
• Transformations from ABM --> EBM should be comprehensive mapping of all available attributes (All ABM Attributes supported in EBM should be mapped). Instance identifying information needs to be populated with as much information as possible in every Identification/IdentificationType element. EBM header needs to be populated fully.
• Use the EBM verbs/EBS operations with care and as intended. For example master data from the System of Record uses the sync, messages to the SoR use create/update.
• The same for EBM List messages, bundling messages lowers the number of instances, but if one message fails all the objects within this message are blocked.

Hope this helps you...