Hide Forgot
out-of-the-box, BRMS is configured with a single persistence.xml that bundles jbpm-bam with core jbpm5 SessionInfo, WorkItemInfo, and ProcessInstanceInfo. since BAM is functionally different than core jbpm5, recommend that at a minimum, jbpm-bam be managed by a separate EntityManagerFactory. Doing so will necessitate a new extension of WorkingMemoryLogger. Please see attachment for an example extension to WorkingMemoryLogger.
Even better would be to send BAM "events" via JMS to another service that persists the BAM data. This (along with potentially other design changes) would allow BAM processing to be removed from the process runtime environment. Doing so would greatly reduce the impact on process instance creation, etc. and allow a BAM server to be more optimally configured. Also, system configuration should allow BAM functionality to be turned off completely if the customer wishes to do so, thereby eliminating all BAM related load.
I see Jeff B captured this last idea in 743419.
I'll look at supporting both use cases, where you can set an entity manager directly (when registering the listener), or you can just reuse the one in the environment (if none is provided). Note that the BAM events already are implemented outside the core engine itself, the history logger is a normal listener that you need to register (and so you have no impact at all if you don't need BAM, just don't register the listener).