Filtering/grouping in BAM by ‘specific’ metrics (explored solutions)

Recently I did a POC with BAM 12c at the customer. In a series of post’s I will describe my findings/experiences.
In a previous post I described the initial situation (Impact of ACM Implementation on BAM). That post ended up with the following problem description.

Problem description

We have a ACM case consisting of about thirty Case Activities. The Case and the individual Case Activities are housed in a private (1 + ~30 composites).

Challenge: How can we group/filter in BAM by ‘specific’ metrics that are present in each composite. For example ‘Department’.

In this post I will describe solutions we have recognised/examined to make Management Information (MI) available for this ACM implementation. 

Starting situation

There are per composite two data objects in BAM:

  1. Activity data for the specific BPM process
  2. Process data for the specific BPM process

Each of these data objects is associated to a personal database view. Actually, under the hood all these views get their data from the same database tables. More details about this will follow in a separate post (BAM Database). See figure below. Same goes for the ‘Process’ variant.


The views contain a subset of the rows and columns in the table.

  1. the rows of a BPM process
  2. Number of default columns that are the same for each process (generic part of e.g. BEAM_VIEW_116, BEAM_VIEW_11)
  3. Number of specific columns for the relevant BPM process (indicators) (specific part of e.g. BEAM_VIEW_116)
  4. Table where data is stored (e.g. BEAM_FLEX_11)

There are also two generic data objects that are not related to a specific composite but cover all composites. These data objects do not contain the specific business indicators. These data objects are also associated to database views (e.g. BEAM_VIEW_11). ‘Activity’ in the above image is one of them. The ‘Process’ variant is the other.

Getting back to our challenge: How can we group/filter in BAM by ‘specific’ metrics that are present in each composite. For example ‘ Department ‘. Derived from this challenge we had the following requirement.

We need one single view that contains the generic and specific data of all composites.

To fulfil this requirement the generic ‘Activity’ and ‘Process’ view should be extended with a number of specific columns that are part of every composites (for us these are functional generic’). But this is not default BAM functionality.

We now have the following options:

  1. Change requirements so they fit the out-of-the-box functionality.
  2. Figure out how the requirements can be implemented on a non-default way.

The following is a further development of these options.

Change requirements so they fit the out-of-the-box functionality.

Desired entry is a consolidated view over all related processes. An alternative is an entry per process. Not one consolidated view. This is a question for the business. Getting an answer is out of scope for this post.

Figure out how the requirements can be implemented on a non default way.

Below I have described the examined solutions, their results and an assessment of the usability/feasibility.

  1. Extend the generic ‘Activity’ and ‘Process’ view with ‘specific’ columns (functional ‘generic’) that are part of every composites.
    a) This means, the activity view of a specific BPM process must be joined with the generic view. The indicators (e.g. 4) can then be added to the data object. This must be repeated for each BPM process. Result: 1 join for the case. 30 joines for the BPM processes.  4 x 31 = 124 indicator datafields.
    b) the corresponding indicators should then be merged into one overall indicator. Merge 31 indicators to 1, resulting in 4 merged indicators.
    More details about Data Objects can be found in a separate post (BAM Data Objecten).
    We have to go through these steps every time a new BPM process or indicator is added. But this causes that all hit BAM components also have to be compiled again (resave) because otherwise they will become invalid. Resulting in the situation that on runtime they still use the old definitions (queries, views, dashboards, etc.).
    Conclusion: this is not maintainable.

  1. As an alternative to repeating all these steps over and over again is the ability to join the views outside BAM. This by creating a view on the database in which all the above steps happen. If it would be possible to use this view in BAM maintainability would greatly improve. Within BAM, there are 2 possible ways to use this view.
    a) External FACT Data Object –> link to the database view
    b) External DIM Data Object–> underwater a Simple Data Object. –> this is a link to a table whose contents should be maintained separately.
    Because DIM objects not refers to the database view this is not an option, making FACT objects remaining. FACT, however, is not an option because it is not possible to join them with BAM Data Objects (part of step a in solution 1, BAM Data Objecten).
    Conclusion: this is not possible.

  1. An even more far-reaching alternative than is to do the joining also outside BAM. In this case, the above mentioned view is even more extensive in BAM and used as External FACT Data Object (join is no longer required, making this become usable).
    The BEAM tables and BEAM views are dynamically created and may have different names per environment. These varying names makes them unsuitable to be used in joins. Using synonyms solves this issue. (BAM Database, BAM Data Objecten).
    Conclusion: seems to be a viable alternative. Impact is quite limited.

  1. An alternative similar to 3 is to join within BAM. It is not possible to do this on Data Object level, but it is possible to do on Query level.
    Down side is that it is no longer possible to use calculated fields because these are defined on Data Object level. Therefore they must also be part of the view (BAM Queries). Another, and more important, disadvantage is that views that are based on this custom queries do not allow to jump to the details. While this is one of the functional requirements (not mentioned before). The next disadvantage is that ‘Parameters’ are associated with a Data Object. Can’t link them to a view. So using the data with parameters is not possible if the join happened on Query level (BAM Parameters).
    Conclusion: this is not possible.

  1. Alternative: aggregating on BPM level. Model BPM in a way that the aggregated data is all available via the same generated Data Object in BAM. E.g. a new BPM process that records all indicators of all individual BPM processes (via event’s, …?). What options are there?
    Conclusion: seems to be a viable, but contrived alternative. Impact is quite large. We have not further investigated this.

  1. Alternative: use Oracle BI instead of BAM. I personally am not in favour of integrating BI and BAM. Products serve a different purpose.
    Conclusion: as a (temporary) workaround it is a viable alternative but specific BAM functionality, such as active data, is unavailable.

  1. Alternative: use ADF instead of BAM. This solution offers a lot of freedom, but results in a fully custom solution. Functionality that BAM offers out-of-to-box must be built. Issues around the usage of iframes plays no longer (we prefer not to use iframe).
    Conclusion: seems to be a viable alternative. But is not further investigated. Impact is quite large.

  1. Alternative: use another tool instead of BAM. This alternative has not been studied.
    Conclusie: out of scope.

  1. Use of a dummy Data Object based on the generic format supplemented by the generic custom indicators. This for both activity and process data. Customizing the generated dummy view on the database by merging the various generated views we more or less fool BAM. I will describe this solution in a separate post (Fool BAM with database hack).
    Conclusion: seems to be a viable alternative. Impact is quite limited.

  2. Use Enterprise Message Sources (EMS) for direct Java Message Service (JMS) connectivity to the Oracle BAM Server. In this way, all data can be made available through one data object (just like intented in solution 5). I will describe this solution in a separate post (Populating BAM using JMS).
    Conclusion: seems to be a viable alternative. Impact is quite limited.

Final conclusion: there are several solutions available for our challenge. When using BAM, solution 9 and 10 we do like the most. Both are not too difficult to implement and maintain. And also both are recognized as supported implementation by Oracle.


5 thoughts on “Filtering/grouping in BAM by ‘specific’ metrics (explored solutions)

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