BAM architecture

It may seem odd to have a section on architecture in the middle of a chapter about how to effectively use BAM, but the key to successfully utilizing BAM is an understanding of how the different tiers relate to each other.

Logical view

The preceding diagram represents a logical view of how BAM operates. Events are acquired from one or more sources through event acquisition and then normalized, correlated, and stored in event storage (generally a memory area in BAM that is backed up to the disk). The report cache generates reports based on events in storage and then delivers those reports, together with real-time updates through the report delivery layer. Event processing is also performed on events in storage, and when defined conditions are met, alerts will be delivered through the alert delivery service.

Physical view

To understand the physical view of the architecture of BAM better, we have divided this section into four parts.

Acquire

This logical view maps onto the physical BAM components, as shown in the following diagram. Data acquisition in the SOA Suite is primarily handled by a BAM Adapter. BAM can also receive events from JMS message queues. BAM exposes a web service interface to allow any web service-capable application to act as an event source. Finally, there is an Oracle Data Integrator (ODI) knowledge module that can be used to feed BAM. BAM has the ability to query data in databases (useful for historical comparison and reference data) but does not detect changes in that data. For complex data formats, such as master details record relationships or for other data sources, using the ODI Knowledge Module in conjunction with Oracle Data Integrator is recommended by Oracle.

As an alternative to using ODI, it is possible to use adapters to acquire data from multiple sources and feed it into BAM through SCA Assemblies or OSB. This is more work for the developer, but it avoids an investment in ODI if it is not used elsewhere in the business.

For high volume, real-time data capture, Oracle provides a Complex Event Processing Engine (CEP) that can batch events before forwarding them to BAM. This reduces the number of calls into BAM, allowing it to scale better.

Finally, it is possible to send messages straight from applications into BAM using a JMS queue or direct web service call. This, however, tightly couples the application and BAM and generally requires reworking the application to support BAM. Using the middleware approaches, which were shown earlier, allows us to avoid this coupling.

At the data capture level, we need to think of the data items that we can provide to feed the reports and alerts that we desire to generate. We must also consider the sources of that data and the best way to load it into BAM. If all the data we require passes through the composite engine, then we can use the BAM adapter within SOA Suite to capture our BAM data. If there is some data that is not visible through the composites, then we need to consider the other mechanisms discussed earlier, such as using ODI, creating new composites to capture the data, or directly wiring the sources of the data to BAM.

Store

Once the data is captured, it is stored in a normalized form in memory in a component called the Active Data Cache (ADC). This storage facility has the ability to do simple correlation based on fields within the data, and multiple data items received from the acquisition layer may update just a single object in the data cache. For example, the state of a given BPEL process instance may be represented by a single object in the ADC and all updates to that process state will just update that single data item, rather than creating multiple data items. The ADC contents are also stored in the BAM data store to avoid losing data across restarts and to avoid running out of memory.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Logical view

The preceding diagram represents a logical view of how BAM operates. Events are acquired from one or more sources through event acquisition and then normalized, correlated, and stored in event storage (generally a memory area in BAM that is backed up to the disk). The report cache generates reports based on events in storage and then delivers those reports, together with real-time updates through the report delivery layer. Event processing is also performed on events in storage, and when defined conditions are met, alerts will be delivered through the alert delivery service.

Physical view

To understand the physical view of the architecture of BAM better, we have divided this section into four parts.

Acquire

This logical view maps onto the physical BAM components, as shown in the following diagram. Data acquisition in the SOA Suite is primarily handled by a BAM Adapter. BAM can also receive events from JMS message queues. BAM exposes a web service interface to allow any web service-capable application to act as an event source. Finally, there is an Oracle Data Integrator (ODI) knowledge module that can be used to feed BAM. BAM has the ability to query data in databases (useful for historical comparison and reference data) but does not detect changes in that data. For complex data formats, such as master details record relationships or for other data sources, using the ODI Knowledge Module in conjunction with Oracle Data Integrator is recommended by Oracle.

As an alternative to using ODI, it is possible to use adapters to acquire data from multiple sources and feed it into BAM through SCA Assemblies or OSB. This is more work for the developer, but it avoids an investment in ODI if it is not used elsewhere in the business.

For high volume, real-time data capture, Oracle provides a Complex Event Processing Engine (CEP) that can batch events before forwarding them to BAM. This reduces the number of calls into BAM, allowing it to scale better.

Finally, it is possible to send messages straight from applications into BAM using a JMS queue or direct web service call. This, however, tightly couples the application and BAM and generally requires reworking the application to support BAM. Using the middleware approaches, which were shown earlier, allows us to avoid this coupling.

At the data capture level, we need to think of the data items that we can provide to feed the reports and alerts that we desire to generate. We must also consider the sources of that data and the best way to load it into BAM. If all the data we require passes through the composite engine, then we can use the BAM adapter within SOA Suite to capture our BAM data. If there is some data that is not visible through the composites, then we need to consider the other mechanisms discussed earlier, such as using ODI, creating new composites to capture the data, or directly wiring the sources of the data to BAM.

Store

Once the data is captured, it is stored in a normalized form in memory in a component called the Active Data Cache (ADC). This storage facility has the ability to do simple correlation based on fields within the data, and multiple data items received from the acquisition layer may update just a single object in the data cache. For example, the state of a given BPEL process instance may be represented by a single object in the ADC and all updates to that process state will just update that single data item, rather than creating multiple data items. The ADC contents are also stored in the BAM data store to avoid losing data across restarts and to avoid running out of memory.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Physical view

To understand the physical view of the architecture of BAM better, we have divided this section into four parts.

Acquire

This logical view maps onto the physical BAM components, as shown in the following diagram. Data acquisition in the SOA Suite is primarily handled by a BAM Adapter. BAM can also receive events from JMS message queues. BAM exposes a web service interface to allow any web service-capable application to act as an event source. Finally, there is an Oracle Data Integrator (ODI) knowledge module that can be used to feed BAM. BAM has the ability to query data in databases (useful for historical comparison and reference data) but does not detect changes in that data. For complex data formats, such as master details record relationships or for other data sources, using the ODI Knowledge Module in conjunction with Oracle Data Integrator is recommended by Oracle.

As an alternative to using ODI, it is possible to use adapters to acquire data from multiple sources and feed it into BAM through SCA Assemblies or OSB. This is more work for the developer, but it avoids an investment in ODI if it is not used elsewhere in the business.

For high volume, real-time data capture, Oracle provides a Complex Event Processing Engine (CEP) that can batch events before forwarding them to BAM. This reduces the number of calls into BAM, allowing it to scale better.

Finally, it is possible to send messages straight from applications into BAM using a JMS queue or direct web service call. This, however, tightly couples the application and BAM and generally requires reworking the application to support BAM. Using the middleware approaches, which were shown earlier, allows us to avoid this coupling.

At the data capture level, we need to think of the data items that we can provide to feed the reports and alerts that we desire to generate. We must also consider the sources of that data and the best way to load it into BAM. If all the data we require passes through the composite engine, then we can use the BAM adapter within SOA Suite to capture our BAM data. If there is some data that is not visible through the composites, then we need to consider the other mechanisms discussed earlier, such as using ODI, creating new composites to capture the data, or directly wiring the sources of the data to BAM.

Store

Once the data is captured, it is stored in a normalized form in memory in a component called the Active Data Cache (ADC). This storage facility has the ability to do simple correlation based on fields within the data, and multiple data items received from the acquisition layer may update just a single object in the data cache. For example, the state of a given BPEL process instance may be represented by a single object in the ADC and all updates to that process state will just update that single data item, rather than creating multiple data items. The ADC contents are also stored in the BAM data store to avoid losing data across restarts and to avoid running out of memory.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Acquire

This logical view maps onto the physical BAM components, as shown in the following diagram. Data acquisition in the SOA Suite is primarily handled by a BAM Adapter. BAM can also receive events from JMS message queues. BAM exposes a web service interface to allow any web service-capable application to act as an event source. Finally, there is an Oracle Data Integrator (ODI) knowledge module that can be used to feed BAM. BAM has the ability to query data in databases (useful for historical comparison and reference data) but does not detect changes in that data. For complex data formats, such as master details record relationships or for other data sources, using the ODI Knowledge Module in conjunction with Oracle Data Integrator is recommended by Oracle.

As an alternative to using ODI, it is possible to use adapters to acquire data from multiple sources and feed it into BAM through SCA Assemblies or OSB. This is more work for the developer, but it avoids an investment in ODI if it is not used elsewhere in the business.

For high volume, real-time data capture, Oracle provides a Complex Event Processing Engine (CEP) that can batch events before forwarding them to BAM. This reduces the number of calls into BAM, allowing it to scale better.

Finally, it is possible to send messages straight from applications into BAM using a JMS queue or direct web service call. This, however, tightly couples the application and BAM and generally requires reworking the application to support BAM. Using the middleware approaches, which were shown earlier, allows us to avoid this coupling.

At the data capture level, we need to think of the data items that we can provide to feed the reports and alerts that we desire to generate. We must also consider the sources of that data and the best way to load it into BAM. If all the data we require passes through the composite engine, then we can use the BAM adapter within SOA Suite to capture our BAM data. If there is some data that is not visible through the composites, then we need to consider the other mechanisms discussed earlier, such as using ODI, creating new composites to capture the data, or directly wiring the sources of the data to BAM.

Store

Once the data is captured, it is stored in a normalized form in memory in a component called the Active Data Cache (ADC). This storage facility has the ability to do simple correlation based on fields within the data, and multiple data items received from the acquisition layer may update just a single object in the data cache. For example, the state of a given BPEL process instance may be represented by a single object in the ADC and all updates to that process state will just update that single data item, rather than creating multiple data items. The ADC contents are also stored in the BAM data store to avoid losing data across restarts and to avoid running out of memory.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Store

Once the data is captured, it is stored in a normalized form in memory in a component called the Active Data Cache (ADC). This storage facility has the ability to do simple correlation based on fields within the data, and multiple data items received from the acquisition layer may update just a single object in the data cache. For example, the state of a given BPEL process instance may be represented by a single object in the ADC and all updates to that process state will just update that single data item, rather than creating multiple data items. The ADC contents are also stored in the BAM data store to avoid losing data across restarts and to avoid running out of memory.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Process

Reports are run-based on user demand. Once a report is run, it will update the user's screen on a real-time basis. Where multiple users are accessing the same report, only one instance of the report is maintained by the report server. As events are captured and stored in real-time, the report engine will continuously monitor them for any changes that need to be made to the reports that are currently active. When changes are detected that impact active reports, the appropriate report will be updated in memory and the updates are sent to the user's screen.

In addition to the event processing required to correctly insert and update items in the ADC, there is also a requirement to monitor items in the ADC for events that require some sort of action to be taken. This is the job of the event processor. This will monitor data in the ADC to see if registered thresholds on values have been exceeded or if certain timeouts have expired. The event processor will often need to perform calculations across multiple data items to do this.

This monitoring of events in the event processor is accomplished through BAM rules, which are used to trigger BAM alerts. A BAM rule may be to monitor the percentage of aborted sales processes in the last 30 minutes and to raise an alert when the percentage exceeds a threshold value.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Deliver

Delivery of reports takes place in two ways. First, users can view reports on their desktop by selecting views within BAM. These reports are delivered as HTML pages within a browser and are updated whenever the underlying data used in the report changes. The other approach is that reports are sent out as a result of alerts being raised by the Event Processing Engine. In this latter case, the report may be delivered by e-mail, SMS, or voice messaging using the notifications service. A final option available for these alerts is to invoke a web service to take some sort of automated action.

Tip

Closing the Loop

While monitoring what is happening is all very laudable, it is only beneficial if we actually do something about what we are monitoring. BAM not only provides the real-time monitoring ability very well, but it also provides the facility to invoke other services to respond to undesirable events such as stock outs. The ability to invoke external services is crucial to the concept of a closed loop control environment where, as a result of monitoring, we are able to reach back into the processes and either alter their execution or start new ones. For example, when a stock out or low stock event is raised, rather than just notifying a manager about the stock out, the message centre could invoke a web service requesting a supplier to send more stock to replenish inventory. Placing this kind of feedback mechanism in BAM allows us trigger events across multiple applications and locations in a way that may not be possible within a single application or process, because they do not have sufficient visibility. For example, in response to a stock out, we may be monitoring stock levels in independent systems, and based on stock levels elsewhere, may redirect stock from one location to another rather than requesting our supplier to provide more stock. By invoking web services, we avoid the need for manual intervention in responding to these alerts.

Another way of accessing BAM reports is through Application Development Framework (ADF is Oracle's UI development framework) BAM data controls. These controls can be used on ADF pages to provide custom applications and portals with access to BAM data. These controls will update in real-time on a user desktop in the same way as reports retrieved directly from BAM.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Steps in using BAM

The following steps are used in creating BAM reports:

Decide what reports are desired
Decide what data is required to provide those reports
Define suitable data objects
Capture events to populate the data objects
Create reports from the data objects

The first two steps are paper-based exercises to define the requirements. The remaining steps are the creation of suitable artifacts in BAM to support the desired business reports, defined in step 1.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

User interface

Development in Oracle BAM is done through a web-based user interface.

This user interface gives access to four different applications that allow you to interact with different parts of BAM:

Active Viewer: For giving access to reports, this relates to the deliver stage for user-requested reports.
Active Studio: For building reports, this relates to the 'process' stage for creating reports.
Architect: For setting up both inbound and outbound events. Data elements are defined here, as are data sources. Alerts are also configured here. This covers setting up acquire and store stages as well as the deliver stage for alerts.
Administrator: For managing users and roles as well as defining the types of message sources.

We will not examine the applications individually, but we will take a task-focused look at how to use them as a part of providing some specific reports.

Monitoring process state

Now that we have examined how BAM is constructed, let us use this knowledge to construct some simple dashboards that track the state of a business process. We will create a simple version of an auction process. The process is shown as follows:

An auction is started, then bids are placed until the time runs out, at which point, the auction is completed. This is modeled in BPEL. This process has three distinct states. They are as follows:

Started
Bid received
Completed

Defining reports and data required

We are interested in the number of auctions in each state as well as the total value of auctions in progress. This leads us to the following reporting requirements:

Display current number of auctions in each state
Display value of all auctions in each state
Allow filtering of reports by bidder and seller
Allow filtering of reports by auction end date

These reports will require the following data:

Auction identifier, so that we can correlate status changes back to a particular auction
Auction state, so that we can track the number of auctions in each state
Current highest bid, so that we can calculate the worth of all auctions
Current highest bidder, so that we can filter reports by a particular bidder
Seller, so that we can filter reports by a particular seller
Auction end date, so that we can filter auctions by completion date

Having completed our analysis, we can proceed to define our data objects, capture events, and build our reports.

We will follow a middle-out approach to building our dashboard. We will take the following steps:

Define our data within the Active Data Cache
Create sensors in BPEL and map to data in the ADC
Create suitable reports
Run the reports

Defining data objects

Data in BAM is stored in data objects. Individual data objects contain the information that is reported in BAM dashboards and may be updated by multiple events. Generally, BAM will report against aggregations of objects, but there is also the ability for reports to drill down into individual data objects.

Before defining our data objects, let's group them into an auction folder so that they are easy to find. To do this, we use the BAM Architect application, and select Data Objects, which gives us the following screenshot:

We select Create subfolder to create the folder and give it a name (Auction).

We then click on Create folder to actually create the folder, and we get a confirmation message to tell us that it has been created. Notice that once created, the folder also appears in the Folders window on the left-hand side of the screen.

Now that we have our folder, we can create a data object. Again, we select Data Objects from the drop-down list. To define the data objects that are to be stored in our Active Data Cache, we open the Auction folder, if it is not already open, and select Create Data Object. If we don't select the Auction folder, then we pick it later when filling in the details of the data object.

We need to give our object a unique name within the folder and optionally provide it with a tip text that helps explain what the object does when the mouse is moved over it in object listings. Having named our object, we can now create the data fields by selecting Add a field. When adding fields, we need to provide a name and type as well as indicating if they must contain data; the default Nullable does not require a field to be populated. We may also optionally indicate if a field should be publically available for display and whether it should have any tool tip text.

Once all the data fields have been defined, we can click Create Data Object to actually create the object as we have defined it. We are then presented with a confirmation screen that the object has been created.

Tip

Grouping data into hierarchies

When creating a data object, it is possible to specify "Dimensions" for the object. A dimension is based on one or more fields within the object. A given field can only participate in one dimension. This gives the ability to automatically group the object by the fields in the given dimension. If multiple fields are selected for a single dimension, then they can be layered into a hierarchy; for example, to allow analysis by country, region, and city. In this case, all three elements would be selected into a single dimension, perhaps called geography. Within geography, a hierarchy could be set up with country at the top, region next, and finally city at the bottom, allowing drill down to occur in views. Just as a data object can have multiple dimensions, a dimension can also have multiple hierarchies.

A digression on populating data object fields

In the previous discussion, we mentioned the Nullable attribute that can be attached to fields. This is very important as we do not expect to populate all or even most of the fields in a data object one at a time. Failing to initialize a field will generate an error unless it is Nullable. Do not confuse data objects with the low-level events that are used to populate them. Data objects in BAM do not have a one-to-one correspondence with the low-level events that populate them. In our auction example, there will be just one auction object for every auction. However, there will be at least two, and usually more, messages for every auction; one message for the auction starting, another for the auction completing, and additional messages for each bid received. These messages will all populate, or in some cases overwrite, different parts of the auction data object. The table shows how the three messages populate different parts of the data object.

Message	Auction ID	State	Highest Bid	Reserve	Expires	Seller	Highest Bidder
Auction Started	Inserted	Inserted	Inserted	Inserted	Inserted	Inserted
Bid Received		Updated	Updated				Updated
Auction Finished		Updated

Instrumenting BPEL and SCA

Having defined the data we wish to capture in BAM, we now need to make our auction process generate appropriate events. We can instrument BPEL and SCA by making explicit calls to a BAM adapter as we would to any other adapter. Within BPEL, we may also take advantage of the sensor framework to raise BAM events from within an activity.

Tip

Sensors versus explicit calls

Explicit calls are available within both SCA and BPEL. Within BPEL, they make it more obvious where the BAM events are being generated. BPEL sensors, however, provide the ability to generate events at a finer grained level than explicit calls. For example, a BAM sensor in a BPEL activity could be set to fire not just on activation and completion (which could be captured by an explicit call just before and after the event), but also on events that are harder to catch with an explicit invoke, such as faults and compensation. Finally, sensors can fire on retry events that are impossible to capture in any other way. BAM sensors do not use partner links or references, but refer to the adapter JNDI location directly.

Sensors are not part of the normal BPEL executable flow. They can be thought of as event generators. They are attached to almost any kind of activity in BPEL, including partner link operations (invoke, receive, reply) and assigns. They can also be attached to variables and will fire whenever the variable is modified.

Invoking the BAM adapter as a regular service

When using the BAM adapter, we first need to configure an adapter instance.

Creating a BAM adapter

Let us start by creating a new BAM adapter. We begin by creating a new BAM Connection from the Connection section of the New Gallery (File | New, and then select Connection under General).

We provide a name for the connection and identify if we wish it to be local to this application or available to all applications. We then define the connection characteristics of hostnames and port numbers for the Active Data Cache (BAM Server Host) and web applications (Web Server). Generally, these will be the same hostname and port number. We also provide a username and password for the BAM server. Finally, we can test our connection to ensure that it works.

Having created our connection, we can now create a BAM partner link for use in BPEL or SCA. We do this in the same way as we create any other adapter-based link. We can drag a BAM Adapter from the Service Adapters section of the Component Palette onto either the External References section of an SCA or the Partner Links section of a BPEL process. This will launch the Adapter Configuration Wizard. After providing a name for our service, we are asked to select a BAM Data Object and determine the Operation to perform on the object. We must also provide an Operation Name and determine the batching behavior.

The Data Object may be selected directly from the BAM server by using the Browse… button to pop up the BAM Data Object Chooser dialog box, which allows selection of the correct data object.

Depending on the operation, we may need to provide a key to locate the correct data object instance. Update, Upsert, and Delete all require a key, only Insert does not.

Tip

Upsert the universal update mechanism

When using upsert, if the key already exists then that object is updated. If the object does not exist, then it is inserted. This enables upsert to cover both insert and update operations and is generally the most useful operation to perform on BAM objects, as it requires only one BAM adapter instance to provide two different operations.

Having identified the update characteristics of our adapter, we now must map it onto a resource in the underlying application server by providing the JNDI location of the BAM connection. Once this is completed, we can complete the wizard and finish creating our BAM adapter.

Invoking the BAM adapter

Invoking the BAM adapter is the same as invoking any other adapter from BPEL or the Mediator. The BAM adapter provides an interface to allow a collection of data objects to be submitted at the same time, each field in the data object is represented by an XML element in the interface to the adapter. XSLT or copy operations may be used to populate the fields of the input variable.

Invoking the BAM adapter through BPEL sensors

In this section, we will examine how to use BPEL sensors to invoke the BAM adapter.

Within JDeveloper, there are several modes in which we can view the BPEL process. On the right-hand side of the title bar for the BPEL editor, there is a drop-down list that allows us to select the viewing and editing mode.

The drop-down list shows us the three modes available:

BPEL: Lets us edit and view the BPEL activities
Monitor: Lets us edit and view sensor annotations to the BPEL process
BPA: Is only used with the Oracle BPA suite.

After choosing Monitor, we can right-click on a BPEL activity to start creating the sensor. This brings up a pop-up menu from which we can select the Create | Sensor item. Note that there are also options to create other monitoring items.

Counter: Creates a count of the number of times an activity has been reached
Business Indicator: Evaluates an XPath expression when an activity has been reached
Interval: Calculates the elapsed time between two activities
Sensor: Creates a BAM sensor

When creating a new sensor we need to provide it with a name and indicate when it should fire. The options are as follows:

Activation: When the activity is started
Completion: When the activity is completed
Fault: When the activity raises a fault
Compensation: When compensation is invoked on a surrounding scope
Retry: When the activity is retried, such as retrying an invoke
All: All of the above

We must also provide a variable that contains the data we want to be part of the sensor-generated event. This variable must be an element variable, not a simple type or a message type.

Invoking the BAM adapter through BPEL sensors

Sensors can have a number of sensor actions associated with them. Sensor actions can be thought of as the targets for the sensor event. One option is to send the events into the BPEL repository, which is useful for testing purposes. Another option is to send them to BAM. Other options revolve around JMS Queues and Topics.

Unfortunately, we cannot add a BAM sensor from the Create Activity Sensor dialog. They can only be created by using the structure pane for the BPEL process. To do this, we navigate to Sensor Actions in the structure pane, right-click, and select Bam Sensor Action. This brings up the Create Sensor Action dialog.

We provide a name for the sensor action and then select an eligible sensor from the drop-down list. There is a one-to-one relationship between BAM sensor sections and sensors. This is not the case for other types of sensors. The reason for the one-to-one relationship is that BAM sensor actions transform the variable associated with the action into the relevant fields for the BAM data object. This is done through an XSLT transform.

Having selected our sensor, we then click the torch next to the Data Object so that we can choose the BAM data object that we will map the sensor variable onto.

Having selected the BAM data object, we need to select the operation to be performed on the data object. The drop-down list gives us four options:

Insert
Update
Delete
Upsert

The Insert operation creates a new instance of the BAM data object. This may result in multiple data objects having the same field values.

The Insert operation does not use a key as it always creates a new data object. The remaining three operations require a key because they may operate on an existing data object. The key must uniquely identify a data object and may consist of one or more data object fields.

The Update operation will update an existing data object, overwriting some or all of the fields, as desired. If the object cannot be found from the key, then no data is updated in the ADC.

The Delete operation will remove a data object from the ADC. If the key does not identify an object, then no object will be deleted.

The Upsert operation behaves as an update operation if the key does identify an existing data object in the ADC. If the key does not identify an existing object in the ADC, then it behaves as an Insert operation.

Generally, we use the Insert operation when we know we are creating an object for the first time, and we use the Update operation when we know that the object already exists. We use the Upsert operation when we are unsure if an object exists.

For example, we may use an Insert operation to create an instance of a process status object and then use an update to change the status value of the object as the process progresses. When tracking process state, it is a good idea to use the process instance identifier as a key field in the data object.

Having chosen our operation, an Insert operation for example, we then need to map the fields in the sensor variable defined in BPEL to the BAM data object. We do this by creating a new XSLT transformation by clicking the green cross next to the Map File field.

Within the XSLT transformation editor, we can map the BPEL variable to the BAM data object. In addition to the variable itself, there is a host of other information available to us in the BPEL variable source document. This can be categorized as follows:

Header Information
- This relates to the process instance and the specific sensor that is firing
Payload
- This contains not only the sensor variable contents but also information about the activity and any fault associated with it

Useful data includes the instance ID of the process and also the time the sensor fired as well as the elapsed times for actions. Once we have wired up the variable data, we can save the transform file.

When we have finished creating the sensor action, we can deploy it to the BPEL server and events will be fired to populate the BAM active data cache.

Testing the events

After creating our BAM sensors, we can test them by executing a process in BPEL and ensuring that the events appear in the Active Data Cache. We can find the actual event data by selecting the object in BAM architect and then clicking Contents, which will then list the actual data object instances.

Creating a simple dashboard

Now that our sensors are in place and working, we can use the BAM Active Studio application to create a report based on the sensor information. To help organize our reports, it is possible to create folders to hold reports in a similar fashion to the way we created folders to hold data objects.

Let us create a report that shows the status of auctions in the system and also shows the value of all auctions currently open. We will start by creating the report itself. The report is just a holder for views, and we create it by selecting the Create A New Report button.

We can select a report that has the right number of panes for the number of views we want. Note that it is possible to change the number of panes on the report, so if we get it wrong, it does not matter. For now, we will choose a simple split-screen report with two panes, one above the other.

We can provide a title for a report by editing the title section directly. Having updated the title, we can then proceed to create the views.

Defining reports and data required

We are interested in the number of auctions in each state as well as the total value of auctions in progress. This leads us to the following reporting requirements:

Display current number of auctions in each state
Display value of all auctions in each state
Allow filtering of reports by bidder and seller
Allow filtering of reports by auction end date

These reports will require the following data:

Auction identifier, so that we can correlate status changes back to a particular auction
Auction state, so that we can track the number of auctions in each state
Current highest bid, so that we can calculate the worth of all auctions
Current highest bidder, so that we can filter reports by a particular bidder
Seller, so that we can filter reports by a particular seller
Auction end date, so that we can filter auctions by completion date

Having completed our analysis, we can proceed to define our data objects, capture events, and build our reports.

We will follow a middle-out approach to building our dashboard. We will take the following steps:

Define our data within the Active Data Cache
Create sensors in BPEL and map to data in the ADC
Create suitable reports
Run the reports

Defining data objects

Data in BAM is stored in data objects. Individual data objects contain the information that is reported in BAM dashboards and may be updated by multiple events. Generally, BAM will report against aggregations of objects, but there is also the ability for reports to drill down into individual data objects.

Before defining our data objects, let's group them into an auction folder so that they are easy to find. To do this, we use the BAM Architect application, and select Data Objects, which gives us the following screenshot:

We select Create subfolder to create the folder and give it a name (Auction).

We then click on Create folder to actually create the folder, and we get a confirmation message to tell us that it has been created. Notice that once created, the folder also appears in the Folders window on the left-hand side of the screen.

Now that we have our folder, we can create a data object. Again, we select Data Objects from the drop-down list. To define the data objects that are to be stored in our Active Data Cache, we open the Auction folder, if it is not already open, and select Create Data Object. If we don't select the Auction folder, then we pick it later when filling in the details of the data object.

We need to give our object a unique name within the folder and optionally provide it with a tip text that helps explain what the object does when the mouse is moved over it in object listings. Having named our object, we can now create the data fields by selecting Add a field. When adding fields, we need to provide a name and type as well as indicating if they must contain data; the default Nullable does not require a field to be populated. We may also optionally indicate if a field should be publically available for display and whether it should have any tool tip text.

Once all the data fields have been defined, we can click Create Data Object to actually create the object as we have defined it. We are then presented with a confirmation screen that the object has been created.

Tip

Grouping data into hierarchies

When creating a data object, it is possible to specify "Dimensions" for the object. A dimension is based on one or more fields within the object. A given field can only participate in one dimension. This gives the ability to automatically group the object by the fields in the given dimension. If multiple fields are selected for a single dimension, then they can be layered into a hierarchy; for example, to allow analysis by country, region, and city. In this case, all three elements would be selected into a single dimension, perhaps called geography. Within geography, a hierarchy could be set up with country at the top, region next, and finally city at the bottom, allowing drill down to occur in views. Just as a data object can have multiple dimensions, a dimension can also have multiple hierarchies.

A digression on populating data object fields

In the previous discussion, we mentioned the Nullable attribute that can be attached to fields. This is very important as we do not expect to populate all or even most of the fields in a data object one at a time. Failing to initialize a field will generate an error unless it is Nullable. Do not confuse data objects with the low-level events that are used to populate them. Data objects in BAM do not have a one-to-one correspondence with the low-level events that populate them. In our auction example, there will be just one auction object for every auction. However, there will be at least two, and usually more, messages for every auction; one message for the auction starting, another for the auction completing, and additional messages for each bid received. These messages will all populate, or in some cases overwrite, different parts of the auction data object. The table shows how the three messages populate different parts of the data object.

Message	Auction ID	State	Highest Bid	Reserve	Expires	Seller	Highest Bidder
Auction Started	Inserted	Inserted	Inserted	Inserted	Inserted	Inserted
Bid Received		Updated	Updated				Updated
Auction Finished		Updated

Instrumenting BPEL and SCA

Having defined the data we wish to capture in BAM, we now need to make our auction process generate appropriate events. We can instrument BPEL and SCA by making explicit calls to a BAM adapter as we would to any other adapter. Within BPEL, we may also take advantage of the sensor framework to raise BAM events from within an activity.

Tip

Sensors versus explicit calls

Explicit calls are available within both SCA and BPEL. Within BPEL, they make it more obvious where the BAM events are being generated. BPEL sensors, however, provide the ability to generate events at a finer grained level than explicit calls. For example, a BAM sensor in a BPEL activity could be set to fire not just on activation and completion (which could be captured by an explicit call just before and after the event), but also on events that are harder to catch with an explicit invoke, such as faults and compensation. Finally, sensors can fire on retry events that are impossible to capture in any other way. BAM sensors do not use partner links or references, but refer to the adapter JNDI location directly.

Sensors are not part of the normal BPEL executable flow. They can be thought of as event generators. They are attached to almost any kind of activity in BPEL, including partner link operations (invoke, receive, reply) and assigns. They can also be attached to variables and will fire whenever the variable is modified.

Invoking the BAM adapter as a regular service

When using the BAM adapter, we first need to configure an adapter instance.

Creating a BAM adapter

Let us start by creating a new BAM adapter. We begin by creating a new BAM Connection from the Connection section of the New Gallery (File | New, and then select Connection under General).

We provide a name for the connection and identify if we wish it to be local to this application or available to all applications. We then define the connection characteristics of hostnames and port numbers for the Active Data Cache (BAM Server Host) and web applications (Web Server). Generally, these will be the same hostname and port number. We also provide a username and password for the BAM server. Finally, we can test our connection to ensure that it works.

Having created our connection, we can now create a BAM partner link for use in BPEL or SCA. We do this in the same way as we create any other adapter-based link. We can drag a BAM Adapter from the Service Adapters section of the Component Palette onto either the External References section of an SCA or the Partner Links section of a BPEL process. This will launch the Adapter Configuration Wizard. After providing a name for our service, we are asked to select a BAM Data Object and determine the Operation to perform on the object. We must also provide an Operation Name and determine the batching behavior.

The Data Object may be selected directly from the BAM server by using the Browse… button to pop up the BAM Data Object Chooser dialog box, which allows selection of the correct data object.

Depending on the operation, we may need to provide a key to locate the correct data object instance. Update, Upsert, and Delete all require a key, only Insert does not.

Tip

Upsert the universal update mechanism

When using upsert, if the key already exists then that object is updated. If the object does not exist, then it is inserted. This enables upsert to cover both insert and update operations and is generally the most useful operation to perform on BAM objects, as it requires only one BAM adapter instance to provide two different operations.

Having identified the update characteristics of our adapter, we now must map it onto a resource in the underlying application server by providing the JNDI location of the BAM connection. Once this is completed, we can complete the wizard and finish creating our BAM adapter.

Invoking the BAM adapter

Invoking the BAM adapter is the same as invoking any other adapter from BPEL or the Mediator. The BAM adapter provides an interface to allow a collection of data objects to be submitted at the same time, each field in the data object is represented by an XML element in the interface to the adapter. XSLT or copy operations may be used to populate the fields of the input variable.

Invoking the BAM adapter through BPEL sensors

In this section, we will examine how to use BPEL sensors to invoke the BAM adapter.

Within JDeveloper, there are several modes in which we can view the BPEL process. On the right-hand side of the title bar for the BPEL editor, there is a drop-down list that allows us to select the viewing and editing mode.

The drop-down list shows us the three modes available:

BPEL: Lets us edit and view the BPEL activities
Monitor: Lets us edit and view sensor annotations to the BPEL process
BPA: Is only used with the Oracle BPA suite.

After choosing Monitor, we can right-click on a BPEL activity to start creating the sensor. This brings up a pop-up menu from which we can select the Create | Sensor item. Note that there are also options to create other monitoring items.

Counter: Creates a count of the number of times an activity has been reached
Business Indicator: Evaluates an XPath expression when an activity has been reached
Interval: Calculates the elapsed time between two activities
Sensor: Creates a BAM sensor

When creating a new sensor we need to provide it with a name and indicate when it should fire. The options are as follows:

Activation: When the activity is started
Completion: When the activity is completed
Fault: When the activity raises a fault
Compensation: When compensation is invoked on a surrounding scope
Retry: When the activity is retried, such as retrying an invoke
All: All of the above

We must also provide a variable that contains the data we want to be part of the sensor-generated event. This variable must be an element variable, not a simple type or a message type.

Sensors can have a number of sensor actions associated with them. Sensor actions can be thought of as the targets for the sensor event. One option is to send the events into the BPEL repository, which is useful for testing purposes. Another option is to send them to BAM. Other options revolve around JMS Queues and Topics.

Unfortunately, we cannot add a BAM sensor from the Create Activity Sensor dialog. They can only be created by using the structure pane for the BPEL process. To do this, we navigate to Sensor Actions in the structure pane, right-click, and select Bam Sensor Action. This brings up the Create Sensor Action dialog.

We provide a name for the sensor action and then select an eligible sensor from the drop-down list. There is a one-to-one relationship between BAM sensor sections and sensors. This is not the case for other types of sensors. The reason for the one-to-one relationship is that BAM sensor actions transform the variable associated with the action into the relevant fields for the BAM data object. This is done through an XSLT transform.

Having selected our sensor, we then click the torch next to the Data Object so that we can choose the BAM data object that we will map the sensor variable onto.

Having selected the BAM data object, we need to select the operation to be performed on the data object. The drop-down list gives us four options:

Insert
Update
Delete
Upsert