It only takes 1 hour and a few simple steps to install and start using GenericParallel. Do it now! Please note: this guide project is available for your reference as an OSB project within the distribution ZIP under name QuickStart.jar. STEP 1. Download GenericParallel Extracted GenericParallel distribution Download the distribution ZIP and extract it into a temporal working directory. STEP 2. Import Into OEPE (Eclipse) OSB project before importing GenericParallel
This is the shortest guide for making an OSB parallel call with GenericParallel. I assume the GenericParallel service is already deployed on your domain. (If not, here’s the guide.) All you need to do then is to call the GenericParallel entry proxy located at GenericParallel/GenericParallel path. The entry proxy takes a list of requests to execute. For example, collecting the monthly bill for electricity and heating may look like this:
How to pass OSB user headers to and from the backend service in a parallel call. A split-join service drops all user headers. End of story. This is because split-join is not really an OSB service, but an implementation of a BPEL engine. It has no idea of OSB-specific concepts such as user headers. As usual, GenericParallel has a built-in workaround for this limitation. Passing User Headers to the Backend To pass user headers with requests via GenericParallel, the caller just needs to include them as attributes of the element.
Putting a cap on the maximum number of parallel request in GenericParallel. Parallel calls are an extremely powerful tool and, like any powerful tool, can be dangerous. Hitting a backend service with 5 parallel requests will reduce the response time. Hitting the same service with 50 parallel requests may bring that service down, causing a prolonged downtime. Overload Protection To prevent accidental overloading, GenericParallel uses the concept of maximum concurrency.
Dynamic routing to other projects’ pipelines and flows using thunks. OSB 12 is out. The dynamic routing functionality in OSB 12 has been extended with the ability to call pipelines and flows (a.k.a. split-joins) directly. A direct call to a pipeline is better for performance. A direct call to a flow is just more convenient than a call via a Biz with Flow transport: you do not need that Biz now, at all.
To get fault details in split-join’s CatchAll, call an intermediary proxy. When split-join invokes an OSB business service and that call fails, CatchAll does not help. Instead of detailed information of what went wrong, the fault variable contains only a single element from the BPEL extensions namespace. Utterly useless. At the same time, if the error is re-raised with the Re-Raise Error block, the code calling the split-join gets the correct description of the fault.
Throttling value, unlike the max threads constraint, is divided equally between all managed servers in the domain. Throttling allows you to limit the number of concurrent requests to a backend server. What is confusing is that the value is not per managed server, but for the whole domain. This makes sense, if you think of this use-case: You have a backend service that can only serve 20 connections at a time.
Most services are having all of their payload’s information in the soap:Body. Some though include meta-information located in the soap:Header. Surprisingly, Split-Join simply drops the soap:Header values. The documentation says it should support them, but I failed to make it work. What to do if you got to pass soap:Header values through Split-Join? How To Pass SOAP:Header In Plain Split-Join: A Hack If you have to use the naked Split-Join facility, I pity you.