Note the following restrictions on the use of composite sensors:

• Functions in XPath expressions cannot be used with properties.

• Any composite sensor that is defined by an expression always captures values as strings. This causes the sensor type to always be a string. This action makes the search possible.

  Capturing values as strings may be useful when dealing with XML types derived from a string. The following example provides details:

  <xs:element name="CardNum">
      <xs:simpleType>
          <xs:restriction base="xs:string">
              <xs:length value="16"/>
          </xs:restriction>
      </xs:simpleType>
  </xs:element>
  

  Even if the expression is a number, it is captured as a string. You cannot use other logical operators such as <, >, =, or any combination of these.

• Any composite sensor that is defined by a variable uses the variable type to determine the sensor type. Sensors can be one of the following types:

  • STRING

  • NUMBER

  • DATE

  • DATE_TIME

  • Complex XML

• Composite sensors only support two types of sensor actions: Enterprise Manager and JMS.

• Header-based sensors are only supported for web service bindings.

• Sensor actions for Oracle B2B, service data objects (SDOs), web services invocation framework (WSIF), and Oracle Business Activity Monitoring bindings are not supported.

• When creating an XPath expression for filtering, all functions that return a node set must be explicitly cast as a string:

  xpath20:upper-case(string($in.request/inp1:updateOrderStatus/inp1:orderStatus) ) = "PENDING"
  

• Sensors cannot be configured on service components that publish business events.

• Sensors based on business event headers are not allowed (only payloads are allowed).

• PL/SQL subscriptions are not supported.