In this new post we are about to discuss how to create a REST WebService using TIBCO BusinessWorks as a HTTP Server. The main goal of this new example is to continue learning how to use some of the basics of a TIBCO BW Development. First of all, we are about to present the ‘design’ (maybe, design it is a strong word for a little example).
As we can see in the picture posted above, the architecture of this new development, must be the following:
- A main process which main goal is accept the HTTP request and process it. It has the responsability to extract the parameters coded by the QueryString method. After that, we are about to invoke a ‘action process’. With the response of the action process we are about to create the HTTP response.
- Many helper processes which help the development doing little actions like extract the parameters or get the process name to invoke.
The input for this process must be an HTTP request with the following parameters:
- action: This parameter must decide which is the action process we are about to invoke. It’s a required one.
- parameter_<INDEX>: Optional parameter which action process are responsible to use in order to get completed its functionality.
An valid example of this request is the following: http://localhost:9090?action=concat¶meter1=aaa¶meter2=bbb and the response for this HTTP request is the following: aaabbb.
Now, we are about to get a first visual to the process developed to implement this logic:
As first node of the development we have an HTTP Receiver wich are going to handle the HTTP request to the localhost at the 9090 port, with the output, we are going to inspect the ‘action’ parameter and extract the ‘process name’ we have to invoke. The output of this subprocess is the path of the process (yes, the path of the BusinessWorks process) we are about to invoke in the next step. So, in the next step we are about to do a ‘dyanmic call process’. We are going to invoke the subprocess named as the getProcessName output, as you can see in the Call Process configuration:
With this configuration we are about to invoke the process name as the $GetProcesName/GetProcessNameOutput/processName parameter. If this parameter is not informed or filled, we are running the ‘default process’ (/Processes/ConcatProcess.process in this case). The parameter must have the path completed (/ is the root of the BW project, and must be ended with .process). This tecnique is better for modularity and exntensibility but its performance is a bit slow versus the static call process, as you can guess.
In this example we only provide one Action Process, but you can provide so many as you want, without modify the main structure of the development, only adding a few changes and a new process.
If we take a deeper look at the ConcatProcess, we can face the following:
In the first step we are going to extract the parameters, with the following structure (key-value pair), and in the mapper we are about to concat the value of the parameters which key starts with ‘parameter’. When you face a mapper you always must think in XPATH and XSLT scope, because you always can get a better approach versus the ‘structured programming approach’. As an example take a look of this:
In the first sight, maybe seems a little complex, but in only one line we are getting the concat of all the value nodes of the parameters which key contains ‘parameter’.
As always, you can download and test it this development here: Download!
I hope you can use these information in your new developments! See you in the next post!