BPEL | PaaS Community Blog

Asynchronous interaction in Oracle BPEL and BPM. WS-Addressing and Correlation sets by Maarten Smeets

November 9, 2016 Leave a comment

There are different ways to achieve asynchronous interaction in Oracle SOA Suite. In this blog article, I’ll explain some differences between WS-Addressing and using correlation sets (in BPEL but also mostly valid for BPM). I’ll cover topics like how to put the Service Bus between calls, possible integration patterns and technical challenges.

I will also shortly describe recovery options. You can of course depend on the fault management framework. This framework however does not catch for example a BPEL Assign activity gone wrong or a failed transformation. Developer defined error handling can sometimes leave holes if not thoroughly checked. If a process which should have performed a callback, terminates because of unexpected reasons, you might be able to manually perform recovery actions to achieve the same result as when the process was successful. This usually implies manually executing a callback to a calling service. Depending on your choice of implementation for asynchronous interaction, this callback can be easy or hard.

WS-Addressing

The below part describes a WS-Addressing implementation based on BPEL templates. There are alternatives possible (requiring more manual work) such as using the OWSM WS-Addressing policy and explicitly defining a callback port. This has slightly different characteristics (benefits, drawbacks) which can be abstracted from the below description. BPM has similar characteristics but also slightly different templates.

When creating a BPEL process, you get several choices for templates to base a new process on. The Synchronous BPEL template creates a port which contains a reply (output message) in the WSDL. When you want to reply, you can use the ‘Reply’ activity in your BPEL process. The activity is present when opening your BPEL process after generation by the template, but you can use it in other locations, such as for example in exception handlers to reply with a SOAP fault. If you want to call a synchronous service, you only need a single ‘Invoke’ activity.

The output message is not created in the WSDL when using the One Way or Asynchronous templates. Also when sending an asynchronous ‘reply’, you have to use the Invoke activity in your BPEL process instead of the ‘Reply’ activity. One Way BPEL process and Asynchronous BPEL process templates are quite similar. The Asynchronous template creates a callback port and message. The ‘Invoke’ activity to actually do the asynchronous callback is already present in the BPEL process after it has been generated based on the template. The One Way template does not create a callback port in the WSDL and callback invoke in the BPEL process. If you want to call an Asynchronous service and want to do something with an asynchronous callback, you should first use an ‘Invoke’ activity to call the service and then wait with a ‘Receive’ activity for the callback. Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: Maarten Smeets,BPEL,SOA Suite 12c,SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress

Filed under SOA Tagged with BPEL, Jürgen Kress, Maarten Smeets, OPN, Oracle BPM, Oracle SOA, soa community, SOA Suite 12c

How to terminate an instance after transaction rollback and return response to caller by Rajeev Misra

August 2, 2016 Leave a comment

We have seen in several customer scenarios where a Parent BPEL process calls a child BPEL process asynchronously. If child process runs into any kind of business or system fault, fault handler sends callback to parent process with failure information. Please note, since parent had invoked child process asynchronously, child can’t throw fault back to parent. Callback is only mechanism to inform parent about the failure in child process execution during asynchronous interaction. This pattern works fine if transaction of child process is not getting rolled back. If child process encounters some error where underlying JTA transaction is marked for rollback, callback may not reach parent process if parent and child are collocated. This is because, callback invoke from child to parent will use the child’s JTA transaction to save callback in dehydration store, but since child’s transaction is in rollback state, callback message information would be rolled back from dehydration store after JTA transaction rolls back.

Second issue is while trying to terminate an instance after it has encountered error which results into transaction rollback. Since terminate state update of instance in dehydration store will be rolled back with transaction, any attempt to execute terminate in fault handler will be futile.

We are recommending a pattern that could help resolve both of above problems. Please look at the flow: Read the complete article here.

SOA & BPM Partner Community

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: Rajeev Misra,terminate instance,rollback,SOA Suite 12c,SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress,BPEL

Filed under SOA Tagged with BPEL, Jürgen Kress, OPN, Oracle BPM, Oracle SOA, Rajeev Misra, rollback, soa community, SOA Suite 12c, terminate instance

Synchronizing databases through BPEL services by Lykle Thijssen

January 31, 2016 Leave a comment

Introduction

This blog post is about how to synchronize two databases through BPEL, focusing on transaction, rollback and fault handling.

During a project, I’ve encountered a situation where we wanted to migrate from an old database to a new one. However, in order to gradually move external systems from the old to the new database, it was required that both databases would be kept in sync for a limited amount of time. Apart from the obvious database tools, for example Oracle Golden Gate, this can be done through the service layer as well and that’s what this article is about. I will explain how I have done it with a strong focus on fault handling, since that’s the most complicated part of the deal. In this case, since keeping things in sync is what we’re aiming for, a rollback needs to be performed on one database when the other fails to process the update.

One of the requirements is that it should be easy to throw the synchronization code away, as it has no place in our future plans. Another requirement is that the service layer should return faults in a decent manner.

Preparation

In order to enable out-of-the-box rollback functionality, make sure that the data sources connecting to both databases are XA enabled. As there is plenty of information about this subject, I will not get into detail about it in this blog.

Now we will be developing two services:

SalesOrderBusinessService: a BPEL process that receives messages from a BPM process and forwards them to our integration service
UpdateSalesOrderIntegrationService: a BPEL process that receives messages from SalesOrderBusinessService and updates two databases through adapters

We need to make sure that both services have a fault specified in their wsdl operation in order to return the recoverable fault. Read the complete article here.

SOA & BPM Partner Community

Blog Twitter LinkedIn Facebook Wiki