June 27 2016

When creating asynchronous services, you don't normally worry about what happens if the service fails to callback to the parent process.  However, if the callback does fails, it can create major problems for the parent process, making it stall without an easy way to recover.  

Take, for example, the following process, called SubmitCreditCheck. The asynchronous Call: Perform Credit Check service blocks until the Receive: Perform Credit Check callback message is received. If, for whatever reason, this service doesn't return, the main process will be stuck and will not make to the Start: Report Write-up service; and it will never end.

Submit Credit Check

With a little bit of planning, however, you can implement a mechanism to recover from this problem and resume the process. This mechanism only requires the addition of a correlation ID at the start of the process and in the callback activity. Refer to Oracle documentation on correlation here.

Now if the service doesn't return a callback message, you can manually trigger the callback using the callback URL defined below.

http://hostname:port/SOA-infra/services/{partition}/{composite}/{subprocess}#{masterprocess}/Services.Externals.{subprocess}.reference

 

Reference in the example above

 

Corresponding Reference

partition = SOA partition, typically default
composite = master composite name with SOA-version ID, BoardReport, for example
subprocess = called subprocess name, PerformCreditCheck
parentprocess  = Parent Process Name, SubmitCreditCheck

No binding found for reference [PerformCreditCheck] of composite [default/BoardReport]. A callback endpoint cannot be created. Please make sure the composite is deployed to this server.Note: If you don't include the SOA composite version ID, you will get the following error:

Getting the SOA Composite Version ID

 

Enterprise Manager - Composite Information

 

 

 

 

 

 

 

 

 

Caution: Redeploying the composite using the same deployed version ID (for example redeploying Board Report and using the same version 1.0.31 ) will change this SOA-based version number. This may make it harder to find and recover in-flight instances for prior versions when they are deployed with the same deployment version.

In this example, the URL for the callback will be as follows:

http://SOA_server:7001/SOA-infra/services/default/BoardReport!1.0.31*SOA_407d5623-01a0-4ac4-85fb-4c131a61287f/SubmitCreditCheck.service#PerformCreditCheck/Services.Externals.SubmitCreditCheck.reference

The payload will be as defined by the callback port. Just be sure to set the correlation ID value in the payload so it will find the appropriate instance and trigger the callback.

Conclusion 

With a little bit of planning, you can create robust asynchronous calls that can recover when the calling service doesn't return a callback message to the parent process. This method works for all asynchronous services unless the service is a sub-process in the same composite as the parent process. This is because BPM uses an RMI call instead of an HTTP call.  However, simply move the sub-process to a separate composite, and this will work for you as well.

About the Author

Mark Peterson

Software Implementer using Business Process Management (BPM) for small to large firms. Used best practices in system design and software methodologies. Successfully executed projects on time and on budget using incremental and iterative software development methodologies.

Join the Conversation

Hillary Brandson
July 29, 2016

If the callback does really fail, it can create huge problems for the parent process without an easy way to recover. I guess there was a guide in one of the blog entries.

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.
By submitting this form, you accept the Mollom privacy policy.