One challenge with enterprise business process management implementations is that a single system might be used for multiple Business Applications.
Consider the following scenario:
Application 1 manages exceptions generated by a line of business system - this is a high volume application, but each instance has low value to the business
Application 2 manages quotation approvals for high value customers - this is a low volume application, but each instance has a high value to the business
Ideally, to ensure true separatation of these applications, it is best to use a separate TIBCO ActiveMatrix BPM instance (system) for each application - for more information on how to use multiple TIBCO ActiveMatrix BPM instances on the same enterprise refer to "Multiple TIBCO ActiveMatrix® BPM Systems in an Enterprise" in the documentation.
When considering how to segment applications it is also worth considering upgrade and mangement implications. For example, if applications are deployed to the same TIBCO ActiveMatrix BPM instance, or use the same ActiveMatrix host they must be lifecycled together and upgraded together.
Applications, such as those above, should at least be hosted on seperate TIBCO host + environment + TIBCO ActiveMatrix BPM instances if sharing an enterprise.
Sometimes it is not possible to have applications on different environment/systems. For example - when the applications need to be accessed by the same group of users using the same worklist or UI. When multiple distinct applications are hosted on the same TIBCO ActiveMatrix BPM instance it is important to seperate the applications as much as possible using appropriate resource instances and thread pool configurations. Consider the below deployment on 2 applications on the same TIBCO ActiveMatrix BPM system:
The applications are both running on the same TIBCO ActiveMatrix BPM Environment and application.
'Application 1 Start Process Service', 'Application 1 Trigger Event Message', 'Application 2 Start Process Service' are all services that are exposed on the same HTTP Connector Resource instance and use the common thread pool to process inbound messages.
' Application 1 Call External Service', 'Application 1 Call External Service 2', 'Application 2 Call External Service 1' are all outbound HTTP Web Service calls from the TIBCO ActiveMatrix BPM applications to external systems. By default these might be configured to use a shared HTTP Client Resource Instance.
Now consider a scenario where High Volume application triggers a large amount of messages to start processes or trigger events. It is possible that this could consume all resources on the environment and overload the shared HTTP Connector and shared thread pool. This could mean that high value messages for Application 2 are delayed, lost or perform poorly.
Best practice, when sharing a TIBCO ActiveMatrix BPM system is to ensure segmentation of the input and output channels so they can be tuned accordingly. This will avoid any single channel locking all resources and impacting other application channels.
For example in this scenario configuration should be as follows:
A new HTTP Connector should be created - 'App1_Inbound_HTTP' - this should then be used by Application 1 Start Process Service' and 'Application 1 Trigger Event Message'
A dedicated Thread Pool should be created - 'App1_inbound_Threadpool' - this should then be used only by 'App1_Inbound_HTTP'
A new HTTP Connector should be created - 'App2_Inbound_HTTP' - this should then be used by Application 2 Start Process Service'
A dedicated Thread Pool should be created - 'App2_inbound_Threadpool' - this should then be used only by 'App2_Inbound_HTTP'
Note: The HTTPInboundConnections have been configured to use the dedicated App1_Inbound_HTTP resource instance.
NOTE: The default HTTPConnector should NOT be used by any services provided by your TIBCO ActiveMatrix BPM applications in production. This should be left reserved for the Out of the Box Clients and APIs
A new HTTP Client should be created - 'App1_Outbound_HTTP' - this should then be used by 'Application 1 Call External Service' and 'Application 1 Call External Service 2'
A new HTTP Client should be created - 'App2_Outbound_HTTP' - this should then be used by 'Application 2 Call External Service'
Note: The Maximum Total Connections per Host has also been increased from 2 to 20 - since 2 is not appropriate for production scenarios.
Note: The HTTPOutboundConnection has been configured to use the dedicated App1_Outbound_HTTP resource instance.
One other area worth considering is the Process Priority used by the process engine. Each instance task has a priority and this is used by the process engine to determine the order of task processing. If you need to ensure that application 2 tasks are processed by the process engine as a priority over application 1 tasks you can set the process priority within a script task in the application 1 and application 2 process models, ensuring that application 2 tasks have a higher priority value. An example of increasing the priority in a proess model is shown below: