Look and feel of Tibco Administrator based on environment

When working with a lot of different environments, it is always good to be able to differentiate between all of them by just having a quick look at it. TIBCO Administrator is a great tool when you need to make some visual health check of a specific application or even for the full system. It becomes however difficult when you need to do that under stressful pressure because the production application does not behave the way it was in staging. You then start looking at the possible issues in the logs, global variables or even in the process definitions stats. After a few switches back and forth between staging and production, you start confusing the two of them. This task becomes even more difficult when you have your localhost running, plus the development environment as well as UAT server. You are not however without any help. You can check for the domain name in the top right corner. If your environments are setup properly, you should have different domain name allocated for each of them.

A TIBCO Administrator interface is running JSP pages on a Tomcat instance. It is therefore possible to change some of the images or style of the pages. The following steps will help you to change the heading logo as well as the right hand side menu for each environment.

1) The first step is to create the logos.

I've created some logos using the existing TIBCO Administrator images and adapting to my preferences. The size of the file must be 366x48 and saved as GIF (without changing too many the pages).

You also need filler for the rest of the page. The file size must be 1x48 and saved as GIF (without changing too many the pages).

2) Once you have your images, connect to the server where TIBCO Administrator is installed and go to the following location:

%TIBCO_HOME%\administrator\5.x\tomcat\webapps\administrator\jsp\com\tibco\administrator\ApplicationHeaderPaneUI\

3) Rename the current images as backup:

sculpted_logo.gif --> sculpted_logo.gif.bak

tiled_banner.gif --> tiled_banner.gif.bak

4) Copy the new images and rename them to the proper name:

sculpted_logo_[env].gif --> sculpted_logo.gif

tiled_banner_[env].gif --> tiled_banner.gif

5) At this point, you can already check the result. (Don't forget to clear the cache for this server otherwise Tomcat will cache the old images)

6) Now for the left hand side menu. Go and edit the file located in:

%TIBCO_HOME%\administrator\5.x\tomcat\webapps\administrator\jsp\com\tibco\administrator\ConsoleSelectorPaneUI.jsp

7) Around the line 10, you will have the colour used for the frame background (bgcolor="#FFFFFF" currently white). Replace it with the same colour as the one you used for your logo.

In my case, for Localhost:

bgcolor="#FFFFFF" --> bgcolor="#ff8328"

for Staging:

bgcolor="#FFFFFF" --> bgcolor="#c9ffbf"

for Production:

bgcolor="#FFFFFF" --> bgcolor="#285bff"

8) Save the file and just refresh the page to see the modification.

Reference:

Thanks to Ben's Blog for the above content:

http://b.amiot.free.fr/comments.php?y=10&m=03&entry=entry100303-033107

TIBCO interview Questions

Will Active Enterprise Adapter palette activities override the existing transport type of adapter service?
Yes.

Does Adapter Service support RVCMQ transport for publishing?
 No

What is the difference between Invoke an Adapter Request-Response Service activity and Adapter Request-Response Service activity?

Invoke an Adapter Request-Response.

Request a response from external application to Adapter service

Adapter Request-Response Server activity

Request a response from adapter service to external application

Does copy file activity allow copying directories to new location?
Yes.  The Copy File activity allows you to copy files and directories to a new location.

Does Copy create file activity allows creating new directories?
Yes. The Create File activity creates a new file or directory with the specified name. When creating a file, you can also provide the file contents.

What is the difference between Concrete WSDL and Abstract WSDL?

The Abstract WSDL describes the interface of the web service which includes the format of request and response messages of each operation.

The Concrete WSDL describes the abstract WSDL plus transport information. Concrete WSDL contains messages, operations and transport specific information (JMS or Http), which is used by SOAP client.

What is the Difference between EMS and RV?
EMS

·         A producer sends a message to the central server. The server stores the message until it has delivered it to each consumer

·         Producer to server; server to consumers.

·         Store and forward queue protocol.

·         The central server stores all messages and delivery state for all its clients; it requires disk resources in proportion to total throughput volume.

·         Disk failure on a server host computer can be catastrophic, affecting all messages from every client. Many installations protect against disk failure using safeguards such as disk mirroring.

·         The central server is the master of overall delivery state.

RV

·         A producer sends a message to consumers. The producer stores the message until each consumer has acknowledged receipt

·         Peer-to-peer.

·         Stream-oriented protocol.

·         Each producer stores its outbound messages and some delivery state; it requires disk resources in proportion to its outbound volume.

·         Disk failure on a peer host computer affects only the messages that its programs produce or consume. However, disk mirroring for each individual peer is often impractical.

How you perform performance tuning on BW engine?

·         Max jobs

·         Flow limit

·         Activation Limit

·         Java heap size

What are included in EAR file?

·         Library builder

·         Alias library

·         Process Definitions

·         Shared resources

What are the maximum, we can configure in FT mode for EMS
At any point of time, can configure only two servers in FT.

What is the use of Critical section Group?
Critical section groups are used to synchronize process instances so that only one process instance executes the grouped activities at any given time

How do you use XSLT file?
The Transform XML activity allows you to transform an input XML document into the output specified by the given XSLT File shared configuration resource

How you send messages in a sequence order in ems?
By using Sequence Key property

Where do you configure database connection for EMS?
In Stores.Config file.

 How to set message priorities on the destinations using tibco EMS?

By specifying priority index at receiving end

Is that possible to change process or shared variable during runtime?
Yes, it's possible to change process or Shared variables at run time using assign and Set shared Variable activity.

In Mapping using XSLT, what is meang of (..) in the statement?
Parent loop

Can you deploy a BW engine on system which has only TRA?

No

What are the main parts of JMS message?

·         Header

·         Body

·         Properties

What is difference between AliasLibrary and LibraryBuilder?
A Library Builder activity is used to create a design time library which can used to share a set of TIBCO BW processes or resources across projects during the development phase.

An Alias Library is used to access some java classes which are part of a jar file.

What is BW memory management?
Memory saving mode can reduce the memory used by actively running process instances as well as potentially improve the performance of checkpoints. By default, memory saving mode is disabled, but you can enable garbage collection on specific process instances by setting the EnableMemorySavingMode. property to true. You can enable memory saving mode for all process instances by setting the EnableMemorySavingMode property to trueEnableMemorySavingMode. = true

Try this property adding your Deployment Tra file or BW Engine.Tra file and Redeploy it. But memory saving is very limited though, make sure if your process is claiming more heap and/or reaching to out of memory exception, there is something wrong with process design, verify each actitivity and cleanup all unused content.

Can we have 2 processes running on the same Http Connection and same Port No.?
No

Do we have to redesign the project if we make some changes in XSD's like Enumeration changes or just update them?
If you modified any property (Enumeration..etc) for any field in in Schema, you need not re-design your project. It's just property, it automatically imported where ever you’re using (diff process) this schema.

What is difference between Soap Event Source and Service activity?
Soap Event Source supports only one operation to be implemented, if you have a need to have multiple operations in one place, you can use services as it supports multiple operations in one place.

What is Check point? What is the use of it?
The Checkpoint activity performs a checkpoint in a running process instance. 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.

Is there any restriction on number of Activities in a process definition?
In general, there is no limitation to activities in process definition.

How to Read Excel file in process?

·         You can save the excel file as .csv file and you can use the same csv format by giving the column separator and line separator.

·         You can use JDBC Excel driver, or JDBC-ODBC Bridge and then ODBC Excel driver. Both methods allow read/write of excel files using SQL

What is the purpose of Event Candidate Key?
Expression used to evaluate whether the incoming message is appropriate for this process. This expression is specified in XPath, and only data from the incoming event is available for use in this XPath expression.

What is the use of Event time out?
The amount of time a message will wait (in milliseconds) if it is received before this task is reached in the process. If the event timeout expires, an error is logged and the event is discarded.

If no value is specified in this field, the message waits indefinitely. If zero is specified, the event is discarded immediately, unless this has already been reached

How do you achieve to store data from group activities for each iteration?
If you wish to store data from each successive iteration of a loop, you can create a process variable and use the Assign activity in the loop to store or alter data for each iteration. For Iterate and Repeat until True loops, you can optionally accumulate the output of each execution of one activity in the group into a list. This list becomes the group’s output and the list is available to subsequent activities in the process definition

What is the use of “No action Group”?
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 behaviour is similar to a try...catch block in Java.

Why you need “pick First Group”?
Pick first groups allow process execution to wait for one or more events. The first event that completes determines which transition to take to continue processing. For example, as part of an order-entry system, when an order is placed, a check is made to see if the order can be filled from stocked inventory or from returned merchandise. Whichever system returns the information first is used to fill the order. If neither system returns the information about available inventory, the order time out and cancels

What are the different types of variables are available? And explain them?

·         Global Variables

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.

·         Process variables

These variables allow you to access various data in your project. For example, there are predefined process variables containing the process ID, project name, and other information. You can also create user-defined process variables for containing process-specific data.

·         Shared variables

These variables allow you to specify data for use across multiple process instances. Because multiple process instances can access the same variable, you can also synchronize access across processes when setting or retrieving the shared variable.

Difference between shared variable and job shared variable?

·         Shared variable

Shared Variable resource allows you to share data across process instances. All process instances can read and update the data stored in a shared variable. This type of shared variable is useful if you wish to pass data across process instances or if you wish to make a common set of information available to all process instances

·         Job shared variable

Job Shared Variable resource is similar to a Shared Variable, but its scope is limited to the current job. A copy of the variable is created for each new process instance. This type of shared variable is useful for passing data to and from sub-processes without creating an input or output schema for the called process.

What is coercion and what is the use of it?
Coercions allow you to specify a type for Process Data elements that are not a specific datatype. For example, a choice element can be coerced into one of the possible data types for the element, or an element of datatype any can be coerced into a specific data type.

What does the various types of timeout specifications mean in 'Wait for JMS Queue Message' mean?

receiverTimeout - advance tab
Specifies the polling interval to check for new messages.
This default interval is set by the custom engine property bw.plugin.jms.receiverTimeout.
If no value is specified for the property, the default polling interval is one second.
Explanation: Checks for new message at Queue for each specified interval time.

Event Timeout (msec) A message may arrive before this activity is executed.
This field specifies the amount of time (in milliseconds) a message waits if it is received before this activity is executed.
If the event timeout expires, an error is logged and the event is discarded.
If no value is specified in this field, the message waits indefinitely.
If zero is specified, the event is discarded immediately, unless this activity has already been executed
Explanation: Messages will be in the queue as specified(Event timeout) time. After reaching this waiting period, message will be elapsed from the queue.

processTimeout integer The time (in milliseconds) to wait for the incoming message.
An error is returned if the message is not received in this time limit. 
Explanation: Time to wait for the messages, upon reaching the time limit, an error transition is returned out of this activity

what is difference between the SOAP over JMS and SOAP over HTTP?

Consider using SOAP over HTTP for:

• Externally facing web services (e.g. customers or suppliers)
• For simple point-to-point and stateless services
• Where you need a thin client with no MOM installations

Consider using SOAP over JMS for:

• High-volume distributed messaging
• Asynchronous messaging
• Where a transaction boundary is needed in the middleware
• Where the message consumers are slower than the producers
• Guaranteed deliver and/or only once delivery of messages
• Publish/subscribe
• Distributed peer systems that might at times be disconnected

what are different variables available in TIBCO Business Works?

There are three different types of variables available in BusinessWorks.

they are

1. Global Variable: which are used all over the project
2. Process Variable: which are used in a particular process definition.
3. Shared Variable: which are used to share the value across multiple process or multiple process instances.

what is Service?

Service is a collection of commonly used functionality!! It’s a package for consistent re-use. Other way eliminating duplicate components/functions/systems from enterprise. Building one common service, which can be re-used many applications with in enterprise and also out side enterprise.

“A service is a reusable unit of functionality which standardized the interfaces”

Example: place Order, Update Order, Order Status, Address validation...

There are 3 types of services:

1. On-demand: Service waits for the requester to invoke an interface and then initiates the requested action. Ex: Place an order.

2. Event-Driven: Upon receipt on event, service wills performs required function.

3. Continues: Service run’s on it’s own without formal invocation either periodically or continuously. Ex: Process monitoring Service.

TIBCO Enterprise Message Service Interview Questions

1. What are the messaging models does EMS support?
a. Point-to-Point (Queue)
b. Publish and Subscribe (Topic)
c. Multicast (Topic)
2. What are the limitations of the Durable Subscriber?
• As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic
3. What is the difference between "Multicasting" and "publish and subscribe" messaging model?
4. What are the EMS Destination features?
• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues
5. What are the extra features are available in EMS apart from JMS?
• 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 MapMessage and StreamMessage body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise formats that have certain features not available within the JMS MapMessage and StreamMessage
6. What is structure of JMS Message?
• Header(Required)
• Properties(optional)
• Body(optional)
7. Where does the undelivered messages will be stored?
• 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
8. What are the messages bodies are supported by the EMS?
• Map Message
• Text Message
• Stream Message
• Bytes Message
• Object Message
9. What is the Maximum message size is supported by EMS?
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
10. What are the different delivery modes available in EMS?
• 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.
11. 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?
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

12. What are the different types of acknowledgement modes in EMS message delivery?
• Auto
• Client
• Dups_ok
• No_ack
• Explciit
• Explicit_client_dups_ok
• Transitional
• Local transitional.
13. What are the different types of messages that can be used in EMS
• Text
• Simple
• Bytes
• Map
• XML test
• Object
• Object ref
• Stream
14. Tell me about bridges. Why do we use them, Syntax to create bridges, use of message selector?
• 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]

15. What is the purpose for stores.conf
• 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.
16. How many modes are the messages written to store file.
• Two Modes: Synchronous and Asynchronous
• Default is asynchronous
17. What is tibemsd.conf
• It is the main configuration file that controls the characteristics of the EMS server
18. Name destination properties and explain them.
• Global, secure, maxmsgs, maxbytes, flowcontrol, sender_name, sender_name_enforced, trace,maxRedelivery
19. What are the different modes of installation in Ems?
• GUI mode
• Console mode
• Silent mode
20. What are the messaging models supported by JMS
• Point-to-point
• Publish-subscribe
• Multicast
21. What is the use of routes? What kind of destinations can be used in routes?
• Topics and queues m-hops

22. What happens if the message expires/exceeded the value specified by maxredelivery property on queue?
• If the jms_preserve_undelivered property is set to true, then it moves he message to undelivered message queue, if set to false, the message is deleted by the server.
23. In how many ways can a destination be created?
• Static-created by server
• Dynamic-created by client
• Temporary destinations.
24. What are the wild cards that we use in ems? how do they work for queues and topics
• *,> you can subscribe to wildcard topics but can’t publish to them. Where as in case of queues we can’t either send /receive.

25. Is bridges are transitive?
• NO
26. Tell me about flow control on destinations
• Some times 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.
27. Tell me about flow control on bridges and routes
• Flow control has to be specified on both sides of bridges where as on routes it operates differently on sender side and receiver side.
28. Name 3 configuration files and tell me what it consists of
• Queues.conf
• Topics.conf
• Routes.conf
• Factories.conf
• Stores.conf
• Groups.conf,users.conf,transports.conf
29. Name some administrative level destination properties
• View
• Create
• Delete
• Modify
• Purge
30. How can you change the configuration properties of EMS server?
• You can change in the tibemsd.conf file or you can change using the ems admin console.
31. What are the permissions that you can grant to users to access queues
• Receive
• Send
• Browse
32. What are the permissions that you can grant to users to access topics
• Subscribe
• Publish
• Durable
• Use_durable
33. Tell me about multicasting in EMS
• 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.
34. What are the advantages and disadvantages of multicasting?
• Advantages: as the message broadcasts only once thereby reducing the amount of bandwidth used in publish and subscribe model. Reduces the network traffic.
• Disadvantages: Offers only last-hop delivery. So can’t be used to send messages between servers.
35. On what destinations can you use multicast?
• Topics
36. 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?
• The user that is assigned to the queue and the user used while creating
37. How does the secondary server know that the primary server is failed?
• Based on heartbeat intervals
38. What is JMS queue requestor?
• 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
39. What is JMS topic requestor?
• 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.
40. How do you add ems server to administrator?
• Using domain utility
41. How do you remove individual messages from destinations?
• Use Puge Command.
42. What are the messaging models does EMS support?
• Point-to-Point (Queue)
• Publish and Subscribe (Topic)
• Multicast (Topic)
43. What are the limitations of the Durable Subscriber?
• As long as the durable subscriber exists
• Expiration time of the message
• Storage limit of that Topic
44. What is the difference between "Multicasting" and "publish and subscribe" messaging model?
45. What are the EMS Destination features?
• Secure Property
• Trace Property
• Store Property
• Redelivery policy
• Flow control
• Exclusive property for queues
46. What are the extra features are available in EMS apart from JMS?
• 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 MapMessage and StreamMessage body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous and ActiveEnterprise formats that have certain features not available within the JMS MapMessage and StreamMessage
47. What is structure of JMS Message?
• Header(Required)
• Properties(optional)
• Body(optional)
48. Where does the undelivered messages will be stored?
• 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
49. What is the Maximum message size is supported by EMS?
• 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
50. What are the different delivery modes available in EMS?
• 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.
51. 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?
• 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

what is the Difference between Businessworks and BusinessEvent

BusinessEvents
BusinessEvents is Stateful, its an eventbased rule engine.

BusinessWorks
BusinessWorks is a procedural and it is stateless

How to find the DateTime Difference from two different Time Zone?

How to find the DateTime Difference from two different Time Zone?

You can use this simple below function.

tib:compare-dateTime((tib:translate-timezone(current-dateTime(), '+05:30')), tib:translate-timezone($Start/root/InputDateTime, '+05:30'))

Introduction to Tibco BusinessEvents

Business Events

Introduction:
TIBCO BusinessEvents™ allows you to abstract meaningful information from the large amount of data that moves through your distributed enterprise systems and take appropriate action. Users can define business rules on events, systems, services, or a combination of all of these and execute tasks. By detecting complex patterns within the real-time flow of simple events, BusinessEvents can help you to detect and understand unusual activity, recognize trends and advantageous situations, and monitor for specific forms of problematic activity. BusinessEvents delivers this business critical information in real time directly to TIBCO BusinessFactor™, TIBCO PortalBuilder®, or custom dashboards.
BusinessEvents also graphically models your business concepts, scenarios, and rules, allowing you to see both the big picture and the detailed view, predict the needs of your customers, make faster decisions, and take faster action.
Major Components in Business Events:
The above diagram presents the major components of TIBCO BusinessEvents and how they are inter-related.

TIBCO Designer—Designtime Activities
Many TIBCO products use TIBCO Designer as their design-time interface. TIBCO Designer hosts palettes for many different purposes. It also organizes project resources and makes the organization visible in graphical and folder-based ways. At design time, BusinessEvents makes use of some resources available in TIBCO BusinessWorks, such as the XML mapper. (BusinessWorks, licensed for use during BusinessEvents development only, is bundled with BusinessEvents software.)
BusinessEvents Workbench Palette
The BusinessEvents Workbench palette integrates with TIBCO Designer and is used at design time. Design time activities performed using the resources in this palette include building an ontology—a set of concepts, scorecards and events that represent the objects and activities in your business—and building rules that are triggered when instances of ontology objects that fulfill certain criteria arrive in events. The output of the design-time activities is an enterprise archive (EAR) file, ready to deploy (or configure for deployment as needed).
State Modeler
The Enterprise Suite of TIBCO BusinessEvents includes a state machine component. It allows you to model states of ontology concept instances and use those states in rules.
TIBCO Administrator—Deploy and Runtime Activities
TIBCO Administrator provides administrative access to BusinessEvents servers. You can use it to perform deploytime configuration, deploy EAR files, and manage the deployed servers. You can also perform many of these tasks at the command line.
BusinessEvents Server (Engine)—Runtime Activities
At runtime, the BusinessEvents engine processes the incoming events using a Rete network as the inferencing engine, and a set of rules that are triggered by conditions in incoming events.
A BusinessEvents server (more commonly referred to as an engine, because it normally does the work of an engine) can be deployed in different modes, to achieve fault tolerance and object management objectives. For example, a server can be used for cache storage only.

The major Design Concepts of Business Events are
Channels and Destinations
Events
Concepts and Concept Instance
Concept view
Scorecard
Rules and Rule set
Object management
State modeler
Query language for querying cached objects
1. Channels and Destinations:
Channels (except local channel) represent a physical connection to a resource, such as Rendezvous daemon. Destinations in a channel represent listeners to message from that resource, and they can also send messages to the resource. All destinations in a particular channel must use same server.
Channels are three types:
TIBCO Rendezvous channels: Connects TIBCO BusinessEvent to TIBCO Rendezvous sources and sinks.
JMs Channels: connect TIBCO BusinessEvents to TIBCO Enterprise message service provider sources and sinks
Local Channels: Connects multiple rule sessions at runtime.
BusinessEvents uses serializers to convert events to messages and a deserializer to convert from message to event. Serializers and deserializers are provided to RV and JMS (Local channels do require serializers).
Selecting a JMS Serializer:
Message Type
BytesMessageSerializer
TextMessageSerializer
Message
Yes
Yes
ByteMessage
Yes
No
MapMessage
Yes
Yes
TextMessage
No
Yes
StringMessage
Not supported
Not supported
OjectMessage
Not supported
Not supported




Selecting a RV Serializer:
Basic Serializer: The basic serializer, TibRvMsgSerializer serializer, is for efficient handling of events and messages that do not have payloads.
Serializer for event with payload: The TibRvMsgSerializerWithXMLPayload serializer allows you to move XML documents between Rendezvous message _payload_ fields and event payloads.


2. Events:
There are three different types of events are present. They are
Simple event
Time Event
Advisory Event

2.1 Simple Events:
An event type includes three sets of information:
· Configuration, which includes a default destination, time to live(expiration period), and an expiry action.
· A set of Properties
· A Payload(optional)
Inheritance:
You can use inheritance to simplify configuration of events. A child event inherits
· All the parent events properties are inherited to child events.
· The parent event’s expiry action (if set). However, an expiry action set in the child event overrides the parent event expiry action.
· A parent event can’t have payload.
· If two events are related by inheritance, you can’t create a new property in one with a name that is already used in the other.
· If two unrelated events have properties that share a name, you cannot create an inheritance relationship between the two concepts

Time To Live (TTL):
Time To Live options are as follows:
Zero (0): the event expires after the completion of the first RTC cycle. Do not set to 0 if you want to correlate the event with a future event or other future occurrences of this event, as explained below.
One or higher (>0): the event expires after the specified time period has elapsed
A negative integer (<0): name="3360976">For each simple event definition, BusinessEvents allows you to specify the action(s) to take when that simple event expires, using the BusinessEvents rule language. For example, you can write an action that routes the simple event to a different destination, sends a message, or creates a new simple event. This action can be anything that is possible with the rule language. An expiry action can be inherited from the event's parent.
If an event is explicitly consumed in a rule, BusinessEvents does not execute the expiry action.

2.2 Time Event:
There are two types of time events. They are
1. Repeating Time Event: You can configure a time event to repeat at a configurable time interval.
2. Rule Based Time Event: A rule based TimeEvent resource has only a name and description. You finish configuring the event in a rule, using its ontology function. You can configure the event to be asserted after a period of time, and you can pass information to the event and specify it’s time to live.

2.3 Advisory Event:
The BusinessEvents engine automatically asserts an advisory event when it catches an exception that originates in user code but that is not caught with the catch command of the BusinessEvents Exception type (available in the rule language).
You never have to create or configure an event of type AdvisoryEvent. Only one event type is needed. It is called AdvisoryEvent, and it is available for selection from the resource list you see when you add a resource to the declaration of a rule in the rule editor.


3 Concepts:
Concept types are descriptive entities similar to the object-oriented concept of a class. They describe a set of properties. For example, one concept might be Department. The Department concept would include department name, manager, and employee properties.
Concept types are descriptive entities similar to the object-oriented concept of a class. They describe a set of properties. For example, one concept might be Department. The Department concept would include department name, manager, and employee properties.

· When BusinessEvents creates a concept instance, it automatically asserts it. (This is not true of events, which BusinessEvents only asserts if instructed to do so.)
· After BusinessEvents retracts an instance, it cannot re-assert it.


Concept property History: Each concept property includes a history, the size of which is configurable. The history size determines how many previous values BusinessEvents stores for that property.
If you set the history size to 0, BusinessEvents does not store historical values for the concept. It stores the value without a time and date stamp.
History Policy
BusinessEvents can record values using either of these policies:
· Changes Only BusinessEvents records the value of the property every time it changes to a new value
· All Values BusinessEvents records the value of the property every time an action sets the value even if the new value is the same as the old value.

Concept relationships: Concepts can have inheritance, containment and reference relationships with other concepts.
Inheritance Relationships
Definition: One concept inherits all the properties of another concept.
Concepts that are related to each other directly or indirectly by inheritance cannot have distinct properties that share a common name. Therefore, the following restrictions apply:
· If two concepts are related by inheritance, you cannot create a new property in one with a name that is already used in the other.
· If two unrelated concepts have properties that share a name, you cannot create an inheritance relationship between the two concepts.
·

Containment Relationships
Definition: One concept is contained inside another concept.
Note the following containment rules:
· A contained concept can have only one container concept. (Correspondingly, at runtime a contained instance can have only one container instance.)
· One container concept, however, can contain multiple different contained concepts.
· A contained concept can also act as a container concept.


For example, the concept Car contains the concept Wheels. The concept Car also contains other concepts, such as Door and Engine. The concept Car can contain multiple instances of a contained concept (such as Wheel) if the property is defined as an array.
But the contained concepts—Wheels, Doors, and Windows—cannot be contained by any other concept type. They can only be contained by the Car concept.

Runtime Behavior
The following statements apply to container and contained concepts at runtime:
· When BusinessEvents retracts a contained instance, under most circumstances, the value of the container’s property becomes null. The exception is when the property is configured as follows:
· The property allows multiple values. (It is a property array.)
· History is set to 1 or 0.

· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· When BusinessEvents replaces one contained instance with another, it retracts the instance that it replaced.
· When BusinessEvents asserts or retracts a container instance, it automatically asserts or retracts the contained instance along with any other contained instances at lower levels of the hierarchy.
· When BusinessEvents modifies a contained instance, it automatically modifies the container instance.



Reference Relationships
A concept reference includes a property that references the ID of another concept.
· When BusinessEvents retracts a concept that is the target of a concept reference, under most circumstances, the value of the concept reference property becomes null. The exception is when the property is configured as follows:
· The property allows multiple values. (It is a property array.)
· History is set to 1 or 0.
· Under these conditions, BusinessEvents deletes the entry in the array that corresponds to the retracted concept, reducing the array size by one.
· At design time, in the rule editor, you can access referenced properties in the rule’s action area, but not in the condition area.






4 Concept view:
You can optionally work with concepts and their relationships using a graphical user interface called a concept view. You create new concepts and create new relationships between the concepts.








5. Scorecard:

Scorecard is special type of concept. A scorecard serves as a static variable that is available throughout the project. You can use a scorecard resource to track key performance indicators or any other information.
Unlike concepts and events, each scorecard resource is itself a single instance — it is not a description for creation of instances. You create the scorecard at design time. Its values can be viewed and updated using rules.
It is more accurate to say there is one instance of a scorecard per rule session. When a BusinessEvents engine runs with multiple rule sessions, each rule session has its own instance of the score card.
It is not necessary to add scorecards to the declaration of a rule, because there is only one instance of each scorecard in a deployed BusinessEvents application. Any change causes all rules that use the scorecard in their conditions to be evaluated.

Rule:
A rule includes a declaration of entity types, and (optionally) one or more conditions, which evaluate to true or false, and one or more actions, which fire when all conditions evaluate to true.
Within the Actions panel, semicolons separate statements; one statement can span multiple lines; one line can include multiple statements. However (unlike conditions) there is only one action. The action might be to execute tasks, create an instance, modify property values in an instance, create and send a simple event, or something else.

Rule Sets
A rule set is a container for rules. All rules exist within a rule set. The main reason to group rules in rule sets is so that you can deploy different rule sets to different BusinessEvents Archives, resulting in different rule sessions at runtime. Your project design determines which rules to put in each rule set.


Rule Priority
BusinessEvents rules are declarative rather than procedural: there is no inherent order for processing. The priority property allows you to specify which rules should fire first.
When a simple event enters BusinessEvents, it triggers BusinessEvents to create an agenda for fireable rules, where the highest priority rule fires first. After firing the highest priority rule, BusinessEvents reevaluates all dependent rules and modifies the rule agenda as needed.

Understanding Rule Functions
A rule function is a function you write in the BusinessEvents rule language for use in a project. To create a rule function, you use a RuleFunction resource.
Rule functions may take arguments and may return a value. The return type can be set to void, indicating that the rule function does not return anything.
You can use rule function in the same way as the standard (provided) functions, custom functions, and ontology functions (which are created automatically from the entity types). You can use rule functions in rule conditions and rule actions.
You can assign rule functions to be used as event preprocessors, and as startup and shutdown actions.
All rule functions created for a project are available project-wide, in any rule session.
Virtual Rule Functions
Virtual rule functions have arguments but no body or return type. The implementation of virtual rule functions is provided by decision tables in Decision Manager.
You can use virtual rule functions in rules in BusinessEvents in the usual way. However, the implementation of the virtual rule function must be provided in an external class that is exported from the Decision Manager Rule management server and placed in a known location. The classes are loaded at system startup, or using JMX while the system is running.


Functions
BusinessEvents offers four types of functions for use in rules. They are
· Standard: These functions are provided with businessEvents.
· Ontology: BusinessEvents generates these functions based on the resources available in the project.
· Custom: we can write our own functions using java and integrate them into businessEvents for use in Rules.
· Rule function: with the help of rule function resources, you can write functions using businessEvents rule language.

State Modeler
The State Modeler feature is available only in TIBCO BusinessEvents Enterprise Suite.
State Modeler is a UML-compliant application that allows you to model the life cycle of a concept instance — that is, for each instance of a given concept, you can define which states the instance will pass through and how it will transition from state to state.
States have entry actions, exit actions, and conditions, providing precise control over the behavior of BusinessEvents. Transitions between states also may have rules. Multiple types of states and transitions maximize the versatility and power of State Modeler.

Object Management
An important aspect of most BusinessEvents applications is management of the objects created and modified at runtime.
Different projects have different object management requirements. For some, it is acceptable to destroy the objects once the rule engine cycle that needs them has completed. They require only memory-based object management. For others, the instances have value beyond the rule engine cycle and need to be persisted.
Part of object management is configuring for fault tolerance so that objects in memory are not lost in the event of a system failure. BusinessEvents supports a variety of object management and fault tolerance options.

Query Language for Querying Cached Objects
Available in TIBCO BusinessEvents Enterprise Suite only, the query features enable you to perform snapshot queries and continuous queries using an SQL-like query language. You can then send query results to outbound destinations or use them in rules as desired.

Introduction To Tibco EMS

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

Multicast
Multicast messaging allows one message producer to send a message to multiple subscribed consumers simultaneously. As in the publish and subscribe messaging models, the message producer addresses the message to a topic. Instead of delivering a copy of the message to each individual subscriber over TCP, however, the EMS server broadcasts the message over Pragmatic General Multicast (PGM). A daemon running on the machine with the subscribed EMS client receives the multicast message and delivers it to the message consumer.
Multicast is highly scalable because of the reduction in bandwidth used to broadcast messages, and because of reduced EMS server resources used. However, multicast does not guarantee message delivery to all subscribers.




Destinations overview:

1. Static: created by EMS administrator.
2. Dynamic: created by Client programs as needed for short-term use.
3. Tempprary: Temporary destinations are ideal for limited-scope uses, such as reply subjects.

EMS supports messages up to a maximum size of 512MB

JMS messages have a standard structure. This structure includes the following sections:
Header(required)
Properties(optional)
Body(optional)
JMS message types:
Message: This message type has no body. This is useful for simple event notification.
Text Message: A Java.Lang.String
MapMessages: A set of name/value pairs.
Bytes Messages: A stream of uninterrupted bytes. The bytes are not typed; that is, they are not assigned to a primitive data type.
StreamMessages: A stream of primitive values in the Java programming language. Each set of values belongs to a primitive data type, and must be read sequentially.
ObjectMessage: A serializable object constructed in the Java programming language.

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 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.
Figure 6 Non-Persistent Message Delivery

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

Message Selectors
A message selector is a string that lets a client program specify a set of messages, based on the values of message headers and properties. A selector matches a message if, after substituting header and property values from the message into the selector string, the string evaluates to true. Consumers can request that the server deliver only those messages that match a selector.
The syntax of selectors is based on a subset of the SQL92 conditional expression syntax.
Identifiers
Identifiers can refer to the values of message headers and properties, but not to the message body. Identifiers are case-sensitive.
Basic Syntax
An identifier is a sequence of letters and digits, of any length, that begins with a letter. As in Java, the set of letters includes _ (underscore) and $ (dollar).

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[KBMBGB]
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.
You can optionally include a KB, MB or GB after the number to specify kilobytes, megabytes, or gigabytes, respectively. For example:
flowControl=1000KB
Means 1000 kilobytes.
The flow_control parameter in tibemsd.conf file must be set to enabled before the value in this property is enforced by the server. See Flow Control for more information about flow control.

Connection Factory:
A connection factory is either dynamically created by the application or obtained from a data store by means of a naming service, such as a Java Naming and Directory Interface (JNDI) server or a Lightweight Directory Access Protocol (LDAP) server.



Fault Tolerance:

You can arrange TIBCO enterprise message service server fault tolerant operation by configuring pair of servers - one primary and backup. The primary server accepts client connection, and interacts with clients to deliver messages. If primary fails, backup server resumes operation on its place.

Shared State
A pair of fault tolerant servers must have access to shared state, which consists of client connections and persistent messages. This information is useful for backup server to resume its operation of current connections and messages.


Locking:

To prevent the backup server from assuming the role primary server, the shared state is locked by primary server during normal operation. If primary server fails, then lock is released and the backup server can obtain lock.


Configuration Files:

When a primary server fails, its backup server assumes as primary server and resume operations. Before becoming new primary server, the backup server re-reads all it configuration files. If configuration files are shared by two servers then administrative changes carry from old primary server to new primary server.


Detection:

The backup server detects the failure of primary server in either two ways:
1. Heartbeat failure: the primary server sends heartbeat messages to backup server to indicate that it is still operating. When a network failure stops the servers from communicating each other, the backup server detects the interruption in the steady stream of heartbeat.
2. Connection failure: The backup server detects its failure of TCP connection with primary server. When the primary process terminates unexpectedly, the backup server detects the broken connection.

Heartbeat Parameters

When the primary server heartbeat stops, the backup server waits for its activation interval (elapsed time since it detected the most recent heartbeat); then the backup server retrieves information from shared storage and assumes the role of primary server.

The default heartbeat interval is 3 seconds, and the default activation interval is 10 seconds. The activation interval must be at least twice the heartbeat interval. Both intervals are specified in seconds. You can set these intervals in the server configuration files.

Shared State:

The primary server and backup server must share same state. The server state includes three categories of information.
1. Persistent message data
2. Client connection of the primary server
3. Meta data about message delivery

Configuring Fault-Tolerant Servers
To configure an EMS server as a fault-tolerant backup, set these parameters in its main configuration file (or on the server command line):
· Server Set this parameter to the same server name in the configuration files of both the primary server and the backup server.
· ft_active In the configuration file of the primary server, set this parameter to the URL of the backup server. In the configuration file of the backup server, set this parameter to the URL of the primary server




Authorization and Fault-Tolerant Servers
EMS authorization interacts with fault tolerance. If authorization is enabled and the two EMS Servers are configured for fault tolerance, then both servers in a fault-tolerant pair must be configured as follows:
· The tibemsd.conf file for each server must have the same server name and password (the server and password parameters must be the same on each server).
· The user name and password in the users.conf file for each server must match the values of the server and password parameters in the tibemsd.conf file.

If the two EMS servers are not sharing a users.config file, make sure that you create a user with the same name as the EMS server, and set the user’s password with the value of the “Server” password.


Configuring Clients for Fault-Tolerant Connections

When a backup server assumes the role of the primary server during failover, clients attempt to reconnect to the backup server (that is, the new primary). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection. Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl).

The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried). If none of the attempts succeed, the connection fails.

For example, to identify the first server as tcp: //server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify:

serverUrl = tcp://server0:7222, tcp://server1:7344

Routes


Tibco Enterprise message service servers can route messages to other servers

1. Topic message can travel from one hop to multiple hops
2. Queue messages travel from one hop to home queue and to one hop from home queue.