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.
How to pass SOAP headers to and from backend service in parallel calls. In an ideal world, a split-join service would pass any SOAP headers to the backend service and back without any effort. In the real world, the headers inevitably get lost along the way. There is apparently a predefined set of conditions that both the WSDL and the request must comply with for the headers to travel through safely; however, most services I see in the real world simply do not comply.
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.
A 10000-ft view of an OSB domain, in 5 minutes, with TransitMap. Is it possible to understand the inter-connectivity of a complex OSB domain? Is walking through the code step by step and making notes, both on paper and mentally, the only way? Can we generate a diagram of the domain? I have created a utility that visualizes an OSB domain or a selected subset of projects in one, to help me in figuring out some of the most complex projects I have to work with.
Using Unit-of-Order with OSB. Download the test project. Unit-of-Order (UOO) is an Oracle (BEA) extension to standard JMS. It enforces the order of messages with the same key so that the messages are consumed in the order they were added to the queue. This functionality works in a cluster, too, by assigning each UOO key to one and only one managed server. When Ordered Updates Are Needed Suppose I update my phone number on a site.
How to read and update JSON in OSB. Download the full example. UPDATE from future! DO NOT CONVERT JSON to XML! It is a pain if you need to convert it back! Use Javascript! Using Javascript to Inspect & Modify JSON Payload See other posts about OSB & JSON: Why JSON Does Help Direct Proxy Performance How To Build a JSON Pass-Through Proxy in OSB OSB and JSON Proxies: Gathering Statistics We can make a pass-through JSON proxy in OSB pretty easily.
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.
A service’s domain-wide throttling value may be different from what you have configured for it. I have mentioned already that the throttling value assigned to a service on a specific managed server is calculated as the throttling value from the configuration divided by the number of managed servers, and rounded up if not whole. There are curious extensions from this statement. Servers May Have Unequal Throttling (e.g. 6, 6, 4) Huh?
Sharing Max Threads Constraint between multiple Work Managers causes them to share the same thread pool. It is natural to think of a Work Manager as a thread pool, and of Max Threads Constraint as a property of that pool. Therefore it is natural to create, say, 3 Work Managers and assign each of them a Max Thread Constraint of 30 – the same named constraint (e.g. “MaxThreads30”). The problem is that it’s wrong.
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.
