A Sequence Template is a parametrized sequence, providing an abstract or generic form of a sequence defined in the WSO2 ESB. Parameters of a template are defined in the form of XPath statement/s. Callers can invoke the template by populating the parameters with static values/XPath expressions using the Call Template Mediator, which makes a sequence template into a concrete sequence.
When you create a sequence template you get a completely empty template. This actually looks a lot like a sequence which of course is logical since this is a sequence template.
But why would you use a Template sequence? Couldn’t you just as simply define variables in the messageContext and read them from the sequence itself?
Yes you could do that. But with the call template mediator you can simply pass the parameter to the template sequence.
Image that you need to check numbers to see if they are valid. There are several algorithms to do that like the ones used in IBAN banking numbers. However, to keep it simple we would like to see if the modulo of the number divided by 3 is zero. In other words, the number is a real multiple of 3, e.g. 3, 6, 9, 12 and so on.
In XPATH this can be done using a simple MOD function. Consider this xml and xpath statement.
It returns true since 3399 is a multiple of 3. So how do we incorporate that in a template sequence?
Creating the template
We create a simple Sequence Template and add two log mediators and a simple filter mediator.
This however does not show what is going on. So let’s look at the source code:
<?xml version="1.0" encoding="UTF-8"?>
<template name="Test" xmlns="http://ws.apache.org/ns/synapse">
<parameter name="number"/>
<sequence>
<log level="custom">
<property expression="$func:number" name="service"/>
</log>
<log level="custom">
<property expression="$func:number mod 3" name="service"/>
</log>
<filter regex="0.0" source="$func:number mod 3">
<then>
<log level="custom">
<property name="service" value="a valid number"/>
</log>
</then>
<else>
<log level="custom">
<property name="service" value="an invalid number"/> </log>
</else>
</filter>
</sequence>
</template>
The flow is quite simple. We filter on a binary decision: it is either a multiple of three (so mod 3 = “0.0”) or it is not. In the case it is a multiple, we enter the then branch and put ‘a valid number’ on the console.
In case it is not, we branch to else and put ‘an invalid number’ on the console.
This example does little else than putting valid or invalid on the console. You need to extend it to be more meaningful.
Creating the proxy
We create a proxy with the following calls and a respond mediator to end the flow.
The source looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<proxy name="TemplateTest" startOnLoad="true" transports="http https" xmlns="http://ws.apache.org/ns/synapse">
<target>
<inSequence>
<call-template description="calling" target="Test">
<with-param name="number" value="3399"/>
</call-template>
<call-template description="calling" target="Test">
<with-param name="number" value="3400"/>
</call-template>
<respond/>
</inSequence>
<outSequence/>
<faultSequence/>
</target>
</proxy>
As you can see we will call the sequence template twice with a valid and invalid number.
We will not describe the process of creating a C-App and Car file and deploying it to the server. You can try it out by downloading the CAR file from https://bitbucket.org/yenlo/yenlo_blogs/downloads/TemplateCAR_1.0.0.car.
Trying the proxy
Since we do not have to send a Soap message to the proxy, tryit from the management UI is the simplest way to test. Go to Deployed Services in the ESB Management UI and Select Try this Service.
Just click Send and observe the output on the console.
Observer the output.
[2017-07-19 16:35:27,102] INFO - ApplicationManager Successfully Deployed Carbon Application : TemplateCAR_1.0.0 {super-tenant}
[2017-07-19 16:35:35,365] INFO - LogMediator service = 3399
[2017-07-19 16:35:35,365] INFO - LogMediator service = 0.0
[2017-07-19 16:35:35,366] INFO - LogMediator service = a valid number
[2017-07-19 16:35:35,366] INFO - LogMediator service = 3400
[2017-07-19 16:35:35,366] INFO - LogMediator service = 1.0
[2017-07-19 16:35:35,366] INFO - LogMediator service = an invalid number
Alternative
We could have created variables in the messageContext and used a get-property to retrieve the value and perform the MOD operation. However this method with a parameter in my opinion creates better readable source code.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
