17 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:

Use Cases for Sensors
Overview of Sensor Concepts
Implementing Sensors and Sensor Actions in Oracle JDeveloper
Sensors and Oracle BPEL Control
Sensor Integration with Oracle Business Activity Monitoring
Sensor Public Views
Sensor Actions XSD File
Summary

17.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:

SOA_Oracle_Home\bpel\samples\tutorials\125.ReportsSchema

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

See:

Oracle BPEL Process Manager Order Booking Tutorial

17.2 Overview of Sensor Concepts

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

Activity sensors

Activity sensors are used to monitor the execution of activities within a BPEL process. For example, they can be used to monitor the execution time of an invoke activity or how long it takes to complete a scope. Along with the activity sensor, you can also monitor variables of the activity.
Variable sensors

Variable sensors are used to monitor variables (or parts of a variable) of a BPEL process. For example, variable sensors can be used to monitor the input and output data of a BPEL process.
Fault sensors

Fault sensors are used to monitor BPEL faults.

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

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

sensor.xml—contains the sensor definitions of a BPEL process
sensorAction.xml—contains the sensor action definitions of a BPEL process

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:

Name
Publish type

The publish type specifies the destination where the sensor data must be presented. You can configure the following publish types:
- Database—used to publish the sensor data to the reports schema in the database. The sensor data can then be queried using SQL.
- JMSQueue—used to publish the sensor data to a JMS queue
- JMSTopic—used to publish the sensor data to a JMS topic
- Custom—used to publish the data to a custom Java class
- JMS Adapter—uses the JMS adapter to publish to remote queues or topics and a variety of different JMS providers. The JMS Queue and JMS Topic publish types only publish to local JMS destinations.
List of sensors—the sensors for a sensor action

17.3 Implementing Sensors and Sensor Actions in Oracle JDeveloper

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

Figure 17-1 Sensors and Sensor Actions Displayed in Oracle JDeveloper

Description of the illustration sensor1.gif

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 SOA_Oracle_Home\bpel\samples\demos

17.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 Oracle JDeveloper, as shown in Figure 17-2. Activities that have sensors associated with them are identified with a magnifying glass in Oracle JDeveloper.

Figure 17-2 Creating an Activity Sensor

Description of the illustration sensor2.gif

The Evaluation Time attribute shown in Figure 17-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 17-3.

Figure 17-3 Creating a Variable Sensor

Description of the illustration sensor3.gif

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 17-4.

Figure 17-4 Creating a Fault Sensor

Description of the illustration sensor4.gif

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>

17.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 create a sensor action, as shown in Figure 17-5, and associate it with the LoanApplicationSensor.

Figure 17-5 Creating a Sensor Action

Description of the illustration sensor5.gif

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 17-6, and associate it with both CreditRatingSensor and LoanApplicationSensor.

Figure 17-6 Creating an Additional Sensor Action

Description of the illustration sensor6.gif

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 and 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 17-7.

Figure 17-7 Creating a Sensor Action with a Filter

Description of the illustration sensor_fltr.gif

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, JMS topic, and JMS Adapter), then you can create a sensor action with the custom publish type, as shown in Figure 17-8. The name in the Publish Target field denotes a fully qualified Java class name that must be implemented.

Figure 17-8 Using the Custom Publish Type

Description of sensor_custom.gif follows

Description of the illustration sensor_custom.gif

17.3.3 Publishing to Remote Topics and Queues

The JMS Queue and JMS Topic publish types only publish to local JMS destinations. If you want to publish sensor data to remote topics and queues, use the JMS adapter publish type, as shown in Figure 17-9.

Figure 17-9 Using the JMS Adapter Publish Type

Description of the illustration sensor7.gif

In addition to enabling you to publish sensor data to remote topics and queues, the JMS adapter supports a variety of different JMS providers, including:

Third-party JMS providers such as Tibco JMS, IBM WebSphere MQ JMS, and SonicMQ
Oracle Enterprise Messaging Service (OEMS) providers such as memory/file and database

If you select the JMS Adapter publish type, you must create an entry in the oc4j-ra.xml file. Use the JMS connection name property in the Sensor Actions dialog to point to the proper entry in the oc4j-ra.xml file.

See Also:

Oracle Adapters for Files, FTP, Databases, and Enterprise Messaging User's Guide for details about the JMS adapter

17.3.4 Creating a Custom Data Publisher

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

Select Project Properties > Libraries > Add Jar/Directory from the Tools main menu.
Browse and select SOA_Oracle_Home\bpel\lib\orabpel.jar.

Description of the illustration sensor_pub1.gif
Create a new Java class.

The package and class name must match the publish target name of the sensor action.
Implement the com.oracle.bpel.sensor.DataPublisher interface.

This updates the source file and fills in the methods and import statements of the DataPublisher interface.
Using the Oracle JDeveloper editor, implement the publish method of the DataPublisher interface, as shown in the following sample custom data publisher class.

Description of the illustration sensor_customdp.gif
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.

17.3.5 Registering the Sensors and Sensor Actions in bpel.xml

Oracle JDeveloper 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.

17.4 Sensors and Oracle BPEL Control

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 Control at

http://localhost:port/BPELConsole

You can also select Start > All Programs > Oracle - Oracle_Home > Oracle BPEL Process Manager > BPEL Control.

17.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 Oracle JDeveloper. In Oracle BPEL Control, 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 17-10 is displayed.

Figure 17-10 Sensor Data on the BPEL Processes Tab of Oracle BPEL Control

Description of sensor_console1.gif follows

Description of the illustration sensor_console1.gif

17.4.2 Viewing Sensor Data

The console provides support to monitor sensors for which a BpelReportsSchema sensor action is defined. In Oracle BPEL Control, 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 17-11 is displayed.

Figure 17-11 Sensor Data on the Instances Tab of Oracle BPEL Control

Description of sensor_console2.gif follows

Description of the illustration sensor_console2.gif

Note:

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

17.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:

Creating a Connection to Oracle BAM Server
Creating a Sensor
Creating a BAM Sensor Action

These instructions assume you have installed and configured Oracle BAM.

17.5.1 Creating a Connection to Oracle BAM Server

Note:

Only one Oracle BAM Server per BPEL project is currently supported.

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

Select Connection Navigator from the View main menu in Oracle JDeveloper.
Right click BAM Server.
Select New BAM Server Connection.
Click Next on the Welcome page.
Provide a name for connecting to the server.
Click Next.

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. This field is case sensitive. If you do not enter the correct case sensitive name, you receive an authentication failure error.
Use secure HTTP protocol	Select this check box if you want to use secure HTTP (HTTP/S) to connect to the Oracle BAM Server. Otherwise, HTTP is used.

Click Next.
Test the connection by clicking Test Connection. If the connection was successful, the following message appears:
```
Success.
```
Click Finish.

Oracle JDeveloper 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 run time 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 Control to update these values.

See Also:

17.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. Since you map the sensor data to Oracle BAM Server data objects, only one variable is allowed for the sensor. If the variable has message parts, then there should be only one message part. This variable must not be defined inline in the WSDL. Only XSD element definitions are supported.
An activity sensor containing exactly one sensor variable.

See Also:

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

17.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.

Right click Sensor Actions in the Structure section of Oracle JDeveloper.
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 the illustration sensors_bam.gif

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 BAM Data Object Chooser window to select the data object in Oracle BAM Server in which you want to publish the sensor data. You must have already created a connection to Oracle BAM Server in order to select data objects.
Enable Batching	The data cached by default by the Oracle BAM component of the Oracle BPEL Process Manager run time 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. See Step 4 for additional details.
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.
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).

WARNING:

If you restart Oracle BPEL Server, any messages currently being batched are lost. Ensure that all messages have completed batching before restarting Oracle BPEL Server.

Notes:

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.

If you want to specify custom batch parameter settings, click Set Batch Parameters.

The Set Batch Parameters window appears.
Deselect the Use Default Batch Parameters check box and provide customized values in the fields below. If you provide customized values and then select this check box again, the settings revert to the default values.

Description of the illustration sensors_bambatch.gif

Enter the following details:

Field	Description
Batch size lower limit	Use the default value of 1000 or specify a lower batch limit. This parameter controls the minimum number of rows in the cache. With this parameter, the data remains in the Oracle BPEL Process Manager run-time cache until the queue size reaches at least this limit or a timeout occurs.
Batch size upper limit	Use the default value of 5000 or specify an upper batch limit. This parameter controls the maximum number of rows in the cache. With this parameter, the Oracle BPEL Process Manager run time flushes the data to Oracle BAM Server prior to the upper limit being reached.
Batch timeout (milliseconds)	Specify the timeout in minutes. The default value is 50 milliseconds. When the timeout occurs, the BPEL run time flushes any data in the queue to Oracle BAM Server.

Click OK to close the Set Batch Parameters window and the Create Sensor Action window.

17.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 Control.

A set of public views is exposed to allow SQL access to sensor values from literally any application interested in the data.

17.6.1 BPM Schema

The database publisher persists the sensor data in a predefined relational schema in the database. The following public views can be used from a client (Oracle Warehouse, OracleAS Portal, and so on) to query the sensor values using SQL.

Note:

In Table 17-1 through Table 17-5, 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_PROCESS_INSTANCES

This view provides an overview of all the process instances of Oracle BPEL Process Manager.

Table 17-1 BPEL_PROCESS_INSTANCES View

Attribute Name	SQL Type	Attribute Size	Indexed or Unique?	Null?	Comment
`INSTANCE_KEY`	`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	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	Evaluation time of the process instance in milliseconds
`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`.

BPEL_ACTIVITY_SENSOR_VALUES

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

Table 17-2 BPEL_ACTIVITY_SENSOR_VALUES View

Attribute Name	SQL Type	Attribute Size	Indexed or Unique?	Null?	Comment
`ID`	`NUMBER`	--	PK	N	Unique ID
`INSTANCE_KEY`	`NUMBER`	--	U1,1	N	ID of process instance
`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
`SENSOR_NAME`	`NVARCHAR2`	100	U1,2	N	The name of the sensor that fired
`SENSOR_TARGET`	`NVARCHAR2`	256	--	N	The target of the fired sensor
`ACTION_NAME`	`NVARCHAR2`	100	U1,3	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 BPEL 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	Evaluation time of the activity in milliseconds

BPEL_FAULT_SENSOR_VALUES

This view contains all the fault sensor values.

Table 17-3 BPEL_FAULT_SENSOR_VALUES View

Attribute Name	SQL Type	Attribute Size	Indexed or Unique?	Null?	Comment
`ID`	`NUMBER`	--	PK	N	Unique ID
`INSTANCE_KEY`	`NUMBER`	--	U1,1	N	BPEL process 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
`SENSOR_NAME`	`NVARCHAR2`	100	U1,2	N	The name of the sensor that fired
`SENSOR_TARGET`	`NVARCHAR2`	256	--	N	The target of the fired sensor
`ACTION_NAME`	`NVARCHAR2`	100	U1,3	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 is 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

BPEL_VARIABLE_SENSOR_VALUES

This view contains all the variable sensor values.

Table 17-4 BPEL_VARIABLE_SENSOR_VALUES View

Attribute Name	SQL Type	Attribute Size	Indexed or Unique?	Null?	Comment
`ID`	`NUMBER`	--	PK	N	Unique ID
`INSTANCE_KEY`	`NUMBER`	--	U1,1	N	BPEL process 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
`SENSOR_NAME`	`NVARCHAR2`	100	U1,2	N	Name of the sensor that fired
`SENSOR_TARGET`	`NVARCHAR2`	256	--	N	Target of the sensor
`ACTION_NAME`	`NVARCHAR2`	100	U1,3	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
`EVAL_POINT`	`VARCHAR2`	30	--	Y	Evaluation point of the corresponding activity sensor
`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
`SCHEMA_NAMESPACE`	`NVARCHAR2`	256	--	Y	Namespace of variable sensor value
`SCHEMA_DATATYPE`	`NVARCHAR2`	256	--	Y	Datatype of the variable sensor value
`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

BPMERRORS

This view provides an overview of all errors from BPM services.

Table 17-5 BPMERRORS 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	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 BPM component that caused the error
`THREAD_ID`	`VARCHAR2`	200	--	N	The Java thread name in which the error occurred.
`STACKTRACE`	`CLOB`	--	--	N	The Java stack trace

17.7 Sensor Actions XSD File

The section provides a sample sensor action schema that you can import into Oracle JDeveloper. 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>

17.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.