TIBCO ActiveMatrix™ Policy Manager enables organizations to centrally define policies across services hosted on heterogeneous SOA environments, for authentication and authorization, encryption, logging, auditing, and service versioning.

ActiveMatrix Policy Manager separates a service’s business logic from these policies and replaces policy hard-coding with more flexible rules. This separation allows organizations to apply policies uniformly across all services regardless of location or underlying technology such as Java or .NET.

It also means companies can implement security, regulatory requirements, and service level agreements much faster than before because changes are no longer required to the existing applications. This results in much greater flexibility, lower costs, and the ability to deliver applications that are driven by the rules of the busines


For training on TIBCO mail us at [email protected]

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 =




For training on TIBCO EMS mail us at [email protected]

Looking in more detail at the iProcess Server’s architecture we can see that its engines are organized into nodes, where a node is formed by 1 or N iProcess Engine servers sharing a database instance. If there is more than one engine for load balancing or fault tolerance, it’s called a node cluster. Engines use Remote Procedure Calls (RPC) to communicate with the clients and can be split into four parts:

• Process Sentinels: which are responsible for making sure that the rest of the processes are running.
• Foreground Processes: processes dealing with user interaction.
• Background Processes: processes performing the “internal” tasks.
• MBox Set: communication link between background and foreground processes

The Server comes with a client interface called Objects Server which provides an API to interact with the engine. It is available in two “flavors”:

• Process Objects (TPO): a thick client implementation API for COM/C++/Java.
• Server Objects (TSO): a thin client implementation API for EJB and .NET.

Using this APIs we can develop custom web-clients, web-services or integrate our J2EE or .NET applications with iProcess.
Business Processes executed by the iProcess Server can interact with external systems as well using EAI plugins. There are plug-ins for different systems, including BusinessWorks, Oracle, Java, SQL Server and scripts.

Normally, Proxy agent is running on the Node server where the a particular application node is running except AMX ENV DEV2 (in this environment, the policy manager and proxy are running on XXXXXtibd008(unix Box name)).

Also in some of the environment, there are multiple Proxies are running, for example XXXXXtibq027 where we have 4 proxies running on different ports. Whatever the case may be either we have single proxy or multiple proxies on particular machine, we should follow the following steps to bounce only one Proxy related to a specific port.

1. First determine the port number where proxy is running. You can get from it the proxy end point url of any service of 
    a particular application. For example, in QA2 @plan is managed by proxy with port#28981.

2. Then logon to the machine where Proxy is running as per the hint given in the beginning of this note.

3. Execute: netstat -nlp |grep <proxy port#>

The output will be something like below example;

[tibco@XXXXtibq027 ~]$ netstat -nlp |grep 28981
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 :::28981 :::* LISTEN 22951/startProxyAge

4. The 3rd column is the port number for which we did a grep. and the last column contains the PID/Process Name. Now we have PID for the Proxy agent for the port we are looking for.

5. Then go to /opt/tibco/policyagent/instances/agent-<port#>/bin and execute ./stopProxyAgent. This will stop the proxy agent for the port mentioned in <port#>.

6. Now verify the Proxy is stopped or not by executing the “ps -ef|grep PID”. The PID is the value we got from the step #3. If the proxy is still running then the kill it by “kill -9 PID”.

7. Now start Proxy by executing : ./startProxyAgent &

If you want start by nohup then execute: nohup ./startProxyAgent >& nohup.out 


For training on TIBCO mail us at [email protected]