Capgemini Oracle Blog

Capgemini Oracle Blog

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Oracle BAM – Look before you leap

One of the lastest blogs about BAM, Enhance your business with Oracle Business Activity Monitoring covered the business side of Oracle BAM, explaining how the Active Studio and Active Viewer work. It shows how easy it is to create reports using out-of-the-box functionality and that you are able to create a live view of what is happening in your organization. In this blog we will cover the data model and Event delivery options. All these nice views would not have been possible without data. This blog will elaborate on getting the data from your environment and feeding it into BAM. Focussing on the data model and why it is important to keep this in mind while setting up your environment.

Your BAM data model
For a technical guy the data model is often the starting point when building an application. But when designing the data model for BAM this is often not in place yet because BAM is new in the organization. Also the data model will probably differ (read: have less tables) from your application data model, since it will mainly store recent instance data.

The “don’ts” Lets start off with some “don’ts” when designing the BAM data model. Keep in mind that BAM is not a replacement for the data warehouse. It does not support snowflake, but only star design schemas. This means you can lookup data from one table to the other, but not further. To keep your solution fast you should only keep recent data and purge or archive data.

The “do’s” Start off by asking the business for the KPI’s of the processes to monitor. This will give you a pretty good idea of on which data and granularity you will need to focus. When you know the KPI’s you also know exactly which data you would need to build up your dashboards. BAM also has the possibility to work with calculated fields, you could use this e.g. to calculate gross income by multiplying “Worked time” * Tariff. When used correctly calculated fields can be very powerful. At start you will not create dashboards to cover every part of the process. But after a few iterations of improving your process, you want to monitor more specific parts. You can save a lot of development time if you have already prepared your BAM data model to support such monitoring. The reason is obvious; the data is already there; you just need to design the right dashboard. And this is something that can be done even by a business user who has some experience in BAM.

Event delivery
As BAM is based on an event driven architecture (EDA), it is dependent on a live stream of events provided by the system(s) you wish to monitor. We need to think of a way to get event data from the system you want to monitor to the BAM datastore. At this stage you have probably already thought of the places in your system where the relevant data can be obtained. It can be a BPEL process, database table, a BPM process, an OSB proxy-service or a combination of any of them. It doesn`t really matter as long as XML messages can be generated containing all relevant event data. We will now have to think of the event message format and a way of getting these events delivered to BAM.

Your event message
Event data must be sent to BAM using (small) XML messages containing the event data so we must think of a XML message structure. The easiest and best way of approaching this is to use the same structure as your BAM data model: simple, flat XML messages with the same attributes as your data objects. BAM does provide XSLT transformation in certain cases (If JMS is your way of transport, see next paragraph) so you could also use other, non-flat XML structures to feed BAM with event data.

Event transport There are several ways of getting the event data from your system into the BAM datastore

  • Web-services - BAM exposes some web-services that enable you to Insert, Update and Delete data in the BAM data objects that we just created in the BAM datastore. These webservices are generic so they don’t need configuration and can be used to update any data object.
  • Oracle BAM Adapter is a JCA adapter available in 11g. It is the recommended way of sending event data from BPEL 11g and other applications certified with this adapter.
  • JMS- last but not least, BAM supports JMS connectivity. It allows for the subscription to any JMS Queue or Topic using the so-called Enterprise Message Source (EMS). As it does require some more configuration (creating JMS queues/connection factories, EMS configuration in BAM) there must be some advantages right? Yes there are. As this is my favorite way of transport, I will elaborate on how cool it is and what advantages it can provide:
  1. Connecting BAM to a JMS queue enables you to perform XSLT transformation of the received XML messages. This enables the processing of more complex, multi-level XML messages. Keep in mind that XSLT transformations require more resources on your BAM server.
  2. JMS enables BAM to process more messages than the previous transport methods. Therefore JMS is recommended for scenarios that produce vast amounts of event messages.
  3. Unlike the first to transport methods (where messages are stored in virtual memory), JMS enables guaranteed delivery of event messages. Therefore JMS is recommended for guaranteed messaging scenarios.
  4. Using the JMS interface in BAM, it is possible to connect to an advanced queue in your Oracle database! This enables you to process event messages created in the database by triggers or any other PL/SQL code. It does require some JMS configuration (a foreign JMS server) on your Weblogic server but if you wish to process database events, this is a nice way of doing it.
  5. Making use of the ‘Message selector’ in BAM, you can tell your Enterprise Message Source (EMS) to filter JMS messages based on (custom) header fields. Without this option your EMS will process ALL messages in a queue and discard of all messages that do not comply with the required message format. So this also means that you are able to process multiple message types (different data objects) from the same JMS queue with multiple EMS`s configured with message selectors. Keep in mind that a Message selector is can be a performance killing for, so for high volume event processing, use a separate JMS queue and a separate EMS in BAM.
Oracle provides us with two applications that could help you fill your BAM datastore:
  • Oracle Data Integrator (ODI) is a separate product in the SOA Suite. It can be used as an additional component to handle more complex data formats or to extract data from any compatible data source and push it to BAM (using JMS or webservice connectivity). ODI can also be used to import/export data or to archive BAM data from your datastore to your data warehouse.
  • BAM I Command is a command line tool that is part of the BAM server installation. It can be used to import and export BAM objects (reports / data objects / etc.) but it can also be used to import data into the datastore. Suitable for manual actions like importing (exported) lookup data into your lookup data objects or for deploying your deployment on other environments. It is not suitable for delivering live event data from the system that you are monitoring
When implementing BAM it is important to think about how you will implement your data model, to save time and effort in future development. For event delivery you have the option to choose from variety of techniques to deliver events to BAM that will enables you to perform Business Activity Monitoring on virtually any system. Again, BAM delivers a Dashboard tool which enables giving insight in data from disparate sources.

Martijn van der Kamp, Oracle developer Jan Willem Pas, Database & Integration specialist

About the author

Léon Smiers

Leave a comment

Your email address will not be published. Required fields are marked *.