Moving down the line of SOA patterns that are used in core technology frameworks, we finally come to Business Activity Monitoring; this term was proposed by Gartner during the earlier years of SOA development. Actually, this term has no relation to any recognized SOA pattern (with the exception of UI Mediator, but very remotely), but every Oracle-technology-related book (related or not related to SOA) has a chapter dedicated to BAM.
You can find them a lot in chapter 19 of the book by Lucas Jellema, which has already been recommended. It's quite typical that you will find guidance on BAM somewhere around the final chapters of this book. Quite interestingly, it contradicts the common corporate purchase practice; usually, BAM is purchased first and implemented in the end.
Why is that? It's quite obvious; top managers love the dashboards full of colorful 3D pie charts, but development teams have to go a very long way before something really useful becomes available for visualization, and that has nothing to do with BAM. Those of us who remember the earlier versions of BAM could also be rather hesitant. It was built on the Microsoft platform with lots of bugs and integration problems with core Oracle SOA products, and worked with the IE browser only. It does not always leave happy memories (and we are not discussing the license costs compared to other products here).
Oracle's early BAM problems and dependence on Microsoft have long gone, and now if you are contemplating using a monitoring tool for your SOA/BI portfolio, the Oracle BAM can be a good alternative to Nagios, for instance. Again, as its main purpose is very straightforward, that is, to construct reports and visualize them in a push-based manner (no manual refreshes should be required), it does not provide any pattern as a solution to any problem; however, it is arguably the best candidate to complete the extremely powerful triad:
- Complex Event Processing on Oracle EPN
- Events/message distribution, aggregation, and reliable replication by Oracle Coherence
- Business events' reporting by Oracle BAM
Frankly, if any of your business cases is similar to the banking, logistic, or telecom examples discussed earlier, this triad with all the available patterns will cover most of your needs (or all in our experience). BAM in this case from the earliest 11g build provides a web-based graphical environment for establishing a completely codeless implementation of reports and dashboards to monitor different KPIs, primarily business-related ones. This high usability, together with the fact that there are no complex SOA patterns associated with this product alone, simplifies our task by presenting this functionality in this paragraph, as we do not have room here for providing drag-and-drop cookbook screenshot demonstrations.
If you return to the figure that presents the WLS SOA console in OFM's introductory chapter for a moment, you will see that simplicity starts with the combined installation of SOA Suite, where the BAM server will be installed in one go, with the whole bundle (of course, you can exclude it from the installation).
It runs on its own WebLogic server (in our case, bam_server1 by default), and it is controlled from the same administration console/OFM control in the same way as other servers are controlled. The Oracle BAM server is a collection of the components Oracle BAM Active Data Cache (Oracle BAM ADC), Oracle BAM Report Cache, Oracle BAM Enterprise Message Sources (EMS), and Oracle BAM Event Engine. All BAM object definitions and reports will be stored in the OFM DB repository, created during the installation. As long as object data is involved, we have two sides of BAM connectivity; naturally, it has APIs for data producers (SOAP and RMI) and data consumers, who will use the BAM DB schema, like with ODI. In fact, Oracle Data Integrator can be both; a data provider for reporting and data consumer of BI data.
When you start bam_server and log in to the BAM web application, http://<your_BAM_host>:<your_BAM_port>/OracleBAM/default.htm, you will see four main buttons that lead to the console responsible for all aspects of the BAM dashboard's life cycle. The architect's console is the most interesting to us, as its name denotes. The architect's console is responsible for creating BAM data objects on which all our reports will be based. Every type of BAM and OFM integration will start from this console. Let's quickly walk through the possible BAM integration use cases.
The direct integration of BAM and BPEL is the most common use case and also the most frequently demonstrated one in any SOA/OFM cookbook. It is also the most ineffective rule-breaking implementation as it directly violates the Loose Coupling SOA principle. Let's see why. First, let's look at Chapter 3, Building the Core – Enterprise Business Flows, where we discussed the SCA Service Broker and were particular about declaring a comprehensive process name at the beginning of the BPEL flow. The next step should be to assign the runtime variables, including the process name. If we need to monitor SCA BPEL instances in BAM, it would be best to inject BPEL Sensor (http://docs.oracle.com/cd/E28280_01/dev.1111/e10224/bp_sensors.htm). To complete this part, we need to perform the following steps:
- Check our connection with the BAM server. If we do not have any, it is time to create one: File | New | Connections | BAM Connections.
- Go to the BAM Architect and declare the data object that we need to populate for our report (http://docs.oracle.com/cd/E21764_01/integration.1111/e10224/bam_data_objects.htm). Different types of data objects are explained at http://docs.oracle.com/cd/E25054_01/dev.1111/e10224/bam_adapter.htm#BABHCHCE.
- Back in SCA, in the BPEL structure console, locate the node for sensor variables and create a BAM sensor, give it an appropriate name, and set the target variable.
After this, we are ready to configure the sensor's actions. In the Structure window, select the sensor's actions and create a new one for BAM when the Sensor Action window appears. Then, set the action name and select BAM DO created in the BAM architect, and also provide the operations (Insert) and keys. XSLT mapping is available at this stage for adjusting BPEL action data sources to BAM DO.
Technically speaking, this is it; we are done with the integration. In the next few steps, you will deploy the application, test it, and verify that instances of data objects are pumping into BAM. Finally, in the BAM active studio, you can assemble a beautiful report with a pie chart and everything. The main point here is that we have a direct connection between BPEL and BAM, and although it is perfectly operational, it is not exactly what we want in production, especially for events monitoring.
BAM gives us several other options for data feed, and you can spot some of them right away in the BAM Architect. Before you create a new data object, please look at the drop-down list at the top. In addition to the first option discussed earlier, we have Enterprise Message Sources, External Data Sources, and Alerts. The first one denotes JMS, which is extremely versatile; however, in addition to listening to JMS, we have a synchronous way of getting data to BAM Active Data Cache and BAM Web Services. Thus, we have many ways to get data for dashboards, including a completely vendor-neutral way.
So, how can we set up JMS as a BAM data channel? Before creating any sensor, please proceed to the SOA Domain Admin console and create Connection Factory and a new Queue (BAMSensorQueue) in SOAJMSModule (in WLS Domain Structure, go to Services | Messaging | JMS Modules. Then, create a new JMS System Module Resource, set the JNDI name as jms/BAMConnectionFactory, and so on). To create a new sensor for its actions, set Publish Type as JMS Queue. The steps for creating a sensor variable are similar to the previous example. After deployment and testing using either the SoapUI or EM console, you will find the message in the previously configured JMS. Now, you can return to the BAM Architect and create a new object according to your input (it could be the same as the previous one for test purposes), but now select Enterprise Message Sources from the list on the top. Set the correct values in the EMS section: JMS Message Type as Text, Operation as Insert (actually, you can perform all the CRUD operations on your objects); then, set the JNDI and queue names as you created them in WLS.
For more administrative details that are not part of the SOA patterns, please refer to http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/bam_ent_msg_sources.htm. Here, you will find that Oracle Messaging is supported, and the sources could be JMS providers from IBM, Apache ActiveMQ, and Tibco.
Summarizing all of the preceding points, we can see three main advantages of this connectivity method when compared to the previous one:
- Vendor neutrality (as long as we can use JMS)
- Complete decoupling between the provider and consumer, allowing BAM to balance its processing workload more effectively
- Asynchronous message exchange allows us to use relatively big objects
Advanced XML formatting in EMS will allow you to map virtually any JMS payload to your data object, but here we would like to advise you to avoid excessive transformations and even simplify (flatten or remove the hierarchy) your messages for better performance and reports aggregation. Really, in most of the cases, you need just a bunch of fields to satisfy the imaginative taste of your managers. Surely, you can also log all the failed messages. If an asynchronous exchange pattern is not suitable for your needs, you can employ the WebService API.
BAM provides a set of web services (WS) for a synchronous data feed:
http://host_name:7001/OracleBAMWS/WebServices/DataObjectOperationsByID?WSDLhttp://host_name:7001/OracleBAMWS/Services/DataObject/DataObjectOperations.asmx?WSDLhttp://host_name:7001/OracleBAMWS/WebServices/DataObjectOperationsByName?WSDL
Here, 7001 is a port by default. For testing, you can start with the first one, DataObjectOperationsByID (without WSDL), by opening it in your browser. The rules of invocation are fairly simple, but strict; if you do not want to get 401 or 403 as a response, please follow them and also refer to the documentation:
- The names of elements in your payload that you paste into the XML payload should be exactly as the field of your data object
- The SOAP action can be from basic CRUD (see on the top), but formatted according to the namespace as
http://xmlns.oracle.com/bam/insert - HTTP authentication must be enabled, and you should provide your OFM username/password
Just press invoke, and see what you will get in the BAM Architect in Active Data Cache. You can perform these kinds of tests without a data provider, just by using a WS test page.
Finally, you can refer to the figure from the EDN in SOA the stack – a practitioner's approach section and replace the Event-Driven Business component with BAM, which is connected to EDN using JMS. This will conclude this block diagram evolution and this section.