Recently I did a POC with BAM 12c at the customer. In a series of post’s I will describe my findings/experiences.
In the first post of this series I described the initial situation (Impact of ACM Implementation on BAM). This post ended up with the following challenge.
We have a ACM Case consisting of about thirty Case Activities. The Case and the individual Case Activities are housed in a private composite (1 + ~30 composites).
Challenge: How can we group/filter in BAM by ‘specific’ metrics that are present in each composite. For example ‘Department’.
In the second post (Filtering/grouping in BAM by ‘specific’ metrics (explored solutions)) I have 10 recognized/examined solutions appointed for this challenge. In this third post one of these solutions (number 9) is further developed.
‘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.’
Create Dummy Data Object
We start by making a ‘dummy’ data object in BAM. This data object is based on the generic activity data object.
By doing this, a new view is created on the database. In the image below you can see that it has the name BEAM_VIEW_116. This is a generated name that may vary per deployments environment. Referencing to this name is not useful. By using user-defined synonyms on the database problems with changing view names can be avoided. By specifing an “Alias” the synonym name of the view can be defined (in the picture below this is DummyWithDepartment).
And on the database you can see the synonym.
Then we add the functional generic fields. In this example, this is only done for ‘Department’.
What has happened on the database ?
On the database there is a view BEAM_VIEW_116 created which all fields of the data object. So all fields of activity Data Object supplemented by the ‘Department’ field.
For each case activity was there a specific view generated that also contains all of these fields (see also the second post).
Now I’m going to adjust the dummy view that it contains/selects the data from all specific views together. The result is a consolidated view of all the necessary data.
The original view
The modified view. I have here again used the example in which there are 5 data objects merged.
BAM has no knowledge that the underlying view is changed, but it will have all the necessary data available. We basically fool BAM a bit.
This solution we have identified as a possible solution. It is tested and works, it’s also discussed with Oracle and recognized as supported implementation (of course, not formally).
But the solution feels somewhat contrived. All views in the consolidated view pick up the data from the same table. Yet it should remain a union over the individual views. This because a specific column in the table can have a different meaning per view. For more details on this see my database post in this series (BAM Database).