Oracle® BPEL Process Manager Developer's Guide 10g (10.1.3.1.0) Part Number B28981-03 |
|
|
View PDF |
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:
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.
You can define the following types of sensors, either through Oracle JDeveloper or manually by providing sensor configuration files.
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 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 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
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
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
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:
TheLoanDemoPlus
tutorial, at SOA_Oracle_Home
\bpel\samples\demos
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.
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.
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.
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>
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
.
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
.
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.
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.
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.
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 adapterTo 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.
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.
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 theCLASSPATH
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.
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.
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.
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
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
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.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.
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.
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 sensorsWhen 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.
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.
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.
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.
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.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 .
|
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 |
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 |
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 |
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 |
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>