The following sub-sections steps through the key functional areas exposed by the SSO API into the TIBCO iProcess Engine and provide a set of best practices that to be followed when working with the API.
Node Discovery
Node Discovery involves the identification of the appropriate iProcess Engine node to connect to, and as such always represents the first task in any SSO module. There are 3 different mechanisms that can be used to locate an iProcess Engine node:
Note: Node Discovery should always be performed via vNodeId instantiation
This leads to 2 other considerations, and one further attendant recommendation:
Connection handling:
Once the iProcess Engine node has been identified, the second task in any SSO module is to log-on to the node, and thereby create a connection to the node. This is handled within the SSO API via the instantiation of any of the ‘Server Objects’.
To instantiate one of the ‘Server Objects’ it is required to pass in the username and password details of the user that is being used to connect to the iProcess Engine. The first time any user is logged in, this in turn causes the creation of an underlying ‘SAL Session’ to the iProcess Engine.
Subsequent logins by the same user will reconnect to the existing SAL Session if it is still available (a much less expensive operation that the creation of a new session). This leads to 3 further recommendations:
The SPO Server should be configured with a SAL Session pool size equal to or greater than the total number of named users, and those SAL Sessions should be configured to never expire.
When disconnecting a server Object always use <server_object>.disconnect(false) to keep the SAL Session alive.
When multiple connections are being made (e.g. if SSO is being used to allow for user access) ensure that each user connects as themselves and not either anonymously, or via any form of user ‘pool’ – this will minimize any potential performance issues to do with the synchronization of calls through the same SAL Session.
Each time a ‘Server Object’ is instantiated a TCP/IP socket connection is made to the iProcess engine node (via the SPO Server / SPO Director component). There is a special ‘Server Object’ called sSession that can be used to share the same socket connection across multiple ‘Server Objects’.
To minimize network overheads it is therefore strongly recommended that the sSession server Object always be used to spawn instances of the other ‘Server Objects’ that are required to fulfill the required functionality. For consistency it is also recommended that this approach be followed even when only one type of ‘Server Object’ is required to fulfill the required functionality.
The first ‘Server Object’ to be instantiated should always be an sSession Object, and that sSession should then be used to spawn the other required ‘Server Objects’.
Load Balancing
Connections to the iProcess engine via the SSO API are handled via the ‘SPO Server’ component of the TIBCO iProcess Engine. Multiple ‘SPO Server’ instances can be configured against any iProcess Engine instance to provide scalability.
When the iProcess engine is configured in this way an additional component, the ‘SPO Director’ can be used to provide automated load balancing. It is not a definitive requirement to make use of the ‘SPO Director’ when dealing with multiple ‘SPO Server’ instances as it is possible to provide a bespoke load balancing solution, but there is no real advantage to such an approach.
If multiple SPO Servers are configured to provide extra scalability then the SPO Director should be enabled and all connections made to the SPO Director
There are several different ways to configure the ‘SPO Director’ component to perform its load balancing (refer to the iProcess Objects Director Administrators Guide in the iProcess Documentation library for full details).
For training on TIBCO IProcess mail us at [email protected]
Node Discovery
Node Discovery involves the identification of the appropriate iProcess Engine node to connect to, and as such always represents the first task in any SSO module. There are 3 different mechanisms that can be used to locate an iProcess Engine node:
- UDP Broadcast via sNodeManager.getNodes
- Directed UDP Discovery via sNodeManager.verifyNode
- Explicit identification via vNodeId instantiation
Note: Node Discovery should always be performed via vNodeId instantiation
This leads to 2 other considerations, and one further attendant recommendation:
- In order to allow for vNodeId instantiation it is required to configure the SPO Server to use a static TCP/IP port
- The connection details for the iProcess node must be made available to the SSO Module. This is most appropriately done via entries in properties files.
Connection handling:
Once the iProcess Engine node has been identified, the second task in any SSO module is to log-on to the node, and thereby create a connection to the node. This is handled within the SSO API via the instantiation of any of the ‘Server Objects’.
To instantiate one of the ‘Server Objects’ it is required to pass in the username and password details of the user that is being used to connect to the iProcess Engine. The first time any user is logged in, this in turn causes the creation of an underlying ‘SAL Session’ to the iProcess Engine.
Subsequent logins by the same user will reconnect to the existing SAL Session if it is still available (a much less expensive operation that the creation of a new session). This leads to 3 further recommendations:
The SPO Server should be configured with a SAL Session pool size equal to or greater than the total number of named users, and those SAL Sessions should be configured to never expire.
When disconnecting a server Object always use <server_object>.disconnect(false) to keep the SAL Session alive.
When multiple connections are being made (e.g. if SSO is being used to allow for user access) ensure that each user connects as themselves and not either anonymously, or via any form of user ‘pool’ – this will minimize any potential performance issues to do with the synchronization of calls through the same SAL Session.
Each time a ‘Server Object’ is instantiated a TCP/IP socket connection is made to the iProcess engine node (via the SPO Server / SPO Director component). There is a special ‘Server Object’ called sSession that can be used to share the same socket connection across multiple ‘Server Objects’.
To minimize network overheads it is therefore strongly recommended that the sSession server Object always be used to spawn instances of the other ‘Server Objects’ that are required to fulfill the required functionality. For consistency it is also recommended that this approach be followed even when only one type of ‘Server Object’ is required to fulfill the required functionality.
The first ‘Server Object’ to be instantiated should always be an sSession Object, and that sSession should then be used to spawn the other required ‘Server Objects’.
Load Balancing
Connections to the iProcess engine via the SSO API are handled via the ‘SPO Server’ component of the TIBCO iProcess Engine. Multiple ‘SPO Server’ instances can be configured against any iProcess Engine instance to provide scalability.
When the iProcess engine is configured in this way an additional component, the ‘SPO Director’ can be used to provide automated load balancing. It is not a definitive requirement to make use of the ‘SPO Director’ when dealing with multiple ‘SPO Server’ instances as it is possible to provide a bespoke load balancing solution, but there is no real advantage to such an approach.
If multiple SPO Servers are configured to provide extra scalability then the SPO Director should be enabled and all connections made to the SPO Director
There are several different ways to configure the ‘SPO Director’ component to perform its load balancing (refer to the iProcess Objects Director Administrators Guide in the iProcess Documentation library for full details).
For training on TIBCO IProcess mail us at [email protected]
RSS Feed
