Oracle SOA Best Practices

Rollbacking EBS API's using BPEL

2009-07-08T06:55:00.000-07:00

We are performing multiple activities in sequence( updating a database using database adapter , calling a Oracle EBS API using oracle applications adapter and inserting data in a queue using JMS adapter or AQ adapter etc.) Now our requirement is to roll back all the activities if any of the above mentioned activity fails.Solution: To achieve this we need to configure our BPEL process for JCA-XA transactions. This is requires following set up:1. Set up JNDI name in oc4j-ra.xml and datasources.xml2. Make Changes in BPEL.xml to make your bpel to participate in transaction.For this we need to set the property transaction of BPEL and all partner links to participate as shown below.Scenario : We are performing multiple activities in sequence( updating a database using database adapter , calling a Oracle EBS API using oracle applications adapter and inserting data in a queue using JMS adapter or AQ adapter etc.) Now our requirement is to roll back all the activities if any of the above mentioned activity fails.Solution: To achieve this we need to configure our BPEL process for JCA-XA transactions. This is requires following set up:1. Set up JNDI name in oc4j-ra.xml and datasources.xml2. Make Changes in BPEL.xml to make your bpel to participate in transaction.For this we need to set the property transaction of BPEL and all partner links to participate as shown below.

< version =" '1.0'" encoding =" 'UTF-8'?"><>< id="TestTransaction2" src="TestTransaction2.bpel"><>< name="client">< name="wsdlLocation">TestTransaction2.wsdl< name="TestAccount">< name="wsdlLocation">TestAccount.wsdl < /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< name="TestLocation">< name="wsdlLocation">TestLocation.wsdl< /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< name="OA_Rollback">< name="wsdlLocation">OA_Rollback.wsdl< /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< /partnerLinkBindings><>< faultpolicy="TestConditionPolicy">< /faultPolicyBindings><>< name="transaction" encryption="plaintext">participate< /property>< /configurations>< /BPELPrHere we need to make sure that fault policy applied to BPEL is not sending your BPEL to manual intervention. Because while sending the BPEL on manual intervention all the activities gets committed so rollback will not be possible in that case.Once above setup is done we are good to go. Now we have two possibilities:1. BPEL is not configured to catch the faults thrown.2. BPEL is configured to catch the faults thrown.BPEL is not configured to catch the fault thrown:In this case as soon as the fault is thrown , all the activities automatically gets rolled back.Disadvantage: Here the disadvantage is all the activities which are part of the transaction will get rolled back and we will not be able to see anything on BPEL console. It will appear that BPEL instance was never created.BPEL is configured to catch the faults thrownIn this we have to explicitly call the rollback. This can be done in two ways:1. Explicitly throwing the bpelx:rollbackFault< name="Throw_1" faultname="bpelx:rollback">Once the error is caught by the fault handler we can do the activities we want to and after that we can throw the rollback fault which will result in to the rollback of all activities part of the rolled back transaction.In this case also disadvantage is we will not be able to see anything on BPELCONSOLE.2. Calling a procedure containing the rollback statement.This procedure will look like followingPROCEDURE "XXDPI_ROLLBACK" ASBEGINrollback;END;Now once the error is caught you can explicitly call this procedure to cause the rollback of statements executed on a particular database. So if there are multiple databases, you will have to multiple such procedures.Advantage: Advantage of this approach is that your BPEL instance still remains there and u can easily see what has actually happened and all the database statements executed also gets roll backed. >< id="TestTransaction2" src="TestTransaction2.bpel"><>< name="client">< name="wsdlLocation">TestTransaction2.wsdl< name="TestAccount">< name="wsdlLocation">TestAccount.wsdl < /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< name="TestLocation">< name="wsdlLocation">TestLocation.wsdl< /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< name="OA_Rollback">< name="wsdlLocation">OA_Rollback.wsdl< /property>< name="retryInterval">60< /property>< name="transaction">participate< /property>< /partnerLinkBinding>< /partnerLinkBindings><>< faultpolicy="TestConditionPolicy">< /faultPolicyBindings><>< name="transaction" encryption="plaintext">participate< /property>< /configurations>< /BPELPr

Here we need to make sure that fault policy applied to BPEL is not sending your BPEL to manual intervention. Because while sending the BPEL on manual intervention all the activities gets committed so rollback will not be possible in that case.Once above setup is done we are good to go. Now we have two possibilities:1. BPEL is not configured to catch the faults thrown.2. BPEL is configured to catch the faults thrown.BPEL is not configured to catch the fault thrown:In this case as soon as the fault is thrown , all the activities automatically gets rolled back.Disadvantage: Here the disadvantage is all the activities which are part of the transaction will get rolled back and we will not be able to see anything on BPEL console. It will appear that BPEL instance was never created.BPEL is configured to catch the faults thrownIn this we have to explicitly call the rollback. This can be done in two ways:1. Explicitly throwing the bpelx:rollbackFault< name="Throw_1" faultname="bpelx:rollback">Once the error is caught by the fault handler we can do the activities we want to and after that we can throw the rollback fault which will result in to the rollback of all activities part of the rolled back transaction.In this case also disadvantage is we will not be able to see anything on BPELCONSOLE.2. Calling a procedure containing the rollback statement.This procedure will look like followingPROCEDURE "XXDPI_ROLLBACK" ASBEGINrollback;END;Now once the error is caught you can explicitly call this procedure to cause the rollback of statements executed on a particular database. So if there are multiple databases, you will have to multiple such procedures.Advantage: Advantage of this approach is that your BPEL instance still remains there and u can easily see what has actually happened and all the database statements executed also gets roll backed.

Transaction Processing in Oracle BPEL Processes

2009-07-08T01:55:00.000-07:00

Just been working with a couple of colleagues on documenting how to migrate transactional processes from WebLogic Integration (WLI) to BPEL and thought I would blog about transaction support in BPEL. First off there are a couple of contradictory statements that need to be made.
BPEL does not have transaction delineation
Oracle BPEL Process Manager supports transactions
The first statement relates to the BPEL language which has no way of marking the start or end of XA style transactions, instead it provides semi-automated recovery through the concept of compensation, but more on this in another entry.
The second statement relates to the Oracle implementation of BPEL. BPEL is inherently a stateful language and the BPEL Process Manager uses XA transactions to manage that state. It also allows XA transactions to extend beyond the boundaries of the active BPEL process. In this post I will try to explain a little about how this works.
Transactions Everywhere
Every BPEL process executes in the context of one or more transactions. When a process starts to execute the process manager does one of two things with transactions;
It starts a new transaction for the process.
It enlists the process in an already open transaction.
BPEL uses this transaction to update process state in the database and also log audit events in the database. Even if all this is turned off the process manager will still have processes execute in a transaction context. When invoked through a web service interface BPEL will use the first option as there will not be a transaction context available. When invoked through the Java API in a transactional environment then the process manager may use either option depending on the parameters used in the call.
Lazy Boy
BPEL will try to squeeze as many activities into a single transaction as it possibly can. Only a few activities actually cause the process manager to update the process state in the database and commit the transaction. A given activity does not always cause a transaction to be committed, sometimes the process may keep the same transaction context because of the properties associated with the activity.
Enlisting Support with a Little Participation
When BPEL calls an adapter, the ESB or another process in the same BPEL domain then it has the option to either include the target in the same transaction, or to start a separate transaction. This behavior is controlled by the “transaction” property in the partner link. If the “transaction” property value is set to “participate” then the callee is enlisted into the current transaction, if it is unset or set to any other value then the callee executes in a seperate transaction. This is great for ensuring that several database updates are all included as part of the same transaction, but it does have a downside. If any of the callees rolls back the exception then the the current BPEL process state is also rolled back to the last commit. If there has been no commit and this process was invoked through a synchronous interaction then the process will seem to disappear from the face of the earth. Something to be aware of. To minimise the impact of this the database adapter will throw an error rather than rollback the transaction if by so doing it would not affect transactional integrity (basically you can do one DB update without rolling back but if you do two then an error will cause a rollback).
Parallel Execution
You might think that a BPEL flow activity would cause a new transaction to be started as this allows several activities to be executed in parallel. However this is not the case as the BPEL Process Manager will try to execute the flows sequentially for efficiency purposes. Only if some action in the flow would cause a new transaction to be started will the activities execute in parallel. A common use case for this is when a flow is used to make several synchronous calls. Normally they would all execute in the same transaction context, however this means that the services are called sequentially, which can add latency to the application. To avoid this there is another partner link property, “nonBlockingInvoke”, which when set to “true” causes a new thread to be spawned to execute the invoke. The upshot of this is that a new transaction is started and this allows for true parallelism in the flow.
Lets Talk About Commitment
The general rules about what causes a commit are pretty straightforward, the BPEL process will commit the transaction and start a new one after the following activites
receive – unless it is the first receive in the process and the process was called with a “transaction=participate” property (possibly by marking it as such in the partner link) in which case the process participates in the already existing transaction.
onMessage
wait – for very short waits (up to a couple of seconds) the process manager will not commit the transaction.
onAlarm
invoke – only if the partner link is non-idempotent (can be marked with the “idempotent” partner link property).
End of process flow – only if the process is not participating in the callers transaction (the corollary of the receive).
The table below summarises the transaction status when performing different activities.
Activity
Transaction Status in BPEL Process
Transaction Status in Target Process or Adapter
Receive
New Transaction
N/A
Receive with Property “transaction=participate”
Use Existing Transaction from Caller
N/A
Invoke Synchronous Process
Use Existing Transaction
New Transaction
Invoke Synchronous Process with Partner Link Property “transaction=participate”
Use Existing Transaction
Use Existing BPEL Transaction
Invoke Synchronous Process with Partner Link Property “idempotent=false”
New Transaction
New Transaction
Invoke Synchronous Process with Partner Link Property “nonBlockingInvoke=true”
New Transaction
New Transaction
Invoke Asynchronous Process
Use Existing Transaction
New Transaction
Invoke Asynchronous Process with Partner Link Property “transaction=participate”
Use Existing Transaction
New Transaction
Invoke Synchronous Process with Partner Link Property “idempotent=false”
New Transaction
New Transaction
Wait < a couple of seconds
Use Existing Transaction
N/A
Wait > a couple of seconds
New Transaction
N/A
Flow
Use Existing Transaction

Flow
You may be surprised to see flow on the list, and then even more surprised to see that it uses the existing BPEL transaction context. The reason for this is that the BPEL process manager will try to execute all the flow legs sequentially and so the behavior of the flow will be determined by the activities in the flow rather than the actual flow itself.

HOw to Call WSSE secured web service from BPEL

2009-04-16T05:55:00.000-07:00

1.Create partner link to the gateway that is wrapping the actual service as shown below.

2.Create a new BPEL variable as shown

The username and password that should be provided to the service gateway should be in the SOAP header of the partner link call. For this we need a BPEL variable that is based on an XSD that is provided by OASIS.

Please click for XSD here

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd

Now create a BPEL Security_header variable based on the Security variable defined in this schema. This variable is of type: ANY_TYPE, but I will address that later.

3. Provide the authentication details to the new security variable The Security_header variable of type security is of ANY_TYPE type. But are now going to assign a piece of XML as the variables value. This piece of XML will contain the username and password; in this case username/password.
Create an assign activity and copy the following XML to the variable

4. The value of the variable should be inserted in the SOAP header of the partner link call.

Loging details have to be provided in the SOAP header, that’s how WS-Security provides authentication details. That can be done by providing the the Security_header variable as a header variable during the Invoke activity. Of course you need to provide the proper input and output variables on the invoke activity.

That’s it. We have created a variable, provided our username and password to the variable. We have then put that variable in the SOAP header. The BPEL process we have now created looks like:

Test the BPEL process confirm the same.