Updating REST Resource Interface

In the previous post we show how to create a REST resource with different query string parameters and parameters inside the URL, but how about updating this REST resource?

Ok, first of all, the official documentation doesn’t give us any idea about how to do that. So, at glance, you will probably think you can do it and you are going to remove your REST resource and create it again.

If that was your only option, it has no sense. Do you image to have to remove all your work only because you need another parameter or have to change the name of anyone? It has no sense at all.

Continue reading

Creating a REST Resource with a Query String parameter

In previous post I showed how to create a REST Resource inside our TIBCO BusinessWorks 6 projects. If you don’t remember the post you can take a look again here. In that post I showed how to create a REST resource without any kind of parameter but that’s not the real word.

When you define a REST interface it is usual to have parameters inside the URL that you have to use inside your process to make some kind of processing logic. It is common to have parameters to filter the current invocation or so. For example, think about this URL:


Here, we have two type of parameters:

  • The first one {format} it is “inside” the URL because it is a path step.
  • The second one {IP or hostname} it is a queryString parameter.

This post’s idea it is to show how to do this in TIBCO BusinessWorks 6.

Continue reading

TIBCO BW 6 – REST Based Service

In previous post I showed how to create a REST based service using TIBCO BW 5.x, but today I’m going to do the same using the 6.x series to highlight the differences between both of them.  Continue reading

TIBCO BW 6 – REST Resources in the same process

In the previous post I talked about how to create a REST Interface using TIBCO BW 6. If you want to take a look back, please go ahead. But in this post I want to focus in another feature that it is important when we are working with REST Resource. And it is the way to add different REST Resources inside the same BW Process.

Continue reading

TIBCO BW 6 – Integrating with Nexmo API (II): Creating the SSL Connection

In the previous post, we started a sample to create a SOAP wrapper to a SMS Rest API provided by Nexmo and we were capable of define a TIBCO BW 6 process that could create the exact request that the Nexmo Servers are expecting, but we need to configure the SSL connection to finish our sample, and that’s what we are going to do in this post.

If you miss the previous post I encourage you to take a look to get the context and the knowledge about the previos steps. Back to the future past.

Continue reading

TIBCO BW 6 – Integrating with Nexmo API (I): Defining the REST API

Usually I get a few mails from you regarding how to integrate with different services or systems that are not “standard” in the way we use when we are used to integration using TIBCO BW. This is so common when you are trying to consume REST services, because the standarization process is not the same in the REST Services that you can find when you are trying to integrate with a SOAP Service.

When you are trying to integrate with a SOAP Service you will always have your WSDL and that’s everything you need and the people from TIBCO only have to provide a way to generate all the artifacts from this WSDL but that’s not he same scenario when you are talking about a REST Services.

In different previous post I talked a lot about REST services and how they are so non-standard despite of the attempts like WADL in the first ages and now Swagger that maybe is the most common approach nowadays.  But the purpose of this post is not to talk about the problems when you are trying to use TIBCO BW to work with REST Service but to trying to integrate with a specific REST Service: Nexmo.

Continue reading

How to specify the Content-Type in your API REST

In the previous posts we talked a bit about how to create your REST Interfaces. Usually, when you are developing this kind of interfaces you use a JSON format in your payload. But, there is no default way to tell that to your API that the content-type that is replying is JSON. So, in this post I’m going to tell you how to do it.

Continue reading