Integration between TIBCO BusinessWorks™ Container Edition and Consul for Service Discovery and Configuration Management

Last updated:
4:01pm May 31, 2019

This page shows in a step-by-step guide how to integrate TIBCO BusinessWorks Container Edition with the open source solution Consul to use Service Discovery and Configuration Management. It uses Docker to run Consul and the TIBCO BusinessWorks Container Edition service in containers.

Overview

The main idea is to use consul to solve the discovery of services developed using TIBCO BusinessWorks Container Edition. We are going to create two different services that generates an echo of the input message. We are going to use REST services in order to avoid the current limitation related to the use of SOAP endpoints when you are using service discovery.

The first service is going to register its echo service in order to be able to be discoverable for the other services (second service). This eco service is going to reply the input but adding a prefix that we are going to configure using a property in Consul.

We are going to use consul in order to unlink at deploy time Service 1 and Service 2, so Service 2 is going to ask to Consul in order to find the service registered by Service 1, as you can see in the picture below:

Versions Used

  • TIBCO BusinessWorks Container Edition 2.1.0
  • Consul 0.6.4
  • Docker 1.11

Creating Service Code

The code from both services are quite dummy and simple because it is not the goal of this test to go deep on the TIBCO BusinessWorks Container Edition capabilities but go deep on the integration between TIBCO BusinessWorks Container Edition and Consul for Service and Discovery.

Service 1 (Project Test1 and Test1.module)

The service 1 exposes a REST service that is exposed at /echo endpoint URI as you can see in the picture below:

Regarding the configuration it is important to notice the following things:

  • HTTP Resource Template has to be configured in order to be registered once the application start, as you can see here:
  • We are going to define a Module Property that is the one that is going to be added as a prefix in the response of the service:

And then we are going to create a Process Property mapped to that Module Property and use it inside the Reply operation:

Service 2

The Service 2 exposes a REST Service (/echoCaller) that is going to be invoked by the final user (in this case using SOAPUI) and it is going to consume the /echo service exposed by the Service 1. To do that, we are going to add an Invoke operation and a REST Reference linked to that invoke like you can see in the picture below:

Regarding the configuration it is important to notice the following things:

  • The HTTP Client Resource isn’t configured using the IP for the Test1 container and anything related but using the Service Discovery capabilities like you can see here:

Creating Docker Images

Creating base image

To create the base image we have to follow the commands and recommendations that are available at: https://github.com/TIBCOSoftware/bwce-docker.

Creating service images

To create the service images based on the base image created on the previous step, we are going to focus on the bwce-docker GitHub repository, that you could reach here, and that have an HTTP example, to be used.

In our case we are going to create two folders (test1 and test2) with this Dockerfile in both of them:

The name of the base image depends on the name that you have provide it when you build the base image. In this case is “tibco/bwce”. Then, we need to generate each EAR file from each BW application inside each folder.

Now, we execute at each folder the following commands:

docker build -t bwce-test-1 .
docker build -t bwce-test-2 .

And now, we have both of the images created and ready to be executed!

Running and Configuring Consul

To run consul we are going to use the docker image available at DockerHub, that you could find at this location: https://hub.docker.com/r/progrium/consul/. To do that, we only have to run the following docker run command:

docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul -server -bootstrap -ui-dir /ui

And after running that command if we are going to “http://localhost:8500” we are going to get the Web UI from Consul:

The only configuration that we are going to do is to create a Key/Value pair in order to define the prefix that we are going to use on the Service 1 service implementation.

To do that, we only have to click on Key/Value and add the following Key Name: Test1/default/ECHO_SERVICE_PREFIX and ConsulTest as the Key Value and that’s all the configuration on the consul side.

Running Service Images & Testing

Now, we only have to run our services images in order to get all the components ready to the end to end test. To do that, we have to keep the consul system running and start executing the Service 1 (Test 1) using the following command:

docker run -ti -P -e APP_CONFIG_PROFILE=default -e BW_LOGLEVEL=INFO -e CONSUL_SERVER_URL=http://172.17.0.2:8080 bwce-test-1

We are going to see that the EchoService is registered on the consul registry. If we go to the user interface from Consul, you are going to see something like this:

After that, we can try to test only the service and we are going to see that is getting the value that we set using consul, so the integration from Service 1 with consul is perfect for service register and for configuration as well.

Then, we need to run the Service 2 and to do that we have to run the following command:

docker run -ti -P -e BW_LOGLEVEL=INFO -e CONSUL_SERVER_URL=http://172.17.0.2:8080 bwce-test-2

We are going to see only that the application has been started successfully. This means that is was able to discover the service and the HTTP Client. And, the only thing that is left, is to do the end-to-end test. To do that, we need to launch a request to the Service 2 and wait for the response from Service 1 as you can see in the picture below:

Feedback (2)

Hi Kai,
 
Thank you for your description, it was very helpful.
 
I created a HelloWorld service with BWCE, I was able to use Consul (for the registration and for the use of the stored key/values).
I figured out that if you only want to use Consul for the registration, you have to leave the variable APP_CONFIG_PROFILE empty. Is this the right way to disable the use of the key/values of Consul?
 
With “ I was able to …” I mean with “docker run”. I tried to do the same under Kubernetes, but without success.
I used Helm and Rancher for the deployment. I configured a pod with a HelloWorld container (I used the same image as with “docker run”) and a Consul container. I configured the environment variables CONSUL_SERVER_URL and APP_CONFIG_PROFILE. One container inside a pod can connect to another container in the same pod by using “localhost”, for that reason the value of CONSUL_SERVER_URL is http://localhost:8500. APP_CONFIG_PROFILE=DOCKER.
 
Unfortunately, the pod doesn’t start:
 
The loglevel is set to ERROR level
BW_PROFILE is set to 'DOCKER.substvar'
Appended ADDONS_HOME/lib in bwappnode.tra file
Appended ADDONS_HOME/lib in bwappnode file
Appended -Xmx1024M -Xms128M to java.extend.properties
java.lang.NullPointerException
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.getConsulAgentURI(DockerProfileTokenResolver.java:217)
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.collectPropertiesfromConfigServer(DockerProfileTokenResolver.java:85)
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.resolve(DockerProfileTokenResolver.java:44)
              at com.tibco.bwce.profile.resolver.Resolver.main(Resolver.java:19)
 
Because the host in the HelloWorld project is 0.0.0.0, I tried the value http://0.0.0.0:8500 for CONSUL_SERVER_URL as well. It still doesn’t work, but the error is different:
 
java.lang.Exception: Failed to load properties from URL [http://0.0.0.0:8500/v1/kv/HelloWorld/DOCKER?recurse]. Check Key/Value store configuration for Application[HelloWorld]
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.collectPropertiesFromConsul(DockerProfileTokenResolver.java:133)
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.collectPropertiesfromConfigServer(DockerProfileTokenResolver.java:87)
              at com.tibco.bwce.profile.resolver.DockerProfileTokenResolver.resolve(DockerProfileTokenResolver.java:44)
              at com.tibco.bwce.profile.resolver.Resolver.main(Resolver.java:19)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
              at java.net.PlainSocketImpl.socketConnect(Native Method)
 
If I perform a “curl http://0.0.0.0:8500/v1/kv/HelloWorld/DOCKER?recurse” (the same url as in the error message) or “curl http://localhost:8500/v1/kv/HelloWorld/DOCKER?recurse” inside the container, then the right key/value pairs are returned!
 
What I’m doing wrong?
 
Thanks and regards,
 
Peter-Paul Baarda
ppbaarda 12:57am Dec. 12, 2019

Hello Kai,

 

Nice document , we could enable the service discovery by following this document. Couple points, if you can address :

1. Eventhough we are not using Consul for Key / value store , we need to create one default key/value pair for Tibco service to start.

2. If we stop the container or remove it compleletly , the service is not getting deregistered automatically from Consul

 

Are there any additional steps to address above issues ?


Thanks 

dijeshtanna 11:36pm May. 06, 2019