TIBCO BW 6 – Conversations

Another new feature that we have in the latest version of TIBCO BW 6 are the Conversations. Conversations is a way to correlate different request inside the same process.

Normally when you have to correlate request inside the same process in the previous versions you have to delegate this responsibility in the capabilities of the protocol you were using to receive the request. For example, to do that correlation is normally to use the Correlation capabilities from the JMS protocol. But today, this feature is incorporated in the core of the product and you can have the possibility to use it no matter what protocol you are using to correlate this information.

I’m going to  create a sample to show how this feature works in this new version. The first thing we have to create is a WSDL with two operations. The first operation only is going to execute a sleep activity with a big time and the second operation is going to finish both requests. You can see here the process definition:

2015-11-22_13-33-18

You have to define which activities creates the Conversation and which ones Join the conversation in our case the first Receive activity is the one which is going to create the Conversation and we are using the “id” parameter as a Correlation Key. The second Receive activity, the one which implements the “cancel” operation, is the one which is going to be joining the Conversation using the id parameter as Correlation Key as well.

2015-11-22_13-35-45

And last but not least the final test about this feature. As always we are using the SoapUI, the first request is something like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.example.org/schema/1448190810063">
 <soapenv:Header/>
 <soapenv:Body>
 <ns:operationRequest>
 <in>aaaaa</in>
 <id>001</id>
 </ns:operationRequest>
 </soapenv:Body>
</soapenv:Envelope>

And the second one is something like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.example.org/schema/1448190810063">
 <soapenv:Header/>
 <soapenv:Body>
 <ns:cancelRequest1>
 <id>001</id>
 </ns:cancelRequest1>
 </soapenv:Body>
</soapenv:Envelope>

And then, both of the request finish, as you can see here:

2015-11-22_13-38-44

 

 

Advertisements

6 thoughts on “TIBCO BW 6 – Conversations

  1. Can you elaborate , how it differs to a service in BW 5.x which handles multiple operations.
    lets say operation1 receives request1 and receives response1 with ID as 1.
    Then consumer can request for operation2 using request2 which includes ID as 1 anticipating the response2.
    SO i believe the same is achieved in 5.x as well.What is difference in 6.x conversatio to the scenario i mentioned above.

    • This behavior could be achieve with 5.x of course. But it differs of the scenarios you are taking about in the following things:

      1) Converstations is about correlation between instances an processes.
      2) It’s the “new alternatives” of the Wait & Notify on TIBCO BW 5.
      3) It differs one the instance running one operations is changing the behavior of the instance running the other operation. It’s all about communicating processes.

  2. Could you please provide a business usecase of where we can implement this ? Just so that it is easier to correlate the topic.

  3. Is it possible to have a single operation start a conversation, then if called again with the same ID, join the conversation.

    A contrived example would be, in a shop, starting a transaction by calling AddProduct, then using a conversation to match multiple subsequent AddProducts. Eugh, very contrived and rubbish 😦

    • Hi John. First of all, thank you again for another comment :).

      About your question. It is technical possible what you comment. That’s the main use of a “conversation” to have another request to join the “first one”.

      But I think the example that you gave it is not the best possible. Because when you have this kind of environment. The “shopping cart” is even stored on the client side (using cookies or so on) or on the backend side using a database or a memory cache but it is never managed by the integrator.

      Hope you find this answer useful

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