|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) B14448-03 |
|
 Previous |
 Next |
|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) B14448-03 |
|
|
Previous |
Next |
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: Oracle_Home\integration\orabpel\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 JDeveloper BPEL Designer 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 monitor variables of the activity also.
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 JDeveloper BPEL Designer, 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
List of sensors—the sensors for a sensor action
In JDeveloper BPEL Designer, sensors and sensor actions are displayed as part of the process tree structure, as shown in Figure 18-1.
Figure 18-1 Sensors and Sensor Actions Displayed in JDeveloper BPEL Designer
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 Oracle_Home\integration\orabpel\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 JDeveloper BPEL Designer, as shown in Figure 18-2. Activities that have sensors associated with them are indicated with a magnifying glass.
The Evaluation Time attribute shown in Figure 18-2 controls the point at which the sensor fires. You can select from the following:
Activation—The sensor fires just before the activity is executed.
Completion—The sensor fires just after the activity is executed.
Fault—The sensor fires if a fault occurs during the execution of the activity. Select this value only for sensors that monitor simple activities.
Compensation—The sensor fires when the associated scope activity is compensated. Select this value only for sensors that monitor scopes.
Retry—The sensor fires when the associated invoke activity is retried.
All—Monitoring occurs during all of the preceding phases.
A new entry is created in the sensor.xml file, as follows:
<sensor sensorName="CreditRatingSensor"
classname="oracle.tip.pc.services.reports.dca.agents.BpelActivitySensorAgent"
kind="activity"
target="getCreditRating">
<activityConfig evalTime="all">
<variable outputNamespace="http://www.w3.org/2001/XMLSchema"
outputDataType="int"
target="$crOutput/payload//services:rating"/>
</activityConfig>
</sensor>
If you want to record all the incoming loan requests, create a variable sensor for the variable input, as shown in Figure 18-3.
A new entry is created in the sensor.xml file, as follows:
<sensor sensorName="LoanApplicationSensor"
classname="oracle.tip.pc.services.reports.dca.agents.BpelVariableSensorAgent"
kind="variable"
target="$input/payload">
<variableConfig outputNamespace="http://www.autoloan.com/ns/autoloan"
outputDataType="loanApplication"/>
</sensor>
If you want to monitor faults from the identity service, create a fault sensor, as shown in Figure 18-4.
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 you create a sensor action, as shown in Figure 18-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 18-6, and associate it with both CreditRatingSensor and LoanApplicationSensor.
Figure 18-6 Creating an Additional Sensor Action
A new entry is created in the sensorAction.xml file, as follows:
<action name="PersistingAction"
enabled="true"
publishType="BPELReportsSchema">
<sensorName>LoanApplicationSensor</sensorName>
<sensorName>CreditRatingSensor</sensorName>
</action
The data of one sensor can be published to multiple endpoints. In the two preceding code samples, the data of LoanApplicationSensor is published to a JMS queue as well as to the reports schema in the database.
If you want to monitor loan requests for which the loan amount is greater than $100,000, you can create a sensor action with a filter, as shown in Figure 18-7.
Figure 18-7 Creating a Sensor Action with a Filter
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:
|
If you have special requirements for a sensor action that cannot be accomplished by using the built-in publish types, database, JMS queue, and JMS topic, then you can create a sensor action with the custom publish type, as shown in Figure 18-8. The name in the Publish Target field denotes a fully qualified Java class name that must be implemented.
Figure 18-8 Using the Custom Publish Type
To create a custom data publisher, double-click your BPEL project in JDeveloper BPEL Designer and do the following:
Open Project Properties, then Libraries, then OraBPEL, and add it to the Selected Libraries list.
This adds the required BPEL libraries to your BPEL project.
Create a new Java class.
The package and class name must match the publish target name of the sensor action.
Select Tools, then Implement Interface, then Available Interfaces, and then DataPublisher.
This updates the source file and fills in the methods and import statements of the DataPublisher interface.
Using the JDeveloper BPEL Designer 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. |
JDeveloper BPEL Designer automatically updates the process deployment file bpel.xml to include appropriate properties for sensors and sensor actions, as follows:
<configurations> … <property name="sensorLocation">sensor.xml</property> <property name="sensorActionLocation">sensorAction.xml</property> … <property name="SLACompletionTime">P0YT1.5S</property> </configurations>
You can specify additional properties with <property name= ...>, as shown in the preceding code sample.
The console provides support to view the metadata of sensors and sensor actions as well as the sensor data created as part of the process execution. Access Oracle BPEL Console at
http://localhost:portnumber/BPELConsole
You can also select Start, then All Programs, then Oracle - Oracle_Home, then Oracle BPEL Process Manager 10.1.2, and then BPEL Console.
After the BPEL process is deployed to Oracle BPEL Process Manager, you can view the definitions of sensors and sensor actions without going back to JDeveloper BPEL Designer. In Oracle BPEL Console, click the BPEL Processes tab and choose the process for which you want to see sensor definitions. Click the Sensors link. A page similar to Figure 18-9 is displayed.
Figure 18-9 Sensor Data on the BPEL Processes Tab of Oracle BPEL Console
The console provides support to monitor sensors for which a BpelReportsSchema sensor action is defined. In Oracle BPEL Console, click the Instances tab and choose the process instance for which you want to see the sensor data created as the result of process execution. A page similar to Figure 18-10 is displayed.
Figure 18-10 Sensor Data on the Instances Tab of Oracle BPEL Console
|
Note: Only sensors associated with a database sensor action are displayed in the console. Sensors associated with a JMS queue, JMS topic, or custom sensor action are not displayed. |
Oracle Business Activity Monitoring (BAM) enables you to monitor business services and processes in an enterprise, correlate key performance indicators (KPIs), and change business processes or take corrective actions if the business environment changes. Oracle BAM enables you to build real-time operational dashboards and monitoring and alerting applications over the Web. Using this technology, you build interactive, real-time dashboards and proactive alerts to monitor business services and processes.
You can create sensor actions in Oracle BPEL Process Manager to publish sensor data as data objects on an Oracle BAM Server. When you create the sensor action, you can select an Oracle BPEL Process Manager variable or activity sensor that you want to monitor and the data object in Oracle BAM Server in which you want to publish the sensor data. Oracle BAM Server publishes the data objects and types information in WSDL files. It uses basic HTTP authentication to enable access to these files.
This section contains the following topics:
These instructions assume you have installed and configured Oracle BAM. Visit the Oracle BAM Web site on the Oracle Technology Network for specific details about Oracle BAM:
http://www.oracle.com/technology/products/integration/bam/index.html
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 JDeveloper BPEL Designer.
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. |
| Use secure HTTP protocol | Select this check box if you want to use secure HTTP (HTTPS) to connect to the Oracle BAM Server. Otherwise, HTTP is used. |
Click Next.
Test the connection by clicking Test Connection. If the connection was successful, the following message appears:
Success.
Click Finish.
JDeveloper BPEL Designer reserves the following property names. These property names define values for the Oracle BAM Server connection you just created.
bamserver.hostname
bamserver.protocol
bamserver.username
bamserver.password
bamserver.port
bamserver.domain
These property names are added in the Preferences tab of the Deployment Descriptor Properties window. If your BPEL process uses a BAM sensor action and you want runtime to use a different Oracle BAM Server than the one used during design time, you must update these values prior to BPEL process deployment. If you have already deployed the process, then you can use Oracle BPEL Console to update these values.
You must create one of the following types of sensors prior to creating a BAM sensor action:
A variable sensor or an activity sensor containing one sensor variable. This sensor contains the BPEL variable that you want to monitor. Only one variable is allowed for the sensor. If the variable has message parts, there must be only one message part.
An activity sensor that does not have a variable
|
See Also: "Implementing Sensors and Sensor Actions in JDeveloper BPEL Designer" for instructions on creating sensors |
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 JDeveloper BPEL Designer.
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 Data Object Chooser window to select the data object in Oracle BAM Server in which you want to publish the sensor data. |
| Enable Batching | The data cached by default by the Oracle BAM component of the Oracle BPEL Process Manager runtime is flushed (sent) to Oracle BAM Server periodically. The decision to periodically send the data is based on upper and lower limit parameter settings on the Set Batch Parameters window. The Oracle BAM component may decide to send data prior to a batch timeout if the cache has a number of data objects between the lower and upper limit values. Disable batching by unselecting this check box.
To modify the batch parameters, click Set Batch Parameters. This displays the Set Batch Parameters window. Select the check box to use default batch parameter settings. If you deselect this check box, provide customized values in the fields below. If you provide customized values and then select this check box, the settings revert to the default values. |
| Operation | Select to Delete, Update, Insert, or Upsert a row in the Oracle BAM Server database. Upsert first attempts to update a row if it exists. If the row does not exit, it is inserted.
See the Oracle Business Activity Monitoring Installation Guide for additional details about these batch process commands: http://www.oracle.com/technology/products/integration/bam/htdocs/1012_support.html#docs |
| Available Keys/Selected Keys | If you selected the Delete, Update, or Upsert operation, you must also select a column name in the Oracle BAM server database to use as a key to determine the row with which this sensor object corresponds. A key can be a single column or a composite key consisting of multiple columns. Select a key and click the > button. To select all, click the >> button. |
| Map File | Provide a file name to create a mapping between the sensor (selected in the Select Sensor list) and the Oracle BAM Server data object (selected in the Data Object list). You can also invoke a mapper window by clicking the Create Mapping icon (second icon) or Edit Mapping icon (third icon). |
|
Note: After you click the Create Mapping or Edit Mapping or OK button on the Create Sensor Action window, you must explicitly save the BPEL file. |
The sensor framework of Oracle BPEL Process Manager provides the functionality to persist sensor values created by processing BPEL instances in a relational schema stored in the dehydration store of Oracle BPEL Process Manager. The data is used to display the sensor values of a process instance in Oracle BPEL Console.
Use the following public views for SQL access to sensor values from any application interested in the data. These views are populated when a sensor action is used to publish to a database.
The database publisher persists the sensor data in a predefined relational schema in the database. You can use SQL to query the sensor values in the following public views from clients such as Oracle Warehouse Builder or OracleAS Portal.
|
Note: In Table 18-1 through Table 18-7, the Indexed or Unique? column provides unique index names and the order of the attributes. For example, U1,2 means that the attribute is the second one in a unique index named U1. PK means primary key. |
This view contains all the deployed BPEL processes across the Oracle BPEL Process Manager domains.
Table 18-1 BPEL_ALL PROCESSES View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
256 |
-- |
N |
The base URL of the BPEL suite |
|
|
|
256 |
-- |
N |
The URL of the sensor file |
|
|
|
256 |
-- |
N |
The URL of the sensor action file |
BPEL_PROCESS_ANALYSIS_REPORT
This view contains all the process instances of Oracle BPEL Process Manager.
Table 18-2 BPEL_PROCESS_ANALYSIS_REPORT View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique instance ID |
|
|
|
100 |
-- |
N |
Name of the BPEL process |
|
|
|
50 |
-- |
N |
Revision of the BPEL process |
|
|
|
50 |
-- |
N |
Oracle BPEL Process Manager domain name |
|
|
|
50 |
-- |
Y |
User-defined title of the BPEL process |
|
|
|
-- |
-- |
Y |
State of the BPEL process instance |
|
|
|
-- |
-- |
Y |
Text presentation of the state attribute |
|
|
|
-- |
-- |
Y |
User-defined priority of the BPEL process instance |
|
|
|
100 |
-- |
Y |
User-defined status of the BPEL process |
|
|
|
100 |
-- |
Y |
User-defined stage property of a BPEL process |
|
|
|
100 |
-- |
Y |
User-defined conversation ID of a BPEL process |
|
|
|
-- |
-- |
N |
The creation time stamp of the process instance |
|
|
|
-- |
-- |
Y |
Time stamp when the process instance was modified |
|
|
|
-- |
-- |
Y |
Date portion of |
|
|
|
-- |
-- |
Y |
Hour portion of |
|
|
|
-- |
-- |
Y |
Time in milliseconds that a process takes to complete |
|
|
|
-- |
-- |
Y |
SLA completion time in milliseconds. This is populated with the value of an optional property you can set in <configurations> ... <property name="SLACompletionTime">POYT1.5S</property> |
|
|
|
1 |
-- |
Y |
|
This view is a subset of BPEL_PROCESS_ANALYSIS_REPORT and contains those process instances for which sensors are defined for the corresponding BPEL process and for which a sensor has fired at least once.
Table 18-3 BPEL_SENSOR_PROCESS_INSTANCES View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique instance ID |
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
50 |
-- |
Y |
User-defined title of the BPEL process |
|
|
|
-- |
-- |
Y |
State of the BPEL process instance |
|
|
|
-- |
-- |
Y |
Text presentation of the state attribute |
|
|
|
-- |
-- |
Y |
User-defined priority of the BPEL process instance |
|
|
|
100 |
-- |
Y |
User-defined status of the BPEL process |
|
|
|
100 |
-- |
Y |
User-defined stage property of a BPEL process |
|
|
|
100 |
-- |
Y |
User-defined conversation ID of a BPEL process |
|
|
|
-- |
-- |
N |
Creation time stamp of the instance |
|
|
|
-- |
-- |
Y |
Time stamp when the process instance was modified |
|
|
|
-- |
-- |
Y |
Date portion of |
|
|
|
-- |
-- |
Y |
Hour portion of |
|
|
|
-- |
-- |
Y |
Time in milliseconds that a process takes to complete |
|
|
|
-- |
-- |
Y |
SLA completion time in milliseconds. This is populated with the value of an optional property you can set in <configurations> ... <property name="SLACompletionTime">POYT1.5S</property> |
|
|
|
1 |
-- |
Y |
|
|
|
|
-- |
U1 |
N |
Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs |
This view contains all the activity sensor values of the monitored BPEL processes.
Table 18-4 BPEL_ACTIVITY_SENSOR_VALUES View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique ID |
|
|
|
-- |
-- |
N |
ID of process instance |
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
100 |
-- |
N |
The name of the sensor that fired |
|
|
|
256 |
-- |
N |
The target of the fired sensor |
|
|
|
100 |
-- |
N |
The name of the sensor action |
|
|
|
256 |
-- |
Y |
The filter of the action |
|
|
|
-- |
-- |
N |
The creation date of the activity sensor value |
|
|
|
-- |
-- |
Y |
The time stamp of last modification |
|
|
|
-- |
-- |
Y |
Date portion of |
|
|
|
-- |
-- |
Y |
Hour portion of |
|
|
|
1 |
-- |
Y |
|
|
|
|
100 |
-- |
N |
The name of the BPEL activity |
|
|
|
30 |
-- |
N |
The type of the BPEL activity |
|
|
|
30 |
-- |
Y |
The state of the activity |
|
|
|
20 |
-- |
N |
The evaluation point of the activity sensor |
|
|
|
2000 |
-- |
Y |
An error message |
|
|
|
-- |
-- |
Y |
The number of retries of the activity |
|
|
|
-- |
-- |
Y |
Time in milliseconds that an activity takes to complete |
|
|
|
-- |
NU1 |
N |
Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs |
This view contains all the fault sensor values.
Table 18-5 BPEL_FAULT_SENSOR_VALUES View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique ID |
|
|
|
-- |
-- |
N |
ID of process instance |
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
100 |
-- |
N |
The name of the sensor that fired |
|
|
|
256 |
-- |
N |
The target of the fired sensor |
|
|
|
100 |
-- |
N |
The name of the sensor action |
|
|
|
256 |
-- |
Y |
The filter of the action |
|
|
|
-- |
-- |
N |
The creation date of the activity sensor value |
|
|
|
-- |
-- |
Y |
The time stamp of last modification |
|
|
|
-- |
-- |
Y |
|
|
|
|
-- |
-- |
Y |
Hour portion of |
|
|
|
1 |
-- |
Y |
|
|
|
|
100 |
-- |
N |
The name of the BPEL activity |
|
|
|
30 |
-- |
N |
The type of the BPEL activity |
|
|
|
-- |
-- |
Y |
The fault message |
|
|
|
-- |
NU1 |
N |
Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs |
This view contains all the variable sensor values.
Table 18-6 BPEL_VARIABLE_SENSOR_VALUES View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique ID |
|
|
|
-- |
-- |
N |
ID of process instance |
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
100 |
-- |
N |
Name of the sensor that fired |
|
|
|
256 |
-- |
N |
Target of the sensor |
|
|
|
100 |
-- |
N |
Name of the action |
|
|
|
256 |
-- |
Y |
Filter of the action |
|
|
|
-- |
-- |
Y |
ID of corresponding activity sensor value |
|
|
|
-- |
-- |
N |
Creation date |
|
|
|
-- |
-- |
N |
Date portion of |
|
|
|
-- |
-- |
N |
Hour portion of |
|
|
|
256 |
-- |
N |
The name of the BPEL variable |
|
|
|
1 |
-- |
Y |
|
|
|
|
256 |
-- |
-- |
-- |
|
|
|
100 |
-- |
N |
The name of the activity or event that updated the variable |
|
|
|
100 |
-- |
N |
The type of the BPEL activity or event |
|
|
|
-- |
-- |
N |
The value type of the variable (corresponds to |
|
|
|
2000 |
-- |
Y |
The value of string-like variables |
|
|
|
-- |
-- |
Y |
The value of number-like variables (such as |
|
|
|
-- |
-- |
Y |
The value of date-like variables |
|
|
|
-- |
-- |
Y |
The value of binary data variables |
|
|
|
-- |
-- |
Y |
The value of CLOB-like variables (XML) |
|
|
|
-- |
NU1 |
N |
Corresponds to the instance key used in the Oracle BPEL Process Manager client APIs |
This view gives an overview of all the errors from BPEL services.
Table 18-7 BPEL_ERRORS View
| Attribute Name | SQL Type | Attribute Size | Indexed or Unique? | Null? | Comment |
|---|---|---|---|---|---|
|
|
|
-- |
PK |
N |
Unique ID |
|
|
|
100 |
U1,1 |
N |
Name of the BPEL process |
|
|
|
50 |
U1,2 |
N |
Revision of the BPEL process |
|
|
|
50 |
U1,3 |
N |
Oracle BPEL Process Manager domain name |
|
|
|
-- |
-- |
N |
The creation date of the activity sensor value |
|
|
|
-- |
-- |
N |
Date portion of |
|
|
|
-- |
-- |
N |
Hour portion of |
|
|
|
-- |
-- |
N |
Error code |
|
|
|
-- |
-- |
N |
Type of the error |
|
|
|
-- |
-- |
N |
Severity of the error |
|
|
|
200 |
-- |
N |
Name of the error |
|
|
|
2000 |
-- |
Y |
A short description of the error |
|
|
|
2000 |
-- |
Y |
A description on how to fix the error |
|
|
|
4000 |
-- |
Y |
The context of the error |
|
|
|
-- |
-- |
N |
The BPEL component that caused the error |
|
|
|
200 |
-- |
N |
The Java thread name where the error occurred |
|
|
|
-- |
-- |
N |
The Java stack trace |
The section provides a sample sensor action schema that you can import into JDeveloper BPEL Designer. This schema is also relevant to custom data publishers.
<?xml version="1.0" encoding="utf-8"?>
<!--
This schema contains the sensor definition. Sensors monitor data
and execute callbacks appropriately.
-->
<xsd:schema blockDefault="#all" elementFormDefault="qualified"
targetNamespace="http://xmlns.oracle.com/bpel/sensor"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://xmlns.oracle.com/bpel/sensor">
<xsd:simpleType name="tSensorActionPublishType">
<xsd:annotation>
<xsd:documentation>
This enumeration lists the possibe publishing types for probes.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="BpelReportsSchema"/>
<xsd:enumeration value="JMSQueue"/>
<xsd:enumeration value="JMSTopic"/>
<xsd:enumeration value="Custom"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="tSensorActionProperty">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="name" use="required" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<!--
Attributes of a sensor action
-->
<xsd:attributeGroup name="tSensorActionAttributes">
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="enabled" type="xsd:boolean" use="optional"
default="true"/> <xsd:attribute name="filter" type="xsd:string"/>
<xsd:attribute name="publishName" type="xsd:string" use="required"/>
<xsd:attribute name="publishType" type="tns:tSensorActionPublishType"
use="required"/>
<!--
the name of the JMS Queue/Topic or custom java API, ignored for other
publishTypes
-->
<xsd:attribute name="publishTarget" type="xsd:string" use="optional"/>
</xsd:attributeGroup>
<!--
The sensor action type. A sensor action consists:
+ unique name
+ effective date
+ expiration date - Optional. If not defined, the probe is active
indefinitely.
+ filter (to potentially suppress data publishing even if a sensor marks
it as interesting). - Optional. If not defined, no filter is
used.
+ publishName A name of a publisher
+ publishType What to do with the sensor data?
+ publishTarget Name of a JMS Queue/Topic or custom publisher.
+ potentially many sensors.
-->
<xsd:complexType name="tSensorAction">
<xsd:sequence>
<xsd:element name="sensorName" type="xsd:string" minOccurs="1"
maxOccurs="unbounded"/>
<xsd:element name="property" minOccurs="0" maxOccurs="unbounded"
type="tns:tSensorActionProperty"/>
</xsd:sequence>
<xsd:attributeGroup ref="tns:tSensorActionAttributes"/>
</xsd:complexType>
<!--
define a listing of sensor actions in a single document. It might be a good
idea to
have one sensor action list per business process.
-->
<xsd:complexType name="tSensorActionList">
<xsd:sequence>
<xsd:element name="action" type="tns:tSensorAction" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="tSensorKind">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="fault"/>
<xsd:enumeration value="variable"/>
<xsd:enumeration value="activity"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="tActivityConfig">
<xsd:annotation>
<xsd:documentation>
The configuration part of an activity sensor comprises of a mandatory
'evalTime' attribute
and an optional list of variable configurations
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig">
<xsd:sequence>
<xsd:element name="variable" type="tns:tActivityVariableConfig"
maxOccurs="unbounded" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="evalTime" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tAdapterConfig">
<xsd:annotation>
<xsd:documentation>
The configuration part of a adapter activity extends the activty
configuration with additional attributes for adapters
</xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="tns:tActivityConfig">
<xsd:attribute name="headerVariable" use="required" type="xsd:string"/>
<xsd:attribute name="partnerLink" use="required" type="xsd:string"/>
<xsd:attribute name="portType" use="required" type="xsd:string"/>
<xsd:attribute name="operation" use="required" type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tVariableConfig">
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig">
<xsd:attribute name="outputDataType" use="required" type="xsd:string"/>
<xsd:attribute name="outputNamespace" use="required" type="xsd:string"/>
<xsd:attribute name="queryName" use="optional" type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tActivityVariableConfig">
<xsd:complexContent>
<xsd:extension base="tns:tVariableConfig">
<xsd:attribute name="target" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tFaultConfig">
<xsd:complexContent>
<xsd:extension base="tns:tSensorConfig"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tNotificationSvcConfig">
<xsd:complexContent>
<xsd:extension base="tns:tActivityConfig">
<xsd:attribute name="inputVariable" use="required" type="xsd:string"/>
<xsd:attribute name="outputVariable" use="required" type="xsd:string"/>
<xsd:attribute name="operation" use="required" type="xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tSensorConfig">
<xsd:sequence>
<xsd:element name="action" type="tns:tInlineSensorAction" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tInlineSensorAction">
<xsd:complexContent>
<xsd:restriction base="tns:tSensorAction"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tSensor">
<xsd:sequence>
<xsd:element name="activityConfig" type="tns:tActivityConfig"
minOccurs="0"/>
<xsd:element name="adapterConfig" type="tns:tAdapterConfig" minOccurs="0"/>
<xsd:element name="faultConfig" type="tns:tFaultConfig" minOccurs="0"/>
<xsd:element name="notificationConfig" type="tns:tNotificationSvcConfig"
minOccurs="0"/>
<xsd:element name="variableConfig" type="tns:tVariableConfig"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="sensorName" use="required" type="xsd:string"/>
<xsd:attribute name="kind" use="required" type="tns:tSensorKind"/>
<xsd:attribute name="classname" use="required" type="xsd:string"/>
<xsd:attribute name="target" use="required" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="tSensorList">
<xsd:sequence>
<xsd:element name="sensor" type="tns:tSensor" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tRouterData">
<xsd:sequence>
<xsd:element name="header" type="tns:tHeaderInfo"/>
<xsd:element name="payload" type="tns:tSensorData"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tHeaderInfo">
<xsd:sequence>
<xsd:element name="processName" type="xsd:string"/>
<xsd:element name="processRevision" type="xsd:string"/>
<xsd:element name="domain" type="xsd:string"/>
<xsd:element name="instanceId" type="xsd:integer"/>
<xsd:element name="midTierInstance" type="xsd:string"/>
<xsd:element name="timestamp" type="xsd:dateTime"/>
<xsd:element name="sensor" type="tns:tSensor"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tSensorData">
<xsd:sequence>
<xsd:element name="activityData" type="tns:tActivityData" minOccurs="0"/>
<xsd:element name="faultData" type="tns:tFaultData" minOccurs="0"/>
<xsd:element name="adapterData" minOccurs="0" type="tns:tAdapterData"/>
<xsd:element name="variableData" type="tns:tVariableData" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="notificationData" type="tns:tNotificationData"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tFaultData">
<xsd:sequence>
<xsd:element name="activityName" type="xsd:string"/>
<xsd:element name="activityType" type="xsd:string"/>
<xsd:element name="data" type="xsd:anyType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tActivityData">
<xsd:sequence>
<xsd:element name="activityType" type="xsd:string"/>
<xsd:element name="evalPoint" type="xsd:string"/>
<xsd:element name="errorMessage" nillable="true" minOccurs="0"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<!--
xml type that will be provided to sensors for variable Datas. Note the
any element represents variable data.
-->
<xsd:complexType name="tVariableData">
<xsd:sequence>
<xsd:element name="target" type="xsd:string"/>
<xsd:element name="queryName" type="xsd:string"/>
<xsd:element name="updaterName" type="xsd:string" minOccurs="1"/>
<xsd:element name="updaterType" type="xsd:string" minOccurs="1"/>
<xsd:element name="data" type="xsd:anyType"/>
<xsd:element name="dataType" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="tNotificationData">
<xsd:complexContent>
<xsd:extension base="tns:tActivityData">
<xsd:sequence>
<xsd:element name="messageID" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="fromAddress" type="xsd:string" minOccurs="0"/>
<xsd:element name="toAddress" type="xsd:string" minOccurs="0"/>
<xsd:element name="deliveryChannel" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="tAdapterData">
<xsd:complexContent>
<xsd:extension base="tns:tActivityData">
<xsd:sequence>
<xsd:element name="endpoint" type="xsd:string"/>
<xsd:element name="direction" type="xsd:string"/>
<xsd:element name="adapterType" type="xsd:string"/>
<xsd:element name="priority" type="xsd:string" minOccurs="0"/>
<xsd:element name="messageSize" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
The header of the document contains some metadata.
-->
<xsd:complexType name="tSensorActionHeader">
<xsd:sequence>
<xsd:element name="processName" type="xsd:string"/>
<xsd:element name="processVersion" type="xsd:string"/>
<xsd:element name="processID" type="xsd:long"/>
<xsd:element name="midTierInstance" type="xsd:string"/>
</xsd:sequence>
<xsd:attribute name="actionName" use="required" type="xsd:string"/>
</xsd:complexType>
<!--
Sensor Action data is presented in the form of a header and potentially many
data elements depending on how many sensors associated to the sensor action
marked the data as interesting.
-->
<xsd:complexType name="tSensorActionData">
<xsd:sequence>
<xsd:element name="header" type="tns:tHeaderInfo"/>
<xsd:element name="payload" type="tns:tSensorData" minOccurs="1"
maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
<!--
<xsd:simpleType name="tActivityEvalPoint">
<xsd:restriction>
<xsd:enumeration value="start"/>
<xsd:enumeration value="complete"/>
<xsd:enumeration value="fault"/>
<xsd:enumeration value="compensate"/>
<xsd:enumeration value="retry"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="tNotificationAction">
<xsd:restriction>
<xsd:enumeration value="creation"/>
<xsd:enumeration value="statusUpdate"/>
</xsd:restriction>
</xsd:simpleType>
-->
<!--
The process sensor value header comprises of a timestamp
where the sensor was triggered and the sensor metadata
-->
<xsd:complexType name="tProcessSensorValueHeader">
<xsd:sequence>
<xsd:element name="timestamp" type="xsd:dateTime"/>
<xsd:element ref="tns:sensor"/>
</xsd:sequence>
</xsd:complexType>
<!--
Extend tActivityData to include more elements
-->
<xsd:complexType name="tProcessActivityData">
<xsd:complexContent>
<xsd:extension base="tns:tActivityData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="evalTime" type="xsd:long" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="retryCount" type="xsd:int" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Extend tVariableData to include more elements
-->
<xsd:complexType name="tProcessVariableData">
<xsd:complexContent>
<xsd:extension base="tns:tVariableData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Extend tFaultData to include more elements
-->
<xsd:complexType name="tProcessFaultData">
<xsd:complexContent>
<xsd:extension base="tns:tFaultData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Extend tAdapterData to include more elements
-->
<xsd:complexType name="tProcessAdapterData">
<xsd:complexContent>
<xsd:extension base="tns:tAdapterData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Extend tNotificationData to include more elements
-->
<xsd:complexType name="tProcessNotificationData">
<xsd:complexContent>
<xsd:extension base="tns:tNotificationData">
<xsd:sequence>
<xsd:element name="creationDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
<xsd:element name="modifyDate" type="xsd:dateTime" minOccurs="0"
maxOccurs="1"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!--
Copy of tSensorData type with some modified types.
-->
<xsd:complexType name="tProcessSensorData">
<xsd:sequence>
<xsd:element name="activityData" type="tns:tProcessActivityData"
minOccurs="0"/>
<xsd:element name="faultData" type="tns:tProcessFaultData" minOccurs="0"/>
<xsd:element name="adapterData" minOccurs="0"
type="tns:tProcessAdapterData"/>
<xsd:element name="variableData" type="tns:tProcessVariableData"
minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="notificationData" type="tns:tProcessNotificationData"
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<!--
A single process sensor value comprises of the sensor value metadata
(sensor and timestamp) and the payload (the value) of the sensor
-->
<xsd:complexType name="tProcessSensorValue">
<xsd:sequence>
<xsd:element name="header" type="tns:tProcessSensorValueHeader"/>
<xsd:element name="payload" type="tns:tProcessSensorData"/>
</xsd:sequence>
</xsd:complexType>
<!--
Process instance header.
-->
<xsd:complexType name="tProcessInstanceInfo">
<xsd:sequence>
<xsd:element name="processName" type="xsd:string"/>
<xsd:element name="processRevision" type="xsd:string"/>
<xsd:element name="domain" type="xsd:string"/>
<xsd:element name="instanceId" type="xsd:integer"/>
</xsd:sequence>
</xsd:complexType>
<!--
The list of sensor values comprises of a process header describing the
BPEL process with name, cube instance id etc. and a list of sensor values
comprising of sensor metadata information and sensor values.
-->
<xsd:complexType name="tProcessSensorValueList">
<xsd:sequence>
<xsd:element name="process" type="tns:tProcessInstanceInfo" minOccurs="1"
maxOccurs="1"/>
<xsd:element name="sensorValue" type="tns:tProcessSensorValue" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<!-- The sensor list is the root element of the sensor.xml document in the
bpel process suitcase and is used to define sensors. -->
<xsd:element name="sensors" type="tns:tSensorList"/>
<!-- A sensor is used to monitor a particular aspect of a bpel process -->
<xsd:element name="sensor" type="tns:tSensor"/>
<!-- The actions element is the root element of the sensorAction.xml document
in the bpel process suitcase and is used to define sensor actions.
Sensor actions define how to publish data captured by sensors -->
<xsd:element name="actions" type="tns:tSensorActionList"/>
<!-- actionData elements are produced by the sensor framework and sent to the
appropriate data publishers when sensors 'fire' -->
<xsd:element name="actionData" type="tns:tSensorActionData"/>
<!-- This element is used when the client API is used to query sensor values
stored in the default reports schema -->
<xsd:element name="sensorValues" type="tns:tProcessSensorValueList"/>
</xsd:schema>
