Posts tagged ·

tibco

·...

TIBCO iProcess engine installation on Solaris

no comments

This is my quick reference for single-server TIBCO BPM iProcess engine installation on Solaris. Possible to add another server and convert environment to a cluster later. Oracle has to be installed, ORACLE_HOME and ORACLE_SID environment variables must be set. Run swinstall installation script as a root user who also DBA in Oracle, script will create iProcess database.

./swinstall

Script will collect installation data:
Installing TIBCO iProcess Engine version 11.0.2

Location, Identification and OS Accounts Menu

* ) Installation Directory : /export/home/tibco/tibco/iprocess
2 ) iProcess Engine Nodename : s-bpm01
3 ) iProcess Engine Licensee Name : TIBCO iPE 11.0.2 Install
4 ) iProcess Engine Background User Name : pro
5 ) iProcess Engine Administration User Name : swadmin
6 ) iProcess Engine User Group Name : staffwar

ORACLE Database Connection and Account Details

1 ) Oracle DB TNS Identifier : orcl
2 ) Oracle DB Administrator Name : system
3 ) Oracle DB Administrator Password : ********
4 ) iProcess Engine DB Schema Owner Name : swpro
5 ) iProcess Engine DB Schema Owner Password : staffpro1
6 ) iProcess Engine DB User Name : swuser
7 ) iProcess Engine DB User Password : swuser1
8 ) Data Tablespace Name : STAFFWAR
9 ) Temporary Tablespace Name : TEMP
10) Schema Sizing Configuration : Small

Display configuration summary and start installation:
==============================================
Configuration Summary
==============================================

General
===============================================
Install type: install (MASTER)
Version: 11.0.2
Target location: /export/home/tibco/tibco/iprocess
Licensee: TIBCO iPE 11.0.2 Install

iProcess Objects Server Version: 11.0.2
iProcess Objects Director Version: 11.0.2

Node Details
===============================================
Node name: s-bpm01
Client-Server RPC port: 391875

Environment Settings
===============================================
iProcess Engine User group: staffwar
iProcess Engine bkg. account: pro
iProcess Engine admin. account: swadmin

Optional Settings
===============================================
Autostart Server: Y
Passwords required for login: Y
Enable Prediction (Global): N
Enable Case Data Normalization: Y
Enable Activity Publishing: N
Configure iProcess E-Mail Plug-in: Y
Enable iProcess Objects Server: Y
Enable iProcess Objects Director: N
Install TIBCO Hawk 4.8.1: N
Enable Webdav write access: N

DataBase Settings
===============================================
Database Type: ORACLE
TNS Identifier: orcl
DBA Name: system
DB Schema Owner: swpro
DB User: swuser
Data Tablespace: STAFFWAR
Temp Tablespace: TEMP

The final step:
Your TIBCO iProcess Engine installation has now been configured as follows:

--------------------------------------------------------------------------------
Machine ID Machine Name Master Check Error Files Machine Comment
--------------------------------------------------------------------------------
1 S-BPM01 Y Y s-bpm01

Checking and setting file permissions ...

TIBCO iProcess Engine Installation Complete

Display engine password:
TIBCO iProcess Engine Password is:
********************************************
* 3BFD-7292-DBAF-A3E7-823D-4720-351E *
********************************************
Licensee Name is:
TIBCO iPE 11.0.2 Install
(The existing TIBCO iProcess Engine Password and Licensee Name may also be
displayed later by running 'swconfig').

Reminder:
All users of TIBCO iProcess Engine (Staffware) should have the
environment variable $SWDIR set to
/export/home/tibco/tibco/iprocess
before invoking or starting TIBCO iProcess Engine.

Installer will run the final check and complete:
TIBCO iProcess Engine Nodename ( s-bpm01 ) checked OK.
TIBCO iProcess Engine RPC Number ( 391875 ) checked OK.
TIBCO iProcess Engine service ports checked OK
TIBCO iProcess Engine process entries OK

Then I have to create this .profile for pro user:
SWDIR=/export/home/tibco/tibco/iprocess
export SWDIR
ORACLE_HOME=/export/home/oracle/product/10.2.0/db_1
ORACLE_SID=orcl
export ORACLE_HOME ORACLE_SID
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib:$SWDIR/libs
export LD_LIBRARY_PATH

To start iProcess engine:
su - pro
cd bin
./swstart -p
./swstart

Admin tool:
su - pro
cd util
./swadm


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

How to reset TIBCO EMS Administrator password

no comments

If the EMS admin password has been lost, it is easy to recover. In EMS all local users and their passwords stored in the users.conf file by default. You can find correct file in the tibemsd.conf:
users = "C:/tibco/tibco/cfgmgmt/ems/data/users.conf"

In the users.conf find admin user:
admin:$2$Z1t2XOwg$vsDsUT+GVRHRiX+OPU/oOsn0:"Administrator"
and remove encrypted password between colons:
admin::"Administrator"

Then restart EMS daemon. Connect to your EMS using EMS Administration Tool and login as admin without password:
> connect
Login name (admin):
Password:
Connected to: tcp://localhost:7222

Then set a new password for admin:
tcp://localhost:7222> set password admin 123
Password of user 'admin' has been modified

If you manage EMS in the TIBCO Administrator, then you need to change EMS admin password there. Start TIBCO DomainUtility, select “TIBCO EMS Plugin”, “Update TIBCO EMS Server”, press “Next”. Select domain and enter domain (not EMS!) admin user name and password. Select EMS server to update, and change EMS password there, test connection on the next screen and press “Next” to save new configuration.

So, EMS password recovery is very simple, isn’t it?


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

Problem with libeay32.dll and ssleay32.dll

6 comments

You may experience this problem, when can’t run TIBCO Administrator, Hawk, BW process or any other TIBCO component. In log files you can find messages related to OpenSSL libraries libeay32.dll and ssleay32.dll. The reason is that TIBCO messaging components use OpenSSL, but other applications may also use OpenSSL and have already installed these dlls in C:\WINDOWS\System32 or C:\WINDOWS\SysWOW64 depending on the platform.

When you start the application, it unsuccessful attempts to find dll files near the binary, then tries to find in the System32 folder. But dlls from other version of OpenSSL are there. Your application will use it, instead correct version from TIBCO Rendezvous bin folder for example, even you have this folder in the PATH. TIBCO product can’t call the necessary functions, gives an error and stops working.

Solution is take libeay32.dll and ssleay32.dll from TIBCO Rendezvous bin folder to the bin folders of every installed TIBCO component. Or just copy and replace to C:\WINDOWS\System32 or C:\WINDOWS\SysWOW64.


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

TIBCO Rendezvous and MS NLB Cluster

no comments

TIBCO Rendezvous is multicast-based messaging. Network Load Balancing (NLB) is a way to configure a pool of machines so they take turns responding to requests. It’s commonly implemented in server farms: identically configured machines that spread out the load for a web site or work as terminal services cluster.

Task was to cross both of these things – Rendezvous based application on servers in MS NLB terminal services cluster. I’ve done some tests using different settings, but the result was an inappropriate. I received RV messages only on one server or one message on the first server, next message on second, and so on, it depend on “Filtering mode”. NLB for multicast packets works even better than I would like! But users of an application work on every server and need all messages delivered to all users on all servers.

What happens with every frame that the Network Load Balancing driver (wlbs.sys) receives is:

  1. on every node wlbs.sys checks if the received packet is send to a virtual IP
  2. on every node wlbs.sys checks the source IP and port
  3. one node decides to accept the packet and passes it up to the TCP/IP driver
  4. all other nodes drop the packet

The issue is that there is no special treatment for multicast IPs. NLB driver treats them like every other IP that is not the dedicated IP of that machine.

What are the possible solutions?

  • Receive the IP multicast traffic over a NIC where no NLB is bound to. Additional NIC in every server.
  • Use TCP connection to remote Rendezvous daemon (rvd). Daemon parameter in RV transport: -daemon "tcp:remotemachine:7500"
  • Use local Rendezvous routing daemon (rvrd) instead of rvd. It requires rvrd on every terminal server and additional rvrd somewhere in the network.

If you would like read more, here is the list of clustering and high availability cluster resources from MS.


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

Security advisories for TIBCO products

no comments

Yesterday TIBCO announced vulnerability in TIBCO Runtime Agent (TRA). To be more specific, in TIBCO Domain Utility (domainutility and domainutilitycmd). To say even more specifically, vulnerability is that the local users (whether they are on your server?) have read access to the properties files where administration domain credentials are stored. Not in clear text, by the way. Here is the advisory.

Here is the list of all security advisories for TIBCO products.

I like TIBCO.


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

TIBCO Hawk NoClassDefFoundError issue

no comments

On the Windows platform you can experience java.lang.NoClassDefFound Error when starting Hawk Agent or Hawk Display. In my example I use TIBCO EMS as a transport for Hawk messaging and issue arose after upgrade EMS from version 4 to version 5 on the server. The reason is that in EMS version 5.1 paths to java class libraries are: <Tibco_Root>\ems\5.1\lib\jms.jar; <Tibco_Root>\ems\5.1\lib\tibjms.jar; <Tibco_Root>\ems\5.1\lib\tibrvjms.jar; <Tibco_Root>\ems\5.1\lib\tibcrypt.jar;
In EMS 4.x. paths were: <Tibco_Root>\ems\clients\java\jms.jar; <Tibco_Root>\ems\clients\java\tibjms.jar; <Tibco_Root>\ems\clients\java\tibrvjms.jar; <Tibco_Root>\ems\clients\java\tibcrypt.jar; <Tibco_Root>\ems\clients\java\jaxp.jar; and they remained in the Hawk configuration.

On windows this configuration is stored in the registry. Just open regedit and modify three classpath strings under HKLM\SOFTWARE\Tibco Software\TIB/Hawk\<version>.

For TIBCO Rendezvous transport situation can be the same, if path to used jar <Tibco_Root>\tibrv\lib\tibrvj.jar; was changed.

About classpath and Hawk. In general, NoClassDefFoundError is a Java (JVM) error that occurs when a class needed to run a Java program cannot be found. Here are Hawk is Java program and classes (a set of dynamically loadable libraries that Java applications can call at runtime) in the jar files mentioned above. Classpath is an argument that tells the JVM where to look for user-defined classes and packages in Java programs.

On Unix in the startagent startup script for TIBCO Hawk Agent for example, you can find something like this:
# If EMS_ROOT is set, add EMS jars files.
if [ ! -z "$EMS_ROOT" ]; then
JARFILE="$JARFILE:$EMS_ROOT/clients/java/jms.jar"
JARFILE="$JARFILE:$EMS_ROOT/clients/java/tibjms.jar"
JARFILE="$JARFILE:$EMS_ROOT/clients/java/tibrvjms.jar"
JARFILE="$JARFILE:$EMS_ROOT/clients/java/tibcrypt.jar"
fi
# Add jar files for RV.
JARFILE="$JARFILE:$RV_ROOT/lib/tibrvj.jar"
# Add existing CLASSPATH environment variable to class path.
JARFILE="$JARFILE:$CLASSPATH"

Here are the same classes and classpath variable. So, please keep in mind this.


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email

What is TIBCO EMS?

1 comment

Remark: this is a brief overview from the admin perspective. If you ask a developer or architect, then their views may differ greatly from what you find below :)

TIBCO Enterprise Message Service (EMS) is fully compliant Java Message Service (JMS) implementation from TIBCO with some enterprise-class enhancements. What is it? In general, from JMS FAQ:

The Java Message Service makes it easy to write business applications that asynchronously send and receive critical business data and events.

The Java Message Service defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products.

The Java Message Service supports both message queuing and publish-subscribe styles of messaging (topics).

It is main part of Enterprise Backbone, Enterprise Middleware and Enterprise SOA. Unlike TIBCO Rendezvous, where publishers and subscribers communicate directly without server, EMS represent dedicated server, hub which connects all clients and passes through itself all messages.

Better to see once than hear a hundred times. Installation process for EMS server is very simple, I slightly described installation on Windows platform in this post. On Solaris or other *nix we can run installer with [-console] option if X11 isn’t configured:
bash-3.2# ./TIBCOUniversalInstaller-sol-sparc.bin -console

New TIBCO Universal Installer will store configuration files and message storages separately from binaries and allows to have multiple environments on the same host, you must specify both paths. EMS is not required any additional components like TIBCO Runtime Agent (TRA), everything is included in the archive.

To start EMS manually with output to console, just execute tibemsd or tibemsd64 (depend on platform) with option [-config] and path to tibemsd.conf file. Later in production it will run as a system service on Windows (install or remove service using emsntsrg utility) or as a daemon in Unix. Start process from console is also good for debugging purposes, if an error somewhere in the configuration files and service isn’t running.

All EMS configuration stored in the configuration files and these files are read when the EMS process going up. Main file is tibemsd.conf: it’s contain service name, listening TCP port, links to other configuration files, logging options and etc. If start EMS without specifying tibemsd.conf file, it will try to find it near binary, if unsuccessful then conf files will be created near binary with default values.

The most of EMS configuration, like new user, new queue or bridge, performed using administration tools on the live system and become active immediately, no restart required. Then changes saved in the corresponding conf files to be restored when you restart the service. But it is also possible to modify conf files manually. Moreover, some parameters, like message storages location or log file name must be predefined in conf files and EMS restart is necessary. Before each change make sure to have fresh backup of the configuration files!

For EMS administration tasks some tools are available: tibemsadmin – command line administration tool provided with EMS, EMS plugin for TIBCO Administrator, Gems (Graphical Administration Tool for EMS) by Richard Lawrence, HermesJMS. Using these tools admin can manage topics, queues, bridges, users and so on. For monitoring EMS offers many options for logging and trace. Also, admin can subscribe to system topics beginning with “$sys.monitor.” for live evens monitoring (easiest using tibemsmonitor utility).

Files used to store messages will be created on the first start using parameters in the stores.conf file (before version 5 in tibemsd.conf). In the normal operational mode, messages may accumulate in the topics and queues if no recipients – files will grow when needed, and therefore it is necessary to continuously monitor, otherwise the service may become unusable. It is possible to predefine minimal size of those files, it will take some time to build files for the first time if predefined size is large, but help to avoid fragmentation. Shrink or truncate large files to predefined minimum is also possible. When EMS restarts, all persistent messages will be recovered, but it will take some time to recover if files are large. In general, when you upgrade EMS from 4.x to 5.x, all stores will be upgraded automatically. Downgrade or rollback is also possible using tibemsdb5revert.

To provide high availability, two EMS servers can run as active-standby fault-tolerant pair. The main requirement of this configuration is the simultaneous access to store files – Cluster File System is required. Veritas Storage Foundation Cluster File System as expensive enterprise solution example. Some variants with network shares or NFS are also possible but guaranteed uptime and messages rate can be much lower. Alternative approach – failover cluster with shared volume.

Starting with EMS version 5 it became possible to use a database to store the messages. This simplifies the creation of fault-tolerant pair – no need to create a shared file system, enough to configure two servers to the same database. So far I haven’t collected a sufficient pro and cons, if you have such please share in the comments.

And lastly few words about connecting clients. Usually, when your application must be integrated into TIBCO middleware, means that you need communicate to EMS only. The most of SOA oriented applications are ready to communicate with JMS, Java clients can use JMS classes. TIBCO ActiveMatrix BusinessWorks has JMS palletes. Applications must be able to work with the fault-tolerant pair of two servers, provide reconnection in case of connection failure, support authentication.

Useful links:


share and enjoy:
  • Twitter
  • Google Buzz
  • Facebook
  • LinkedIn
  • Digg
  • del.icio.us
  • Technorati
  • StumbleUpon
  • email