Routing Rules in a Mediator component carry several attributes that govern the routing rule run time behavior. These include: XSLT or XQuery used for transformation, the filter expression, target operation, the parallel or sequential indicator, the Schematron document used for validation, the native validation and the value assignment (for example for header properties).
In SOA Suite 12c, we can conditionally set overriding values for each of these attributes. That means that at run time, based on the evaluation of some expression against the contents of the request message (or the time of the day, day of the week,…) , we can use a different transformation stylesheet or assign a different header value. This dynamic override of the static rule definition is configured using the Override Using option – shown last in the figure overhead.
The Override Using can work with either a Business Rule component or a Domain Value Map to derive the values to be used for each routing rule attributes. In this article I will show the DVM variant.
With the override based on a DVM, we have to define an XPath expression that derives the key with which we will look a record in the Domain Value Map. If no record is found, no override takes place, and the static values are used to process and route a request message. However, when the key does return a row from the DVM, then each of the routing rules attributes can (but does not have to be) overridden.
Note: override is only available for Request processing – not in the Response phase. Furthermore, override is not available for routing rules that do an Echo or rules for Event (EDN) subscriptions.
In the example that follows next, we will have a Mediator that implements a simple synchronous interface with one operation. A string (we tacitly assume it contains a name) and some string gets returned: your basic Hello World example. The mediator routes to a BPEL process that produces a special greeting.
The Mediator has very simple behavior: no filtering, validation, content based routing or even transformation. All it does is assign the value it receives in the request message to the outgoing message:
In this situation, we will add a little bit of dynamic behavior: when the value of the process/input element in the request message is long – longer than 6 characters – we want this value to be passed in UPPERCASE to the BPEL process. If the value is shorter, then nothing should be done. In order to achieve this, we will use the Override feature and we will use the feature only for the Assign Values attribute; all other routing rule properties will be left alone.
Add the Override to the Mediator Routing Rule
Open the Mediator editor. Click on the icon behind the Override Using field.
A popup appears: the Override Routing editor. Select the radio button Use Domain Value (as opposed to Use Decision Component). Press the green plus icon to have new Domain Value Map created
A new DVM is created. It has domains setup corresponding to the routing rule attributes that can be overridden. The editor for the DVM opens. Click on the green plus icon to add a [set of] Domain Values:
A new row is added in the DVM. The first column contains the key: this is the string value against which the Value Expression we will specify a little later will be compared. This value is set to long.
Click on the edit icon for selected row. An editor window opens. Click on the edit-icon for the Assign [Values] attribute. The Assign Values editor opens:
Here is specified that the output passed onwards from the routing rule is the uppercased value from the input.
The total set of domain values associated with the key long is shown here:
Note that only one of these is really relevant – the Assign Values expression.
Click OK to close this dialog. Next up: the value expression.
Whenever the input element contains a string that is longer than 6 characters, we want the domain value set under key “long” to be applied. In all other cases we do not need any overriding at all. We achieve the latter by producing a value “notlong” for which there is no record in the DVM. The result is that no overriding is applied.
The XPath expression uses a little trick that works like an IF-THEN-ELSE or a DECODE or a Ternary expression:
when the expression string-length($in.payload/client:process/client:input) > 6 evaluates to true, the numerical equivalent is 1 and the first substring expression becomes substring(‘long’, 1, 4) evaluating to ‘long’. The expression ‘string-length($in.payload/client:process/client:input) <= 6’ in that case evaluates to false whose numerical equivalent is 0. The second substring therefore returns an empty string as substring(‘notlong’,1,0) evaluates to ‘’. Note: this clever use of substring is something called Becker’s method and I picked it up here.
Next, we have to specify which features in the Routing Rule should be overridden:
We need only one feature to be overridden: the Assign Values feature. All other attributes of the Routing Rule are untouched – and all other domains in the DVM are irrelevant. Only the domain (column) Assign is actually used from the DVM.
Press OK to complete the configuration of the override.
Deploy the composite. Time to try it out.
Test Run the Mediator with Override inside
Invoke the service exposed from the Mediator with a string value shorter than 7 characters:
For the input “tom” we receive the greeting “Hello dear tom”. Clearly, no uppercasing applied.
However, when we invoke the service with the input value “richard” – longer than 6 characters – the override kicks in:
Thanks to the override value for Assign Values, we now get “Hello dear RICHARD” with the input string uppercased.
The mediator audit trail provides some insight in the fact that an override may have been involved. However, it does not tell us which key value was produced by the expression, which row from the DVM was retrieved (if any) and what the overriding values were that were read from that DVM record and for which attributes. From the Assign step however, we can see for ourselves that the assign expression from the DVM was used in this case – the one with uppercase in it.
It would seem that many use cases can be addressed with this conditional override of mediator routing rules properties. Note that the key expression can leverage more than just the contents of the request message – current date and time being examples of more dynamic, contextual values that can be used.
