Impact of ACM Implementation on BAM

Recently I did a POC with BAM 12c at the customer. In a series of post’s I will describe my findings/experiences.
This is the first post in the series.

As a starting point we have the following situation:

We have an ACM composite consisting of a case with associated BusinessRule component and different BPM processes implemented as Case Activities. See figure below.


This is one single composite application. This means that there are two objects for BAM (‘VeryHugeCase Activity’ and ‘VeryHugeCase Process’) generated in the ‘Process Analytics’ project.

Notes on above image.
The ‘Activity’ data object tracks the time that passes from the moment the process instance arrives at a flow object until it moves to the next flow object in the process.
The ‘Process’ data object tracks the time an instance takes to run that process from the start to the end event.
The ’HWF Taskdata object tracks the humantasks metrics (open, closed, overdue, etc…).
Workload and performance metrics for the Participants are based on the ’HWF Task Assignment’ data object.
I leave the ‘CM Case … Instance’ data objects for what they are, they are out of scope for this post. Besides that I could not find information about them.

The data objects mentioned in the notes are generic, what this means is that they contain information about all composites in the systeem. Thus e.g. the ‘Activity’ data object contains activity information of all instances on the system regardless of the composite their housed. There is also a specific ‘Activity’ and ‘Process’ data object for each composite. These contain only the metrics of the associated composite. ‘VeryHugeCase Activity’ and ‘VeryHugeCase Process’ are examples of this.

The specific data object ‘VeryHugeCase Activity’ contains besides the generic data (which is also present in the ‘Activity’ data object) also the composite specific metrics. These are user defined Business indicators that may be defined in different places. E.g. in the different BPM processes available as Case Activity.

Fact that all Business Indicators are available through only one and the same data object is a very important fact. All activity data of the VeryHugeCase is available through the ‘VeryHugeCase Activity’ data object. Through the ‘Activity’ data object, all generic information is available but not the VeryHugeCase specific business indicators. See figure below. Same goes for the ‘Process’ variant.

But what if we have to deal with the following conditions:

  • The ACM case is very big
  • Different teams develop at the same time on the same case
  • Instances are long running (6 months … 2 years)
  • Released to production every 2 weeks

This situation leads to some issues:

  • Source merge issues
  • Many different versions of the case in production
  • High number of composites (causing slow startup, high memory usage)

Implement Case Activities as ‘external processes’

As a solution to overcome these issues, we have chosen to implement the Case Activities as external processes (outside the case). In the case there is for all Case Activities only a wrapper that calls the external implementation (via an ActivityRouter).

Updated Case

Router (call to external implementation and waiting for reply)

External Case Activity

Final result is a single composite application for the ACM Case and a separate composite for each remote-implemented Case Activity. This solution, however, has also consequences for BAM. There are per composite two data objects in BAM. So now we have in addition to data objects ‘VeryHugeCase Activity’ and ‘VeryHugeCase Process ‘ another 30 new ‘Activity’ data objects and ‘Process’ data objects (we have around 30 BPM processes implemented as Case Activity). In the picture below there are 5 out of the 30.


Each specific data objects, e.g. ‘CaseActivity1 Activity’ contains the generic data (which is also present in the ‘Activity’ data object) and also the composite specific metrics. These are the user defined Business indicators specified in the BPM process of the Case Activity. See figure below. Same goes for the ‘Process’ variant.

But what if some of these specific metrics are only for BAM specific but generic for the implementation. For example, the metric ‘Department’ in each composite. Because it is a specific metric, it is not possible to group/filter in BAM over all activities in the case. This is because BAM objects (such as queries and views) are by default based on a single data object and not on several at once.

Challenge: How can we group/filter in BAM by ‘specific’ metrics that are present in each Composite?

If that is not possible, BAM is not useful for this ACM implementation.
In another post (Impact of ACM Implementation on BAM) I will describe the solutions we have recognised/examined to make Management Information (MI) available to this ACM implementation.


12 thoughts on “Impact of ACM Implementation on BAM

  1. Great blog post. Have been looking into the same things for our live ACM implementation with 30+ case activities. Have you had any success with sub-case type case activities when the number of case activities are growing so large? thanks, Vikram

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s