Skip Headers
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2)
B14448-02
  Go To Documentation Library
Home
Go To Product List
Solution Area
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

18 Sensors

Using sensors, you can specify BPEL activities, variables, and faults that you want to monitor during run time. This chapter describes how to use and set up sensors for a BPEL process. This chapter also describes how to create sensor actions in Oracle BPEL Process Manager to publish sensor data as data objects in an Oracle BAM Server.

This chapter contains the following topics:

18.1 Use Cases for Sensors

Using sensors is demonstrated in the sample 125.ReportsSchema. The sample uses sensors to identify key data during an employee update process and a sensor action to publish information about the update to the database.


See:

Oracle_Home\integration\orabpel\samples\tutorials\125.ReportsSchema

Inserting sensors on activities is also demonstrated in the OrderBooking tutorial.

18.2 Overview of Sensor Concepts

You can define the following types of sensors, either through JDeveloper BPEL Designer or manually by providing sensor configuration files.

You typically add or edit sensors as part of the BPEL modeling of activities, faults, and variables.

When you model sensors in JDeveloper BPEL Designer, two new files are created as part of the BPEL process suitcase:

See "Configuring Sensors" and "Configuring Sensor Actions" for how these files are created.

After you define sensors for a BPEL process, you must configure sensor actions to publish the data of the sensors to an endpoint. You can publish sensor data to the BPEL reports schema, which is located in the BPEL dehydration store, to a JMS queue or topic, or to a custom Java class.

The following information is required for a sensor action:

18.3 Implementing Sensors and Sensor Actions in JDeveloper BPEL Designer

In JDeveloper BPEL Designer, sensors and sensor actions are displayed as part of the process tree structure, as shown in Figure 18-1.

Figure 18-1 Sensors and Sensor Actions Displayed in JDeveloper BPEL Designer

Description of Figure 18-1  follows
Description of "Figure 18-1 Sensors and Sensor Actions Displayed in JDeveloper BPEL Designer"

You typically add or edit sensors as part of the BPEL modeling of activities, faults, and variables. You can add sensor actions by right-clicking the Sensor Actions folders and selecting Create Sensor Action. To add activity sensors, variable sensors, or fault sensors, expand the Sensors folder, right-click the appropriate Activity, Variable, or Fault subfolder, and click Create.

Using LoanDemoPlus as an example, the following sections describe how to configure sensors and sensor actions.


See Also:

The LoanDemoPlus tutorial, at Oracle_Home\integration\orabpel\samples\demos

18.3.1 Configuring Sensors

If you are monitoring the LoanFlow application, you may want to know when the getCreditRating scope is initiated, when it is completed, and, at completion, what the credit rating for the customer is. The solution is to create an activity sensor for the getCreditRating scope in JDeveloper BPEL Designer, as shown in Figure 18-2. Activities that have sensors associated with them are indicated with a magnifying glass.

Figure 18-2 Creating an Activity Sensor

Description of Figure 18-2  follows
Description of "Figure 18-2 Creating an Activity Sensor"

The Evaluation Time attribute shown in Figure 18-2 controls the point at which the sensor fires. You can select from the following:

  • Activation—The sensor fires just before the activity is executed.

  • Completion—The sensor fires just after the activity is executed.

  • Fault—The sensor fires if a fault occurs during the execution of the activity. Select this value only for sensors that monitor simple activities.

  • Compensation—The sensor fires when the associated scope activity is compensated. Select this value only for sensors that monitor scopes.

  • Retry—The sensor fires when the associated invoke activity is retried.

  • All—Monitoring occurs during all of the preceding phases.

A new entry is created in the sensor.xml file, as follows:

<sensor sensorName="CreditRatingSensor"

classname="oracle.tip.pc.services.reports.dca.agents.BpelActivitySensorAgent"
          kind="activity" 
          target="getCreditRating">

  <activityConfig evalTime="all">
    <variable outputNamespace="http://www.w3.org/2001/XMLSchema"
              outputDataType="int" 
              target="$crOutput/payload//services:rating"/>
  </activityConfig> 
</sensor>

If you want to record all the incoming loan requests, create a variable sensor for the variable input, as shown in Figure 18-3.

Figure 18-3 Creating a Variable Sensor

Description of Figure 18-3  follows
Description of "Figure 18-3 Creating a Variable Sensor"

A new entry is created in the sensor.xml file, as follows:

<sensor sensorName="LoanApplicationSensor" 
    classname="oracle.tip.pc.services.reports.dca.agents.BpelVariableSensorAgent"
    kind="variable" 
    target="$input/payload">
  <variableConfig outputNamespace="http://www.autoloan.com/ns/autoloan"
                  outputDataType="loanApplication"/> 
</sensor>

If you want to monitor faults from the identity service, create a fault sensor, as shown in Figure 18-4.

Figure 18-4 Creating a Fault Sensor

Description of Figure 18-4  follows
Description of "Figure 18-4 Creating a Fault Sensor"

A new entry is created in the sensor.xml file, as follows:

<sensor sensorName="IdentityServiceFault"
        classname="oracle.tip.pc.services.reports.dca.agents.BpelFaultSensorAgent"
        kind="fault" 
        target="is:identityServiceFault">
    <faultConfig/>
</sensor>

18.3.2 Configuring Sensor Actions

When you create sensors, you identify the activities, variables, and faults you want to monitor during run time. If you want to publish the values of the sensors to an endpoint, for example, you want to publish the data of LoanApplicationSensor to a JMS queue, then you create a sensor action, as shown in Figure 18-5, and associate it with the LoanApplicationSensor.

Figure 18-5 Creating a Sensor Action

Description of Figure 18-5  follows
Description of "Figure 18-5 Creating a Sensor Action"

A new entry is created in the sensorAction.xml file, as follows:

<action name="BAMFeed"
        enabled="true"
        publishType="JMSQueue"
        publishTarget="jms/bamTopic"> 
  <sensorName>LoanApplicationSensor</sensorName>
  <property name=ÒJMSConnectionFactoryÒ> 
    jms/QueueConnectionFactory
  </property>
</action>  
 

If you want to publish the values of LoanApplicationSensor and CreditRatingSensor to the reports schema in the database, create an additional sensor action, as shown in Figure 18-6, and associate it with both CreditRatingSensor and LoanApplicationSensor.

Figure 18-6 Creating an Additional Sensor Action

Description of Figure 18-6  follows
Description of "Figure 18-6 Creating an Additional Sensor Action"

A new entry is created in the sensorAction.xml file, as follows:

<action name="PersistingAction"
     enabled="true" 
     publishType="BPELReportsSchema">
  <sensorName>LoanApplicationSensor</sensorName> 
  <sensorName>CreditRatingSensor</sensorName>
</action

The data of one sensor can be published to multiple endpoints. In the two preceding code samples, the data of LoanApplicationSensor is published to a JMS queue as well as to the reports schema in the database.

If you want to monitor loan requests for which the loan amount is greater than $100,000, you can create a sensor action with a filter, as shown in Figure 18-7.

Figure 18-7 Creating a Sensor Action with a Filter

Description of Figure 18-7  follows
Description of "Figure 18-7 Creating a Sensor Action with a Filter"

A new entry is created in the sensorAction.xml file, as follows:

<action name="BigMoneyBAMAction"
        enabled='true' 
        filter="boolean(/s:actionData/s:payload
                        /s:variableData/s:data
                        /autoloan:loanAmount > 100000)"
        publishType="JMSQueue" 
        publishTarget="jms/bigMoneyQueue">
  <sensorName>LoanApplicationSensor</sensorName> 
  <property name=ÒJMSConnectionFactoryÒ>
    jms/QueueConnectionFactory 
  </property>
</action>   

Note:

  • You must specify all the namespaces that are required to configure an action filter in the sensor action configuration file.

  • You must specify the filter as a Boolean XPath expression.


If you have special requirements for a sensor action that cannot be accomplished by using the built-in publish types, database, JMS queue, and JMS topic, then you can create a sensor action with the custom publish type, as shown in Figure 18-8. The name in the Publish Target field denotes a fully qualified Java class name that must be implemented.

Figure 18-8 Using the Custom Publish Type

Description of Figure 18-8  follows
Description of "Figure 18-8 Using the Custom Publish Type"

18.3.3 Creating a Custom Data Publisher

To create a custom data publisher, double-click your BPEL project in JDeveloper BPEL Designer and do the following:

  1. Open Project Properties, then Libraries, then OraBPEL, and add it to the Selected Libraries list.

    This adds the required BPEL libraries to your BPEL project.

    Adding a BPEL library to a BPEL project
    Description of the illustration sensor_pub1.gif

  2. Create a new Java class.

    The package and class name must match the publish target name of the sensor action.

    Creating a Java class
    Description of the illustration sensor_pub2.gif

  3. Select Tools, then Implement Interface, then Available Interfaces, and then DataPublisher.

    This updates the source file and fills in the methods and import statements of the DataPublisher interface.

    Updating the source file
    Description of the illustration sensor_pub3.gif

  4. Using the JDeveloper BPEL Designer editor, implement the publish method of the DataPublisher interface, as shown in the following sample custom data publisher class.

    Sample custom data publisher class
    Description of the illustration sensor_customdp.gif

  5. Ensure that the class compiles successfully.

    The next time that you deploy the BPEL process, the Java class is added to the BPEL suitcase and deployed to Oracle BPEL Process Manager.


Note:

Ensure that additional Java libraries needed to implement the data publisher are in the CLASSPATH of the Oracle BPEL Server.

Oracle BPEL Process Manager can execute multiple process instances simultaneously, so ensure that the code in your data publisher is thread safe, or add appropriate synchronization blocks. To guarantee high throughput, do not use shared data objects that require synchronization.


18.3.4 Registering the Sensors and Sensor Actions in bpel.xml

JDeveloper BPEL Designer automatically updates the process deployment file bpel.xml to include appropriate properties for sensors and sensor actions, as follows:

<configurations>
  … 
  <property name="sensorLocation">sensor.xml</property>
  <property name="sensorActionLocation">sensorAction.xml</property>
  …
  <property name="SLACompletionTime">P0YT1.5S</property>
</configurations>

You can specify additional properties with <property name= ...>, as shown in the preceding code sample.

18.4 Sensors and Oracle BPEL Console

The console provides support to view the metadata of sensors and sensor actions as well as the sensor data created as part of the process execution. Access Oracle BPEL Console at

http://localhost:portnumber/BPELConsole

You can also select Start, then All Programs, then Oracle - Oracle_Home, then Oracle BPEL Process Manager 10.1.2, and then BPEL Console.

18.4.1 Viewing Sensor and Sensor Action Definitions

After the BPEL process is deployed to Oracle BPEL Process Manager, you can view the definitions of sensors and sensor actions without going back to JDeveloper BPEL Designer. In Oracle BPEL Console, click the BPEL Processes tab and choose the process for which you want to see sensor definitions. Click the Sensors link. A page similar to Figure 18-9 is displayed.

Figure 18-9 Sensor Data on the BPEL Processes Tab of Oracle BPEL Console

Description of Figure 18-9  follows
Description of "Figure 18-9 Sensor Data on the BPEL Processes Tab of Oracle BPEL Console"

18.4.2 Viewing Sensor Data

The console provides support to monitor sensors for which a BpelReportsSchema sensor action is defined. In Oracle BPEL Console, click the Instances tab and choose the process instance for which you want to see the sensor data created as the result of process execution. A page similar to Figure 18-10 is displayed.

Figure 18-10 Sensor Data on the Instances Tab of Oracle BPEL Console

Description of Figure 18-10  follows
Description of "Figure 18-10 Sensor Data on the Instances Tab of Oracle BPEL Console"


Note:

Only sensors associated with a database sensor action are displayed in the console. Sensors associated with a JMS queue, JMS topic, or custom sensor action are not displayed.

18.5 Sensor Integration with Oracle Business Activity Monitoring

Oracle Business Activity Monitoring (BAM) enables you to monitor business services and processes in an enterprise, correlate key performance indicators (KPIs), and change business processes or take corrective actions if the business environment changes. Oracle BAM enables you to build real-time operational dashboards and monitoring and alerting applications over the Web. Using this technology, you build interactive, real-time dashboards and proactive alerts to monitor business services and processes.

You can create sensor actions in Oracle BPEL Process Manager to publish sensor data as data objects on an Oracle BAM Server. When you create the sensor action, you can select an Oracle BPEL Process Manager variable or activity sensor that you want to monitor and the data object in Oracle BAM Server in which you want to publish the sensor data. Oracle BAM Server publishes the data objects and types information in WSDL files. It uses basic HTTP authentication to enable access to these files.

This section contains the following topics:

These instructions assume you have installed and configured Oracle BAM. Visit the Oracle BAM Web site on the Oracle Technology Network for specific details about Oracle BAM:

http://www.oracle.com/technology/products/integration/bam/index.html

18.5.1 Creating a Connection to Oracle BAM Server

You must create a connection to Oracle BAM Server to browse the available data objects. This connection information is automatically used during deployment.

  1. Select Connection Navigator from the View main menu in JDeveloper BPEL Designer.

  2. Right click BAM Server.

  3. Select New BAM Server Connection.

  4. Click Next on the Welcome page.

  5. Provide a name for connecting to the server.

  6. Click Next.

  7. Enter the following connection information about the Oracle BAM Server host.

    Field Description
    Host Name Enter the name of the host on which Oracle BAM Server is installed. Depending on your organization's security policy, the fully-qualified host name may be required.
    Port Number Enter the port number or accept the default value of 80.
    User Name Enter your Windows domain user name. Oracle BAM Server uses the Windows domain for authentication.
    Password Enter the password of the domain user name.
    Domain Name Enter the domain name in which the Oracle BAM Server host is located.
    Use secure HTTP protocol Select this check box if you want to use secure HTTP (HTTPS) to connect to the Oracle BAM Server. Otherwise, HTTP is used.

  8. Click Next.

  9. Test the connection by clicking Test Connection. If the connection was successful, the following message appears:

    Success.
    
    
  10. Click Finish.

JDeveloper BPEL Designer reserves the following property names. These property names define values for the Oracle BAM Server connection you just created.

  • bamserver.hostname

  • bamserver.protocol

  • bamserver.username

  • bamserver.password

  • bamserver.port

  • bamserver.domain

These property names are added in the Preferences tab of the Deployment Descriptor Properties window. If your BPEL process uses a BAM sensor action and you want runtime to use a different Oracle BAM Server than the one used during design time, you must update these values prior to BPEL process deployment. If you have already deployed the process, then you can use Oracle BPEL Console to update these values.

18.5.2 Creating a Sensor

You must create one of the following types of sensors prior to creating a BAM sensor action:

  • A variable sensor or an activity sensor containing one sensor variable. This sensor contains the BPEL variable that you want to monitor. Only one variable is allowed for the sensor. If the variable has message parts, there must be only one message part.

  • An activity sensor that does not have a variable


See Also:

"Implementing Sensors and Sensor Actions in JDeveloper BPEL Designer" for instructions on creating sensors

18.5.3 Creating a BAM Sensor Action

When you create the sensor action, you select the BPEL variable or activity sensor that you want to monitor and the data object in Oracle BAM Server in which you want to publish the sensor data.

  1. Right click Sensor Actions in the Structure section of JDeveloper BPEL Designer.

  2. Select Create BAM Sensor Action.

    The Create Sensor Action window appears. You create BAM sensor actions to publish sensor data to data objects on Oracle BAM Server.

    Description of sensors_bam.gif follows
    Description of the illustration sensors_bam.gif

  3. Enter the following details:

    Field Description
    Action Name Enter a unique and recognizable name for the sensor action.
    Select Sensor Select a BPEL sensor to monitor. This is the sensor that you created in "Creating a Sensor" for mapping sensor data to a data object in Oracle BAM Server.
    Data Object Click the flashlight icon to open the Data Object Chooser window to select the data object in Oracle BAM Server in which you want to publish the sensor data.
    Enable Batching The data cached by default by the Oracle BAM component of the Oracle BPEL Process Manager runtime is flushed (sent) to Oracle BAM Server periodically. The decision to periodically send the data is based on upper and lower limit parameter settings on the Set Batch Parameters window. The Oracle BAM component may decide to send data prior to a batch timeout if the cache has a number of data objects between the lower and upper limit values. Disable batching by unselecting this check box.

    To modify the batch parameters, click Set Batch Parameters. This displays the Set Batch Parameters window. Select the check box to use default batch parameter settings. If you deselect this check box, provide customized values in the fields below. If you provide customized values and then select this check box, the settings revert to the default values.

    Operation Select to Delete, Update, Insert, or Upsert a row in the Oracle BAM Server database. Upsert first attempts to update a row if it exists. If the row does not exit, it is inserted.

    See the Oracle Business Activity Monitoring Installation Guide for additional details about these batch process commands:

    http://www.oracle.com/technology/products/integration/bam/htdocs/1012_support.html#docs
    
    Available Keys/Selected Keys If you selected the Delete, Update, or Upsert operation, you must also select a column name in the Oracle BAM server database to use as a key to determine the row with which this sensor object corresponds. A key can be a single column or a composite key consisting of multiple columns. Select a key and click the > button. To select all, click the >> button.
    Map File Provide a file name to create a mapping between the sensor (selected in the Select Sensor list) and the Oracle BAM Server data object (selected in the Data Object list). You can also invoke a mapper window by clicking the Create Mapping icon (second icon) or Edit Mapping icon (third icon).


    Note:

    After you click the Create Mapping or Edit Mapping or OK button on the Create Sensor Action window, you must explicitly save the BPEL file.

18.6 Sensor Public Views

The sensor framework of Oracle BPEL Process Manager provides the functionality to persist sensor values created by processing BPEL instances in a relational schema stored in the dehydration store of Oracle BPEL Process Manager. The data is used to display the sensor values of a process instance in Oracle BPEL Console.

Use the following public views for SQL access to sensor values from any application interested in the data. These views are populated when a sensor action is used to publish to a database.

18.6.1 BPEL Reporting Schema

The database publisher persists the sensor data in a predefined relational schema in the database. You can use SQL to query the sensor values in the following public views from clients such as Oracle Warehouse Builder or OracleAS Portal.


Note:

In Table 18-1 through Table 18-7, the Indexed or Unique? column provides unique index names and the order of the attributes. For example, U1,2 means that the attribute is the second one in a unique index named U1. PK means primary key.

BPEL_ALL_PROCESSES

This view contains all the deployed BPEL processes across the Oracle BPEL Process Manager domains.

Table 18-1 BPEL_ALL PROCESSES View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

BASE_URL

NVARCHAR2

256

--

N

The base URL of the BPEL suite

SENSOR_URL

NVARCHAR2

256

--

N

The URL of the sensor file

SENSOR_ACTION_URL

NVARCHAR2

256

--

N

The URL of the sensor action file


BPEL_PROCESS_ANALYSIS_REPORT

This view contains all the process instances of Oracle BPEL Process Manager.

Table 18-2 BPEL_PROCESS_ANALYSIS_REPORT View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique instance ID

BPEL_PROCESS_NAME

NVARCHAR2

100

--

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

--

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

--

N

Oracle BPEL Process Manager domain name

TITLE

VARCHAR2

50

--

Y

User-defined title of the BPEL process

STATE

NUMBER

--

--

Y

State of the BPEL process instance

STATE_TEXT

VARCHAR2

--

--

Y

Text presentation of the state attribute

PRIORITY

NUMBER

--

--

Y

User-defined priority of the BPEL process instance

STATUS

VARCHAR2

100

--

Y

User-defined status of the BPEL process

STAGE

VARCHAR2

100

--

Y

User-defined stage property of a BPEL process

CONVERSATION_ID

VARCHAR2

100

--

Y

User-defined conversation ID of a BPEL process

CREATION_DATE

TIMESTAMP

--

--

N

The creation time stamp of the process instance

MODIFY_DATE

TIMESTAMP

--

--

Y

Time stamp when the process instance was modified

TS_DATE

DATE

--

--

Y

Date portion of modify_date

TS_HOUR

NUMBER

--

--

Y

Hour portion of modify_date

EVAL_TIME

NUMBER

--

--

Y

Time in milliseconds that a process takes to complete

SLA_COMPLETION_TIME

NUMBER

--

--

Y

SLA completion time in milliseconds. This is populated with the value of an optional property you can set in bpel.xml. For example,

<configurations>
...
<property name="SLACompletionTime">POYT1.5S</property>

SLA_SATISFIED

VARCHAR2

1

--

Y

Y means SLA satisfied: SLA_COMPLETION_TIME < EVAL_TIME.

N means SLA not satisfied; SLA_COMPLETION_TIME > EVAL_TIME.

NULL means that no SLACompletion property was set.


BPEL_SENSOR_PROCESS_INSTANCES

This view is a subset of BPEL_PROCESS_ANALYSIS_REPORT and contains those process instances for which sensors are defined for the corresponding BPEL process and for which a sensor has fired at least once.

Table 18-3 BPEL_SENSOR_PROCESS_INSTANCES View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique instance ID

BPEL_PROCESS_NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

TITLE

VARCHAR2

50

--

Y

User-defined title of the BPEL process

STATE

NUMBER

--

--

Y

State of the BPEL process instance

STATE_TEXT

VARCHAR2

--

--

Y

Text presentation of the state attribute

PRIORITY

NUMBER

--

--

Y

User-defined priority of the BPEL process instance

STATUS

VARCHAR2

100

--

Y

User-defined status of the BPEL process

STAGE

VARCHAR2

100

--

Y

User-defined stage property of a BPEL process

CONVERSATION_ID

VARCHAR2

100

--

Y

User-defined conversation ID of a BPEL process

CREATION_DATE

TIMESTAMP

--

--

N

Creation time stamp of the instance

MODIFY_DATE

TIMESTAMP

--

--

Y

Time stamp when the process instance was modified

TS_DATE

DATE

--

--

Y

Date portion of modify_date

TS_HOUR

NUMBER

--

--

Y

Hour portion of modify_date

EVAL_TIME

NUMBER

--

--

Y

Time in milliseconds that a process takes to complete

SLA_COMPLETION_TIME

NUMBER

--

--

Y

SLA completion time in milliseconds. This is populated with the value of an optional property you can set in bpel.xml. For example,

<configurations>
...
<property name="SLACompletionTime">POYT1.5S</property>

SLA_SATISFIED

VARCHAR2

1

--

Y

Y means SLA satisfied: SLA_COMPLETION_TIME < EVAL_TIME.

N means SLA not satisfied; SLA_COMPLETION_TIME > EVAL_TIME.

NULL means that no SLACompletion property was set.

INSTANCE_KEY

NUMBER

--

U1

N

Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs


BPEL_ACTIVITY_SENSOR_VALUES

This view contains all the activity sensor values of the monitored BPEL processes.

Table 18-4 BPEL_ACTIVITY_SENSOR_VALUES View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique ID

PROCESS_INSTANCE

NUMBER

--

--

N

ID of process instance

BPEL_PROCESS_NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

SENSOR_NAME

NVARCHAR2

100

--

N

The name of the sensor that fired

SENSOR_TARGET

NVARCHAR2

256

--

N

The target of the fired sensor

ACTION_NAME

NVARCHAR2

100

--

N

The name of the sensor action

ACTION_FILTER

NVARCHAR2

256

--

Y

The filter of the action

CREATION_DATE

TIMESTAMP

--

--

N

The creation date of the activity sensor value

MODIFY_DATE

TIMESTAMP

--

--

Y

The time stamp of last modification

TS_DATE

DATE

--

--

Y

Date portion of modify_date

TS_HOUR

NUMBER

--

--

Y

Hour portion of modify_date

CRITERIA_SATISFIED

VARCHAR2

1

--

Y

NULL, Y, or N

ACTIVITY_NAME

NVARCHAR2

100

--

N

The name of the BPEL activity

ACTIVITY_TYPE

VARCHAR2

30

--

N

The type of the BPEL activity

ACTIVITY_STATE

VARCHAR2

30

--

Y

The state of the activity

EVAL_POINT

VARCHAR2

20

--

N

The evaluation point of the activity sensor

ERROR_MESSAGE

NVARCHAR2

2000

--

Y

An error message

RETRY_COUNT

NUMBER

--

--

Y

The number of retries of the activity

EVAL_TIME

NUMBER

--

--

Y

Time in milliseconds that an activity takes to complete

INSTANCE_KEY

NUMBER

--

NU1

N

Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs


BPEL_FAULT_SENSOR_VALUES

This view contains all the fault sensor values.

Table 18-5 BPEL_FAULT_SENSOR_VALUES View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique ID

PROCESS_INSTANCE

NUMBER

--

--

N

ID of process instance

BPEL_PROCESS_NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

SENSOR_NAME

NVARCHAR2

100

--

N

The name of the sensor that fired

SENSOR_TARGET

NVARCHAR2

256

--

N

The target of the fired sensor

ACTION_NAME

NVARCHAR2

100

--

N

The name of the sensor action

ACTION_FILTER

NVARCHAR2

256

--

Y

The filter of the action

CREATION_DATE

TIMESTAMP

--

--

N

The creation date of the activity sensor value

MODIFY_DATE

TIMESTAMP

--

--

Y

The time stamp of last modification

TS_DATE

DATE

--

--

Y

Date portion of modify_date

TS_HOUR

NUMBER

--

--

Y

Hour portion of modify_date

CRITERIA_SATISFIED

VARCHAR2

1

--

Y

NULL if no action filter specified, Y if action filter specified and evaluates to true, N otherwise

ACTIVITY_NAME

NVARCHAR2

100

--

N

The name of the BPEL activity

ACTIVITY_TYPE

VARCHAR2

30

--

N

The type of the BPEL activity

MESSAGE

CLOB

--

--

Y

The fault message

INSTANCE_KEY

NUMBER

--

NU1

N

Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs


BPEL_VARIABLE_SENSOR_VALUES

This view contains all the variable sensor values.

Table 18-6 BPEL_VARIABLE_SENSOR_VALUES View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique ID

PROCESS_INSTANCE

NUMBER

--

--

N

ID of process instance

BPEL_PROCESS_NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

SENSOR_NAME

NVARCHAR2

100

--

N

Name of the sensor that fired

SENSOR_TARGET

NVARCHAR2

256

--

N

Target of the sensor

ACTION_NAME

NVARCHAR2

100

--

N

Name of the action

ACTION_FILTER

NVARCHAR2

256

--

Y

Filter of the action

ACTIVITY_SENSOR

NUMBER

--

--

Y

ID of corresponding activity sensor value

CREATION_DATE

TIMESTAMP

--

--

N

Creation date

TS_DATE

DATE

--

--

N

Date portion of creation_date

TS_HOUR

NUMBER

--

--

N

Hour portion of creation_date

VARIABLE_NAME

NVARCHAR2

256

--

N

The name of the BPEL variable

CRITERIA_SATISFIED

VARCHAR2

1

--

Y

NULL, Y, or N

TARGET

NVARCHAR2

256

--

--

--

UPDATER_NAME

NVARCHAR2

100

--

N

The name of the activity or event that updated the variable

UPDATER_TYPE

NVARCHAR2

100

--

N

The type of the BPEL activity or event

VALUE_TYPE

SMALLINT

--

--

N

The value type of the variable (corresponds to java.sql.Types values)

VARCHAR2_VALUE

NVARCHAR2

2000

--

Y

The value of string-like variables

NUMBER_VALUE

NUMBER

--

--

Y

The value of number-like variables (such as float, double, and int)

DATE_VALUE

TIMESTAMP

--

--

Y

The value of date-like variables

BLOB_VALUE

BLOB

--

--

Y

The value of binary data variables

CLOB_VALUE

CLOB

--

--

Y

The value of CLOB-like variables (XML)

INSTANCE_KEY

NUMBER

--

NU1

N

Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs


BPEL_ERRORS

This view gives an overview of all the errors from BPEL services.

Table 18-7 BPEL_ERRORS View

Attribute Name SQL Type Attribute Size Indexed or Unique? Null? Comment

ID

NUMBER

--

PK

N

Unique ID

BPEL_PROCESS_NAME

NVARCHAR2

100

U1,1

N

Name of the BPEL process

BPEL_PROCESS_REVISION

VARCHAR2

50

U1,2

N

Revision of the BPEL process

DOMAIN_ID

VARCHAR2

50

U1,3

N

Oracle BPEL Process Manager domain name

CREATION_DATE

TIMESTAMP

--

--

N

The creation date of the activity sensor value

TS_DATE

DATE

--

--

N

Date portion of creation_date

TS_HOUR

NUMBER

--

--

N

Hour portion of creation_date

ERROR_CODE

NUMBER

--

--

N

Error code

EXCEPTION_TYPE

NUMBER

--

--

N

Type of the error

EXCEPTION_SEVERITY

NUMBER

--

--

N

Severity of the error

EXCEPTION_NAME

NVARCHAR2

200

--

N

Name of the error

EXCEPTION_DESCRIPTION

NVARCHAR2

2000

--

Y

A short description of the error

EXCEPTION_FIX

NVARCHAR2

2000

--

Y

A description on how to fix the error

EXCEPTION_CONTEXT

VARCHAR2

4000

--

Y

The context of the error

COMPONENT

NUMBER

--

--

N

The BPEL component that caused the error

THREAD_ID

VARCHAR2

200

--

N

The Java thread name where the error occurred

STACKTRACE

CLOB

--

--

N

The Java stack trace


18.7 Sensor Actions XSD File

The section provides a sample sensor action schema that you can import into JDeveloper BPEL Designer. This schema is also relevant to custom data publishers.

<?xml version="1.0" encoding="utf-8"?>
<!-- 
  This schema contains the sensor definition. Sensors monitor data
  and execute callbacks appropriately.
-->
<xsd:schema blockDefault="#all" elementFormDefault="qualified"
            targetNamespace="http://xmlns.oracle.com/bpel/sensor"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:tns="http://xmlns.oracle.com/bpel/sensor">

  <xsd:simpleType name="tSensorActionPublishType">
    <xsd:annotation>
      <xsd:documentation>
        This enumeration lists the possibe publishing types for probes.
      </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="BpelReportsSchema"/>
      <xsd:enumeration value="JMSQueue"/>
      <xsd:enumeration value="JMSTopic"/>
      <xsd:enumeration value="Custom"/>
    </xsd:restriction>
  </xsd:simpleType>
  
  <xsd:complexType name="tSensorActionProperty">
    <xsd:simpleContent>
      <xsd:extension base="xsd:string">
        <xsd:attribute name="name" use="required" type="xsd:string"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>

  <!-- 
    Attributes of a sensor action
  -->              
  <xsd:attributeGroup name="tSensorActionAttributes">
    <xsd:attribute name="name" type="xsd:string" use="optional"/>
    <xsd:attribute name="enabled" type="xsd:boolean" use="optional"
 default="true"/>    <xsd:attribute name="filter" type="xsd:string"/>
    <xsd:attribute name="publishName" type="xsd:string" use="required"/>
    <xsd:attribute name="publishType" type="tns:tSensorActionPublishType"
 use="required"/>
    <!-- 
      the name of the JMS Queue/Topic or custom java API, ignored for other 
      publishTypes 
    -->
    <xsd:attribute name="publishTarget" type="xsd:string" use="optional"/>
  </xsd:attributeGroup>
  
  <!-- 
    The sensor action type. A sensor action consists:
    + unique name
    + effective date
    + expiration date - Optional. If not defined, the probe is active 
                        indefinitely.
    + filter (to potentially suppress data publishing even if a sensor marks
             it as interesting). - Optional. If not defined, no filter is 
             used.
    + publishName A name of a publisher
    + publishType What to do with the sensor data?
    + publishTarget Name of a JMS Queue/Topic or custom publisher.
    + potentially many sensors.
  -->
  <xsd:complexType name="tSensorAction">
    <xsd:sequence>
      <xsd:element name="sensorName" type="xsd:string" minOccurs="1"
 maxOccurs="unbounded"/>
      <xsd:element name="property" minOccurs="0" maxOccurs="unbounded"
 type="tns:tSensorActionProperty"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="tns:tSensorActionAttributes"/>
  </xsd:complexType>
  
  <!--
    define a listing of sensor actions in a single document. It might be a good
 idea  to 
    have one sensor action list per business process. 
  -->
  <xsd:complexType name="tSensorActionList">
    <xsd:sequence>
      <xsd:element name="action" type="tns:tSensorAction" minOccurs="0"
 maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:simpleType name="tSensorKind">
    <xsd:restriction base="xsd:string">
      <xsd:enumeration value="fault"/>
      <xsd:enumeration value="variable"/>
      <xsd:enumeration value="activity"/>
    </xsd:restriction>
  </xsd:simpleType>

  <xsd:complexType name="tActivityConfig">
    <xsd:annotation>
      <xsd:documentation>
        The configuration part of an activity sensor comprises of a mandatory
 'evalTime' attribute
        and an optional list of variable configurations 
      </xsd:documentation>
    </xsd:annotation>
    <xsd:complexContent>
      <xsd:extension base="tns:tSensorConfig">
        <xsd:sequence>
          <xsd:element name="variable" type="tns:tActivityVariableConfig"
 maxOccurs="unbounded" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="evalTime" type="xsd:string" use="required"/>
      </xsd:extension>
    </xsd:complexContent>    
  </xsd:complexType>

    <xsd:complexType name="tAdapterConfig">
      <xsd:annotation>
        <xsd:documentation>
          The configuration part of a adapter activity extends the activty
 configuration with additional attributes for adapters
        </xsd:documentation>
      </xsd:annotation>
      <xsd:complexContent>
        <xsd:extension base="tns:tActivityConfig">
          <xsd:attribute name="headerVariable" use="required" type="xsd:string"/>
          <xsd:attribute name="partnerLink" use="required" type="xsd:string"/>
        <xsd:attribute name="portType" use="required" type="xsd:string"/>
        <xsd:attribute name="operation" use="required" type="xsd:string"/>
        </xsd:extension>    
      </xsd:complexContent>
    </xsd:complexType>

  <xsd:complexType name="tVariableConfig">
    <xsd:complexContent>
      <xsd:extension base="tns:tSensorConfig">
        <xsd:attribute name="outputDataType" use="required" type="xsd:string"/>
        <xsd:attribute name="outputNamespace" use="required" type="xsd:string"/>
        <xsd:attribute name="queryName" use="optional" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="tActivityVariableConfig">
    <xsd:complexContent>
      <xsd:extension base="tns:tVariableConfig">
        <xsd:attribute name="target" type="xsd:string" use="required"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="tFaultConfig">
    <xsd:complexContent>
      <xsd:extension base="tns:tSensorConfig"/>
    </xsd:complexContent>
  </xsd:complexType>
  
  <xsd:complexType name="tNotificationSvcConfig">
    <xsd:complexContent>
      <xsd:extension base="tns:tActivityConfig">
        <xsd:attribute name="inputVariable" use="required" type="xsd:string"/>
        <xsd:attribute name="outputVariable" use="required" type="xsd:string"/>
        <xsd:attribute name="operation" use="required" type="xsd:string"/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
    
  <xsd:complexType name="tSensorConfig">
    <xsd:sequence>
      <xsd:element name="action" type="tns:tInlineSensorAction" minOccurs="0"
 maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="tInlineSensorAction">
    <xsd:complexContent>
      <xsd:restriction base="tns:tSensorAction"/>
    </xsd:complexContent>
  </xsd:complexType>

  <xsd:complexType name="tSensor">
    <xsd:sequence>
      <xsd:element name="activityConfig" type="tns:tActivityConfig"
 minOccurs="0"/>
      <xsd:element name="adapterConfig" type="tns:tAdapterConfig" minOccurs="0"/>
      <xsd:element name="faultConfig" type="tns:tFaultConfig" minOccurs="0"/>
      <xsd:element name="notificationConfig" type="tns:tNotificationSvcConfig"
 minOccurs="0"/>
      <xsd:element name="variableConfig" type="tns:tVariableConfig"
 minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="sensorName" use="required" type="xsd:string"/>
    <xsd:attribute name="kind" use="required" type="tns:tSensorKind"/>
    <xsd:attribute name="classname" use="required" type="xsd:string"/>
    <xsd:attribute name="target" use="required" type="xsd:string"/>
  </xsd:complexType>

  <xsd:complexType name="tSensorList">
    <xsd:sequence>
      <xsd:element name="sensor" type="tns:tSensor" minOccurs="0"
 maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="tRouterData">
    <xsd:sequence>
      <xsd:element name="header" type="tns:tHeaderInfo"/>
      <xsd:element name="payload" type="tns:tSensorData"/>
    </xsd:sequence>
  </xsd:complexType>
  
  <xsd:complexType name="tHeaderInfo">
    <xsd:sequence>
      <xsd:element name="processName" type="xsd:string"/>
      <xsd:element name="processRevision" type="xsd:string"/>
      <xsd:element name="domain" type="xsd:string"/>
      <xsd:element name="instanceId" type="xsd:integer"/>
      <xsd:element name="midTierInstance" type="xsd:string"/>
      <xsd:element name="timestamp" type="xsd:dateTime"/>
      <xsd:element name="sensor" type="tns:tSensor"/>
    </xsd:sequence>
  </xsd:complexType>
  
  <xsd:complexType name="tSensorData">
      <xsd:sequence>
        <xsd:element name="activityData" type="tns:tActivityData" minOccurs="0"/>
      <xsd:element name="faultData" type="tns:tFaultData" minOccurs="0"/>
      <xsd:element name="adapterData" minOccurs="0" type="tns:tAdapterData"/>
        <xsd:element name="variableData" type="tns:tVariableData" minOccurs="0"
 maxOccurs="unbounded"/>
        <xsd:element name="notificationData" type="tns:tNotificationData"
 minOccurs="0"/>
      </xsd:sequence>
  </xsd:complexType>
  
  <xsd:complexType name="tFaultData">
    <xsd:sequence>
      <xsd:element name="activityName" type="xsd:string"/>
      <xsd:element name="activityType" type="xsd:string"/>
      <xsd:element name="data" type="xsd:anyType" minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="tActivityData">
    <xsd:sequence>
      <xsd:element name="activityType" type="xsd:string"/>
      <xsd:element name="evalPoint" type="xsd:string"/>
      <xsd:element name="errorMessage" nillable="true" minOccurs="0"
 type="xsd:string"/>
    </xsd:sequence>
  </xsd:complexType>
  
  <!--
   xml type that will be provided to sensors for variable Datas. Note the
      any element represents variable data.
   -->
  <xsd:complexType name="tVariableData">
    <xsd:sequence>
      <xsd:element name="target" type="xsd:string"/>
      <xsd:element name="queryName" type="xsd:string"/>
      <xsd:element name="updaterName" type="xsd:string" minOccurs="1"/>
      <xsd:element name="updaterType" type="xsd:string" minOccurs="1"/>
      <xsd:element name="data" type="xsd:anyType"/>
      <xsd:element name="dataType" type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="tNotificationData">
    <xsd:complexContent>
      <xsd:extension base="tns:tActivityData">
        <xsd:sequence>
          <xsd:element name="messageID" type="xsd:string" minOccurs="0"
 maxOccurs="unbounded"/>
          <xsd:element name="fromAddress" type="xsd:string" minOccurs="0"/>
          <xsd:element name="toAddress" type="xsd:string" minOccurs="0"/>
          <xsd:element name="deliveryChannel" type="xsd:string" minOccurs="0"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
    
  </xsd:complexType>
  <xsd:complexType name="tAdapterData">
    <xsd:complexContent>
      <xsd:extension base="tns:tActivityData">
        <xsd:sequence>
          <xsd:element name="endpoint" type="xsd:string"/>
          <xsd:element name="direction" type="xsd:string"/>
          <xsd:element name="adapterType" type="xsd:string"/>
          <xsd:element name="priority" type="xsd:string" minOccurs="0"/>
          <xsd:element name="messageSize" type="xsd:string" minOccurs="0"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!--
    The header of the document contains some metadata.
  -->
  <xsd:complexType name="tSensorActionHeader">
    <xsd:sequence>
      <xsd:element name="processName" type="xsd:string"/>
      <xsd:element name="processVersion" type="xsd:string"/>
      <xsd:element name="processID" type="xsd:long"/>
      <xsd:element name="midTierInstance" type="xsd:string"/>
    </xsd:sequence>
    <xsd:attribute name="actionName" use="required" type="xsd:string"/>
  </xsd:complexType>
              
  <!--
 Sensor Action data is presented in the form of a header and potentially many
 data elements depending on how many sensors associated to the sensor action
 marked the data as interesting.
  -->
  <xsd:complexType name="tSensorActionData">
    <xsd:sequence>
      <xsd:element name="header" type="tns:tHeaderInfo"/>
      <xsd:element name="payload" type="tns:tSensorData" minOccurs="1"
                   maxOccurs="1"/>
    </xsd:sequence>
  </xsd:complexType>
<!--
  <xsd:simpleType name="tActivityEvalPoint">
    <xsd:restriction>
      <xsd:enumeration value="start"/>
      <xsd:enumeration value="complete"/>
      <xsd:enumeration value="fault"/>
      <xsd:enumeration value="compensate"/>
      <xsd:enumeration value="retry"/>
    </xsd:restriction>
  </xsd:simpleType>

  <xsd:simpleType name="tNotificationAction">
    <xsd:restriction>
      <xsd:enumeration value="creation"/>
      <xsd:enumeration value="statusUpdate"/>
    </xsd:restriction>
  </xsd:simpleType>
-->
  
  <!--
    The process sensor value header comprises of a timestamp
    where the sensor was triggered and the sensor metadata
  -->
  <xsd:complexType name="tProcessSensorValueHeader">
    <xsd:sequence>
      <xsd:element name="timestamp" type="xsd:dateTime"/>
      <xsd:element ref="tns:sensor"/>
    </xsd:sequence>
  </xsd:complexType>

  <!--
    Extend tActivityData to include more elements
  -->
  <xsd:complexType name="tProcessActivityData">
    <xsd:complexContent>
      <xsd:extension base="tns:tActivityData">
        <xsd:sequence>
          <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="evalTime" type="xsd:long" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="retryCount" type="xsd:int" minOccurs="0"
 maxOccurs="1"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <!--
    Extend tVariableData to include more elements
  -->
  <xsd:complexType name="tProcessVariableData">
    <xsd:complexContent>
      <xsd:extension base="tns:tVariableData">
        <xsd:sequence>
          <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <!--
    Extend tFaultData to include more elements
  -->
  <xsd:complexType name="tProcessFaultData">
    <xsd:complexContent>
      <xsd:extension base="tns:tFaultData">
        <xsd:sequence>
          <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <!--
    Extend tAdapterData to include more elements
  -->
  <xsd:complexType name="tProcessAdapterData">
    <xsd:complexContent>
      <xsd:extension base="tns:tAdapterData">
        <xsd:sequence>
          <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

  <!--
    Extend tNotificationData to include more elements
  -->
  <xsd:complexType name="tProcessNotificationData">
    <xsd:complexContent>
      <xsd:extension base="tns:tNotificationData">
        <xsd:sequence>
          <xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
          <xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
 maxOccurs="1"/>
        </xsd:sequence>      
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!--
    Copy of tSensorData type with some modified types.
  -->
  <xsd:complexType name="tProcessSensorData">
    <xsd:sequence>
      <xsd:element name="activityData" type="tns:tProcessActivityData"
 minOccurs="0"/>
      <xsd:element name="faultData" type="tns:tProcessFaultData" minOccurs="0"/>
      <xsd:element name="adapterData" minOccurs="0"
 type="tns:tProcessAdapterData"/>
      <xsd:element name="variableData" type="tns:tProcessVariableData"
 minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="notificationData" type="tns:tProcessNotificationData"
 minOccurs="0"/>
    </xsd:sequence>
  </xsd:complexType>
  <!--
    A single process sensor value comprises of the sensor value metadata
    (sensor and timestamp) and the payload (the value) of the sensor
  -->
  <xsd:complexType name="tProcessSensorValue">
    <xsd:sequence>
      <xsd:element name="header" type="tns:tProcessSensorValueHeader"/>
      <xsd:element name="payload" type="tns:tProcessSensorData"/>
    </xsd:sequence>
  </xsd:complexType>

  <!--
    Process instance header. 
  -->
  <xsd:complexType name="tProcessInstanceInfo">
    <xsd:sequence>
      <xsd:element name="processName" type="xsd:string"/>
      <xsd:element name="processRevision" type="xsd:string"/>
      <xsd:element name="domain" type="xsd:string"/>
      <xsd:element name="instanceId" type="xsd:integer"/>
    </xsd:sequence>
  </xsd:complexType>

  <!--
    The list of sensor values comprises of a process header describing the 
    BPEL process with name, cube instance id etc. and a list of sensor values
    comprising of sensor metadata information and sensor values.
  -->
  <xsd:complexType name="tProcessSensorValueList">
    <xsd:sequence>
      <xsd:element name="process" type="tns:tProcessInstanceInfo" minOccurs="1"
 maxOccurs="1"/>
      <xsd:element name="sensorValue" type="tns:tProcessSensorValue" minOccurs="0"
 maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>
  
  <!-- The sensor list is the root element of the sensor.xml document in the 
       bpel process suitcase and is used to define sensors. -->
  <xsd:element name="sensors" type="tns:tSensorList"/>
  
  <!-- A sensor is used to monitor a particular aspect of a bpel process -->
  <xsd:element name="sensor" type="tns:tSensor"/>
  
  <!-- The actions element is the root element of the sensorAction.xml document
       in the bpel process suitcase and is used to define sensor actions. 
       Sensor actions define how to publish data captured by sensors -->
  <xsd:element name="actions" type="tns:tSensorActionList"/>  
  
  <!-- actionData elements are produced by the sensor framework and sent to the
       appropriate data publishers when sensors 'fire' -->
  <xsd:element name="actionData" type="tns:tSensorActionData"/>  
  
  <!-- This element is used when the client API is used to query sensor values 
       stored in the default reports schema -->
  <xsd:element name="sensorValues" type="tns:tProcessSensorValueList"/>
</xsd:schema>

18.8 Summary

This chapter describes how to set up and use sensors to monitor BPEL activities, variables, and faults during run time. This chapter also describes how to create sensor actions in Oracle BPEL Process Manager to publish sensor data as data objects in an Oracle BAM Server.