TIBCO BUSINESS WORKS VIDEOS

There are three ’locations’ or ‘containers’ that a Business Work EAR can be deployed to. These are:

1) Business Work Standalone Service Engine

2) Business Work Service Engine Implementation Type (BWSE-IT) within an ActiveMatrix Node

3) Business Work Service Container (BW-SC)

The first two scenarios do not require any special effort during deployment and usually can be done through the admin interfaces (bw-admin for standalone and amx-admin for BWSE-IT). But if one wishes to deploy an EAR to a Service Container then we need to setup the container and make a change in the Process Archive. This tutorial is for a Windows-based system.

Before we get into all that let us figure out what a BW Service Container (BW-SC) and why one would want to use it.

A BW-SC is a virtual machine which can host multiple processes and services within individual process engines. Each EAR deployed to a BW-SC gets its own process engine. The number of such process engines that can be hosted by a container depends on the running processes and the deployment configurations. To give an analogy, the load that an electric supply (service container) can take depends on not just the number of devices (i.e. process engines) on it but also how electricity each device requires (processes running within each engine).

Keeping in mind the above, when using BW-SC, it becomes even more important to have proper grouping of processes and services within an EAR.

The standard scenario when you would use a BW-SC is for fault-tolerance and load-balancing. In other words, to deploy the same service (fault-tolerance) and required backend processes (load balancing) on multiple containers. Also Service Containers can be used to group related services together to create a fire-break for a failure-cascade.

The first step to deploying to a BW-SC is to enable the hosting of process engines in a container. The change has to be made in the bwengine.xml file found in the bw//bin directory. Locate the following entry (or add it if you cannot find it):

BW Service Container

bw.container.service

Enables BW engine to be hosted within a container

The second step is to start a service container to which we can deploy our EARs. Go to the command line and drill down to the bw//bin directory. There run the following command:

bwcontainer –deploy

Here the value, supplied by you, will uniquely identify the container when deploying EARs. Make sure that the container name is recorded properly. In the image below you can see an example of starting a container called Tibco_C1.

The third step is to deploy our application to the container (Tibco_C1). Log in to the BusinessWork Administrator and upload the application EAR. In the image below the test application EAR has been uploaded and awaits deployment.

The fourth step is to point the process archive towards the container we want to deploy to. Click on the Process Archive.par and select the ‘Advanced’ tab. Go down the variable list and locate the bw.container.service variable which should be blank if you are already not deploying to a container.

Type the container name EXACTLY as it was defined during startup. TIBCO will NOT validate the container name so if you set the wrong name you will NOT get a warning, you will just be left scratching your head as to why it didn’t work. In our example we enter ‘Tibco_C1′ in the box (see below).

Save the variable value and click on Deploy. Once the application has been deployed, start the service instance. That is it.

To verify that your application is running on the container, once the service instances enter the ‘Running’ state, go back to the command line and the bin directory containing bwcontainer.exe. There execute the following:

bwcontainer –list

This command will list the process engines running in any active containers on the local machine. The output from our example can be seen below.

We can see the process archive we just deployed, running in the Tibco_C1 container.

If you have any other containers they will also show up in the output.

Remember one important point: If a service container goes down, all the deployed applications also go down. These applications have to be re-started manually through the Administrator, after the container has been re-started.

If your project has messaging encoding set to UTF-8 but your TIBCO Administrator is set to ISO8859-1 then you will not be able to deploy your project.

The TIBCO recommended encoding to use is UTF-8. But in case you made the mistake of not using UTF-8 (either in your project or in TIBCO Administrator) then you will need to change the encoding.

To change project encoding:

- Click on the root project folder.

- In the configuration panel you will see three tabs [Configuration, Project Settings and Design Time Libraries].

- Click on Project Settings where you will find a drop down titled ‘TIBCO Messagin Encoding’ with two values: ISO8859-1 and UTF-8.

- Select UTF-8 and click Apply and then save your project.

To change it for the TIBCO Administrator:

- Locate the tibcoadmin_.tra file. It should be in: \administrator\domain\\bin

- Open this file in a text-editor and locate the entry ‘tibcoadmin.client.encoding’ and ‘repo.encoding’.

- Change them both to UTF-8 if they are not UTF-8.

- Save the file.

- Restart both the Hawk Agent and the TIBCO Administrator service on the machine.

If the Administrator fails to deploy a UTF-8 encoded project after making the changes above and in the log you see a ‘com.tibco.infra.repository.OperationFailedException: Can not change encoding from ISO8859-1 to UTF-8 because of other existing connection with different encoding’ exception try and restart your Hawk Agent and any other TIBCO related service.

Version of Designer: 5.5.2.2

Version of TIBCO EMS: 4.4.3

Some time ago I did a post about developing web-services using TIBCO BusinessWorks. In this post I would like to discuss how to develop a web-service which uses JMS as the SOAP transport instead of HTTP. The problem with developing a web-service bound to a JMS Queue instead of an HTTP transport, is that it can be used only in a homogeneous TIBCO environment. In other words we need to have TIBCO at both (client and server) ends if we are using a web-service bound to a JMS Queue.

This is so because the WSDL representation of the binding is proprietary to TIBCO (more on this later) as there is no agreed standard for binding SOAP to JMS. Although when I was digging around I did find a ‘working draft’ at W3.org for SOAP over JMS (http://www.w3.org/TR/soapjms/) so something is being done to plug this gap!

Why all this hassle for SOAP over JMS you ask? Why not stick with good old SOAP over HTTP? Well simply because JMS transport is whole lot more robust and can be scaled up easily without affecting QoS etc.

Introducing the Example

The web-service we are going to create in this example is a relatively simple one. It will take in two integers and return their sum. A fairly simple example but this post is about using SOAP over JMS so that is what we will concentrate on.

The schema for the request and response messages is given below:

xmlns="http://www.tibco.com/schemas/WebServiceTest/Schema/Schema.xsd"

targetNamespace="http://www.tibco.com/schemas/WebServiceTest/Schema/Schema.xsd"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

Now the next thing we need to do is to setup the Service Resource. I won't go into the details of how it is done as I have already covered most of the steps in a different post.

The reason I don’t need to go into details is because web-services are designed to decouple the operation from the ways of accessing that operation (i.e. the binding). Obviously as binding = message format + transport AND each operation can have different bindings, the only thing that will be different when setting up the Service Resource will be the Binding Section. Furthermore as we are still using SOAP as the message format the only difference that you will see in the Service Resource, as compared to SOAP over HTTP configuration, will be in the Transport sub-tab (see image below).

In the Transport sub-tab, if instead of selecting a HTTP connection, a JMS connection is selected in the Transport box (see image above), then you will get options to setup the JMS transport.

Setting up the JMS Transport

Setting up the Transport in case of JMS is bit more involved than HTTP. For the sake of clarity we will use Queues for our web-service instead of Topics. There are four main things to setup once you have selected a JMS connection in the Transport box. These settings are similar to those in the JMS activities such as JMS Queue Sender.

1) JMS Destination – the queue or topic which will contain the JMS message carrying the SOAP as payload.

2) JMS Destination Type – Queue or Topic (depending on what kind of interaction is required).

3) JMS Message Type – Text or Bytes message – we go for Text in the example so that we can examine the SOAP message being sent over the EMS.

4) Acknowledgement Mode – Auto for the example otherwise all the standard and TIBCO EMS specific options are available for selection.

If you select ‘Topic’ as the JMS Destination Type then you can also decide which of the Operations have a ‘durable subscription’.

That is the only difference in changing from SOAP over HTTP to SOAP over JMS as far as the Service Resource is concerned.

Looking at the WSDL

Once everything is setup navigate to the WSDL Source tab in the Service Resource configuration to look at the WSDL which has been generated for the web-service.

tibjmsnaming://localhost:7222

com.tibco.tibjms.naming.TibjmsInitialContextFactory

QueueConnectionFactory

inQueue

Let get back to the issue of lack of standards for SOAP over JMS and why we need TIBCO at both ends.

For that we need to focus down into the Binding and Service elements of the WSDL.

Looking at the Service element (see below), where the method of connecting to the web-service is defined. We find that it contains information about the EMS server (from the Connection resource we set in the Transport box) as well as the queue name we set in the Transport sub-tab.

tibjmsnaming://localhost:7222

com.tibco.tibjms.naming.TibjmsInitialContextFactory

QueueConnectionFactory

inQueue

We also find two strange new namespaces being used - jms and jndi. Let us see what these namespace prefixes stand for. Scroll right up to the top of the WSDL and you will see the following entries:

xmlns:jms="http://www.tibco.com/namespaces/ws/2004/soap/binding/JMS"

xmlns:jndi="http://www.tibco.com/namespaces/ws/2004/soap/apis/jndi"

These two namespaces have been defined by TIBCO so they are internal and are not 'standardized' as are other namespaces in the WSDL such as xs ( xmlns:xs="http://www.w3.org/2001/XMLSchema") for the schema in Types or soap (xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/") for SOAP related properties in Binding.

Thus if you are a non-TIBCO client you will have no idea what jms:targetAddress element means in the WSDL.

Once there is a standard for SOAP over JMS then instead of TIBCO specific namespaces we will see a prefix like soapjms with the definition xmlns:soapjms = "http://www.w3.org/2010/soapjms/" [1] .

Next we look at the Binding element (see below). Here also we find the TIBCO specific JMS namespace as well as SOAP over JMS transport definition (in bold).

Again once we have a standardized way of binding SOAP to JMS then instead of the TIBCO specific listing in transport attribute we will have something like “http://www.w3.org/2010/soapjms/”[1].

If we compare the Service and Binding elements above to those in the same web-service but using HTTP instead of JMS we that all namespaces being used to define the connection and binding properties are standardized. That is what makes SOAP over HTTP web-services independent of vendors and implementation languages.

Next we test the web-service. Make sure you save the WSDL Source (i.e. the concrete WSDL) so that our test client can use it.

Testing

To test the web-service we will create a client using BusinessWorks. We will use a SOAP Request Reply activity to test the web-service. The images below show how to configure the activity to access the web-service.

In the configuration simply select the namespace from the concrete WSDL file we saved for the client. As we are using TIBCO to create the client once you set the WSDL everything will be auto-populated. Go to the Transport Details tab (see below) and there you will see the JNDI and JMS sub-tabs which have also been auto-populated from the WSDL. This is so because TIBCO understands the jms and jndi namespaces and knows what to do with the information in the WSDL.

JNDI Sub-tab:

JMS Sub-tab:

After loading the WSDL and saving the changes the SOAP Request Reply activity will ask you for an input (the two integers to be added).

Save everything and load the relevant processes. On starting the test you should see the Request being fired. If you monitor the relevant queue you will see a message being posted on the queue. The message will be consumed by the web-service and it will return the result back to the queue which in turn will be consumed by the client and you will see the output in the process. As we provided ’3′ and ’4′ as the two integers to be added in the input (see image above) the result we get is ’7′ (see below).

7

If you want to take a look at the actual messages being sent in the JMS Message you can always stop the server before sending the request or after sending the request stop the client. The request or response message will remain in the queue and you can view the content (as we are using JMS Message Type of Text) by browsing the queue.

That is the end of the tutorial. Let me know if I have made any mistakes or if you have any suggestions.

Thank you for reading!

Version of Designer used: 5.5.2.2

Global Variables (GVs) are one of the most important bits of any BusinessWorks project. Every project will have at least one set of GVs, usually to store certain settings centrally. GVs also allow those settings to be changed on a running application without having to re-archive and re-deploy it.

A common usage scenario (which I will be using as an example as well) for GVs is to store connection settings for the EMS server. Basic set of connection settings for say a JMS Connection resource would be the Username and Password information and the JNDI information.

As it is very important to structure the GVs properly for easy reference and maintainability you should make good use of Groups. A common way of structuring GVs is to use the location path as a group.

For example if your JMS Connection resource is in /MyProject/Connections/JMS/ folder then you would create three groups. A main group for all the project GVs called MyProject, below that a sub-group for all Connections in your project and below that a group for all JMS connections and so on.

But if you have tried to use the GV editor in Designer and have been frustrated with forever expanding and collapsing nodes, re-sizing the window and not being able to copy-paste stuff then you will know what a nightmare it is to create complex group hierarchies. Don’t you wish you could just edit an XML file and create those GVs instead of using the built-in GV editor in Designer.

Fear not though, there is a quicker and easier way of creating and edition GVs (otherwise no point in writing this post

Lets start with a blank canvas so as to say. Open up the Designer and navigate to the Global Variables tab (see image below). Click the yellow pencil button to bring up the dreaded built-in GV editor.

Let us say we want to create a complex hierarchy of groups and values but we want to do it without getting frustrated with the built-in GV editor. It is possible to achieve this using the Windows Explorer (or the Linux equivalent) along with a text-editor (even Notepad will do but I prefer Notepad++ as it has XML support).

Basic Concept

Before we start the editing process it is important to understand how the GVs are stored in a project. One would have thought there would be a file with the GV hierarchy and values which we could edit. That thought is partially correct.

The main thing to understand is that every GV Group is a folder within the Global Variable root folder (more on this later). Furthermore every GV is an entry in a simple text file within the folder of the Group it belongs to.

Locate the Global Variable Root Folder

Open up your Windows Explorer and navigate to your TIBCO Designer Workspace folder. There navigate to the project for which you want to create GVs. Within the project folder there should be a folder called ‘defaultVars’. This is the ‘root’ folder for your global variables.

In the example the project name is WebServiceTest and the path is: [TIBCO Workspace Folder]\WebServiceTest\defaultVars

DefaultVars.substvar File

Within the ‘defaultVars’ folder you will find a file named defaultVars.substvar. This file can be opened in any text-editor and it contains all GVs belonging to the ‘root’ Group.

If you open this file in a text-editor you will find that it contains XML data. For the above set of GVs (see image) in the ‘root’ Group you will see entries like:

JmsProviderUrl

tcp://localhost:7222

true

false

String

1282736878059

JmsSslProviderUrl

ssl://localhost:7243

true

false

String

1282736877974

RemoteRvDaemon

true

false

String

1282736878048

From the above listing we can see that each GV has its own globalVariable element. There are several child elements present for each global variable:

Name - is the ‘name’ of the GV which is also displayed in the Global Variable tree (see figure above).

Value - is the actual value of the GV.

DeploymentSettable - GV can be set during deployment.

ServiceSettable - GV is settable at per service level. Used for TIBCO Adapter archives.

Type – Data type of the GV. Possible data types: String, Integer, Password and Boolean.

ModTime - Time GV was modified.

So the root variable JmsProviderUrl is represented as:

JmsProviderUrl

tcp://localhost:7222

true

false

String

1282736878059

Example Now if we want to create a new set of GVs for a JMS connection with the location WebServiceTest/Connections/JMS then we need to first create the folder structure within the root folder which will give us the corresponding Groups in the Global Variables tab. The folder structure will now look like below: Next we need to add some GVs to the JMS group. To do this go down to the JMS sub-folder and in there create a defaultVars.substvar to store the GVs. Make sure the extension of the file is .substvar. Next open this file in a text-editor and add the following tags:

All variables will be defined within the globalVariables tag.

Next we create two GVs one for storing the EMS username (JMS_Username) and one for storing the password (JMS_Password) as below:

JMS_Username

User

true

false

String

1282736878069

JMS_Password

Password

true

false

Password

1282736878069

Save and close the file. Then close and reopen the project in Designer (required to refresh the Global Variable tab).

After reopening the project if you go to the GV tab you will see the following:

As you can see the two GVs we created in the file are now ready for use. Also notice each of the folders we created within the defaultVars root folder is shown as a Group.

Using this method you can also copy-paste GVs for things like JMS Queue Receiver and Senders to create separate set of GVs for different processes and/or services.

Example project: http://www.fisheyefocus.com/GVTest.zip

Overview with the created GVs on the left hand side and the JMS connection using one of the GVs on the right hand side:

The project running:

Versions of software used:

TIBCO BusinessWorks Designer 5.5.2.2

SOAP UI 3.0.1

A quick round of testing within the Designer before packaging the project and deploying anything on a full scale test setup is always a good idea.

So you have just designed and implemented your first web-service in TIBCO Designer. But what about testing it from outside the TIBCO environment with a non-TIBCO client? After all the point of web-services is to be independent of implementation!

There are several ways of doing this. You could quickly create a client in your language of choice, especially with modern IDEs supporting auto-client generation from the WSDL file. Or you could use a software like SOAP UI and do everything in SOAP without bothering with the SOAP-to-Language API.

Now as such it is VERY EASY to test a web-service running under TIBCO Designer with SOAP UI:

1) Save the WSDL generated by TIBCO (how to save will depend on whether you are using a SOAP Event Source Starter Activity or a Service Resource for your Web-Service).

2) Start SOAP UI and create a new project.

3) It will ask for the WSDL associated with the Web-Service that you want to test, supply the saved WSDL.

4) Click OK and default SOAP requests for all operations will be created by SOAP UI.

Things get a bit complicated when it comes to testing Web-Services which require authentication. This is so because TIBCO leaves authentication with the BusinessWorks Administrator and credentials are defined in the domain (which makes sense). Then how can we check web-services with authentication without needing to package and deploy them?

There is an easy way, especially if you are using basic authentication.

Setting Web-Service to use Basic Authentication

To enable basic authentication in a Service Resource (see image below) you will need to go to the Endpoint Bindings tab within the Service for which you want to set the basic authentication. Select a SOAP endpoint for which you want to setup the authentication. This will give you two tabs, one for Transport and one for SOAP details.

Within the Transport tab you will find a check-box titled ‘Use Basic Authentication’. Select it to use basic authentication.

To achieve the same in a SOAP Event Source starter activity just go to the Transport Details tab within the configuration and you will see a similar ‘Use Basic Authentication’ checkbox.

One word of warning: once you select basic authentication your web-service clients will NOT work till you finish the next step and add a valid username and password to the request.

Enable Authentication in Designer

Now that your web-service is setup for using basic-authentication, you need to setup TIBCO Designer to authenticate incoming requests.

To do this copy tibco\tra\domain\[Domain Name]\AuthorizationDomain.properties to tibco\tra\5.5 (x.x is the version number of the installed TRA, in my case it was version 5.5).

Found this solution here: http://eai.ittoolbox.com/groups/technical-functional/tibco-l/bw-http-basic-authentication-2526019

Testing

Final step is to test the web-service using basic authentication.

If you try and invoke the web-service without copying the properties file and without supplying the username and password you will get an ‘Internal Error’ response.

If you try and invoke the web-service without a username or password (irrespective of whether you copied the properties file or not) you will get a ‘This request requires HTTP authentication’ error response.

Once the properties file has been copied to the correct location the only thing that is left is to supply the username and password in the request.

In SOAP UI, navigate to the request generated for the web-service being tested. In the bottom left hand side there will be a Request Properties box (see image below). Scroll till you see the option for Username and Password. Enter the details for the username defined in the properties file (UserID property) and execute the request. This time if all is well then you should get the correct response from the web-service.

SOAP UI Basic Authentication Test

If you don’t get the correct response make sure you restart SOAP UI and Designer after copying the file.

Always remember to test your web-service WITHOUT basic authentication BEFORE testing with it. This will ensure there is nothing fundamentally wrong with the web-service.

You do not need to refresh the WSDL file for the web-service after enabling/disabling basic authentication. This is because basic-authentication operates at the level of the HTTP request and does not affect the SOAP content which is a payload of the request. Therefore basic authentication is available for HTTP transport only and not for JMS.

Service

- Port definition

– soap:address

Binding

- soap:binding

- operation

– soap:operation

– input

– soap:body

– output

– soap:body

PortType

- operation

– input

– output

Message

- part

Types

Figure 1: WSDL Structure – visual representation of various sections of a WSDL and the relationships between them.

Any WSDL document is a combination of an abstract service interface and its concrete implementation.

The PortType section represents the service in an abstract way, similar to an ‘interface’ in object-oriented programming (OOP). In other words, it lays down the ‘contract’ between the service provider and the consumer by listing the various operations supported by the web-service as well as the required input and the resulting output of each operation. The inputs and outputs are listed as messages which are described in the Message section of the WSDL.

The Binding section is similar to an interface implementation in OOP. The ‘type’ attribute in the Binding tag points to the PortType name which is being implemented.

The thing to keep in mind is that the Binding section is where the abstract web-service contract is implemented or realised. Thus, among other things the Binding section describes operational level details such as which protocol to use for transporting SOAP packets (usually HTTP) and how the web-service will be called (style and encoding).

The Service section describes one or more concrete ‘endpoints’ where the functionality of the service can be found.

Figure 1 shows these various sections of the WSDL and how they connect with each other.

Finally the Types section contains schema information for the various inputs and outputs from the web-service operations.

After developing a web-service using the Service resource from the TIBCO Designer palette (ver. 5.6) we need to develop a resource retriever to allow clients to access the service WSDL.

The basic idea behind getting the WSDL for a Service resource web-service is to use the SOAP Retrieve Resources activity (found within the SOAP menu) and point it to the Service resource for the web-service with the filter set to “wsdl”.

The screenshot below shows the basic process for retrieving the WSDL. We will use the HTTP Receiver process starter connected with the SOAP Retrieve Resources which sends its output to Send HTTP Response activity.

Here is how it works:

A HTTP Receiver forwards the incoming request to a SOAP Retrieve Resources activity (SOAP-RRA).

The SOAP-RRA retrieves the WSDL text and outputs it to the Send HTTP Response activity.

The Send HTTP Response activity then sends the WSDL text as response to the HTTP request received by the HTTP Receiver.

The process ends.

The HTTP Receiver will need an HTTP Connection to complete the configuration.

The key thing here is to configure the SOAP-RRA correctly. The HTTP Receiver even though connected to the SOAP-RRA provides no input to it.

Click on the SOAP-RRA and go to the Input tab in the properties (see the screenshot above). In the Activity Input section we need to configure the resourcePath and filter values.

The reourcePath should point to the Service resource. To get the Service resource path right-click the Service resource for the web-service whose WSDL is required and click on inspect resource.

The Resource Inspector window that pops up will show the resource path for the Service resource (see marked area in screenshot below). Remember to enclose the path in double-quotes!

In the filter value type in “wsdl” (double quotes included) as we want the WSDL to be retrieved.

SOAP-RRA connects next to the Send HTTP Response activity. We connect the resourceData output from SOAP-RRA to the Send HTTP Response asciiContent input as shown in the screenshot below.

The Send HTTP Response activity connects to the End Process activity which completes the process.

Testing the Retriever Process

To test the process start the process tester. Make sure you select the retriever process we have just created AS WELL AS the Service resource for the web-service whose WSDL is being retrieved.

Open up the browser and type in the address defined in the HTTP Connection used for the HTTP Receiver.

The WSDL should pop-up in the browser and if you check the process tester you will find the retriever process would have fired once.

In this post we are going to talk about developing web-services in TIBCO ActiveMatrix BusinessWorks (AMBW). We will be using the following software:

1) TIBCO Designer 5.6 to develop and test-deploy the web-service

2) SOAP-UI 3.0.1 (Freeware) to test the web-service

We are going to be looking at web-service development from a conceptual point of view rather than concentrating on specific implementations.

The TIBCO AMBW Process Design Guide and the Palette Reference do an excellent job of describing web-service implementations.

Before we get into web-service development in TIBCO AMBW let us just review what goes into developing a web-service. As there are many excellent books on web-services out there this section will be restricted to a brief overview.

A web-service consists of three basic components:

Description – all the information about the web-service, including how to invoke it.

Protocol – how to communicate with the web-service.

Implementation – how to implement the operations defined by the web-service.

The Description of a web-service needs to address both, the abstract interface as well as its concrete implementation. As we all know this description is contained in the WSDL file associated with the web-service. With modern tools it is very easy to create client stubs for web-services using just the WSDL.

The WSDL also acts as a contract between the service provider and the consumer. Therefore a skeleton of the web-service implementation can also be created using just the WSDL. This approach towards service development is called the ‘contract-first’ approach where you define the interface before defining the implementation.

The opposite of the above process i.e. ‘implementation-first’ approach allows easy exposure of existing functionality as a web-service.

TIBCO AMBW allows for both styles of web-service development.

Before we go any further it will help to review the structure of a WSDL document.

There are two ways of implementing a web-service in TIBCO AMBW:

1) Service Resource

2) SOAP Event Source process starter

Which route you take depends on your specific requirements as well as the current state of development.

You would ideally use a SOAP Event Source process starter to expose a single process as a web-service over a single transport protocol. In case you need to expose multiple processes over multiple transport protocols and have a clean separation between web-service definition and implementation, use the Service Resource.

I will first focus on using the Service Resource as it (in my opinion) is a cleaner way of doing things and conforms well to the philosophy behind web-services of separation of interface and implementation.

SOAP Event Source will be covered in another post.

Now from the TIBCO AMBW Process Design Guide we have:

“A service joins an abstract WSDL interface to a concrete implementation and exposes them on one or more endpoints”

There are three main steps in setting up a web-service using the Service Resource:

1) Define the service interface using the WSDL and Schema Resource – involves definition of the abstract part of the WSDL as well as defining schema for input and output data using the Schema Resource

2) Setup the endpoint bindings to expose the service.

3) Implement the operations defined in the web-service.

Figure 1 shows the mapping between TIBCO AMBW components and various components of a web-service (as represented in the WSDL).

Figure 1: Mapping between TIBCO AMBW components and various components of a web-service.

Request Context

As the Service Resource separates the service definition from the implementation, there might be a requirement to access the ‘context’ of the request by the implementing process. This ‘context’ could be the client’s digital signature (for authentication) or something simpler like a client ID. The Context Resource allows us to do just this. We can define a schema to store the relevant ‘context’ which can then be accessed by the implementing process using the GetContext and SetContext activities.

Example

I will take the example of a simple web-service for Customer Information Management (add and retrieve customer information). The web-service will contain two operations:

Add Customer Information (name, age and ID).

Retrieve Customer Information using Customer ID with a Request ID for logging purposes.

To get the customer information we supply the customer ID and a request ID to the web-service which will return the customer information.

To add information for a new customer we will supply the customer information (id, name and age).

Going back to the three step process for implementing a web-service using the Service Resource:

Step 1: Defining the web-service interface

We will use the Schema Resource and the WSDL Resource to define the web-service interface including the operations and the associated input/output schema.

The Schema

Firstly create the Schema for the input and output messages using the Schema Resource (within the XML menu).

Below we can see a simple CustomerInformation schema which defines the customer information structure (for both retrieval and addition) as well as a CustomerInformationRequest schema which defines the structure of the incoming request for customer information.

The Web-service Interface using WSDL

Next we define the interface for the web-service using the schema we defined above and a WSDL resource.

We will first define the input and output messages using the schema and then use them to define the operations. All the required resources are in the WSDL menu.

Create a new WSDL resource and double-click it. Add two new Messages: CustomerInformationRequest and CustomerInformation. The output message for the retrieve information operation has the same schema as the input for the add information operation.

Next we define the operations using previously defined Messages. Add a PortType resource to start defining operations. Double click the PortType resource and add two new Operations: AddCustomer and RequestCustomer.

In the AddCustomer operation configuration, add an input message with the message schema set to CustomerInformation (we are now connecting the schema with the interface). We don’t need any output message for this operation.

In the RequestCustomer operation configuration, add an input message with message schema set to CustomerInformationRequest and the output message with message schema set to CustomerInformation.

This can be seen in the screenshot below.

You will notice that till now we have been defining only the interface of the web-service (namely the operations and messages). We have not spoken about things like which transport protocol to use or the style of the web-service (document vs. RPC).

The next step is to use the Service resource to configure the concrete endpoints using the interface we have just defined. After that in the final step we will use the Service resource to join the abstract interface of the service with the actual implementation of the operations.

Step 2: Implementing the service endpoints using Service Resource

Add a Service resource from the Service menu.

The first thing we need to do is to give this service a ‘face’ (in other words define which interface it is going to ‘implement’).

Double-click it and within the Configuration tab click on the ‘+’ button in the ‘Implementation’ section. In the window that pops up locate the WSDL file (on the left side) with the abstract interface that you have defined in Step 1. The PortType, Namespace and Operations will be loaded from the WSDL on the right hand side. This is shown in the screenshot below.

Check the operations and the input and output for them. Click on ‘OK’.

The Service resource should contain a whole lot of new stuff now (see screenshot below). In Configuration tab, the Implementation will have two tabs: Operations and Endpoint Bindings.

The next thing to do is to create the endpoint for the service. This involves defining style and encoding of the service and the operations and selecting the transport for the service.

Click the ‘Endpoint Bindings’ tab and then the ‘+’ to add a new endpoint. Change the Endpoint Type to SOAP and two more tabs will come up: Transport and SOAP Details.

Transport tab requires you to select a HTTP connection (as we are going for SOAP over HTTP in this example), which is required to host the service. Once the transport connection is set up you will see the Endpoint URI appear below it.

Next move to the SOAP Details tab. Define the default service style (document or RPC – in present example document) and the styles and encoding for the different operations within the service (in our case document – literal). You can set style to ‘Use Default Style’ to make your life easier in case of multiple operations.

The screenshot below shows this.

The final step is to go ahead and implement the operations we have defined in interface.

Step 3: Implementing the service operations

Firstly we create the processes for adding customer information and requesting customer information. The only thing I will say about creating the processes is that the Start and End activities must have their outputs and inputs same as the WSDL messages setup for the corresponding web-service operation.

For example the process to handle request for customer information (i.e. RequestCustomerOperation) should have output for the Start activity a WSDL message: CustomerInformationRequest (that is the input going in to the RequestCustomerOperation). Same goes for the input to the End activity which should be a WSDL message: CustomerInformation.

Go back up to the Operations tab and click on the ‘binocular’ button in the Operation Implementation column next to the operation to be implemented. All processes which have input and output WSDL messages matching the operation to be implemented will be shown in the window that pops up. Select the relevant processes. Do the same for all the operations defined in the interface.

The screenshot below shows the two operations for the example being implemented.

Test

Everything is now set for the web-service to be tested. But before we test the service it is worthwhile to see the WSDL for the service that we have just created. Go to the WSDL Source tab in the Service resource. This is the WSDL for the service. You will need this file to create a test client.

There are two ways to give a client access to the WSDL. First is to setup a WSDL retrieval process using SOAP Retrieve Resources resource with a HTTP Receiver process starter. Then the client will be able to download the WSDL as normal. The second option is to save the WSDL file (by clicking on Save WSDL in WSDL Source) and providing a local copy to the client.

We shall use SOAP UI (free edition) to test the TIBCO web-service. We setup a new SOAP UI project with a local copy of the WSDL file. SOAP UI creates test requests for the web-service as a part of the project setup.

Make sure in the TIBCO Designer the Service resource and the processes implementing the operations have been selected and run.

In SOAP-UI, go to the test request for the operation to be tested and double-click it. A blank request will open up with ‘?’ where you need to fill in data to complete the request.

After filling in the data, execute the request by pressing the green ‘play’ button. On the right-hand side you will see the response of the request (if the operation has a response). In case of an error you will see an error response.

The screenshot below shows a test of the RequestCustomerOperation. The customer information request sent is on the left-hand side and the response from the example web-service received on the right-hand side.

Hope this limited example has explained how to setup a basic web-service in TIBCO AMBW using the Service resource. There are several things that I have left out including using the SOAP Event Source process starter, using Contexts and retrieval of WSDL. All these topics deserve complete posts in themselves that is why I aim to cover them as and when I get the time!

Note: If you are going to deploy to BW engine then you will need to create an archive file (.ear). Remember to include the Service Resource (if you are using it) in the Process Archive starter processes before building the archive.

Please leave comments and suggestions.

SSL Configuration in Tibco EMS SERVER

There is a sample SSL configuration you should start with in <tibco_home>/ems/<version>/samples/config called tibemsdssl.conf.

Start it with “tibemsd -config tibemsdssl.conf”.

Take a look at the properties.

The EMS Server is using the certificate “server.cert.pem” as its identity, adn it will trust certificates that were signed by

client_root.cert.pem.

ssl_server_identity = ../certs/server.cert.pem

ssl_server_key = ../certs/server.key.pem

ssl_password = $man$WjtSRCpaXu7hoTkDlcEPr6KNKRr

# Server Issuer certificate(s).# Supports PEM, DER and PKCS#12.# This may be a part of PKCS12 specified by

ssl_server_identity

ssl_server_issuer =

# Trusted issuers of client certificates. Supports PEM, DER and PKCS7.

ssl_server_trusted = ../certs/client_root.cert.pem

So…you can use client_identity.p12 in your BW project as an Identity (there is a README in the certs directory explaining the relationships), and use server_root.cert.pem so you can trust the server.cert.pem by importing it into a Trusted Certificates folder in your BW project.

There are also SSL properties for FT heartbeats:

ft_ssl_identity =

ft_ssl_issuer =

ft_ssl_private_key =

ft_ssl_password =

ft_ssl_trusted =

ft_ssl_verify_host =

ft_ssl_verify_hostname =

ft_ssl_expected_hostname=

ft_ssl_ciphers =

Gems (Graphical Administration Tool for EMS)

Gems v3.2

Gems is a graphical user interface utility for TIBCO Enterprise Message Service (EMS). It can be used by JMS developers as a general purpose test debugging tool and by administrative support staff as a management and monitorig tool.

Gems provides the following main features:

•Server Monitoring. Server state and main statistics are automtically updated, warning and error limits may be configured. Server generated events are also captured.

•Server Management. Including, general server configuration, JMS destinations, JNDI factories, users/groups, permissions, bridges, routes etc.

•JMS support. Messages may be sent/received, queues may be browsed and message contents inspected. Selectors and filters may be specified.

•JMS Message Monitoring. Messages may be monitored (snooped) as they pass trough the server. Request and reply messages can be correlated to provide service response times.

•JMS Message Management. Eg; purging messages, copy messages from a queue to another queue on a different server.

•Charting. Server statistics may be charted in real time, data may be saved to CSV files for export to other tools such as Excel.

•Logging. Server statistics may be logged automatically when warning or error limits are breached.

•Security. SSL connectivity, view only mode.

•Customisable display and look and feel.

•Support for Managing and Monitoring TIBCO SubStation

Requires:

•Tibco EMS 4.x, EMS 5., EMS 6.x

•JRE 1.5 or higher

Tibco EMS Monitoring

If you are using Tibco EMS, you should be aware that there is a decent tool that comes with the Tibco SDK that allows you to monitor all activity that goes on in your broker. In the directory c:\tibco\ems\bin, you will find a command-line application called tibemsmonitor.exe. If you run this utility, you can see every connect/disconnect, every creation and destruction of a MessageProducer and MessageConsumer, every creation of a topic or queue.

tibemsmonitor -monitor <topic>

[-server <server-url>]

[-user <name>]

[-password <password>]

[-selector <text>]

[-short]

[-help]

[-helpssl]

tibemsmonitor -server “tcp://emshost:7222″ -monitor “>”

tibemsadmin [-server] [-user] [-password]

tibemsadmin.exe -server “tcp://emshost:7222″ -user admin -password admin123

tibemsd

[-config <filename>]

[-ft_active <active_url>]

[-ft_heartbeat <seconds>]

[-ft_activation <seconds>]

[-ssl_password <string>]

[-trace <items>]

[-ssl_trace]

[-ssl_debug_trace]

[-help]

tibemsd -config c:\tibco\cfgmgmt\ems\data\tibemsd.conf

How to handle corrupted message in EMS datastore?

Problem Description

When a message is corrupted in the EMS database, you may notice the following errors in the EMS log file:

SEVERE ERROR: Exception trying to read message from store.

ERROR: Exception trying to create message from store: IO failed.

SEVERE ERROR: Exception trying to create valid messages record, Invalid message.

SEVERE ERROR: Persisted message possibly corrupt.

SEVERE ERROR: Exception trying to create valid messages record, Invalid message.

When your client tries to consume the message, you may get a “javax.jms.JMSException: Corrupted incoming data message” exception.

When a corrupted message is sent to a client and the client application cannot process the corrupted message properly, the client will block successive messages sent to it. These messages will remain queued on the server and will not be consumed by the client.

Possible Reasons for Generating Corrupted Messages in the EMS Datastore

1. A hardware problem with the physical disk: Media error

2. Forced unmount of a physical disk when the disk is in use, or a hard disk in operation having been unplugged.

3. Locking problem, the record in the db file has been modified by different applications/threads of the application at the same time.

4. The EMS server receives a corrupt message.

5. The machine was terminated abruptly. For example: a running system in operation has been unplugged, etc.

Solution

When one or more messages are corrupted and a client cannot receive the corrupted messages, you can do the following to delete the corrupted messages:

1. If you have already enabled the “track_message_ids” then you should try to remove the corrupt message as follows. To enable track_message_ids, in EMS main configuration file, set: in tibemsd.conf

track_message_ids=enabled.

a) Use the tibemsadmin command (available in EMS_Home\bin directory) to set server console_trace = +MSG (or set log_trace if that is more appropriate).

b) Use the tibemsadmin command to set addprop queue trace.

c) When the server delivers the corrupted message to the consumer, the server should print the message ID.

d) Use the tibemsadmin command “delete message” with that message ID to remove the corrupted message.

e) Undo steps a) and b), if needed.

How to Configure EMS 5.x Server with Database Datastore?

EMS 5.x can be configured to use a database to store messages. The following steps have been tested on a Windows host to configure EMS 5.x with a database. For other platforms, the steps will be similar.

Setup Steps:

1. Install EMS 5.x

2. Download and install JDK 1.5 or later

3. Download and install Hibernate from the link provided at the EMS 5.x download on http:

download.tibco.com.

4. Download the corresponding database JDBC drivers. They can be found on the Internet. The corresponding jar files for the JDBC need to be added to dbstore_classpath in EMS main configuration file.

For example:

1). MySQL InnoDB

MySQL Connector:

mysql-connector-java-5.0.6-bin.jar

2). Microsoft SQL Server

Microsoft JDBC Driver for SQL Server:

sqljdbc.jar

3). Oracle 9i and 10g

Oracle JDBC Thin Driver:

ojdbc14.jar or ojdbc5.jar

4). IBM DB2 Server 8.1 and 9.1

DB2 Universal JDBC Driver:

db2jcc.jar and db2jcc_license_cu.jar

5. Modify the sample EMS main configuration file used for database: c:\tibco\ems\5.0\samples\config\tibemsd-db.conf:

Modify the variables: dbstore_classpath, dbstore_driver_name, dbstore_driver_dialect, jar_library to reflect your own settings and database.

Here is an example which uses the Oracle 10g database:

==============================================

dbstore_classpath = c:\tibco\components\eclipse\plugins\com.tibco.tpcl.org.hibernate_3.2.5.001\hibe rnate3.jar;c:\tibco\components\eclipse\plugins\com.tibco.tpcl.org.com.mchange.c3 p0_0.9.1.001\c3p0-0.9.1.jar;c:\tibco\EMS\5.0\bin\antlr-2.7.6.jar;c:\tibco\EMS\5. 0\bin\asm-attrs.jar;c:\tibco\EMS\5.0\bin\asm.jar;c:\tibco\EMS\5.0\bin\cglib-2.1. 3.jar;c:\tibco\EMS\5.0\bin\commons-collections-2.1.1.jar;c:\tibco\EMS\5.0\bin\co mmons-logging-1.0.4.jar;c:\tibco\EMS\5.0\bin\dom4j-1.6.1.jar;c:\tibco\EMS\5.0\bi n\ehcache-1.2.3.jar;c:\tibco\EMS\5.0\bin\jta.jar;C:\tibco\EMS\5.0\databaselib\oj dbc14.jar;C:\tibco\EMS\5.0\bin\ojdbc14.jar

dbstore_driver_name = oracle.jdbc.driver.OracleDriver

dbstore_driver_dialect = org.hibernate.dialect.Oracle10gDialect

jre_library = C:\jdk1.5.0_06\jre\bin\server\jvm.dll

==============================================

6. Create database users for EMS usage in the database. The users should have permissions to create, alter, delete, update for table, index and sequence.

7. Modify c:\tibco\ems\5.0\samples\config\stores-db.conf to put your own database store information:

Example, in stores-db.conf, defines oracle database information:

$sys.failsafe

type=dbstore

dbstore_driver_url=jdbc:oracle:thin:adminfs/[email protected]//osrv_1:1521/orclperf

dbstore_driver_username=adminfs

dbstore_driver_password=admin123

8. Modify the file queues.conf or topics.conf to define where the messages will be stored:

Example, in the file queues.conf:

TIBCO.quotes maxbytes=10MB,trace,store=$sys.failsafe

9. Use the schema export tool to export the EMS schema into database:

Example:

java -jar c:\tibco\ems\5.0\bin\tibemsd_util.jar -tibemsdconf c:\tibco\ems\5.0\samples\config\tibemsd-db.conf -createall -export

See the TIBCO Enterprise Message Service User’s Guide, Chapter 5, entitled “Running the EMS Server” for details about the schema export tool.

10. Start the EMS server using c:\tibco\ems\5.0\samples\config\tibemsd-db.conf

How to Secure the Database Password in EMS 5.x Configuration file?

When defining the database stores in EMS 5.x, you will need to define the following parameters in stores.conf:

dbstore_driver_url = JDBCURL

dbstore_driver_username = username

dbstore_driver_password = password

The database password can be entered as clear text for two parameters: dbstore_driver_password and dbstore_driver_url.

1. dbstore_driver_password

You can also use a mangled password for the dbstore_driver_password. That is, you can use the tibemsadmin tool to mangle a database password and define the mangled password for dbstore_driver_password.

For example, you can run the tibemsadmin command to mangle a clear text password:

===================================================

tibemsadmin.exe -mangle

TIBCO Enterprise Message Service Administration Tool.

Copyright 2003-2008 by TIBCO Software Inc.

All rights reserved.

Version 5.0.0 V27 4/29/2008

Enter phrase to mangle:

Confirm phrase to mangle:

$man$-RV84410jfkIKs3GET2dmcc5MPs

===================================================

In stores.conf, you can define the mangled password for dbstore_driver_password:

dbstore_driver_password=$man$-RV84410jfkIKs3GET2dmcc5MPs

2. dbstore_driver_url

When defining dbstore_driver_url for an Oracle database, the URL format is entered as following:

jdbc:oracle:thin:/@:/{remote database name} If you don’t want to enter the clear text database password within the URL, you can define the Oracle service name (aliase name) for the database using the following syntax: dbstore_driver_url=jdbc:oracle:thin:@:/{dbservice name}

This way you don’t need to define dbusername and dbpassword in the dbstore_driver_url parameter.

Hawk rule for monitoring queue

You can use the ems admin API to get the queue stats and check against the flowcontrol value to find out if it exceeds 80%. Call the API using a script from hawk & send mail when it exceeds.

Please find the below code.

/*

* Copyright 2007-2010 SRIK Solutions Pvt Ltd Inc.

* All rights reserved.

* For more information, please contact us :

*

*

*/

import java.util.*;

import javax.jms.Topic;

import javax.jms.Queue;

import javax.jms.Destination;

import com.tibco.tibjms.admin.*;

//

// The tibjmsServerAdministrator class is used by the tibjmsPerfMaster class

// to change various settings in the EMS server.

//

public class tibjmsServerAdministrator

{

TibjmsAdmin[] _admin = null;

String queue = null;

String topic = null;

/**

* Creates an admin client on the specified server

* and then walks any routes to other servers creating

* admin clients on the discovered servers as well.

*

* @param serverUrl server URL on which to connect

* @param userName the administrator name

* @param password the administrator password

*/

public tibjmsServerAdministrator(

String serverUrl,

String userName,

String password)

{

Map map = new HashMap();

addAdmin(serverUrl, userName, password, map);

_admin = new TibjmsAdmin[map.size()];

map.values().toArray(_admin);

}

private void addAdmin(String serverUrl, String userName, String password, Map map)

{

try

{

System.err.println(“connecting as “+userName+” to “+serverUrl);

TibjmsAdmin admin = new TibjmsAdmin(serverUrl,userName,password);

ServerInfo si = admin.getInfo();

// enable statistics

si.setStatisticsEnabled(true);

admin.updateServer(si);

if (!map.containsKey(si.getServerName()))

{

map.put(si.getServerName(), admin);

RouteInfo[] ri = admin.getRoutes();

for (int i = 0; i < ri.length; i++)

{

if (!map.containsKey(ri[i].getName()) && ri[i].isConnected())

addAdmin(ri[i].getURL(), userName, password, map);

}

}

else

{

admin.close();

}

}

catch (Exception e)

{

e.printStackTrace();

System.exit(-1);

}

}

/**

* Create a topic on all servers.

*

* @param name topic name

* @param failsafe failsafe setting

* @param flowControl flow control setting

*/

public void createTopic(String name, boolean failsafe, long flowControl)

{

try

{

TopicInfo ti = new TopicInfo(name);

ti.setGlobal(_admin.length > 1);

ti.setFailsafe(failsafe);

ti.setFlowControlMaxBytes(flowControl);

System.err.println(“creating topic “+name);

for (int i = 0; i < _admin.length; i++)

{

_admin[i].destroyTopic(name);

_admin[i].createTopic(ti);

}

topic = name;

}

catch (Exception e)

{

e.printStackTrace();

System.exit(-1);

}

}

/**

* Create a queue on all servers.

*

* @param name queue name

* @param server name of queue’s home server

* @param failsafe failsafe setting

* @param flowControl flow control setting

* @param prefetch prefetch setting

*/

public void createQueue(String name, String server, boolean failsafe, long flowControl, int prefetch)

{

String fullName = name;

if (server != null)

fullName = name + ‘@’ + server;

try

{

QueueInfo qi = new QueueInfo(fullName);

qi.setGlobal(_admin.length > 1);

qi.setFailsafe(failsafe);

qi.setFlowControlMaxBytes(flowControl);

qi.setPrefetch(prefetch);

System.err.println(“creating queue “+fullName);

for (int i = 0; i < _admin.length; i++)

{

_admin[i].destroyQueue(name);

_admin[i].createQueue(qi);

}

queue = name;

}

catch (Exception e)

{

e.printStackTrace();

System.exit(-1);

}

}

/**

* Return the number of receivers from all servers

* for a particular destination.

*

* @param dest the destination

* @return the number of receivers for the destination

*/

public int getNumberOfReceivers(Destination dest)

{

int numReceivers = 0;

try {

for (int i = 0; i < _admin.length; i++)

{

DestinationInfo info;

if (dest instanceof Topic)

info = _admin[i].getTopic(((Topic)dest).getTopicName());

else

info = _admin[i].getQueue(((Queue)dest).getQueueName());

ConsumerInfo[] ci = _admin[i].getConsumersStatistics(null, null, info);

if (ci != null)

numReceivers += ci.length;

}

}

catch (Exception e) {

e.printStackTrace();

System.exit(-1);

}

return numReceivers;

}

/**

* Check if flow control is enabled for all servers.

*

* @return true iff flow control is enabled on all servers

*/

public boolean isFlowControlEnabled()

{

boolean flowControlEnabled = true;

try

{

for (int i = 0; i < _admin.length; i++)

{

ServerInfo si = _admin[i].getInfo();

if (!si.isFlowControlEnabled())

flowControlEnabled = false;

}

}

catch (Exception e)

{

e.printStackTrace();

System.exit(-1);

}

return flowControlEnabled;

}

/**

* Remove the destination from all servers.

*/

public void cleanup(String controlTopic)

{

try

{

for (int i = 0; i < _admin.length; i++)

{

if (topic != null)

{

TopicInfo[] info = _admin[i].getTopics(topic);

for (int j = 0; j < info.length; j++)

{

if (!controlTopic.equals(info[j].getName()))

_admin[i].destroyTopic(info[j].getName());

}

}

if (queue != null)

{

QueueInfo[] info = _admin[i].getQueues(queue);

for (int j = 0; j < info.length; j++)

{

_admin[i].destroyQueue(info[j].getName());

}

}

}

}

catch (Exception e)

{

e.printStackTrace();

System.exit(-1);

}

}

}

To add EMS server to TIBCO administrator, follow these steps:

Note: To add the ems server, both Administrator and EMS should be up and running.

1. Make sure the TRA installalled on the machine where EMS server is running.

2. Run Domain Utility from TIBCO_HOME/TRA/<version that matches to ur domain>/BIN/DomainUtility.exe (Windows) or .bin (Unix)

3. In windows you can double click the domain utility, but in unix use ./<PATH to TRA BIN>/DomainUtility

Note: To enable GUI mode in Unix, your desktop must have xwindows terminal like reflection,cygwin or xwindows etc. Puty does not support xwindows properly.

4. Choose EMS administration from the menu list.

5. Click Add EMS server to TIBCO domain and next.

6. Enter all the details that is required for EMS (Version, path of tibemsd executable (.exe in windows, .bin in unix)

7. Enter the port number, user name and password

8. Test the connection

9. Finish the rest

10. Stop the EMS and start from TIBCO administrator.

Leave a Comment

October 16, 2010

Installing the TIBCO EMS Central Administration Server

Filed under: Tibco EMS — SRIK @ 3:42 pm

I’d like to share my experience about installation of the TIBCO Enterprise Message Service Central Administration (EMSCA) server and client. At this time, TIBCO provides EMSCA server software only for Linux (Red Hat Enterprise Linux 4 and 5 (x86), Oracle Enterprise Linux 4 and 5 (x86) and SUSE Enterprise 10 (x86)) and EMSCA client only for Windows, but as client is Eclipse based, I think that it could be ported easily.

I will start with the server side installation on my Red Hat Linux. The new TIBCO Universal Installer can run in GUI (default), console or silent mode. If you prefer GUI, don’t forget to set DISPLAY:

LOGINFROM=`who am i | cut -f2 -d"(" | cut -f1 -d")"`

DISPLAY=${LOGINFROM}:0.0

export LOGINFROM DISPLAY

Run the installer # ./TIBCOUniversalInstaller-lnx-x86.bin, accept the license agreement, create a new or select an existing environment. Installation will perform quickly. When installation is complete, it is necessary to do some post installation tasks:

•    Environment variables from the file <emsca_home>/1.0/bin/setenv must be set. Perhaps it is good idea to call this file from the user’s profile or add content of this file to the profile;

•    Make Apache run as the user ‘nobody’:

# cd <emsca_home>/1.0/httpd/conf

# vi httpd.conf

User nobody

Group nobody

and make sure that user and group ‘nobody’ are in the system;

•    Configure an authentication in Apache:

# vi httpd.conf

AuthBasicProvider file

AuthUserFile conf/users.txt

Then prepare users file, I will define the ‘admin’ user only:

# cd ../bin

# ./htpasswd -c ../conf/users.txt admin

New password:

Re-type new password:

Adding password for user admin

Then check the file:

# cd ../conf/

# cat users.txt

admin:GfwLuEIw320SY

•    Adding Subversion users and change folders owners:

# cd /opt/tibco/ems/ca/1.0/repos/conf

# cat pre-commit.perms

admin

So, ‘admin’ is already here. Next check/set owner for the repos and temp Subversion’s folders:

# pwd

/opt/tibco/ems/ca/1.0

# chown -R nobody:nobody repos temp

Owner should be the same user as running apache (‘nobody’ in my case).

Then I can start emsca:

# emsca start

Starting TIBCO EMS Central Administration

Started Apache httpd: pid=20119

Started Tomcat: pid=20140

and check Apache logs in the <emsca_home>/1.0/httpd/logs folder.

Next step is to create a new deployment server. Deployment server is one per project, can be one for many EMS.

# emsca server create rhl01

Created directory 'rhl01' in the repository

Created directory /opt/tibco/ems/ca/1.0/servers/rhl01

Created configuration file '/opt/tibco/ems/ca/1.0/servers/rhl01/conf/configuration.xml'

Created deployment server 'rhl01'

Now creating a new central administration agent. One agent per one EMS.

# emsca agent create rhl01 name=agent_EMS-SERVER1 path=/ems-server1.emsserver url=tcp://10.2.148.82:7222

Created agent on deployment server 'rhl01'

It is possible to provide a username and a password to connect to the EMS. If is not included, the agent uses ‘admin’ ad username and an empty password. ems-server-username – the username used to connect to the tibemsd, ems-server-password – used with ems-server-username to connect to the tibemsd. Also it has options to grant agent some additional rights, find in the docs.

To check EMSCA server use:

# emsca list

TIBCO EMS Central Administration

Deployment Servers

------------------

rhl01 (started)

# emsca status

TIBCO EMS Central Administration Status

Apache httpd is running: pid=1427

Tomcat is running: pid=1448

Installing the TIBCO EMS Central Administration Client

There is the same Universal Installer by TIBCO, it helps to make installation process easy. Execute it, accept the license agreement, create a new or select an existing environment, check the summary and complete the installation.

Then I can star EMSCA from my Start menu. This is Eclipse, I have to create a new workspace. Then File => New EMS Central Administration Project. Enter host name and port, where is EMSCA Server is installed. Enter username and password to connect, select the deployment to create a project for.

Next step is synchronizing with EMS. TIBCO EMS => Synchronize Configurations With EMS Servers. Enter username and password, select EMS server to synchronize.

Now I can change the server configuration. Then save to SVN repository. TIBCO EMS => Save Configurations to Repository.

Then it is possible to deploy changes to the server. TIBCO EMS => Deploy EMS Project.

So, this was short description of the TIBCO EMS Central Administration, very helpful tool to manage configurations of multiple EMS instances.

These are some of the sample interview questions on EMS..

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

2.   What are the different types of messages that can be used in EMS

•   Text

•   Simple

•   Bytes

•   Map

•   XML test

•   Object

•   Object ref

•   Stream

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

4.   What is the purpose for stores.conf

a.   This file defines the locations either store files or a database, where the EMS server will store messages or metadata.

b.   Each store configured is either a file-based or a database store.

5.   How many modes are the messages written to store file.

         2 modes.. sync or async. When absent , the default is async

6.   What is tibemsd.conf

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

7.   How many delivery modes for messages?

   Persistent, Non-persistent, Reliable-delivery.

8.   What is the maximum messagesize?

   Ems supports max message size of 512 mb

9.   Name 3 destination properties and explain them.

   Global, secure, maxmsgs, maxbytes, flowcontrol, sender_name, sender_name_enforced, trace,maxRedelivery

10.    What are the different modes of installation in Ems?

a.   GUI mode

b.   Console mode

c.   Silent mode

11.   What are the messaging models supported by JMS

a.   Point-to-point

b.   Publish-subscribe

c.   Multicast

12.   Tell me about routes

   What is the purpose of routes, what kind of destinations can be used in routes? Topics and queues m-hops

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

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

a.   Static-created by user

b.   Dynamic-created by ems server on the fly.

c.   Temporary destinations.

15.   What are the wild cards that we use in ems?how do they work for queues and topics

     *,>

   U can subscribe to wildcard topics but cant publish to them. Where as in case of queues we can’t either send /receive.

16.   Are bridges transitive?

             NO

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

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

19.   Name 3 configuration files and tell me what it consists of

a.   Queues.conf

b.   Topics.conf

c.   Routes.conf

d.   Factories.conf

e.   Stores.conf

f.   Groups.conf,users.conf,transports.conf

20.   Name some administrative level destination properties

a.   View

b.   Create

c.   Delete

d.   Modify

e.   Purge

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

22.   What are the permissions that you can grant to users to access queues

a.   Receive

b.   Send

c.   Browse

23.   What are the permissions that you can grant to users to access topics

a.   Subscribe

b.   Publish

c.   Durable

d.   Use_durable

24.   Tell me about multicasting in EMS

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

b.   Each multicast enabled topic is associated with a channel.

25.   What are the advantages  and disadvantages of multicasting..

a.   Advantages: as the message broadcasts only once thereby reducing the amount of bandwidth used in publish and subscribe model. Reduces the network traffic.

b.   Disadvantages: Offers only last-hop delivery. So can’t be used to send messages between servers.

26.   On what destinations can you use multicast?

a.   Topics

27.   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?

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

28.   How does the secondary server know that the primary server is failed?

a.   Based on heartbeat intervals

29.   What is JMS queue requestor?

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

30.   What is JMS topic requestor?

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

31.   How do you add ems server to administrator?

a.   Using domain utility

32.   How do you remove individual messages from destinations?

a.   Using purge command.