Copyright © Cloud Software Group, Inc. All rights reserved.
Copyright © Cloud Software Group, Inc. All rights reserved.


Chapter 1 Introduction : Running Multiple Instances of the TIBCO iProcess Objects Server

Running Multiple Instances of the TIBCO iProcess Objects Server
You can run multiple instances of the TIBCO iProcess Objects Server. This is done in the following ways:
If you’ve saturated the resources of a single machine, you can add TIBCO iProcess Objects Servers to other machines in the cluster, allowing you to spread the load across multiple machines. All nodes in the cluster share the same database.
To run the TIBCO iProcess Objects Server on multiple machines, it must be installed on each of the machines in the cluster on which it will be running. As an example, if the TIBCO iProcess Objects Server is installed on two machines in the cluster, the process_config table will appear as follows:
 
This shows that there is a single instance of the TIBCO iProcess Objects Server installed on each of two machines.
Multiple instances of the TIBCO iProcess Objects Server can be run on a single machine, resulting in all TIBCO iProcess Objects Servers running from the same $SWDIR directory and using the same database. This allows you to run multiple TIBCO iProcess Objects Servers without requiring you to have a cluster. The reasons for running multiple instances of TIBCO iProcess Objects Server on the same machine are:
Adding and Deleting Instances of the TIBCO iProcess Objects Server
When the TIBCO iProcess Objects Server is initially installed on a machine, it becomes instance 1 by default. A new installation of a TIBCO iProcess Objects Server on a machine will cause an entry for that server to be automatically added to the process_config table, as follows:
 
Once the initial installation is completed, additional instances of the TIBCO iProcess Objects Server can then be added to or deleted from the process_config table using the following swadm commands:
Windows systems:
SWDIR\util\swadm add_process MachineID SPO Y
SWDIR\util\swadm delete_process MachineID SPO <ProcessInst>
UNIX systems:
$SWDIR/util/swadm add_process MachineID SPO Y
$SWDIR/util/swadm delete_process MachineID SPO <ProcessInst>
For example, after adding a second instance to machine 1, the process_config table appears as follows:
 
For additional information about using the swadm utility, see iProcess Engine Administrator’s Guide.
Number of Instances
The TIBCO iProcess Engine does not impose a limitation on the number of instances of a process running on a machine in the node cluster. The maximum number of instances is really a function of the amount of resources available on the machine. In reality, it does not seem reasonable nor practical to run more than 16 TIBCO iProcess Objects Server instances on a machine. However, the TIBCO iProcess Objects Server is coded to limit the number of instances per machine to 99. You will still be able to configure more than 99 instances per machine in the Process Manager, but any TIBCO iProcess Objects Server instance greater than 99 will generate an error status to the Process Manager and exit gracefully. This error will be seen in the "Last Status" column when running “swadm show_processes”.
Implementation
To run multiple TIBCO iProcess Objects Servers against one TIBCO iProcess Engine, you must specify the TCP and UDP ports, as appropriate, for each instance of the TIBCO iProcess Objects Server.
For information about configuring TCP ports for multiple instances, see the TCPServiceName parameters on This identifies the port number on which the TIBCO iProcess Objects Server will listen for client connections. This can be specified in the following ways:; for information about configuring UDP ports for multiple instances, see the UDPServiceName parameter on UDPServiceName.
Starting/Stopping Multiple TIBCO iProcess Objects Servers
The Process Sentinels control the starting and stopping of multiple TIBCO iProcess Objects Servers that have been added to the process_config table.
By default, once the Process Sentinels have started, they automatically start the processes in the process_config table. You can force all processes in the process_config table to be started or stopped by using the following commands:
Windows systems:
SWDIR\bin\swstart
SWDIR\bin\swstop
UNIX systems:
$SWDIR/bin\swstart
$SWDIR/bin\swstop
Or, you can start or stop individual TIBCO iProcess Objects Server instances using the following commands:
Windows systems:
SWDIR\util\swsvrmgr START MachineID SPO <ProcessInst>
SWDIR\util\swsvrmgr SHUTDOWN MachineID SPO <ProcessInst>
UNIX systems:
$SWDIR/util/swsvrmgr START <MachineID> SPO <ProcessInst>
$SWDIR/util/swsvrmgr SHUTDOWN <MachineID> SPO <ProcessInst>
For more information about the swsvrmgr utility, see iProcess Engine Administrator’s Guide.
Configuration Parameter Instances
All of the TIBCO iProcess Objects Server configuration parameters (except NumFiles, AnonymousUserName’X’, AnonymousSWUserName’X’, AnonymousPoolSize’X’ and AnonymousPrivilege’X’) can be designated for a particular instance, allowing you to configure each instance of the TIBCO iProcess Objects Server differently. The way in which this is done depends on whether you are using a UNIX or Windows TIBCO iProcess Objects Server, as follows:
The UNIX TIBCO iProcess Objects Server includes a configuration file that specifies the values assigned to each TIBCO iProcess Objects Server configuration parameter. You can define a configuration parameter for each instance of the TIBCO iProcess Objects Server by appending the instance number to the parameter name (e.g., LogFileMaxSize03). For more information, see Configuring Multiple Instance Parameters on UNIX Systems.
The Windows TIBCO iProcess Objects Server includes a configuration utility for administering configuration parameters. The configuration utility allows specification of parameters for each instance of the TIBCO iProcess Objects Server running on that machine. For more information, see Configuring Multiple Instance Parameters on Windows Systems.
Specifying TCP and UDP ports for multiple instances of the TIBCO iProcess Objects Server works a little differently than the other configuration parameters. See TCPServiceName and UDPServiceName for more information.
Log File Names
If you are using a TIBCO iProcess Objects Server that is multiple-instance capable, the name of the TIBCO iProcess Objects Server log, archive log, and audit log will include the instance number (XX) of the TIBCO iProcess Objects Server instance. The timestamp variable in the log file names:
See Name and Location of the TIBCO iProcess Objects Server Log for more information.
SWEntObjSvXX.log
SWEntObjSvXX_timestamp.log1
SWEntObjSvXX.log
swentobjsvXX_timestamp.log
SWEntObjUaXX_timestamp.log
swentobjuaXX_timestamp.log
TIBCO iProcess Objects Server archive log2
SWEntObjSvXX_timestamp
_archive_xxx.log
swentobjsvXX_timestamp
_archive_xxx.log

1
This file is the archived SWEntObjSvXX.log, where the timestamp variable is the date when the log is generated.

2
For more information about the archive log, see LogFileMaxArchives.

Accessing Multiple Instances of the TIBCO iProcess Objects Server
The way in which you access multiple instances of the server depends whether you are using TIBCO iProcess Objects or TIBCO iProcess Server Objects, as described in the following subsections.
Using TIBCO iProcess Objects
The following are methods you can use to access multiple instances of the TIBCO iProcess Objects Server using TIBCO iProcess Objects:
   ComputerName|NodeName|IsDirector|InstanceNumber
For more information about these methods of accessing multiple instances of the TIBCO iProcess Objects Server, see TIBCO iProcess Objects Programmer’s Guide.
Using TIBCO iProcess Server Objects
The following are methods you can use to access multiple instances of the TIBCO iProcess Objects Server using TIBCO iProcess Server Objects:
UDP Broadcast - Calling the getNodes method on sNodeManager causes a UDP broadcast to be issued on the LAN segment. The getNodes method returns an array of vNode objects, one for each TIBCO iProcess Objects Server that responded to the UDP broadcast. You can then call the getInstance method on the vNode object to determine the instance number of that TIBCO iProcess Objects Server.
Directed UDP Message - Calling the verifyNode method on sNodeManager causes a directed UDP message to be sent to a specific instance of the TIBCO iProcess Objects Server. This method provides an aInstance parameter to specify the specific instance of the TIBCO iProcess Objects Server to receive the UDP message.
Manually Create a vNodeId Object- You can construct a vNodeId object that represents the specific instance of the desired TIBCO iProcess Objects Server. Note that the constructor for the vNodeId object does not have an Instance parameter — you must use the aTCPPort parameter to uniquely identify the instance of the TIBCO iProcess Objects Server the vNodeId object is to represent.
For more information about these methods of accessing multiple instances of the TIBCO iProcess Objects Server, see TIBCO iProcess Server Objects Programmer’s Guide.
Multiple Instance Limitations
The following limitations apply when running multiple instances of TIBCO iProcess Objects Servers:

Copyright © Cloud Software Group, Inc. All rights reserved.
Copyright © Cloud Software Group, Inc. All rights reserved.