Integration framework
Tune the mechanisms that IBM TRIRIGA Application Platform uses to integrate with external applications.
Integration components
The following components are the main integration components:
- Connector for Business Applications (CBA)
- DataConnect (DC)
- Data Integrator (DI)
- Integration Object (IO)
- Open Services for Lifecycle Collaboration (OSLC). For more information, see Integrating data by using the OSLC REST API.
For more information about the integration components, see Integrating data with external applications.
These integration components can significantly affect the performance of the system. Consider these components when you are sizing and tuning your system. The incorporation of both multi-threading and clustering greatly increases throughput in an integrated environment. The TRIRIGA® platform uses a multi-threaded integration model. The Connector for Business Applications (CBA) model is set up to process multiple inbound transactions at once. In a large and integrated system, tune the application and the overall environment parameters, including the parameters for the application server.
- Dedicated server
- Use a dedicated server for multiple integrations.
- Off-peak scheduling
- Schedule regular integration jobs during off-peak user times.
- Session tracking
- Turn off the session tracking for integrations.
- Workflow execution
- Minimize the number of workflows that the integration processes run.
- Data loading
- For large data loads, migrations, and batch jobs, take the following steps:
- Schedule a maintenance window when you plan to optimize the system for data loading.
- Notify users of the maintenance window.
- Lock out users during the maintenance window.
- Configure the system for optimal data loading, for example, maximize JVM heap, increase workflow agents and threads, and enable only essential components.
- After the data load or batch migration is complete, reverse the configurations from step 4.
- Reverse the user lockout and notify users.
Integration workflow processing and performance
All of these integration components use the workflow engine. The integration components can also be tuned by following the best practice guide lines in the Agents section in System properties and Workflow performance.
When TRIRIGA performs integration operations, such as importing large numbers of floor and space records by using DataConnect (DC), increase the throughput by analyzing which workflows are run as part of the process. Then disable those workflows that are not needed by the operation.
Find out which workflows are run by enabling all workflow instances to be recorded and then inspect them after you go through the process once. However, you can miss instances in many workflows that are run as side effects of creating and associating records. In addition, enabling workflow instance recording might cause process and system overhead. Therefore, avoid enabling all workflows except when you are debugging a part of the processing. Disable all instance recording at all other times. You can set the WF_INSTANCE_SAVE property in the TRIRIGAWEB.properties file and temporarily override the proprty if needed by using the Workflow Agent Manager in the Administrator Console. For more information, see Workflow performance.
You can also which workflows are run and why by enabling synchronous and asynchronous workflow performance logging and collecting the performance.log file from the process server that runs the Workflow Agent. Then, process and analyze the performance.log file by using the Workflow Analysis Utility to get an interactive view into what is running, why, and for how long.
Also, if integration processing is done regularly, consider using the Integration flag in the workflow start conditions to skip workflows instead of temporarily retiring them.
Running multiple workflow servers allows workflow processing to be fair to all users. It does not necessarily increase the throughput of the number of workflows that are processed. Adding multiple Workflow Agents to a single environment can slow down processing and cause undesirable results if workflows are not written with multi-threading in mind.
The optimum approach is to assign secondary Workflow Agents to dedicated power users who run more workflows than a typical user. Take this approach by using the Workflow Agent Manager in the Administrator Console.
If multiple Workflow Agents remain open, that is, not bound to a user, then a set of workflow instances are picked up in parallel and some might be processed out-of-order. Increasing the number of threads on a single process server results in higher throughput than splitting the threads across two servers. Typically, the bottleneck of performance is the database server rather than the process servers.
- Stopping the secondary agents and increasing the threads on the primary Workflow Agent server to be the sum of the threads across the other servers.
- Restricting the secondary agents to be exclusive for the set of power users.
Hierarchy path mapping
If a database server is slow and you create many hierarchy records by using Data Integrator (DI) and an asynchronous workflow, the triPathSY hierarchy path of some records might not be mapped properly. To resolve this issue, either delete the incorrect records and re-create them or create a patch helper to fix those records.