TIBCO BW 5.X – Creating an API REST using the REST Plug-in

Normally when we create our process we include an input protocol to comunicate our process with the outside world. We can use a lot of technologies to do this expose to the outside, but normally the usual choices are HTTP and JMS. And when we talk about HTTP normally we are talking about WebService using HTTP/SOAP as the protocol.

But, nowadays it’s more common to have to deal with REST interfaces and also to expose a REST interface as a default option or as a second option (device oriented in most cases). Ok, so in this post we are going to see the main stepts to create an API REST in TIBCO BW 5.X.

First things first, The REST Palette (formaly is the REST & JSON Palette) is not included with the standard installation of the product so we need a plug-in to enable this capabilities. In the 6.x series this palette comes with the default and standard installation so no plug-in is required.

Ok, the first thing we have to know is that the REST Palette shares a lot of things in common with the Service palette with can use to define a Web Service without using the SOAP Palette, so if you have any experience creating Web Service this way, you are going to see that’s the steps are pretty similars.

As a first step we are going to create the skeleton of our process that is going to expose the REST interface, and it’s going to be a very easy and small process only with 3 activities.

The first activity is the HTTP Receiver because we still need the HTTP connection and the data coming from the outside using HTTP. Then we are going to use the new activity the plugin provide to us named REST Dispatch and RY. Finally we have the End activity. The full process is shown in this picture:


Ok, now we have to create the interface of our REST Service and we need to create a WADL artifact. A WADL is the REST equivalent to the WSDL artifact when we are talking about SOAP Web Services. And we have two ways to do it:

  • We can create an WADL artifact using the WADL Palette you are going to see in the TIBCO Designer when you install the REST plug-in and then reference it in the REST Dispatch and Reply activity configuration.
  • You can define it, inside the REST Dispatch and Reply activity.

In this first example we are going to do it the second way but the steps are very similar for the other one. We go to the Service Editor tab  inside the REST Dispatch Activity Settings and using the Context Menu we start to create the service, as you can see here:


In our case we are going to create a Rest Service called “RestService” with one Resource inside called “TestResource” and inside one method called “sayHello”, as you can see here:


There are a few aspects that are important regarding the configuration of this service definition:

  • When you create the Resource, you have to specify the Resource Path, that’s a URL relative path that later you are going to have to use to do the invocation. Think that the complete URL is going to be something similar to this: http://server:port/<resource>/ and then the HTTP Method is the one that is going to decide with operation are you invoking.
  • When you create the resource, you also have to define the parameters of the resource and you have a table to do that. In our case we are going to create one parameter named ‘name’.
  • When you create the method you have to specify a BW Sub-Process that is going to be the one who is really implementing the service. In our case the service is so simple that we don’t need any aditional activity. We only use the Start and the End, because we want to concatenate the input parameter to a constant string.
  • When you already specify the subprocess you have to assign which input parameter from the  BW Process should be map into the BW Subprocess and which output parameters should be recovered from the process. To do that you have the “Bind” button inside the method definition.

And that’s it! You have your API REST completed and ready to test. To do that, in my case I’m using the SOAP UI. To create the request in the SOAP UI we need the WADL file, and we can export it using the button “Export WADL” inside the REST Dispatch and Reply settings.



As usual, you can check the code in our GitHub repo and try it yourself. Here is the direct link: Download!


7 thoughts on “TIBCO BW 5.X – Creating an API REST using the REST Plug-in

  1. Thank you for your post, I’ve tried and it works. I would like to apply a basic authentication for my REST service but it seems unable by TIBCO (unlike SOAP we can use policy). Any idea ? Best regards

    • Hi Dany. First of all thank you for your comment. Which BW 6.x version are you using right now? I’m asking that because in the Release Notes I can read the from the 6.2.1 version the Basic Authentication is supported when you create a REST Binding Service. You can check it here:https://docs.tibco.com/pub/activematrix_businessworks/6.3.0/TIB_BW_6.3.0_relnotes.pdf

      But that’s the information I could retrieved it:

      Basic Authentication support for REST Binding
      and Invoke REST API activity

      The REST Service Binding and the Invoke REST API activity support Basic Authentication. The REST Service Binding can be configured using a check box in the Binding Configuration. When the check box is selected, the REST Binding uses the LDAP Shared Resource configured on its HTTP Connector to perform Basic Authentication. The Invoke REST API activity automatically adds the authorization header with the user credentials if an Identity shared resource is configured on the HTTP Client shared resource. See REST Binding for details.

  2. Thanks that makes sense. I decided that with the above scenario, I could create one process containing many branches/transitions to handle the additional non-required query types.

  3. Could you explain how to use multiple methods in one REST Service’s Resource? I have a REST Service that has multiple resources that work fine with one Method. But as soon as I add another method to a Resource (that has the first method’s param plus another param) input and bind to it, it ignores the second method and picks up the first only. Example – I have a Method called GetABCByType with input param of statusType. The second Method I cannot get to work is called GetABCByTypeAndDate with input params of dateType & statusType. Any ideas?

    • Hi madelyn first of all, thank you for your comment. You can have diferent methods inside one REST resource. The only limitaiton is that any methods should use a different HTTP Method. (So, you can only have one method that implements a GET request, only method that implements a POST request, PUT Request and so on) If you want more detail I can create a post about that thing, so you can have a working sample to get it working. Best regards,

      • Thanks that makes sense. I decided that with the above scenario, I could create one process containing many branches/transitions to handle the additional non-required query types.

      • You approach is going to work but you will have inline operation definition. This solution is maybe not optimal for a design/architectural view but it will definitely work.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s