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.
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 correlationhere.
Now if the service doesn't return a callback message, you can manually trigger the callback using the callback URL defined below.
Reference in the example above
|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
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:
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.
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.