Categories: TIBCOTIBFAQS

Learn Now 2 Ways To Configure TIBCO BW EMS Reconnection

On this article we are going to cover how TIBCO BW EMS Reconnection works and how you can apply it on your application and the pros and const about the different options available.

Tibco Bw Ems Reconnection

One of the main issues we all have faced when working on a TIBCO BW and EMS integration is the reconnection part. Even though this is something that we need on minimal occasions because of the TIBCO EMS server’s extreme reliability, it can have severe consequences if we don’t have that well configured.

But before we start talking about the options, we need to do a little background explanation to understand the situation entirely.

Usually, there are two ways that we can use to connect our TIBCO BW application to our TIBCO EMS server: Direct and JNDI. And based on that, this will change how and where we need to configure our reconnection properties.

TIBCO BW + EMS: Direct Connection

This is, as it sounds, a direct connection to the TIBCO BW application to the EMS server itself, with the listener used to send and receive messages. There is no component in the middle, and you can detect that because on the JMS Connection Resources, it will show as “Direct,” and the URL is always in the following fashion: tcp://server: port as you can see in the picture below:

Tibco Bw + Ems: Direct Connection

TIBCO BW + EMS: JNDI Connection

This is a different kind of connection, and it has a central component compared with the Direct link, as you can imagine. In this scenario, at the connection time, the TIBCO BW application performs a first connection to the JNDI server that is inside the TIBCO EMS server and lookups for the connection details based on a “Connection Factory.” This connection factory will have its connection URL and connection properties. TIBCO BW Application will receive that information and start connecting to that EMS Server.

You will know that you are using a JNDI Connection because the Connection Factory Type now will show JNDI. Also, you will require an additional resource name, JNDI resource, and your URL connection will be something like this tibjmsnaming://server:port.

Learn Now 2 Ways To Configure Tibco Bw Ems Reconnection 6
&Nbsp;Tibco Bw + Ems: Jndi Connection

TIBCO EMS Reconnection Properties

Different properties manage the reconnection process. Those properties will affect the behavior of the EMS client library that lives in the client application, in this case, the TIBCO BW Application. The properties will control the following aspects: the number of connection attempts, time intervals between them, and timeout of the gap to consider it an unsuccessful attempt.


And you will have each of these properties for the reconnection process and the connection process. The main difference is that the connection process will only act when you are setting a connection for the first time (at the startup of the TIBCO BW application). The reconnection settings will apply when you lose a previously established connection.

The concrete properties are the following:

  • tibco.tibjms.reconnect.attemptcount/tibco.tibjms.connect.attemptcount: It will define the number of attempts you will perform when a reconnection scenario is detected
  • tibco.tibjms.reconnect.attemptdelay/tibco.tibjms.connect.attemptdelay: It will define the time interval between two reconnection attempts.
  • tibco.tibjms.reconnect.attempts/tibco.tibjms.connect.attempts It will serve as a combination of the attemptcount and attemptdelay in a comma-separated version.
  • tibco.tibjms.reconnect.attempt.timeout/tibco.tibjms.connect.attempt.timeout: It will define the timeout for each of the reconnection attempts, and if that time is reached, the reconnection is not established; it will be detected as an unsuccessful attempt.

Where To Set the Reconnection Properties?

In the case that we are talking about a Direct connection, these properties need to be specified on the TIBCO BW application, and these properties will be set as JVM properties.

So depending on your deployment model, these properties will need to be added to the AppNode TRA file or the BW_JAVA_OPS environment variables if we are talking about a containerized deployment.

On the other hand, if we talk about a JNDI connection, these properties will be set at the EMS level as part of the Connection Factory reconnection properties. This can be done using the tibemsadmin CLI component, putting it directly in the factories.conf file, or even using a Graphical tool such as gEMS using the Factories section to update that, as shown in the picture below:

Learn Now 2 Ways To Configure Tibco Bw Ems Reconnection 7

Depending on the approach that you will follow, the properties will be applied at runtime (gEMS or tibemsadminapproach) or on the next restart (factories.conf)

Pros and Cons

There are different pros and cons to using one connection mode. Based on the reconnection properties, using a centralized way such as the JNDI model ensures that all the components using that connection will have the same reconnection properties. If you need to change it, you don’t need to change all your TIBCO BW applications. That can be a number up to hundreds.

But, at the same time, the usage of a centralized way provides less flexibility than the direct connection where you can decide the specific values for each application or even which ones need reconnection configuration and which ones don’t.

Suppose you are looking for simplicity and ease of management. In that case, I will always go for the JNDI-based connection because it provides more benefits in those aspects, and the lack of flexibility is usually not required at all.

If you find this content interesting please think about making a contribution using the button below to keep this content updated and increased!


Alexandre Vazquez

Share
Published by
Alexandre Vazquez

Recent Posts

Nomad vs Kubernetes: 1 Emerging Contestant Defying The Proven King

Nomad is the Hashicorp alternative to the typical pattern of using a Kubernetes-based platform as…

1 month ago

DevSecOps vs DevOps: Fundamentals and Differences Answering 3 Questions

DevOps vs DevSecOps: Fundamentals about DevSecOps understanding what it is, why it is crucial and…

2 months ago

Trivy: Get To Scan Docker Local Images with Success

Scan Docker images or, to be more honest, scan your container images is becoming one…

2 months ago

Helm Dependency: Discover How it Works

Helm Dependency is a critical part of understanding how Helm works as it is the…

2 months ago

Multi-Stage Dockerfile: Awesome Approach To Optimize Your Container Size

Multi-Stage Dockerfile is the pattern you can use to ensure that your docker image is…

2 months ago

How To Inject Secrets in Pods To Improve Security with Hashicorp Vault in 5 Minutes

Introduction This article will cover how to inject secrets in Pods using Hashicorp Vault. In…

3 months ago