SOA Composite Sensors : Good Practice
- by angelo.santagata
I was discussing a interesting design problem with a colleague of mine Niall (his blog) on the topic of how to cancel an inflight SOA Composite process. Obviously one way to do this is to cancel the process from enterprise Manager ( http://hostort/em ) , however we were thinking this isnt a “user friendly” way of doing this.. If you look at Nialls blog you’ll see he’s highlighted a number of different APIs which enable you the ability to manipulate the SCA instance, e.g. Code Snippet to purge (delete) an instance How to determine the instanceId from a composite_sensor_value using the “composite_sensor_value” table How to determine a BPEL Process status using the cube_instance table Now all of these require that you know the instanceId of your SOA Composite, how does one find this out? Well the easiest way of doing this is to create a composite sensor on the SCA component. A composite sensor is simply a way of publishing a piece of business data as part of your composite. The magic here is that you can later query composites based on this value. So a good best practice is that for any composites you create consider publishing a composite sensor value using a primary key of some sort , e.g. orderId, that way if you need to manipulate/query composites you can easily look up the instanceId using the sensorid. For information on how to create a composite Sensor id see this documentation link
