Implementing composite sensors within a SOA solution provides the ability to define trackable fields on messages and enables you to find a specific composite instance by searching for a field or fields within a message. For example, a sensor could be defined for an invoice number within a message, thus allowing us to search and find the instance where the invoice number in question is found.
While this functionality is not new within Oracle SOA Suite 12c, there are some improved capabilities that have been included in this release, which will be covered in this article.
Composite Sensors Review
Composite sensors can be defined within a SOA composite application in several components:
- Service component (exposed service)
- Reference component (external reference)
- Mediator or BPEL component that have subscribed to a business event (publishing an event cannot have a sensor)
Within these components, a composite sensor can be defined in a couple of different ways. One way is to specify an existing variable as the sensor (as shown below). Another way is to define by an expression with the help of the expression builder. The third way is to define using properties (e.g. message header properties).
A filter can also be specified to further qualify when a sensor is created at runtime. In the example above, the sensor data will only be generated when the value of ‘name’ field is equal to ‘Bill’. This provides the control to only produce the sensor under given circumstances.
The composite sensor actions provide the ability to configure where the sensor data will be stored when generated at runtime. When the ‘Enterprise Manager’ selection is made, the sensor data is stored within the trackable fields database table. Checking this box allows the sensor data to be searchable within the Enterprise Manager.
Sensor data can also be stored in a JMS queue or JMS topic.
Composite Sensors in 12c
Along with the ability to define composite sensors within JDeveloper, new to Oracle Suite 12c is the capability to create, update, and delete composite sensors within the SOA Composer. In previous versions, this functionality required changes to be made within the composite in JDeveloper, and then a deployment of the updated composite. With this new capability, managing sensors in the SOA Composer can be done at runtime, without the need for redeployment.
To manage sensors within the SOA Composer, select the desired composite within the ‘Deployment View’. As shown below, the tab in the middle of the screen displays composite sensors for the selected composite. To add, update or delete a sensor, select ‘Create Session’:
Once a session is open, a sensor can be added, edited or deleted by selecting the appropriate icon:
Once the sensor type (service, reference, event subscription) is chosen, the creation of a sensor in SOA Composer is very similar to the functionality within JDeveloper:
One thing to note is the expression builder in the SOA Composer is a little different than the one in JDeveloper. In SOA Composer, there is a category called ‘Core XPath Functions’. Look in this category first, since it contains many of the commonly used functions (concat, sum, etc.).
Once the sensor(s) are defined, select Save, then Publish. The composite sensors are now active. Something else to note about SOA Composer is the ability to ‘View Composite Diagram’. This displays the components in the selected composite, but note that only those sensors defined within JDeveloper will be signified with the sensor icon. As shown below, sensors are defined on both the external service and reference, but only the external service shows a sensor icon since it was the only one defined within JDeveloper.
Another gotcha to be aware of is that subsequent deployments of the composite will remove any sensors that were previously defined within the SOA Composer.
Sensors in Enterprise Manager
Defining a sensor to be published to the Enterprise Manager allows for a quick search for data within a composite instance. Within the dashboard tab in EM, there is the ability to search for instances by sensor name and value. These fields are free form and to retrieve instances requires the exact name and value of the defined sensor:
As you could imagine, finding the particular instance in question may be difficult in the dashboard, given the need to remember the sensor name and the exact value of the sensor value. One tip is to use the ‘Flow Instances’ tab instead. Within that tab you can select sensors from a drop downs plus use wildcard-like values for the sensor value. If the sensor fields are not visible, navigate to ‘Add/remove Filters’, then select ‘Flow Instances’.
Now, the sensor name can be searched by first selecting the composite. It also offers more flexibility in the operator of the sensor value. For example, the ‘Like’ clause allows for searching for a value that does not require an exact match:
Summary
Implementing composite sensors is a great way to provide insight and tracking into SOA composites. With the new 12c functionality, this capability is made even more effective given the runtime configuration within SOA Composer.