Fool BAM with database hack

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.

3image1

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).
3image2

And on the database you can see the synonym.
3image3

Then we add the functional generic fields. In this example, this is only done for ‘Department’.
3image4

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.
3image5

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

3image6

The modified view. I have here again used the example in which there are 5 data objects merged.
3image7

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).

 

Advertisements

2 thoughts on “Fool BAM with database hack

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s