Maintaining IBM BPM-dependent systems
This chapter focuses on the performance of and maintaining the underlying infrastructure and dependent systems that are used in IBM Business Process Manager (BPM). The nature of BPM is to regularly and methodically integrate different applications and people into a defined process, which involves integrations to various systems.
The performance and stability of IBM BPM relies on a maintained infrastructure. These integrations can be a few or many systems within or external to the IBM BPM installation.
This chapter includes the following topics:
5.1 Lower stack level products, Java, WebSphere Application Server, and web servers
This section describes the underlying stack products on which IBM BPM is installed.
5.1.1 WebSphere Application Server and IBM Java upgrades
IBM BPM is a stack product that relies on IBM Java, IBM WebSphere Application Server, and the OS on which IBM BPM is installed. IBM BPM supports up-level fix packs of IBM Java and IBM WebSphere Application Server.
Starting with WebSphere Application Server version 8 and later, IBM Java upgrades are bundled with the WebSphere Application Server upgrades, which making it a single installation. For more information about the initial versions of WebSphere for each BPM release, see the systems requirements page under “Prerequisites” at the following website:
The Java SDK version for each version of WebSphere is available at the following website:
It is recommended to regularly upgrade to the latest WebSphere fix pack level. If a security vulnerability is found, the announcement and fix is available for all affected product versions. It also is recommended to apply security patches when they are available.
Security bulletins also are sent out by the IBM My Notification system. You can sign up to receive notifications updates for defects, fix packs, product announcements, and security bulletins at the following website:
5.1.2 Thread pools and sizings
IBM BPM uses several different thread types. These types feature different tuning needs that are based on your application design. For more information about monitoring systems and load testing optimizations for the thread pools, see IBM Business Process Manager V8.5Performance Tuning and Best Practices, SG24-8216, which is available at this website:
All of these thread pools are managed at the WebSphere Application Server level. For more information about a tool that is available to assist with tuning, see the following website:
Common threads to tune with IBM BPM
The following common threads might need extra tuning:
•JMS threads, which are heavily used in BPEL applications, also are used to send messages to the BPMN event manager and invoke UCAs. For more information about tuning, see this website:
•ORB, which is used for Process Designer and Process Center communication. This thread also can be used in an integration service for a BPEL application.
•WebContainer, which is used for BPMN coaches, portal, and web interactions and for BPEL human task manager.
•For Work Manager thread, the BPMN event manager uses the wm/BPMEventManagerWorkManager thread. For more information about configuring, see this website:
5.1.3 HTTP sessions
The primary way business users of IBM connect to IBM BPM is by using a browser. Users log in to a portal to view, claim, and complete tasks. In this section, the configuration that is described applies to the IBM BPM Process Portal and custom portal that is made by the Application Development team.
Session affinity
Session affinity (sometimes referred to as sticky sessions) is used at the load balancer in a clustered IBM BPM configuration. It is a required setting for clustered environments. When a user logs in, they are routed to one of the nodes in a clustered configuration. The user works on that server and continues there until their HTTP session is destroyed or times out.
For more information, see this website:
Session replication
IBM BPM does not support session replication. Session replication is used in some applications. When a node the user is connected to goes offline, the user can continue work without interruption. This continuation is not possible with IBM BPM as the main interaction of data is a coach. Coaches are EJB objects and the data from the users’ interface is lost when a server becomes unavailable. The data cannot be retrieved.
 
Note: When a JVM must be restarted during business hours, remove the server from the load balancer configuration. Taking this precaution prevents new users from being directed to the server that is being restarted. Monitor the load balancer to ensure that sessions are no longer active on that server. Monitoring this activity reduces the number of users who were interrupted from a server restart during the day.
User logout and session expiration
The following sessions are related timeouts in IBM BPM:
•Lightweight Third-Party Authentication
Lightweight Third Party Authentication (LTPA) is issued by WebSphere for security authentication. The default timeout is 2 hours.
•EJB
This session is the session bean timeout, which is most commonly connected to Coaches in the BPMN application. The default timeout is 2 hours.
•HTTP
This session is the relationship between user and web server. The default timeout is 30 minutes.
Consult with your Business and Security teams about standards and expectations for user logout and session timeouts. For example, a requirement might be that a user should log in only from one client IP address at a time. This requirement is not something WebSphere Application Server or IBM BPM can configure. Single sign on (SSO) tools, such as WebSEAL from IBM Security Access Manager, can provide this feature. You might need to consult with your SSO provider for more security options, which can be a business or security requirement.
For more information about how to change the values for these session-related timeouts and technical details, see the following resources:
5.1.4 Operating system maintenance
The operating system in which BPM is installed also must be maintained. This maintenance includes having enough temporary disk space, appropriate swap space, and memory allocation for the IBM BPM server and any supporting applications, such as monitoring tools. Keeping the OS updated also is important for security and other bug fixes. For more information about supported operating systems for your IBM BPM versions, see the following System Requirements website:
5.1.5 Virtualization
Your installation can be installed in a virtual machine (VM), which includes the main IBM BPM installation and the database. Considerations of how many VMs and the distribution of CPU, memory, and IO are needed.
If the system that is controlling the VMs is undersized, you can see CPU starvation or memory swapping. Consult with your virtualization platform and database vendor about how best to monitor and configure a virtual system. A good start is the article Performance tuning considerations when IBM Business Process Manager (BPM) is running in a virtual machine, which is available at this website:
5.2 Security and LDAP connections
This section describes configuration options for the Lightweight Directory Access Protocol (LDAP), performance with LDAP, and some IBM BPM authorization. In this section, the term LDAP refers to any LDAP directory server that WebSphere supports as described in the following document:
WebSphere Application Server can accommodate more security repositories. This section describes LDAP. The API calls from BPM to WebSphere Application Server behave the same way for all configured security providers in the federated repositories.
 
Note: The following terms are used in this section:
•Authentication
Authentication refers to ensuring that the user is who they claim to be. This process is handled by WebSphere Application Server.
•Authorization
After the user is authenticated, authorization dictates the features, consoles, operations, and data that a user can access. Authorization can be modified and granted through the IBM BPM configuration settings and through application design. Some can be changed at run time, others require a restart after configuration.
5.2.1 Default configuration
The default settings in IBM BPM 8.5 and later include federated repositories as its user registry. The only configured repository in the federation is the WebSphere Application Server internal file registry.
The federation can be easily extended to also include your corporate LDAP server or even a custom adapter to integrate non-LDAP-based user repository. Although other configurations are possible, their use is discouraged because they are uncommon and often include restrictions.
The file registry is the initial configuration. Figure 5-1 shows an example federated configuration that includes the o=defaultWIMFileBasedRealm configuration. It is a good practice to change the default realm name to avoid accidentally having SSO enabled between two environments.
Figure 5-1 Federated configuration
Figure 5-2 shows an example of a configuration with a second repository (in this case, a Microsoft Active Directory Server).
Figure 5-2 Configuration with secondary repository
During the IBM BPM installation process, at least two users are defined: The deployment administrator and the cell administrator. You can provide a dedicated authentication alias and a dedicated user for all BPM security roles while the deployment environment is created. These users are mapped to the WebSphere administrative roles and the IBM BPM security groups.
Extra local users and local security groups can be added manually through the IBM BPM Process Administration console or the WebSphere Application Server console. Scripting options also are available to add users by using wsadmin commands.
The following BPM and WebSphere Application Server user and group security consoles are available:
•Add local users and security groups in WebSphere Administration Console, as shown in Figure 5-3.
Figure 5-3 WebSphere Application Server console
•Maintain relations with users and internal groups and modify user attributes in the IBM BPM Process Administration console, as shown in Figure 5-4.
Figure 5-4 IBM BPM Process Administration user console
For more information about WebSphere Application Server wsadmin references (user and group administration commands), see this website:
5.2.2 Default users and groups
During product installation, two users are configured: the deployment administrators and cell administrators. These users configure and run WebSphere Application Server and start the IBM BPM systems. It is not recommended to put these users in LDAP. If the primary IBM BPM administrative users are in LDAP and the LDAP server cannot be reached, you cannot log in to the system to perform operational duties. If the LDAP server is down, administrative login security can be disabled; however, logins can still occur without security credentials, which might not be an allowed security policy.
In IBM BPM v8.5 and later, the document storage is implemented with an embedded IBM FileNet server. The configuration of this component is required, even if your application does not use the internal document storage feature.
For more information about the limitations of the document store that relates to the security configuration for IBM BPM, see this website:
Some security requirements state that all users must be in an LDAP or other outside repository. If this requirement is applies to you, specific steps are needed to properly configure the EmbeddedECMTechnicialUser for LDAP. For more information, see the following documentation:
For more information about the default BPM security groups, see the following documentation:
 
Note: Do not delete the default security groups or users, which are needed for core functionality. If these groups or users are removed or modified, contact IBM BPM Support for assistance. The group tw_all_users is a special group; therefore, do not add users or groups to this local security group.
5.2.3 LDAP
This section describes configuring LDAP and provides useful tips.
Preparing to configure LDAP
Before configuring LDAP with IBM BPM, first review with the business which organization units and groups in the company need access to IBM BPM. After you draft a list of users and groups, work with the LDAP administrator to develop an entry point to the LDAP tree.
With the federated repositories, you can have multiple configurations to LDAP. In addition to LDAP tree filtering, groups can be narrowed with a search filter. It is important to limit the scope of LDAP of which IBM BPM can access. The reason is metadata about users and groups (no passwords, only names and membership relations) are stored in the IBM BPM database tables. There is no current functionality to remove metadata that is synced from LDAP. Therefore, we recommend careful planning before LDAP is configured. Each environment features a different base configuration.
Generally, the following user groups need access to IBM BPM:
•Developers
•Operations team
•Business users
•Testers
These users need access to the following types of IBM BPM installations:
•Development
•QA, Test, or Pre-production
•Production
The four groups across these environments can overlap or have the same people, depending on the company structure and separation of duties (see Table 5-1).
Table 5-1 Example user types per environment
Environment
User types
Development (Process Center)
Operations, development
QA, TEST
Operations, development, testers
Production
Operations, business users
Configuring LDAP
To configure an LDAP repository, review the directions that are included in the following WebSphere documentation:
Contact the LDAP administrator for more information about the ports, host name, and LDAP filter list that authorizes users for the server that you are configuring. It is recommended to configure LDAP with only the deployment manager (dmgr) running and other servers that are turned off. By following this approach, you can quickly test and determine whether there are any issues with the configuration. You can also check and see whether all expected users and groups are visible in the Users and Groups section of WebSphere. If WebSphere cannot see a user or group, IBM BPM also cannot see the user or group.
Resolve LDAP configuration issues before starting the nodes and BPM JVMs (AppTarget). This issue also is important to not accidentally add groups and users to BPM user and group XREF meta tables. No functionality is available to remove the metadata of users and groups that are synced from LDAP.
 
Note: Before configuring LDAP, backup the wimconfig.xml, fileRegistry.xml, and security.xml files. These core files are used for configuring security in WebSphere. If the settings are not correct after the deployment manager is restarted, replace the files with your backup version and try the configuration again.
After LDAP is configured, see the IBM BPM administration section of the IBM Knowledge Center for more information about how to grant users authorization to different areas of the product:
This process includes authorization capabilities in the Process Center Repository, authorization to the Process Admin console, configuration of Teams during run time, and other authorization options.
For more information, see the following documents:
•IBM Business Process Manager security overview:
•Managing access to the Process Center Repository
•Configuration properties for Process Portal action policies:
•Modifying the Process Admin Console setting and behavior:
•Creating a secure environment:
After LDAP is configured, you can search for users and groups that are in the federated repositories. Examples of the WebSphere Application Server user and groups section system after LDAP is configured are shown in Figure 5-5 and Figure 5-6. You can see the local file users of celladmin and LDAP users, such as ldapuser1.
Figure 5-5 List of file registry and LDAP users in WebSphere Administration console
Figure 5-6 List of LDAP Groups in WebSphere Administration console
Figure 5-7 shows a list of groups in the IBM BPM Process Admin Group Administration panel. LDAP groups cannot be removed, only displayed.
Figure 5-7 List of Groups in BPM Process Admin Console with a wildcard search
Figure 5-8 shows an LDAP group in the IBM BPM Process Admin console. The group membership here is read-only and cannot be changed.
Figure 5-8 LDAP membership is read only
Figure 5-9 shows the group tw_author, which grants privileges to the Process Center repository that is configured with LDAP users and groups.
Figure 5-9 BPM Security group with local users and LDAP members
5.2.4 User and group synchronization
User and group synchronization occurs automatically and can be initialized by using commands. These concepts are important for IBM BPM. The time and length for the automatic synchronization depends on the number of members that are in an individual security group or team and the size of the connected LDAP.
Server start
During the process server or process center (AppTarget JVM) startup, IBM BPM scans and updates new groups that it sees from the federated repositories. If new groups are visible, it adds these groups to the XREF tables and the Group Cache.
The start and end of the synchronization is recorded as an information message in SystemOut.log, as shown in Example 5-1.
Example 5-1 SystemOut messages for group sync start and completion
wle_security I com.lombardisoftware.server.core.GroupCore getAllGroupsInternal CWLND0005I - The group replication process has started.
wle_security I com.lombardisoftware.server.core.GroupCore getAllGroupsInternal CWLND0006I - The group replication process has completed.
During startup, you might see the exception MaxResultsExceededException: CWWIM1018E. This exception means that the maximum search value in the LDAP settings was reached. The search limit must be increased or a filter added for groups that are not needed.
For more information, see the following WebSphere Application Server documentation:
For more information about max search results, see the following resources:
User login
This section describes configuration and other notes for user login.
LDAP configuration
When you add LDAP to federated repositories, you can specify a login ID. One or more values can be entered so that users can log in with one or more unique attributes. This information is the Federated repository properties for login field setting in the configuration page for LDAP, as shown in Figure 5-10. Typically uid; mail is entered, which allows users to log in with their user ID or mail setting. An example of a user ID can be 35121243 and the mail is [email protected].
Figure 5-10 WebSphere Administration Console for configuring LDAP
It is not recommended to use only the mail ID for this configuration because user emails can change. By having the user ID listed first, this entry is entered into the IBM user XREF tables. If a user email changes or has a new alias, such as [email protected], they can then log in and still see the same data as the IBM BPM user tables are using the user ID as the primary reference.
Initial and subsequent user login
When a user first logs in to IBM BPM, their primary login ID is added to the database and all group memberships. Subsequent logins refresh only the group membership for the user. Therefore, if user X transferred from Development to Product Management, this relation is reflected in the local database. The user then sees a different set of tasks as their group membership changed and thus their authorization to see tasks.
There are some considerations for login and user lookups. The first is where the group cache is referenced upon login. By default, it accesses updated information from LDAP. This configuration can be changed to use the local cached information in the database. To enable this feature, a 100Custom.xml setting and a WebSphere Application Server LDAP configuration must be applied. In addition, the use of the wsadmin commands to refresh group and user memberships must be run periodically.
For more information about changing the group, see the following resources:
If the application was created before IBM BPM 8.5, places can exist in which the task assignment is set as an “Expression.” This group dynamic and an example configuration option for this setting is shown in Example 5-2 on page 81.
Example 5-2 Configuration options for controlling when dynamic groups are updated
<update-dynamic-groups-on-login>
<update-dynamic-groups-on-task-creation>
<update-dynamic-groups-on-uadchanged>
The default values are set to true and are configurable by using a 100Custom.xml file. The new feature uses Teams with services.
For more information, see the following website:
Group member cache can be changed to reference the database (see Example 5-3), which reduces calls to LDAP. In environments where the IBM BPM user population LDAP membership is static, changing to the database improves performance.
Example 5-3 Configuration option for group member cache
<group-member-cache-source>
For more information about the group member cache feature, see this website:
Installing a snapshot
During the installation of a snapshot, teams that are defined in the application are added to target servers group tables. A unique entry is used for each team entry for each snapshot. After a snapshot is installed, the users and groups that are defined in the team can be changed at run time in the Team Bindings section. Consult with the Application Development and Business teams who should be assigned in each environment in the role bindings page. For more information, see this website:
Updating users and groups
Several methods are available to update users and their group memberships. The command line scripts are common for the Operations group because they have console access. The JavaScript and REST commands tend to be used in the application. However, the Operations team also might create their own helper applications to facilitate security maintenance.
Command-line scripts
Users and groups can be synced by using the wsadmin commands. These commands allow for synchronization outside of a user login or server startup routine. This configuration can be greatly beneficial to offload the time to create users and groups for large LDAP systems. The group and user functions are helpful for the following cases:
•Adding an application to IBM BPM and extending the number of people who can access IBM BPM. You can synchronize the known LDAP groups that are defined in the Role Bindings page. For applications where tasks are assigned in a round-robin or other dynamic fashion, pre-synchronizing groups and users is helpful.
•Reducing the time for a user’s first login to IBM BPM.
•A known LDAP group has high turnover rate. For example, a group for a call center has a 25% change every month. Use the wsadmin command to synchronize members of this group.
•Dynamic groups; for example, there is a dynamic group that is created with the combination of data points (customer type, account value, and geographic region) to determine the best set of people to work on it.
For more information about the commands that are used to synchronize user and groups, see the following resources:
JavaScript API
The TWTeam and TWUser objects include methods to find and update other information about the Users and Teams. For more information, see this website:
REST API methods
The REST API includes a useful set of commands for users and groups. A built-in testing tool is available that lists all REST API methods. This tool is available at this website:
For more information about User, Group, and Team REST functions, see this website:
5.2.5 IBM BPM database and custom data sources
IBM BPM is backed by a database and many applications feature integrations to outside databases. This section describes maintaining and configuring these systems.
Maintaining the BPM database
From an operations perspective, the database affects the system health most, almost as much as application design and interactions from other integrations. The IBM BPM system is highly reliant on the database for daily work and maintaining performance.
For more information about tips and commands for DB2, see the developer works article series, IBM Business Process Manager database troubleshooting, Part 1: What you can learn from your IBM DB2 for Linux, UNIX, and Windows database, which is available at this website:
The same methodology and similar commands can be applied to Oracle and Microsoft SQL Server databases.
Tuning recommendations
IBM BPM uses a relational database to store the application models and business data. The design of the database is not an archival repository. Regular data deletion is necessary for best performance. For more information about purging data, see Chapter 4, “Purging and archiving in IBM BPM systems” on page 51.
IBM BPM inserts and updates data. This configuration is different than that from a database, which is primarily used for read statements (SELECT). Database statements in IBM BPM involve multiple tables and most of these tables involve multiple updates, which affect several tables per transaction. The operations team must work with the DBA to tune the database so that the database is optimized to update and insert large data sets.
Indexes and reorganization
IBM BPM features a set of indexes across many tables. These indexes facilitate finding information quickly. As the number of rows in tables increase through daily use or decreases through deletion, the indexes might need to be reorganized.
As the percentage of rows (which are inserted or deleted from a table) increases since the last index, the greater the need for a reorganization. Maintaining the indexes is an important part of keeping an IBM BPM system healthy. Typically, an IBM BPM production system needs reorganization of tables once a week during a scheduled maintenance window or low-usage period. Monitoring your system over time indicates whether indexes must occur more frequently.
Load test systems that generate large amounts of data and are then deleted should be reorganized between testing scenarios. Monitoring the growth of records in the database can show that certain indexes might need to be run on a more frequent basis (possibly once a day). For more information about how to run the reorganization on indexes, see your database vendor’s documentation.
Adding custom indexes
Creating indexes for the IBM BPM tables often is not needed. If evidence shows that a new index is needed, the issue can be solved by enabling a current feature or applying a fix pack that includes the updated index. One example is the saved search accelerator tables. These changes dramatically increase the speed of finding task records and decrease stress on the LSW_TASK table. This feature functions as an index would on the database. It is recommended that all runtime servers have this feature configured. For more information, see this website:
For more information about the use of custom indexes with IBM BPM to add an index to an IBM BPM table, see the following website:
Query plans and reviewing performance
In addition to indexes, another area to consider is query plans. When a query is sent to the database, the database engine determines a path for the data to take. For simple single selects, few paths are available. For more complex queries that involve multiple joins, conditions, and groupings, different ways are available for the database to internally search for this information.
For queries that do not improve after reindexing and data deletion, the query plan might need to be investigated. For more information about tips and commands for DB2, see the developer works article series, IBM Business Process Manager database troubleshooting, Part 2: Solve performance issues with IBM DB2 for Linux, UNIX, and Windows examples, which is available at this website:
Upgrading databases without affecting IBM BPM downtime
To maintain the highest availability for system uptime, the database can be set up to allow rolling upgrades. These upgrades allow you to apply the next database fix pack and keep IBM BPM running. Consult with your DBA and database vendor for proper configuration of this high availability scenario.
JDBC provider and data source configurations
After IBM BPM is installed, the JDBC driver must be updated. Custom data sources that are created for the application also might need tuning.
JDBC driver
After the IBM BPM system is installed, upgrade the JDBC drivers to the version that matches your database. IBM BPM requires Type 4 JDBC driver. It is a best practice to mach the JDBC driver version to the version of the database, including the IBM BPM product data sources and any added custom data sources. An example of SystemOut.log that shows the named data source and associated JDBC driver version is shown in Example 5-4.
Example 5-4 Example SystemOut message with JDBC Version from DB2 without the box drivers
DSRA8225I: DataSource JNDI name : jdbc/TeamWorksDB
DSRA8203I: Database product name : DB2/NT64
DSRA8204I: Database product version : SQL10053
DSRA8205I: JDBC driver name : IBM Data Server Driver for JDBC and SQLJ
DSRA8206I: JDBC driver version : 4.11.69
DSRA8218I: JDBC driver specification level : 4.0
DSRA8212I: DataStoreHelper name is: com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper@67c85533.
DSRA8208I: JDBC driver type : 4
For more information, see the following resources:
•IBM DB2 JDBC Driver download list:
•For more information about Microsoft SQL Server download list:
•Oracle Database download list:
Data source properties
Common tuning for data source connection pool properties is connection timeout, max connections, and unused timeout. For the IBM BPM product default data sources, these properties should not need to be tuned. This issue is true for almost all default values in IBM BPM 8.5.0.1 and later.
Custom data sources that are added for the applications must be configured and tuned. During a load test, monitor the custom data sources and determine how often connections were released and if the pool was ever exhausted. For more information about configuring a JDBC provider and data source in WebSphere for your custom applications, see this website:
5.3 External integrations
Various configuration tuning in the IBM BPM installation were described in this chapter. The IBM BPM applications connect to outside systems with the various connections that were described.
During initial configuration and troubleshooting, it is a good idea for the Operations team to have a list of all dependent systems and a way to identify host names or IP addresses. Having a list or an internal tool to find the owners of the system reduces time and cycles to find the owners who can help resolve issues.
 
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.2.78