This topic recommends best practices for integrating the BAM server with Process Analyzer and configuring the BAM project.
The application server that hosts the BAM server (for example, JBoss) should be configured with maximum available memory. On 32-bit UNIX, the maximum memory is 3.5 GB; on Microsoft Windows, the maximum memory that can be configured for the JVM is 1.5 GB.
The BAM database server may be collocated with the BAM server since the BAM database does not require a large amount of space and does not impose a heavy load on the CPU.
The BAM database and the Process Analyzer database should reside on separate servers.
Memory usage is a primary consideration when configuring a BAM project. Each additional measure in a stateful view or cube, additional dashboard object, and additional rule and alert combination has significant impact on memory usage. FileNet recommends monitoring memory usage as you add these items to theBAM project—it is best to make one change at a time. For example, add one user-defined field, and create the dashboard object, rules, and alert using that field. Check the system memory usage at each addition before continuing to the next item.
The following are additional tips for configuring the BAM project:
When new BA< functionality has been validated in a development environment, you can deploy the changes in the BAM project to the production environment. FileNet recommends the following general steps:
When there are a large number of users accessing BAM Dashboards and BAM Application Workbench, you can use one of the following scaling approaches:
![]() |
Approach A uses multiple servers, each running a single deployment of a Java Application server installed with BAM server software and the same BAM project. Each server retrieves its data from the same data source. Users are assigned to a specific BAM server engine. |
![]() |
Approach B uses multiple servers--usually more powerful Unix servers--running multiple Java Application servers installed with BAM server software. Each BAM server has a separate connection and performs separate queries to retrieve data from the data source— Process Analyzer data base. This approach might have some impact on the performance of the system that hosts the data source. If the data source contains small amounts of data, such as the WIP fact tables in the Process Analyzer database, then the performance impact might be minimal. If the data source contains large amounts of data, multiple BAM servers querying the data source could significantly impact the performance of that server. In this case, it is best to replicate the source data to separate servers. This approach is not a true horizontal scaling solution. Each user has a "home" BAM server and his BAM operation would be with that particular BAM server. Manual load balancing would be required—manually monitor the health of the system and redistribute the users accordingly across the servers. NOTE Each BAM server polls the data source at an interval. It is very likely that the BAM servers would either not retrieve the data at the same time or process the events in the same timely fashion—for example, one server could be faster than another. As a result, one BAM server could have the latest data and fire alerts sooner than another server. This is unavoidable, but the latency is small if the data source contains small amounts of data like the WIP fact tables in the Process Analyzer database. However, with large amounts of data, this latency might be more significant. |
![]() |
Approach C uses multiple servers running different BAM projects. For example, Project-A might be a financial application, while Project-B might be a resource management application. Each project uses data from a separate external database, as well as data from the Process Analyzer database. This approach can be used to support multiple languages by treating each language as a separate BAM solution. |
See Back up Business Activity Monitor and Restore Business Activity Monitor for instructions.