rss
SOATUBE
Oracle
Custom Search SOABYTE here

Monday, September 27, 2010

Performnace Tuning in SOA 10g


















There are many process level and domain level properties that we need to understand in order to fine tune the performance of our process.


For any BPEL process we have a file called bpel.xml we can set these properties over here and redeploy the project in order to make the changes take effect.

The different performance properties used are

1>Idempotent
=================

It can be set within the bpel.xml file.

General sysntax is

<partnerLinkBindings>
<property name="idempotent">true</property>
</partnerLinkBinding>

An idempotent activity is an activity that can be retried eg- the assign activity. A non-idempotent activity is an activity that can happen only once.The default value of idempotent property is true.By default, in a bpel process invoke activity is an idempotent activity, It means that the BPEL engine will not dehydrate the instance right after invoke activities. This property can be set for each partner link.If it is set to true and when you invoked a bpel process and your environment get crashed all of a sudden then when you will restart the system the invoke will be executed again.But when we will set this property to false the bpel engine will dehydrate the activity after the invoke and when you will start the server it will start from the last saved activity and not from the invoke activity.Thus it will enhance performance.

2>nonBlockingInvoke
=====================

This property is used when you have more than one invoke activity in parallel like in a typical flow activity.The bpel engine by default creats a single thread and even though your invoke activities are in parallel the engine calls them sequentially essentially from left to right.We can change this behaviour by including a property called nonBlockingInvoke in order to create separate threads for each invoke activity causing the performace to increase.The default value for nonBlockingInvoke is false which mean the engine will call the invoke activity in a single process Thread.We will change it to true in order to create new threads for execution thus processing in parallel will increase the performance.

General syntax

<partnerLinkBindings>

<property name="nonBlockingInvoke">true</property>

</partnerLinkBindings>


3>inMemoryOptimization
=========================

This properties is applied only in transient process.Transient process are those process which doesnot contain any mid point activities like receive,pick or wait activities or even any idempotent activities or in other words we can say it never stops and wait for any activities in between or wait for any results in between.This property tells the engine that the process is transient process and dehydration of the instance is not required.The default value of this property is false.When it is set to true the engine will keep the instances of this process only in memory during the course of execution.

This property works in conjunction with completionPersistPolicy and completionPersistLevel.

These properties values are determined to determine the behaviour of persistence

General syntax is


<BPELProcess src="getValue.bpel" id="getValue">
.................................
<configurations>
<property name="inMemoryOptimization">true</property>
</configurations>
</BPELProcess>


4>completionPersistPolicy 
============================

The completionPersistPolicy property can only be used when inMemoryOptimization is set to be true in a transient process.This property controls when to persist instances.

The default value for this property is on ,which means that the instance will be saved normally.The other values that can be used for this property are

a>off-no instance for the process will be saved.
b>faulted-Only faulted instances will be saved for the process.
c>deferred-It is more or like on status but here some of the instances may not get stored in case of a crash of server.

General syntax is


<BPELProcess src="getValue.bpel" id="getValue">
.................................
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">off</property>
</configurations>

</BPELProcess>


You can change it accordingly as per your requirement.

5>completionPersistLevel
===========================

The completionPersistLevel property can only be used when inMemoryOptimization is set to be true in a transient processes.The default value for this property is all which mean it will store all the state of the instances.It can also have an value of
instanceHeader which means only the meta data will be stored for the instance.by saying meta data i meana completion state, start/end dates, etc.

General syntax is


<BPELProcess src="getValue.bpel" id="getValue">
...
<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">faulted</property>
<property name="completionPersistLevel">All</property>
</configurations>
</BPELProcess>


here in my case i have set it to all that is i want to store all the states of the instance for the faulted instance.

6>deliveryPersistPolicy
============================

The deliveryPersistPolicy configuration property is used to turn on and off the DB persist of asynchronous process.The default value is on which means it store asynchronous process in delivery service DB.


To change it log in to the BPel console

http://host:port/BPELConsole

switch to configuration tab.There you will find this property

Changes whether the delivery messages are persisted. Delivery messages include invoke message, callback message and subscription message.

* on - delivery messages are persisted
* off - delivery messages are kept only in memory.

The default value is "on".

Asynchronous requests by default are saved in the delivery queue database table. These requests are later picked up by the worker threads and delivered to the targeted BPEL instances. The messages can be kept in delivery queue in memory cache in case of enhanced performance. 

If you are on version lower than 10.1.3.4 then you also need to take care of dspMaxThreads and ReceiverThreads

As per best practices it is recommended to have sum of dspMaxThreads across all the domain less than or equal to the receiverThreads.

Thursday, September 23, 2010

Transaction Support in Oracle DB JCA Adapter


















The Oracle Database Adapter enables transaction support, which, along with the inherent data processing, ensures that each modification has a clearly defined outcome, resulting in either success or failure, thus preventing potential corruption of data, executes independently from other changes, and, once completed, leaves underlying data in the same state until another transaction takes place.


There are two types of transaction support, XA Transaction support and Local Transaction support. XA transaction support allows a transaction to be managed by a transaction manager external to a resource adapter, whereas, a local transaction support allows an application server to manage resources that are local to the resource adapter.
To ensure two Oracle Database Adapter invokes commit or rollback as a unit, you need to perform the following:

  • Both Oracle Database Adapter invokes must be configured to participate in global transactions.
  • Both Oracle Database Adapter invokes must participate in the same global transaction.
  • The failure of either invoke must cause the global transaction to roll back.


    Configuring Oracle Database Adapter for Global Transaction Participation

    In the deployment descriptor (weblogic-ra.xml file), you must set the xADataSourceName parameter. Additionally, the referenced DataSource must be configured for transaction participation by creating a data source in Oracle WebLogic Server Console.
    You must create a data source and choose one of the XA data sources from the list.

    Both Invokes in Same Global Transaction

    Once both the Oracle Database Adapter invokes participate in global transactions, to commit or rollback as a unit, they must be participating in the same global transaction. In BPEL, this requires the understanding of where the transaction boundaries are, at what points does a checkpoint have to write to the dehydration store, commit the current global transaction, and start a new one.
    The transaction boundaries in a BPEL process occur either before a Receive activity or wait activity, or before an onMessage or pick activity. This may also occur when invoking a synchronous child BPEL process, unless the bpel.config.transaction property is set on the partnerlink, as shown in the following code sample.
    <property name="bpel.config.transaction">required</property>
    
    Otherwise, the parent process is broken into two transactions and the child process runs in its own transaction.

    Failure Must Cause Rollback

    Finally, even if both Oracle Database Adapter invokes participate in the same global transaction, the failure of either invoke may not cause the global transaction to rollback.
    The only cases where a failure can actually cause a global rollback are:
    • A Oracle Database Adapter operation that inserts/updates multiple tables as part of one invoke fails after having succeeded in some writes but not others. In this case, the Oracle Database Adapter marks the global transaction as rollback only, because the invoke operation was not atomic and a commit could cause data corruption.
    • The invoke retries multiple times in a database down scenario, until the global transaction times out and is rolled back.
    • An explicit bpelx:rollback fault is thrown from within the BPEL process.


     
     
     
    Using the Same Sessions for Both Invokes
     
    You must set the GetActiveUnitOfWork JCA parameter to true to enable using the same sessions or connections for both the Oracle Database Adapter invokes.
    GetActiveUnitOfWork is an advanced JCA property you can set on any DBInteractionSpec. It causes the invoke to register itself with the two-phase commit callbacks, and all writes to the database are performed as part of the two-phase commit. By setting this property on any failure, the transaction is automatically rolled back, as there is no way to handle a fault at this late stage. Similarly, the same underlying TopLink session is used for both invokes, meaning if you merge the same object twice, it is inserted/updated once. All merge invokes that setGetActiveUnitOfWork as true are cumulative.

    Transaction/XA Support

    To make two Oracle Database Adapter invokes commit or roll back as a unit requires the following: both Oracle Database Adapter invokes must be configured to participate in global transactions, both invokes must participate in the same global transaction, and the failure of either invoke must cause the global transaction to rollback.


    Configuring an Oracle Database Adapter for Global Transaction Participation
    In the deployment descriptor (weblogic-ra.xml), you must set xADataSourceName. The matching data source entry must be configured for global transaction participation.

    True XA: Two-Phase (XA) Versus One-Phase (Emulated) Commit
    XA is a two-phase commit protocol, which is more robust than a one-phase commit or emulated protocol. The difference is that with a one-phase protocol, you may very rarely still see message loss or other rollback/commit inconsistency, on the order of one per one thousand generally.



Remove empty elements XSLT


















<?xml version="1.0" encoding="UTF-8" ?>
<?oracle-xsl-mapper
  <!-- SPECIFICATION OF MAP SOURCES AND TARGETS, DO NOT MODIFY. -->
  <mapSources>
    <source type="XSD">
      <schema location="xsd/source.xsd"/>
      <rootElement name="InputParameters" namespace="http://xmlns.oracle.com/pcbpel/adapter/db/source/"/>
    </source>
  </mapSources>
  <mapTargets>
    <target type="XSD">
      <schema location="xsd/source.xsd"/>
      <rootElement name="InputParameters" namespace="http://xmlns.oracle.com/pcbpel/adapter/db/source/"/>
    </target>
  </mapTargets>
  <!-- GENERATED BY ORACLE XSL MAPPER 11.1.1.3.0(build 100415.2045.2557) AT [WED AUG 25 18:53:43 IST 2010]. -->
?>
<xsl:stylesheet version="1.0"
                xmlns:xref="http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions"
                xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20"
                xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:ora="http://schemas.oracle.com/xpath/extension"
                xmlns:ehdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.esb.server.headers.ESBHeaderFunctions"
                xmlns:orcl="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc"
                xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath"
                xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath"
                exclude-result-prefixes="xsl xref xp20 bpws ora ehdr orcl ids hwf">
<xsl:output method="xml" indent="yes" />
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>
   
    <xsl:template match="@*[.='']"/>


    <xsl:template match="*[not(node())]"/>
</xsl:stylesheet>

Friday, September 10, 2010

Deployment Descriptor Properties in Oracle 11G















Deployment descriptors are BPEL process service component properties used at runtime by Oracle WebLogic Server, Oracle Enterprise Manager, or both. There are two types of properties:

·         Configuration
·         Partner link binding
You define configuration properties and values in the BPEL process service component section of the composite.xml file as in example below:- 

<composite name=”mybpelproc”>
<property name=”bpel.config.completionPersistPolicy”>on</property>
</composite>
                                             
 

Property Name
Description
completionPersistPolicy
This property configures how the instance data is saved. It can only be set at the BPEL service component level. The following values are available:
  • on (default): The completed instance is saved normally.
  • deferred: The completed instance is saved, but with a different thread and in another transaction.
  • faulted: Only the faulted instances are saved.
  • off: No instances of this process are saved.

<composite name=”mybpelproc”>
<property name=”bpel.config.completionPersistPolicy”>on</property>
</composite>

globalTxMaxRetry
If using outbound adapters in an asynchronous BPEL process, specify the maximum number of retries for a remote fault.
globalTxRetryInterval
If using outbound adapters in an asynchronous BPEL process, specify the time interval in milliseconds between retries for a remote fault.
inMemoryOptimization
Default value is false. This property can only be set to true if it does not have dehydration points. Activities like wait, receive, onMessage, and onAlarm create dehydration points in the process. If this property is set to true, in-memory optimization is attempted on the instances of this process on to-spec queries.
keepGlobalVariables
Specify whether the server can keep global variable values in the instance store when the instance completes:
  • false (default): Global variable values are deleted when the instance completes.
  • true: Global variable values are not deleted.
oneWayDeliveryPolicy
This property sets the persistence policy of the process in the delivery layer. The possible values are:
  • async.persist: Messages into the system are saved in the delivery store before being picked up by the engine.
  • async.cache: Messages into the system are saved in memory before being picked up by the engine.
  • sync: The instance-initiating message is not temporarily saved in the delivery layer. The engine uses the save thread to initiate the message.

XA datasource vs Non-XA datasource


















An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.


An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).


XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.


Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database. XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources


Thursday, September 9, 2010

Convert comma delimited data to XML NODESET using XSL transforms in Oracle BPEL

















ANOTHER METHOD

<?xml version="1.0" encoding="UTF-8" ?>
<?oracle-xsl-mapper <!-- SPECIFICATION OF MAP SOURCES AND TARGETS, DO NOT MODIFY. -->
  <mapSources>
    <source type="XSD">
      <schema location="source.xsd"/>
      <rootElement name="SourceCollection" namespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/source%22/>
    </source>
  </mapSources>
  <mapTargets>
    <target type="XSD">
      <schema location="target.xsd"/>
      <rootElement name="parameters" namespace="http://xmlns.oracle.com/Application1/target%22/>
    </target>
  </mapTargets>
  <!-- GENERATED BY ORACLE XSL MAPPER 11.1.1.3.0(build 100415.2045.2557) AT [WED SEP 08 18:02:30 IST 2010]. -->
?>
<xsl:stylesheet version="1.0"
                xmlns:ns1="http://xmlns.oracle.com/Application1/target"
                xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
                xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20"
                xmlns:ns0="http://xmlns.oracle.com/pcbpel/adapter/db/top/source"
                xmlns:mhdr="http://www.oracle.com/XSL/Transform/java/oracle.tip.mediator.service.common.functions.MediatorExtnFunction"
                xmlns:bpel2="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
                xmlns:oraext="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.ExtFunc"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:dvm="http://www.oracle.com/XSL/Transform/java/oracle.tip.dvm.LookupValue"
                xmlns:hwf="http://xmlns.oracle.com/bpel/workflow/xpath"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:med="http://schemas.oracle.com/mediator/xpath"
                xmlns:ids="http://xmlns.oracle.com/bpel/services/IdentityService/xpath"
                xmlns:bpm="http://xmlns.oracle.com/bpmn20/extensions"
                xmlns:xdk="http://schemas.oracle.com/bpel/extension/xpath/function/xdk"
                xmlns:xref="http://www.oracle.com/XSL/Transform/java/oracle.tip.xref.xpath.XRefXPathFunctions"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:ora="http://schemas.oracle.com/xpath/extension"
                xmlns:socket="http://www.oracle.com/XSL/Transform/java/oracle.tip.adapter.socket.ProtocolTranslator"
                xmlns:ldap="http://schemas.oracle.com/xpath/extension/ldap"
                exclude-result-prefixes="xsi xsl ns0 xsd ns1 bpws xp20 mhdr bpel2 oraext dvm hwf med ids bpm xdk xref ora socket ldap">
  <xsl:template match="/">
    <ns1:parameters>
      <xsl:variable name="commandString">
        <xsl:value-of select="/ns0:sourceCollection/ns0:delimitedString"/>
      </xsl:variable>
      <xsl:call-template name="populateParam">
        <xsl:with-param name="commandString" select="$commandString"/>
      </xsl:call-template>
    </ns1:parameters>
  </xsl:template>
  <!--  User Defined Templates  -->
  <xsl:template name="populateParam">
    <xsl:param name="commandString"/>
    <xsl:if test="string-length($commandString) > 0">
      <xsl:variable name="tempParam">
        <xsl:value-of select="substring-before($commandString,',')"/>
      </xsl:variable>
      <ns1:param>
        <xsl:choose>
          <xsl:when test="string-length($tempParam) > 0">
            <xsl:value-of select="$tempParam"/>
          </xsl:when>
          <xsl:otherwise>
            <xsl:value-of select="$commandString"/>
          </xsl:otherwise>
        </xsl:choose>
      </ns1:param>
      <xsl:variable name="residualCmdString"
                    select="substring-after($commandString,',')"/>
      <xsl:if test="string-length($residualCmdString) > 0">
        <xsl:call-template name="populateParam">
          <xsl:with-param name="commandString" select="$residualCmdString"/>
        </xsl:call-template>
      </xsl:if>
    </xsl:if>
  </xsl:template>

</xsl:stylesheet>

Sunday, September 5, 2010

Configuring the Common SOA Infrastructure Properties in Oracle 11g


















In Oracle SOA Enterprise Manager Console, there are few common SOA Infrastructure properties that helps us during development.


  • Audit Level
  • Composite Instance State
  • Payload Validation

In the EM console go to the SOA->soa-infra  and right click the soa-infra to see the Common Properties











By default the Audit Level is set to Production and others are unchecked.

  • Audit Level
               "Production" (default): Composite instance tracking is collected, but Mediator engine will not collect payload details and BPEL engine will not collect payload details for assign activities (payload details for other BPEL activities are collected). This level is optimal for most normal production operations.

"Development": Allows both the composite instance tracking and payload detail tracking. However it may impact the performance. This level is useful mostly for testing and debugging purposes.

"Off": No logging is performed. Composite instance tracking and payload details are not collected. 

  • Capture Composite Instance State 
                 Turning this feature on will allow for separate tracking for "running" instances. However, this may impact the performance. 

  • Payload Validation 
                Select to enable validation of incoming and outgoing messages.

 Choose the values accordingly as required and save the properties (no server restart required).

         
        Blogger Profile