Tibco EMS Interview Questions and Answers

Experienced in Tibco?. Tibco is a software company that provides services, analytics in cloud environment. EMS is a Enterprise Management Server which provides services for communicating using queues. EMS server ensures that the messages are sent to right queue. Another feature of this server in message queue is fanout where a single message is sent to many queues. Asynchronous and synchronous types of communication is possible. In case of transactionality, when a operation fails in between then the actual message is rolled back. There won’t be any commit. ACTE has interview questions which are exclusively designed for employees to assist them in clearing interviews. Tibco Ems interview questions and answers are useful for employees who are good at TIBCO and EMS server message queues.

1. What Are The Messaging Models Ems Support?

Ans:

• Point-to-Point (Queue)
• Publish and Subscribe (Topic)
• Multicast (Topic)

2. What Are The Limitations Of The Durable Subscriber?

Ans:

• As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic

3. What Are The Ems Destination Features?

Ans:

• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues

4. What Are The Extra Features Are Available In Ems Apart From Jms?

Ans:

• The JMS standard specifies two delivery modes for messages, PERSISTENT and NON_PERSISTENT. EMS also includes a RELIABLE_DELIVERY mode that eliminates some of the overhead associated with the other delivery modes.
• For consumer sessions, you can specify a NO_ACKNOWLEDGE mode so that consumers do not need to acknowledge receipt of messages, if desired. EMS also provides an EXPLICIT_CLIENT_ACKNOWLEDGE and EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE mode that restricts the acknowledgement to single messages.
• EMS extends the Map Message and Stream Message body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous and Active Enterprise formats that have certain features not available within the JMS Map Message and Stream Message.

5. What Is The Structure Of Jms Message?

Ans:

• Header (Required)
• Properties (optional)
• Body (optional)

6. Where Does The Undelivered Messages Will Be Stored?

Ans:

• 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.
• You can only set the undelivered property on individual messages, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level.

7. What Are The Message Bodies Are Supported By The Ems?

Ans:

• Map Message
• Text Message
• Stream Message
• Bytes Message
• Object Message

8. What Is The Maximum Message Size Is Supported By Ems?

Ans:

EMS supports messages up to a maximum size of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance limits of most current hardware and operating system platforms.

9. What Are The Different Delivery Modes Available In Ems?

Ans:

Persistent:
When a producer sends a PERSISTENT message, the producer must wait for the server to reply with a confirmation. The message is persisted 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 persisting 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.
• Regardless of whether authorization is enabled or disabled, you can use the npsend_check_mode parameter in the tibemsd.conf file to specify the conditions under which the server is to send confirmation of NON_PERSISTENT messages to the producer.
• Reliable:
• • 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.

10. If A Persistent Message Is Published On To A Topic, Does These Messages Will Store On Disk If Topic Doesn’t Have Durable Subscriber Or Subscriber With A Fault-tolerant Connection?

Ans:

No. Persistent messages published to a topic are written to disk only if that topic has at least one durable subscriber or one subscriber with a fault-tolerant connection to the EMS server. In the absence of a durable subscriber or subscriber with a fault-tolerant connection, there are no subscribers that need messages resent in the event of a server failure. In this case, the server does not needlessly save persistent messages. This improves performance by eliminating the unnecessary disk I/O to persist the messages.

11. What Are The Different Types Of Acknowledgement Modes In Ems Message Delivery?

Ans:

• Auto
• Client
• Dups_ok
• No_ack
• Explicit
• Explicit_client_dups_ok
• Transitional
• Local transitional

12. What Are The Different Types Of Messages That Can Be Used In Ems?

Ans:

• Text
• Simple
• Bytes
• Map
• XML test
• Object
• Object ref
• Stream

13. Tell Me About Bridges. Why Do We Use Them, Syntax To Create Bridges, Use Of Message Selector?

Ans:

• Some applications require the same message to be sent to more than one destination possibly of different types. So we use bridges in that scenario.
• Create bridge source=type: dest_name target=type:dest_name [selector=selector]

14. What Is The Purpose For Stores.conf?

Ans:

This file defines the locations either store files or a database, where the EMS server will store messages or metadata. Each store configured is either a file-based or a database store.

15. How Many Modes Are The Messages Written To Store File?

Ans:

Two Modes:

• Synchronous and Asynchronous.
• Default is asynchronous.

16. What Is Tibemsd.conf?

Ans:

It is the main configuration file that controls the characteristics of the EMS server.

17. Name Destination Properties And Explain Them?

Ans:

Global, secure, maxumsgs, maxbytes, flow control, sender name, sender_name_enforced, trace, maxRedelivery.

18. What Are The Different Modes Of Installation In Ems?

Ans:

• GUI mode
• Console mode
• Silent mode

19. What Are The Messaging Models Supported By Jms?

Ans:

• Point-to-point
• Publish-subscribe
• Multicast

20. What Is The Use Of Routes? What Kind Of Destinations Can Be Used In Routes?

Ans:

Topics and queues m-hops.

21. What Happens If The Message Expires/Exceeds The Value Specified By Maxredelivery Property On Queue?

Ans:

If the jms_preserve_undelivered property is set to true, then it moves the message to the undelivered message queue, if set to false, the message is deleted by the server.

22. In how many ways can a destination be created?

Ans:

• Static-created by server.
• Dynamic-created by client. 
• Temporary destinations.

23. What Are The Wild Cards That We Use In Ems? How Do They Work For Queues And Topics?

Ans:

*,> you can subscribe to wildcard topics but can’t publish to them. Whereas in case of queues we can’t either send /receive.

24. Tell Me About Flow Control On Destinations?

Ans:

Sometimes the producer may send messages faster than the consumers can receive them. So, the message capacity on the server will be exhausted. So we use flow control. Flow control can be specified on destinations.

25. Tell Me About Flow Control On Bridges And Routes?

Ans:

Flow control has to be specified on both sides of bridges whereas on routes it operates differently on sender side and receiver side.

26. Name 3 Configuration Files And Tell Me What It Consists Of?

Ans:

• Queues.conf
• Topics.conf
• Routes.conf
• Factories.conf
• Stores.conf
• Groups.conf, users.conf, transports.conf

27. Name Some Administrative Level Destination Properties?

Ans:

• View
• Create
• Delete
• Modify
• Purge

28. How Can You Change The Configuration Properties Of Ems Server?

Ans:

You can change in the tibemsd.conf file or you can change using the ems admin console.

29. What Are The Permissions That You Can Grant To Users To Access Queues?

Ans:

• Receive
• Send
• Browse

30. What Are The Permissions That You Can Grant To Users To Access Topics?

Ans:

• Subscribe
• Publish
• Durable
• Use durable

31. Tell Me About MultiCasting In Ems?

Ans:

• Multicast is a messaging model that broadcasts messages to many consumers at once rather than sending messages individually to each consumer. EMS uses Pragmatic general multicast to broadcast messages published to multicast enabled topics.
• Each multicast enabled topic is associated with a channel.

32. What Are The Advantages And Disadvantages Of Multicasting?

Ans:

Advantages: as the message broadcasts only once thereby reducing the amount of bandwidth used in the publish and subscribe model. Reduces the network traffic.
Disadvantages: Offers only last-hop delivery. So can’t be used to send messages between servers.

33. Suppose, You Got An Error While Accessing A Queue, That You Don’t Have Necessary Permissions To Access The Queue. What Might Be The Solution/reason?

Ans:

The user that is assigned to the queue and the user used while creating.

34. What Is Jms Queue Requester?

Ans:

The JMS Queue Requestor activity is used to send a request to a JMS queue name and receive a response back from the JMS client.

35. What Is Jms Topic Requester?

Ans:

The JMS Topic Requestor activity is used to communicate with a JMS application’s request-response service. This service invokes an operation with input and output. The request is sent to a JMS topic and the JMS application returns the response to the request.

36.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 Non-Persistent 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.

37.What is the difference between TIBCO EMS PERSISTENT, NON-PERSISTENT 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 Non-Persistent 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.

38. 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.

39. 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

40. What is the difference between Queues and Topics?

Ans:

The difference between TIBCO EMS Queues and Topics is that Queues are based on a point to point communication model with only one consumer for each queue while EMS Topics are based on the Publish/Subscribe model where messages are multicast to more than one consumer from a topic.

41.What are TIBCO EMS bridges and why bridges are used?

Ans:

Bridges are used to connect multiple destinations (queues or topics) so that the same message can be sent to multiple destinations.  When a bridge exists between two queues, the message is delivered to both queues.

42.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

43. Which configuration file has EMS Server configurations stored?

Ans:

All EMS Server properties are configured in the file tibemsd.conf

44. 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 non-starter (normal) activity which is used to request for a message to a queue and gets back a response.

45.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.

46.What is the difference between Get JMS queue and Wait for JMS queue message activity?

Ans:

The Get JMS Queue Message activity retrieves a message from the specified queue. This Activity allows you to perform a receive operation on the queue as opposed to waiting for queue message to be delivered to the Wait for JMS Queue Message activity or the JMS QueueReceiver process starter.The Wait for JMS Queue Message activity uses event key which is the JMSCorrelationID to filter the right response with the right job. The key is the JMSMessageID sent by the QueueSender activity

47. Why do we use JMS?

Ans:

For BW to touch the EMS server we use JMS. Using this JMS we build a connection between them and once the connection is successful we use this connection in the JMS queuesender

48. When do you get the error “Array Index out of Bounds Exception?”

Ans:

When the formats are not specified correctly. If we give Fixed format instead of delimiter we get this type of error. If we give a fixed format then we need to specify the length in offsetas equal to the number of characters as (0, 4, 7) and so on.

49. How can we transfer the data between multiple EMS servers?

Ans:

By using the Routing concept.

50. What is the caption of TIBCO?

Ans:

The information Bus Company. Since it transfers the messages in the form of a bus from one end to the other.

51. What is a domain?

Ans:

Domain is a computer term for a network based group of computers. These computers,in a domain, share a common database on that network

52. What is the need of monitoring?

Ans:

To handle network health checks even when the administrator is not before the system we write some rule bases in HAWK and this HAWK will do the monitoring.

53. What is a subject based messaging?

Ans:

RV follows Subject based messaging where all publishers publish the message on subject name and interested subscribers are listening on this subject. It’s pure bus architecture.

54. What is queue and topic based messaging?

Ans:

Queue follows point to point mode of messaging whereas topics follow pub/hub or client server messaging modes. Both are server based messaging in EMS.

55. Explain fail safe and non fail safe properties of a message. Also the flow of these messages in the synchronous and asynchronous databases.

Ans:

Failsafe: Ensures that no message loss when the connection gets failed over queues.Non failsafe means message loss when an unconditional network glitz?s occurs.

56. What is the difference between RVD and RVRD?

Ans:

RVD (Rendezvous Daemon): RVD is used to connect only within the network.RVRD (Rendezvous Routing Daemon): RVRD is used to connect outside the network and also within the network. If we have RVRD then there is no need for RVD.

57. What is RVA?

Ans:

To receive packets coming through internet i.e. web pages we use RVA (RendezvousAgent)

58.What is the critical section in TIBCO Business works and what is it used for? 

Ans:

Critical section is used to sync process instances so that only once 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. Particularly used for controlling access to shared variables. Critical section is one of the group actions. Others are iterating, repeat until true, repeat on error until true, while true, pick first and transaction. If we select the critical section as the group, then we get two options. Single group and multiple groups.

Single Group

If you wish to synchronize process instances for a single process definition in a single process engine (only one ear(instance) is deployed), perform the following:

• Create a group around the activities you wish to synchronize.
• Specify Critical Section for the Group Action field.
• Specify Single Group for the Scope field.
• Only one process instance at any given time will execute the activities contained in the Critical Section group.

Multiple Groups

If you wish to synchronize process instances for multiple process definitions, or if you wish to synchronize process instances across multiple process engines, perform the following:

• Create a Lock shared configuration resource and specify a name for the resource.
• To perform the synchronization across multiple process engines, check the Multi-Engine field of the Lock resource. When the process instances are executed by the same process engine, locking is performed in memory. When the process instances are executed across multiple engines, the process engines must be configured to use a database for storage, and a database transaction is performed to ensure that only one process instance is executing the critical section group at any given time.
• Create a group around the activities you wish to synchronize.
• Specify Critical Section for the Group Action Field.
• Specify Multiple Groups for the Scope field.
• Use the Browse button in the Lock Object field to locate the Lock shared configuration resource you created in Step 1.
• Perform steps 3 to 6 for any process definitions you wish to synchronize. Make sure you specify the same Lock shared configuration object for all Critical Section groups.

59.If there are three activities in the critical section, jdbc update then a write file and then again jdbc update. If the second jdbc update fails, then what will happen to the file written by write file activity?

Ans:

The contents of the file will persist.

60.What are different types of transaction groups supported in TIBCO BW? 

Ans:

Iterate, repeat until true, repeat on error until true, critical section, transaction, pick first, while true.

61.Can two queue receivers listen to the same queue? If yes, if the message arrives on the queue, when does the receiver receive it?  

Ans:

The queue which has made connection first. First come first serve.

If the message has hit the queue, and there are no receivers for it, and the receiver comes alive after 6 hours, what happens to the message?

Message stays on the queue.

If there are five messages and the prefetch property is set to 4 then what happens? 

Fetches 4 messages

62.What all palettes have you worked on at TIBCO BW? 

Ans:

File palette, general activities palette, jdbc palette, http palette, jms palette, parse palette, service palette, soap palette, wsdl palette.

63.What are the different types of variables available in TIBCO?

Ans:

There are three types of variables available in TIBCO. They are:

• Global variables: Global variables are used for assigning constants a value which is used over a project
• Process variables: Process variables are again of four types.

They are:

• Activity output
• Predefined process variables
• Error variables
• User defined process variables.
• Predefined process variables include $_GlobalVarialbes and $_ProcessContext
• shared variables – User defined process variables could be defined at a process definition level and assigned a value by using an assign activity.

64.What are the different acknowledgment modes for a message? 

Ans:

There are 6 modes of acknowledgement. They are:

• Auto – message is acknowledged automatically
• Client – use confirm activity for acknowledgement
• TIBCO EMS Explicit – use confirm activity for acknowledgement, only available for TIBCO EMS
• TIBCO EMS no ack
• Dups ok – message is acknowledged automatically on its receipt
• Transactional – when a transaction is included in a process definition. The message is back when the transaction commits.

65.What is prefetch and failsafe?

Ans:

Prefetch is fetching the messages from the server before receiver calls. Failsafe property enables you to write persistence messages to the file with synchronous i/o calls.

66.How do you send a response from a web service?

Ans:

We write an output to the queue from which we received the request.

67.What is the difference between soap event source and service palette?

Ans:

Soap event source is used for single operation, single end. Service palette is used for multiple operations, multiple end bindings like http, jms.

68.If you want to count the number of times a job is called, how will you go about doing it? 

Ans:

Use a job shared variable in a critical section.

69.If there are hundred messages lying on the queue, what will you do and which activity will you use to retrieve one message at a time? 

Ans:

JMS Queue receiver will confirm activity. Sequencing the key in a misc tab of the configuration could also be used.

70.What are the resources that get included in the EAR file, created by the TIBCO Designer?

Ans:

An EAR file can contain local project resources, Library Builder resources, and files as specified in Alias Library resources. In addition, the TIBCO Designer class path may include references to other files that are included in the EAR file.

71.What are the different modes of service invocation?

Ans:

Services can be invoked in several ways.

A one-way operation is executed once and does not wait for a response.

A request-response operation is executed once and waits for one response. In a request-response service, communication flows in both directions. The complete interaction consists of two point-to-point messages—a request and a response. The interaction is only considered complete after the response has arrived.

Publication (notification) means an operation sends information on an as-needed basis, potentially multiple times.

Subscription means incoming information is processed on an as-needed basis, potentially multiple times.

72.What are the TIBCO BW activities that can participate in transactions?

Ans:

Not all TIBCO BusinessWorks activities can participate in a transaction. Only the following types of activities have transactional capabilities:

• JDBC activities
• JMS activities
• ActiveEnterprise Adapter activities that use JMS transports
• EJB activities
• TIBCO iProcess BusinessWorks Connector activities

73.What are the different types of Transactions TIBCO provides?

Ans:

TIBCO BusinessWorks offers a variety of types of transactions that can be used in different situations. You can use the type of transaction that suits the needs of your integration project. When you create a transaction group, you must specify the type of transaction. TIBCO BusinessWorks supports the following types of transactions:

• JDBC
• Java Transaction API (JTA) UserTransaction
• XA Transaction

74.What activities are supported in JTA Transaction?

Ans:

The Java Transaction API (JTA) UserTransaction type allows:

• JDBC
• JMS
• ActiveEnterprise Adapter (using JMS transports)
• EJB activities

to participate in transactions.

75.What are the options for configuring storage for the process engine’s checkpoint repository?

Ans:

The options for configuring storage for process engine’s checkpoint repository are:

• Local File
• Database. Fault tolerant engines can recover from a checkpoint only when the database is used.

76.Process engines in a fault tolerant group can be configured as peers or master secondary.How do these differ ?

Ans:

The options for configuring storage for process engine’s checkpoint repository are:

• Peer means all of them have the same weight. In this case when one engine fails another one takes over and continues processing till it fails.
• In master secondary configuration weights are unequal, the secondary starts processing when master fails. But when master recovers, secondary stops and master continues processing.

77.What are the three scenarios where BW engine must be configured with database persistence instead of Local File?

Ans:

The three scenarios are: 

• Shared Variables across BW engines.
• Locking across groups in multiple BW engines.
• Wait Notify across BW engines.

78.If you want a group to be executed if there is some unhandled error but subject to some max number of iterations which group do you use?

Ans:

We can use Repeat on Error until true

79.When is a ‘Generate Error’ activity useful?

Ans:

When you handle an error inside a called sub-process or group and want to re-throw the error to the caller (happens by default if you don’t handle the error in the called process)

80.What is vcrepo.dat?

Ans:

TIBCO Designer creates a file named vcrepo.dat in the project root directory when you first save the         project. This file is used to store properties such as display name, TIBCO Rendezvous encoding, and         description. This file can be used for identification in place of the project root directory and can be             used as the repository locator string (repoUrl).