Oracle Business Activity Monitoring (BAM) 11g R1 architecture leverages the push-based mechanism to deliver the high volume of data changes to the frontend web browser in real time, which is the key differentiator from other conventional reporting solutions that use the pulling approach for report rendering.
To help you understand the push-based mechanism and BAM Architecture, this chapter first introduces BAM key concepts, which are the prerequisites to learning BAM. We will then discuss an overview of the architecture, and its key server side components. Finally, you will see an explanation of the message flows in typical report opening and data change scenarios, so that you can understand what happens behind the scenes.
In this section, we will give you a brief review of the key concepts, which will help you to gain a better understanding of BAM Architecture, and more advanced topics.
A Data Object is an internal data structure that represents the business data in the BAM server. Like the concept of the database tables, a Data Object has a flat structure, which includes fields with primitive data types, such as string, integer, float, date time, and so on. It can also include calculated fields and lookup fields, which reference to other Data Objects using foreign keys. The Data Object field cannot be defined using complex data types, such as arrays, objects, and so on.
The following screenshot depicts the Employees Data Object layout, which is defined using simple primitive data types, such as string, integer, and timestamp:
 |
Data Objects are managed in the in-memory data cache to meet the needs of high volume data processing, and get persistent in the BAM database schema automatically. In the current release, Oracle BAM supports the following RDBMS as its persistence store: Oracle Database, IBM DB2, and Microsoft SQL server.
More Data Object details will be covered in Chapter 2,Designing your First Data Objects and Reports.
A ViewSet is an object that represents a query to a given Data Object. A ViewSet provides an abstraction layer that decouples the View design and underlying data model, which allows multiple reports to share the same Data Object.
In BAM, a ViewSet is defined using an XML schema, which can contain the following elements:
To understand this concept, let's take a look at an example that represents the query to the Employee Data Object that you saw before.
 |
In this ViewSet definition, the dataset attribute specifies the database table (_Employees) that is used to persist the Data Object (Employee). The DatasetField and AggregateField elements specify the _Sales_Area data field and the aggregate SUM(_Sales_Number) that can be used to construct the query to the _Employees dataset.
ViewSets can also be sorted, filtered, and applied row-level securities. More topics related to ViewSet will be covered in the next chapter.
A View is a rendered result set, which is generated by opening one or a collection of ViewSets. The following is a sample of the 3D bar chart View that shows the number of orders, grouped by its status:
 |
Note
In the current BAM release, a View can only be rendered in the IE browser. The View type specific XSL transformation, which is used to convert report data to DHTML with JavaScript, utilizes proprietary IE features that are not available in other web browsers, such as Firefox, Chrome, and so on.
The list of View types supported in BAM 11g R1 include the following:
You will learn more about these View types in Chapter 4, .
A Snapshot is a query result set created by a ViewSet. When a report is first rendered, a ViewSet is opened to generate the initial result, which is called a Snapshot. The XML representation of the Snapshot is then transformed to DHTML using View-specific XSL, and sent to the client along with JavaScript.
Snapshots are cached in the BAM Server. So, every time the same report is opened in another browser session, the Snapshot will be retrieved, and sent back to the client without generating from scratch, which helps improve the report rendering performance.
Snapshots can be used to generate static Views. To produce dynamic Views, or in other words, to render a report that can reflect the data changes in real time, you will need a push-based mechanism called Active Data, which we will look at next.
Active Data is the continuous stream of changes that the ViewSet can produce. Once a report is first rendered with a Snapshot, any subsequent changes to the Snapshot of the ViewSet will be captured at the server side, and pushed back to the client. This is what we call a push-based mechanism.
A push-based mechanism is an efficient way of delivering real-time notifications to the client. Unlike the polling approach, in which clients need to consistently send requests to the server, Active Data allows the server to send the changed data in an incremental way, instead of transferring all the report data to the client, and thus can provide significant advantages, such as the following:
Leveraging client and server resources more efficiently
Significantly reducing the network traffic
Fast rendering report with Active Data
You will learn more about Active Data and push-based mechanisms in the Understanding message flow section, later in this chapter.
A ChangeList is an Active Data Payload that includes the changes produced by a specific ViewSet.
The ChangeList is in XML format, which normally includes the following:
index:A sequence number of a ChangeList. When a report is first rendered, aViewSetwill be opened with a Snapshot. Any further Data Object changes may trigger a ChangeList generated with incremental index numbers starting from one. The index will increment by one as any new changes come.viewsetID:A unique identifier for a particularViewSet, the index, andviewsetIDtogether identify the ChangeList.Record:An XML element representing a row in the updated query result of aViewSet. ARecordcontains a transaction type(insert, update, upsert, anddelete), Data Object field references, and contents.
Let us look at a ChangeList example, which is produced by a ViewSet of the Employees Data Object.
 |
The key points that you can see from the example are:
The
ChangeListsequence number is identified by theindexattribute value.1means this is the firstChangeListfor theViewSet.The
Fielddefinition andFormattedValueprovide the detailed information for theChangeListcontents.The
xnTypeattribute defined in theRecordelement specifies the transaction type (update) for theRecordof theChangeList. The other possible transaction type values areinsert, upsert, anddelete.
In this section, we will give you a brief review of the key concepts, which will help you to gain a better understanding of BAM Architecture, and more advanced topics.
A Data Object is an internal data structure that represents the business data in the BAM server. Like the concept of the database tables, a Data Object has a flat structure, which includes fields with primitive data types, such as string, integer, float, date time, and so on. It can also include calculated fields and lookup fields, which reference to other Data Objects using foreign keys. The Data Object field cannot be defined using complex data types, such as arrays, objects, and so on.
The following screenshot depicts the Employees Data Object layout, which is defined using simple primitive data types, such as string, integer, and timestamp:
|
Data Objects are managed in the in-memory data cache to meet the needs of high volume data processing, and get persistent in the BAM database schema automatically. In the current release, Oracle BAM supports the following RDBMS as its persistence store: Oracle Database, IBM DB2, and Microsoft SQL server.
More Data Object details will be covered in Chapter 2,Designing your First Data Objects and Reports.
A ViewSet is an object that represents a query to a given Data Object. A ViewSet provides an abstraction layer that decouples the View design and underlying data model, which allows multiple reports to share the same Data Object.
In BAM, a ViewSet is defined using an XML schema, which can contain the following elements:
To understand this concept, let's take a look at an example that represents the query to the Employee Data Object that you saw before.
|
In this ViewSet definition, the dataset attribute specifies the database table (_Employees) that is used to persist the Data Object (Employee). The DatasetField and AggregateField elements specify the _Sales_Area data field and the aggregate SUM(_Sales_Number) that can be used to construct the query to the _Employees dataset.
ViewSets can also be sorted, filtered, and applied row-level securities. More topics related to ViewSet will be covered in the next chapter.
A View is a rendered result set, which is generated by opening one or a collection of ViewSets. The following is a sample of the 3D bar chart View that shows the number of orders, grouped by its status:
|
Note
In the current BAM release, a View can only be rendered in the IE browser. The View type specific XSL transformation, which is used to convert report data to DHTML with JavaScript, utilizes proprietary IE features that are not available in other web browsers, such as Firefox, Chrome, and so on.
The list of View types supported in BAM 11g R1 include the following:
You will learn more about these View types in Chapter 4, .
A Snapshot is a query result set created by a ViewSet. When a report is first rendered, a ViewSet is opened to generate the initial result, which is called a Snapshot. The XML representation of the Snapshot is then transformed to DHTML using View-specific XSL, and sent to the client along with JavaScript.
Snapshots are cached in the BAM Server. So, every time the same report is opened in another browser session, the Snapshot will be retrieved, and sent back to the client without generating from scratch, which helps improve the report rendering performance.
Snapshots can be used to generate static Views. To produce dynamic Views, or in other words, to render a report that can reflect the data changes in real time, you will need a push-based mechanism called Active Data, which we will look at next.
Active Data is the continuous stream of changes that the ViewSet can produce. Once a report is first rendered with a Snapshot, any subsequent changes to the Snapshot of the ViewSet will be captured at the server side, and pushed back to the client. This is what we call a push-based mechanism.
A push-based mechanism is an efficient way of delivering real-time notifications to the client. Unlike the polling approach, in which clients need to consistently send requests to the server, Active Data allows the server to send the changed data in an incremental way, instead of transferring all the report data to the client, and thus can provide significant advantages, such as the following:
Leveraging client and server resources more efficiently
Significantly reducing the network traffic
Fast rendering report with Active Data
You will learn more about Active Data and push-based mechanisms in the Understanding message flow section, later in this chapter.
A ChangeList is an Active Data Payload that includes the changes produced by a specific ViewSet.
The ChangeList is in XML format, which normally includes the following:
index:A sequence number of a ChangeList. When a report is first rendered, aViewSetwill be opened with a Snapshot. Any further Data Object changes may trigger a ChangeList generated with incremental index numbers starting from one. The index will increment by one as any new changes come.viewsetID:A unique identifier for a particularViewSet, the index, andviewsetIDtogether identify the ChangeList.Record:An XML element representing a row in the updated query result of aViewSet. ARecordcontains a transaction type(insert, update, upsert, anddelete), Data Object field references, and contents.
Let us look at a ChangeList example, which is produced by a ViewSet of the Employees Data Object.
|
The key points that you can see from the example are:
The
ChangeListsequence number is identified by theindexattribute value.1means this is the firstChangeListfor theViewSet.The
Fielddefinition andFormattedValueprovide the detailed information for theChangeListcontents.The
xnTypeattribute defined in theRecordelement specifies the transaction type (update) for theRecordof theChangeList. The other possible transaction type values areinsert, upsert, anddelete.
In this section, we will introduce a BAM11gR1 high level architecture, and the overview of its components.
BAM server is a Java EE application deployed to Weblogic Server. As shown in the following diagram, BAM server contains the following components:
Active Data Cache
Messaging Framework
Enterprise Messaging Sources (EMS)
Report Cache
Report Server
Event Engine
BAM Web Applications
BAM Web Services
Among them, Active Data Cache, Report Cache, and Report Server are the major components that are responsible for static and dynamic report rendering.
 |
In this section, you will see an overview of BAM server components, what these server components are, and what services they provide.
Oracle BAM Active Data Cache (ADC) is the key BAM server component and is a high-performance, persistent, and memory-based storage system, designed to support data model management and Active Data processing.
Active Data Cache is the component that receives continuous data streams from various data sources, such as BPEL processes, SOA composites, JMS queues or topics, databases, enterprise information systems, legacy applications, and so on. It also provides the following services, which are explained as follows:
Persistence
Maintaining BAM artifacts
Managing data models
Processing Active Data
Continuous data streams received by BAM are converted to the corresponding data models, which are persistent in the backend repository. BAM 11gR1 supports Oracle, DB2, and Microsoft SQL server as the repository. The repository is created using Repository Creation Utility (RCU) . The usage of RCU is out of the scope of this book, and you can find more information about RCU in the Oracle Fusion Middleware Repository Creation Utility User's Guide 11g Release 1 (11.1.1). Note that documentation link varies on different releases. On 11.1.1.6 release, this document can be accessed at the following URL:
http://docs.oracle.com/cd/E23943_01/doc.1111/e14259/toc.htm.
BAM artifacts are the metadata stored in the repository. Examples of BAM artifacts are Data Objects, reports, users, and roles.
Oracle BAM schema contains a list of tables starting with SysIter, which represent system tables storing the metadata. For example, the SysIterReport table stores Report metadata, such as report definition, the created date, last modified date, and so on.
BAM artifacts are internal concepts and definitions, and it is not recommended to modify these artifacts by directly manipulating system tables. The preferred way of maintaining BAM artifacts is through the appropriate GUI tools provided by BAM.
BAM ADC provides methods for creating, modifying, and deleting BAM Data Objects. It also provides APIs to insert, update, upsert, and delete data into Data Objects.
This is a very important feature provided by ADC, and you will learn how to manage data models in the next chapter.
Note
APIs used to manage data models are exposed by Session EJB, called BamServerBean. These APIs are used internally by BAM web applications, such as Architect, other BAM server components, and BAM sensors and adapters. When attempting to feed live data into BAM, data is passed through existing channels, such as BAM adapter, BAM web service interface, ODI, or Enterprise Message Sources, which in turn call BamServerBean APIs.
Messaging framework is a common messaging layer that provides producing and consuming message services, which are used by other BAM server components.
As shown in the architecture diagram, the Messaging Framework provides a messaging backbone that allows different server components to communicate with each other in an asynchronous way. For example, when Active Data are pushed from ADC to other components, it will be sent to an internal queue through the Messaging Framework.
While understanding this concept will help you troubleshoot messaging related issues, you will not directly use Messaging Framework APIs when building your BAM applications. You will learn more about the Messaging Framework in Chapter 3,Populating Data Objects with Real-time Data.
Enterprise Message Sources (EMS) provides direct Java Message Service (JMS) connectivity to Oracle BAM server, by mapping messages directly to Oracle BAM Data Objects. Oracle BAM server can read data directly from any JMS-based message queue or topic through the Messaging Framework.
EMS allows mapping from an XML message directly to a Data Object on Oracle BAM server, however, you may use XSL transformations before the data is inserted, updated, upserted, or deleted into the Data Object. Each EMS consumes messages from a specific JMS topic or a queue, and the information is delivered into a Data Object in Oracle BAM ADC.
The Oracle BAM Architect web application is used to configure EMS definitions. You will learn more about EMS in Chapter 3.
Oracle BAM Report Cache off-loads the burden of maintaining the ViewSet Snapshot in memory from Oracle BAM Active Data Cache. Report Cache opens ViewSets, and caches the Snapshot and the ChangeList before sending it to the Report Server. This allows for random access into the Snapshot, and recovery from losing Internet connectivity.
Report Cache also allows for the Oracle BAM Report Server to be stateless.
The Event Engine monitors complex data conditions, and implements user-defined rules. The Event Engine continuously monitors the information in the ADC for certain conditions, and executes the related actions defined in associated rules. It takes a variety of actions in response to those changes, including notifying the appropriate user with an alert and/or report(s).
Oracle BAM Report Server renders static and active reports. It also manages persistent connections between the web browser clients and BAM server.
Oracle BAM Report Server applies the report definitions to the data sets retrieved from the Oracle BAM Report Cache for presentation in a browser. It manages information paging for viewing and printing reports.
Oracle BAM web applications are a set of web-based interfaces for building and managing data models, creating Views and reports, viewing reports, and performing administrative tasks. The BAM web applications include the following:
Note
From the perspective of the user's experience, BAM 11g web applications remain the same as those of BAM 10g, except for the Administrator web application, in which you can only view BAM users and roles in BAM 11gR1. The reason is that BAM 11gR1 dedicates the user management to the WebLogic server console, and the role management to Oracle enterprise manager fusion middleware control. Thus, the Administrator web application only provides a read-only view of the existing users and roles. You will learn more about BAM Securities in Chapter 6,Managing BAM Securities.
In this section, we will dive into the BAM server components to help you to understand what happens behind the scenes in the following scenarios:
Opening a report for the first time
Processing Active Data
This is the scenario when a user attempts to open a report for the first time.
 |
This diagram depicts the message flow, which can be interpreted as follows:
1. The client sends an HTTP request containing report definition ID and a list of parameters to the Report Server. An example request is something like:
http://<bam_server_hostname>:<port>/OracleBAM/reportserver/default.jsp?Event=viewReport&ReportDef=58&Buttons=False&ReportParameters=()
In this URL, <bam_server_hostname> is the BAM server hostname, ReportDef is a parameter that specifies the report ID, and ReportParameters is an HTTP request parameter that specifies report parameters.
2. The Report Server processes the request, then invokes the Report Cache method to open a ViewSet.
3. Since this is the first time a ViewSet is opened, the Report Cache invokes Active Data Cache APIs to create a ViewSet.
4. The Active Data Cache instantiates the ViewSet, and registers it as a listener to the associated Data Object Notification Queue.
5. The Active Data Cache builds and executes SQL queries, and returns the initial result set (Snapshot) to the Report Cache.
6. The Report Cache saves the opened Viewset and associated Snapshot in the cache, and then passes the ViewSet and Snapshot to the Report Server.
7. The Report Server transforms the Snapshot to DHTML, using View specific XSL, and sends it to the client along with JavaScript for rendering.
8. After the initial View is rendered successfully in the web browser, the View generates a
getChangeList()request, and sends it through HTTP POST to Report Server ActiveDataServlet.
Note
Why does the client send a separate HTTP request to BAM Report Server after a View is rendered for the first time?
BAM report leverages a push-based mechanism to receive Active Data in real time. After a report is first rendered in a web browser, it has to find out a way to register the View to the Report Server, which maintains persistent connections between the client and BAM Server. Sending the getChangeList() request to ActiveDataServlet creates the persistent connection through which the Active Data changes are pushed.
Up to now, we have mentioned many times that BAM server uses the push-based mechanism to process Active Data. In this section, we will use a diagram to illustrate how Active Data are processed by BAM server components:
 |
As shown in this diagram, Active Data processing message flows are as follows:
1. The Active Data Cache receives a data change Event (Insert, Update, Upsert, and Delete) that happens to one of its managed Data Objects.
2. The Active Data Cache persists the change to the repository, and raises an Event to notify the changes to ViewSet, which is listening on particular Events in the notification queue.
3. The Active Data Cache calculates how the change is affecting the specific continuous query that it is running for the user, and in the end, it will generate a ChangeList, and push it through the Messaging Framework for asynchronous delivery.
4. The Report Cache gets notified when the ChangeList arrives, consumes the XML payload through the Messaging Framework, and saves it into its internal cache.
5. The Report Cache pushes the ChangeList to the Report Cache Channel, which is an internal or JMS topic.
6. The Report Server receives the ChangeList from the Report Cache Channel.
7. The Report Server sends the ChangeList to the client through the persistent connection established by
ActiveDataServletthat you saw before.8. Client side JavaScript receives the
ChangeList, and then updates the Views opened in the browser to reflect the changes in real time.
In this chapter, we covered BAM key concepts, the architecture overview, BAM server components, and most importantly, the message flows that happen, given two typical scenarios in BAM.
In the next chapter, we will dive into Active Data Cache, discuss more Data Object related concepts, and provide instructions and best practices for building, extending, and managing Data Objects.
