Dynamic Routing to Foreign Pipelines and Flow

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.

New Syntax for New Features

OSB 12 introduces two new ways to use dynamic routing’s route structure.

For calling pipelines, there is this format:

<ctx:route xmlns:ctx="http://www.bea.com/wli/sb/context">
     <ctx:pipeline>CustomerProfile/Internal</ctx:pipeline>
     <ctx:operation>GetCustomerProfile</ctx:operation>
</ctx:route>

And for calling flows (split-joins), there is this:

<ctx:route xmlns:ctx="http://www.bea.com/wli/sb/context">
     <ctx:splitjoin>CustomerProfile/AllLOBs</ctx:splitjoin>
</ctx:route>

Note that split-join DR cannot have the operation element, because a flow always supports one and only one operation (unlike GenericParallel, by the way).

The syntax for calling proxy and business services remains the same:

<ctx:route xmlns:ctx="http://www.bea.com/wli/sb/context">
    <ctx:service isproxy="true">CustomerProfile/Internal</ctx:service>
    <ctx:operation>GetCustomerProfile</ctx:operation>
</ctx:route>

Not All Roses

Unfortunately, there is a serious restriction.

You can NOT call pipelines and flows that are located under a different OSB project.

This is unfortunate for any supporting code that uses DR.

For example, in our domains we have the Common project, which contains proxies that perform various generic tasks (error handling, auditing, common header injection and so on), and then use DR to route the message to proxies in other projects.

We would like to update some of the routing destinations to the pipelines instead of proxies and then may be get rid of unnecessary local proxies.

For instance, this is how we might call the Internal pipeline directly from the Audit pipeline via a dynamic route:

But the restriction above causes this fault:

OSB-382190 Component Pipeline CustomerProfile/Internal may not be invoked because it exists in a different project

Disappointing.

But there is a way.

Using Thunks to Call Foreign Pipelines

Thunks are a way for a piece of code to call another piece of code that is normally not accessible. For instance, a 32-bit code may call a 64-bit function via a special 32-bit thunk that re-packages the parameters and then calls the 64-bit code.

In the context of DR, a thunk is a special proxy whose entire purpose is to allow calls to pipelines and flows within its project. The target pipeline or flow path is passed to the thunk proxy as a user header.

That proxy’s only job is to perform a yet another DR, now to the final destination.

This is not faster than calling the pipeline via its own proxy, but it allows us to delete all unused local proxies. We then will use the same Thunk proxy for all CustomerProfile’s internal pipelines:

As an example, here’s the thunk proxy used in GenericParallel 1.4:

1. Load the DR’s structure from a user header. It will be passed as string, so a inlinedXml() call will be needed.

2. Pass all other headers to the target pipeline or flow.

3. Pass all headers returned by the target pipeline or flow, back to the caller.

4. Catch faults and respond with failure if soap:Fault is found.

GenericParallel code, when it needs to call a pipeline or a flow, dynamically determines whether the target project has the GenericParallelThunk proxy, and if it has, calls the target service via that thunk.

Hence, to support parallel calls to pipelines in foreign projects, the developer just needs to copy the GenericParallelThunk proxy to the target project.

Not as easy as I wish, but still pretty easy.