TIBCO EMS Interview Questions Answers-1

TIBCO EMS Interview Questions Answers-1

TIBCO EMS (Enterprise Messaging Service) is used for communication between processes and
applications through a centralized EMS Server. EMS simplifies as well as standardizes integration of
complex applications in an enterprise environment.
In this post, I am going to talk about TIBCO EMS Top Interview Questions and Answers based on my
experience in this domain.
Q1: What is the difference between JMS and TIBCO EMS?
Ans: TIBCO EMS is a customization of JMS specifications by TIBCO. The difference between JMS and
TIBCO EMS is that JMS provides two types of delivery modes which are Persistent and NonPersistent
while TIBCO EMS adds another type of delivery mode which is RELIABLE delivery mode.
Also, for restriction of messages acknowledgement, JMS provides NO_ACKNOWLEDGE mode while
TIBCO EMS extends the functionality of JMS by providing EXPLICIT_CLIENT_ACKNOWLEDGE mode
and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode.
Q2: What is the difference between TIBCO EMS PERSISTENT, NONPERSISTENT
and RELIABLE
delivery modes?
Ans: In PERSISTENT delivery mode, messages sent by the producer to the EMS Server are
persisted/stored in a disk and a confirmation is sent to the producer for every message.
In case of NonPersistent
delivery mode, messages sent by the producer are not stored/persisted on
EMS Server. Acknowledgement is sent back only if authorization is enabled.
In case of RELIABLE delivery mode, messages are not persisted and also, no acknowledgement is sent
back to the producer.
Q3: What is the difference between Static and Dynamic destination queues?
Ans: Static EMS queues are created using EMS Administrator or by configuring directly in the
configuration file (queues.conf) and are permanent and can be used at enterprise level. Static queues
have a permanent TTL (Time To Live) and they exist till the time they are deleted manually.
On the other hand, dynamic queues are short lived queues which are created when needed and get
expired once they are not in use. Dynamic queues remain alive until at least one client is associated with
them.
Q4: Which command is used to delete all the messages from a queue or topic?
Ans: Purge command is used to delete all the pending messages from a queue. For example, if you
want to purge a queue named ‘queue.ajmal’; you can run following command in TIBCO EMS
Administrator:
purge queue queue.ajmal
Q5: What is the difference between Queues and Topics?
Ans: The difference between TIBCO EMS Queues and Topics is that Queues are based on point to point
communication model with only one consumer for each queue while EMS Topics are based on
Publish/Subscribe model where messages are multicast to more than one consumers from a topic.
Q6: What are TIBCO EMS bridges and why bridges are used?
Ans: Bridges are used to connect multiple destinations (queues or topics) so that same message can be
sent to multiple destinations. When a bridge exists between two queues, the message is delivered to
both queues.
Q7: Which configuration file is used for creating and configuring bridges in EMS?
Ans: bridges between destinations are configured in a configuration file named as bridges.conf
Q8: Which configuration file has EMS Server configurations stored?
Ans: All EMS Server properties are configured in the file tibemsd.conf
Q9: What is the difference between JMS Queue Receiver and JMS Queue Requestor Activity?
Ans: JMS Queue Receiver is a process starter activity that starts a process whenever a new message
is available in a queue while JMS Queue Requestor is a nonstarter
(normal) activity which is used to
request for a message to a queue and gets back a response.
Q10: Can we use Multicast on queues?
Ans: No, multicast can be used only for topics. Queues are point to point and can’t be used for multicast.

TIBCO BW SSL Protocol

TIBCO BW SSL Protocol:

Secure Sockets Layer (SSL) is a protocol that provides secure authentication and transmits encrypted data over the Internet or an internal network. Most web browsers support SSL, and many Web sites and Java applications use it to obtain confidential user information, such as credit card numbers.

SSL Support in TIBCO Enterprise Message Service

TIBCO Enterprise Message Service supports the Secure Sockets Layer (SSL) protocol. SSL uses public and private keys to encrypt data over a network connection to secure communication between pairs of components:

• between an EMS client and the tibemsd server

• between the tibemsadmin tool and the tibemsd server

• between two routed servers

• between two fault-tolerant servers

SSL provides secure communication that works with other mechanisms for authentication available in the EMS server. When authorization is enabled in the server, the connection undergoes a two-phase authentication process. First, an SSL hand-shake between client and server initializes a secure connection. Second, the EMS server checks the credentials of the client using the supplied username and password. If the connecting client does not supply a valid username and password combination, the connection fails, even if the SSL 67 succeeded.

When authorization is enabled, usernames and passwords are always checked, even on SSL secured connections.

Digital Certificates

Digital certificates are data structures that represent identities. EMS uses certificates to verify the identities of servers and clients. Though it is not necessary to validate either the server or the client for them to exchange data over SSL, certificates provide an additional level of security.

A digital certificate is issued either by a trusted third-party certificate authority, or by a security officer within your enterprise. Usually, each user and server on the network requires a unique digital certificate, to ensure that data is sent from and received by the correct party.

A digital certificate has two parts—a public part, which identifies its owner (a user or server); and a private key, which the owner keeps confidential.

TIBCO BW Groups

TIBCO BW Groups:

Groups are used to specify related sets of activities. The main uses of groups are the following:

• To create a set of activities those have a common error transition. Basically, this is similar to a try...catch block in Java. This allows you to have a set of activities with only one error-handling transition, instead of trying to individually catch errors on each activity.

• To create sets of activities those are to be repeated. You can repeat the activities once for each item in a list, until a condition is true, or if an error occurs.

• To create sets of activities those participate in a transaction. Activities in the group that can take part in a transaction are processed together, or rolled back, depending upon whether the transaction commits or rolls back.

No Action Groups

You can group a set of related activities, with a common set of transitions into and out of the group. If you do not wish for the activities in the group to repeat, specify the group action to be none. No action groups are primarily useful for specifying a single error transition out of the group so that if an unhandled error occurs in the group, you only need one error transition instead of an error transition for each activity. This behavior is similar to a try...catch block in Java.

If Groups

You can use groups to conditionally execute business logic. The If group allows you to specify a set of conditions that are evaluated in order.

Critical Section Groups

Critical section groups are used to synchronize process instances so that only one process instance executes the grouped activities at any given time.

Any concurrently running process instances that contain a corresponding critical section group wait until the process instance that is currently executing the critical section group completes. Critical Section groups are particularly useful for controlling concurrent access to shared variables.

Overview of Loops

Loops allow you to execute a series of activities more than once. You can iterate based on the items in an array stored in the process data, you can iterate while or until a given condition is true, or you can iterate if an error is encountered while processing. The following are the types of loops that are available:

• Iterate Loop

• Repeat Until True Loop

• While True Loop

• Repeat On Error Until True Loop

Iterate Loop

An Iterate loop repeats the series of grouped activities once for every item in the list.

Repeat Until True Loop

The Repeat Until True loop repeats the series of grouped activities until the given condition evaluates to true. The activities are always executed once before checking if the condition is true. After executing the series of activities, the condition is checked, and the loop exits when the condition evaluates as true. Thefollowing is an example of a Repeat Until True loop.

While True Loop

The While True loop repeats the series of grouped activities as long as the given condition evaluates as true. The condition is evaluated when the group is entered. If the condition evaluates to false, the activities within the group are not executed.

Repeat On Error Until True Loop

The Repeat On Error Until True loop allows you to repeat a series of activities when an unhandled error occurs. The activities in the group are executed once. If there are no unhandled errors, the loop terminates. If an error occurs for which there is no error transition, the condition of the loop is evaluated — if the condition is true, the loop terminates, if the condition is false, the loop repeats until there is no error occurs or the condition is true.

TIBCO EMS| EMS Destination Properties

EMS Destination Properties

Destination Overview:

Destinations for messages can be either Topics or Queues. A destination can be created statically in the server configuration files, or dynamically by a client application.

Servers connected by routes exchange messages sent to temporary topics. As a result, temporary topics are ideal destinations for reply messages in request/reply interactions.

There are three types of Destinations, they are:

1.      Static Destinations

2.      Dynamic Destinations

3.      Temporary Destinations

Secure

When the secure property is enabled for a destination, it instructs the server to check user permissions whenever a user attempts to perform an operation on that destination. You can set secure using the form:

secure

When server authorization is enabled, the server checks user names and password of all connections without exceptions. However, operations on destinations, such as sending a message or receiving a message, are not verified unless the destination has enabled the secure property on the destination.

The secure property is independent of SSL-level security. The secure property controls only basic authentication and permission verification. It does not affect the security of communication between clients and server.

When a destination does not have the secure property set, any authenticated user can perform any actions on that topic or queue.

Creating Secure Destinations:

By default, all authenticated EMS users have permissions to perform any action on any topic or queue. You can set the secure property on a topic or queue and then use the grant topic or grant queue command to specify which users and/or groups are allowed to perform which actions on the destination.

The secure property requires that you enable the authorization property on the EMS server.

For example, to create a secure queue, named myQueue, to which only users "joe" and "eric" can send messages and "sally" can receive messages, in the EMS Administration Tool, enter:

set server authorization=enabled

create queue myQueue secure

grant queue myQueue joe send

grant queue myQueue eric send

grant queue myQueue sally receive

flowControl

The flowControl property specifies the target maximum size the server can use to store pending messages for the destination. Should the number of messages exceed the maximum; the server will slow down the producers to the rate required by the message consumers. This is useful when message producers send messages much more quickly than message consumers can consume them. Unlike the behavior established by the overflowPolicy property, flowControl never discards messages or generates errors back to producer.

You can set flowControl using the form:

flowControl=size [KB|MB|GB]

where size is the maximum number of bytes of storage for pending messages of the destination. If you specify the flowControl property without a value, the target maximum is set to 256KB.

Maxbytes

For queues, maxbytes defines the maximum size (in bytes) that the queue can store, summed over all messages in the queue. Should this limit be exceeded, messages will be rejected by the server and the message producer sends calls will return an error

maxmsgs

Topics and queues can specify the maxmsgs property in the form:

maxmsgs=value

where value defines the maximum number of messages that can be waiting in a queue. When adding a message would exceed this limit, the server does not accept the message into storage, and the message producer’s send call returns an error

overflowPolicy

Topics and queues can specify the overflowPolicy property to change the effect of exceeding the message capacity established by either maxbytes or maxmsgs.

Set the overflowPolicy using the form:

overflowPolicy=defauld|discardOld|rejectIncoming

If overflowPolicy is not set, then the policy is default.

maxRedelivery

The maxRedelivery property specifies the number of attempts the server should make to deliver a message sent to a queue.

Set maxRedelivery using the form: maxRedelivery=count

where count is an integer between 2 and 255 that specifies the maximum number of times a message can be delivered to receivers. A value of zero disables maxRedelivery, so there is no maximum.

Undelivered Message Queue

If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s JMS_TIBCO_PRESERVE_UNDELIVERED property.

 If JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue, $sys.undelivered. This undelivered message queue is a system queue that is always present and cannot be deleted. If JMS_TIBCO_PRESERVE_UNDELIVERED is set to false, the message will be deleted by the server.

Prefetch

Prefetch is a fetch batch value indicates how many messages will be send by the server to client in one time - and also indicates how many might be rollbacked when one of them is not confirmed.
Quoting doc: "To reduce waiting time for client programs, the message consumer can prefetch messages—that is, fetch a batch of messages from the server, and hold them for client code to accept, one by one.

You can set prefetch using the form:

prefetch=value

2 or more: The message consumer automatically fetches messages from the server. The message consumer never fetches more than the number of messages specified by value.

1: The message consumer automatically fetches messages from the server—initiating fetch only when it does not currently hold a message.

None:  Disables automatic fetch. That is, the message consumer initiates fetch only when the client calls receive—either an explicit synchronous call, or an implicit call (in an asynchronous consumer). This value cannot be used with topics or global queues.

0: The destination inherits the prefetch value from a parent destination with a matching name. If it has no parent, or no destination in the parent chain sets a value for prefetch, then the default value is 5 queues and 64 for topics. When a destination does not set any value for prefetch, then the default value is 0 (zero; that is, inherit the prefetch value).

global

Messages destined for a topic or queue with the global property set are routed to the other servers that are participating in routing with this server. You can set global using the form: global

TIBCO EMS| Message Acknowledgement Modes

Message Acknowledgement Modes:

The JMS specification defines three levels of acknowledgement for non-transacted sessions:

• Client: The message will be acknowledged when the process implementing the operation ends successfully. The session is locked.

Auto: The message is automatically acknowledged when it is received.

DUPS_OK_ACKNOWLEDGE specifies that the session is to "lazily" acknowledge the delivery of messages to the consumer. "Lazy" means that the consumer can delay acknowledgement of messages to the server until a convenient time; meanwhile the server might redeliver messages. This mode reduces session overhead. Should JMS fail, the consumer may receive duplicate messages.

EMS extends the JMS acknowledge modes to include:

• NO_ACKNOWLEDGE

• EXPLICIT_CLIENT_ACKNOWLEDGE

• EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE

NO_ACKNOWLEDGE:NO_ACKNOWLEDGE mode suppresses the acknowledgement of received messages. After the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources.

Note: 1.Sessions created in no-acknowledge receipt mode cannot be used to create durable subscribers.

2. Also, queue receivers on a queue that is routed from another server are not permitted to specify NO_ACKNOWLEDGE mode.

TIBCO EMS Explicit Client Acknowledge: this mode behaves exactly the same as the Client mode, except the session is not locked and one session can handle all the incoming messages.

TIBCO EMS| Message Delivery Modes

Message Delivery Modes

The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. EMS extends these delivery modes to include a RELIABLE_DELIVERY mode.

PERSISTENT

 When a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is saved on disk by the server. This delivery mode ensures delivery of messages to the destination on the server in almost all circumstances. However, the cost is that this delivery mode incurs two-way network traffic for each message or committed transaction of a group of messages.

NON_PERSISTENT

Sending a NON_PERSISTENT message omits the overhead of storing the message on disk to improve performance. If authorization is disabled on the server, the server does not send a confirmation to the message producer. If authorization is enabled on the server, the default condition is for the producer to wait for the server to reply with a confirmation in the same manner as when using PERSISTENT mode.

RELIABLE_DELIVERY

EMS extends the JMS delivery modes to include reliable delivery. Sending a RELIABLE_DELIVERY message omits the server confirmation to improve performance regardless of the authorization setting.

When using RELIABLE_DELIVERY mode, the server never sends the producer a receipt confirmation or access denial and the producer does not wait for it. Reliable mode decreases the volume of message traffic, allowing higher message rates, which is useful for messages containing time-dependent data, such as stock price quotations.

TIBCO EMS| JMS Message Models

JMS Message Models

JMS is based on creation and delivery of messages. Messages are structured data that one application sends to another. The creator of the message is known as the producer and the receiver of the message is known as the consumer. The TIBCO EMS server acts as an intermediary for the message and manages its delivery to the correct destination.

JMS supports these messaging models:

• Point-to-Point (queues)

• Publish and subscribe (topics)

• Multicast (topics)

Point-to-Point

Point-to-point messaging has one producer and one consumer per message. This style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgement that the message was received.

More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever consume each message that is placed on the queue.

Publish and Subscribe

In a publish and subscribe message system, producers sends messages to a topic. In this model, the producer is known as a publisher and the consumer is known as a subscriber. Many publishers can publish to the same topic, and a message from a single publisher can be received by many subscribers. Subscribers subscribe to topics, and all messages published to the topic are received by all subscribers to the topic.

This type of message protocol is also known as broadcast messaging because messages are sent over the network and received by all interested subscribers, similar to how radio or television signals are broadcast and received.

Durable Subscribers for Topics

By default, subscribers only receive messages when they are active. If messages arrive on the topic when the subscriber is not available, the subscriber does not receive those messages.

The EMS APIs allow you to create durable subscribers to ensure that messages are received, even if the message consumer is not currently running. Messages for durable subscriptions are stored on the server as long as durable subscribers exist for the topic, or until the message expiration time for the message has been reached, or until the storage limit has been reached for the topic. Durable subscribers can receive messages from a durable subscription even if the subscriber was not available when the message was originally delivered.

When an application restarts and recreates a durable subscriber with the same ID, all messages stored on the server for that topic are delivered to the durable subscriber.

TIBCO EMS| JMS Overview

JMS Overview

Java Message Service (JMS) is a Java framework specification for messaging between applications. Sun Microsystems developed this specification, in conjunction with TIBCO and others, to supply a uniform messaging interface among enterprise applications.

Using a message service allows you to integrate the applications within an enterprise. For example, you may have several applications: one for customer relations, one for product inventory, and another for raw materials tracking. Each application is crucial to the operation of the enterprise, but even more crucial is communication between the applications to ensure the smooth flow of business processes. Message-oriented-middleware (MOM) creates a common communication protocol between these applications and allows you to easily integrate new and existing applications in your enterprise computing environment.

TIBCO BW|General palette

Assign Activity:

The Assign activity allows you to assign a value to a user-defined process variable.

When the Assign activity is executed, the entire schema for the selected process variable is replaced with the specified values. Elements that do not have a value specified in the Input tab are set to null. Therefore, be certain to set all necessary values when using the Assign activity to set a process variable.

Call Process Activity:

The Call Process activity calls and executes an existing process definition. The input to the called process is defined in the Start activity of the called process. The output of the called process is defined in the End activity of the called process.

Note: You should only call processes that have Start activities. Do not call processes that begin with a process starter such as HTTP Receiver or Receive Mail. Providing the name of a process with a process starter results in

an exception at run time.

Catch Activity:

The Catch activity receives control of execution when an unhandled exception occurs. You can select a specific exception type to catch or you can specify that this activity should catch all unhandled exceptions. You can have more than one Catch activity in each exception scope, but each Catch activity must have a unique exception type.

Rethrow:

If you wish to propagate the caught exception to the next highest scope, use the Rethrow activity.

Generate Error:

This activity generates an error and causes an immediate transition to any error transitions. If there are no error transitions, the process instance halts execution. This activity is useful in a group or in a called process. If you would like to catch and raise your own error conditions, you can use this activity to do so.

For example, for a process that calls a sub process to check the credit of a customer, you can use the Generate Error activity to raise an error for any error conditions, such as the customer does not exist, or the customer has no credit available. In the called sub process, create a transition to the Generate Error activity after detecting the error condition and the called process terminates. Processing continues with an error in the calling process. An error transition on the Call Process activity can handle the error.

Checkpoint Activity:

A checkpoint saves the current process data and state so that it can be recovered at a later time in the event of a failure. If a process engine fails, all process instances can be recovered and resume execution at the location of their last checkpoint in the process definition. If a process instance fails due to an unhandled exception or manual termination, it can optionally be recovered at a later time, if the process engine is configured to save checkpoint data for failed processes only the most recent state is saved by a checkpoint. If you have multiple checkpoints in a process, only the state from the last checkpoint is available for recovering the process.

Duplicate Key: A key value that is used to compare to other process instances to determine whether another process instance with the same duplicate key value already exists.

Note: 1. A Checkpoint activity cannot be placed in or in parallel to a transaction

2. If the checkpoint is taken before the Confirm activity, and then a crash occurs after a checkpoint but before confirm activity, the original message is resent. In this case, the restarted process can no longer send the confirmation.

If the checkpoint is taken after a Confirm activity, there is potential for a crash to occur after the Confirm but before the checkpoint. In this case, the message is confirmed and therefore not redelivered. The process instance is not restarted, because the crash occurred before the checkpoint.

Confirm Activity:

The Confirm activity confirms any confirmable messages received by the process instance. For example, if a process is started because of the receipt of an RVCM message, the Confirm activity can send a confirmation message to the publisher of the RVCM message.

Custom Activity

This is useful if you wish to develop processes for others to use, but you also wish to hide the implementation details of the process from users.

Lock Object: Shared Configuration

Lock Object shared configuration resources are used by Critical Section groups to ensure that only one process instance executes the activities in a critical section group at a time.

The Lock Object resource can be used to synchronize process instances from more than one process definition in the same process engine, or it can be used to synchronize process instances across multiple process engines.

Engine Command Activity:

The Engine Command activity allows you to retrieve statistics and information about process definitions, process instances, and activities in the currently running process engine. This activity also used to perform engine maintenance, such as suspending and resuming process instances and shutting down the engine.

The Command to Execute using Engine Command Activity:

1.      Get Activity Status

2.      Get process definition status

3.      Get process instance exceptions

4.      Get process instance info

5.      Get process starter status

6.      Get recoverable processes

7.      Kill process instance

8.      List All roles

9.      Remove recoverable processes

10.  Restart recoverable processes

11.  Suspend Process instance

12.  Suspend process starter

13.  Shutdown

Set Shared Variable Activity:

The Set Shared Variable activity allows you to change the value of a shared variable. If you are using this activity to set the value of a Shared Variable resource, you may want to use a critical section group to ensure that no other process instances are altering the value of the shared variable at the same time.

Get Shared Variable Activity:

The Get Shared Variable activity retrieves the current value of a Shared Variable or Job Shared Variable resource.

If you are using this activity to retrieve the value of a Shared Variable resource, you may want to use a critical section group to ensure that no other process instances are altering the value of the shared variable at the same time.

Job Shared Variable: Shared Configuration

A Job Shared Variable shared configuration resource allows you to store data for use by each process instance. A copy of the variable is created for each new process instance. This resource is useful for passing data to and from sub-processes without creating an input or output schema for the called process.

Mapper Activity:

The Mapper activity adds a new process variable to the process definition. This variable can be a simple data type, a TIBCO ActiveEnterprise schema, an XML schema, or a complex structure.

TIBCO BW| Variables interview questions

1.     What are the Types of Variables in TIBCO BusinessWorks?

Ans: There are 3 types of variables available in Tibco BusinessWorks. They are

i)       Global variables

ii)    Process variables

iii)  Shared Variables

2.     What are the Global variables and what is the use of Global variables?

Ans: these variables allow you to specify constants that can be used throughout the project. The constants can be specified and changed while designing and testing your project. You can also specify different values for each deployment of your project.

3.     What are the Process variables?

Ans: The Process Variables tab allows you to specify user-defined process variables for the process definition. For example, there are predefined process variables containing the process ID, project name, and other information.

 Process variables are displayed in the Process Data panel of each activity’s Input tab.

4.     How can we assign the values to Process variables?

Ans: You can assign a value to the process variables with the Assign activity.

5.     What is the difference between Deployment and Service level Global Variables?

Ans: Deployment: Select the deployment check box to make the variable visible and we can change the value of Global Variable, when deploying using TIBCO Administrator. If the check box is clear, the variable is not visible in TIBCO Administrator.

• Service: Service indicates that the variable should be included when the Include all service level global   variables option is selected when building the enterprise archive file. A variable that can be changeable on a per-service basis can be set for each adapter service. This option is used for TIBCO adapter archives. TIBCO ActiveMatrix BusinessWorks does not use this setting.

6.     How can we change the value of Global variables in TIBCO Administrator?

Ans: 1. Select Respective application under the Application Management.

     2. An application’s advanced tab to set application-specific variables.

7.     What is the difference between Shared Variables and job shared variables?

Ans: Shared Varaibles: Shared Variables allow you to specify data for use across multiple process instances. Because multiple process instances can access the same variable.

Job Shared Variable:

A Job Shared Variable shared configuration resource allows you to store the data for use by each process instance. A copy of the variable is created for each new process instance. This resource is useful for passing data to and from sub-processes without creating an input or output schema for the called process.