Apama 10.15.0 | Connecting Apama Applications to External Components | Standard Connectivity Plug-ins | Codec Connectivity Plug-ins | The Classifier codec connectivity plug-in
 
The Classifier codec connectivity plug-in
The Classifier codec can be used to take messages from a transport and assign them message types suitable for the host. Typically this is the type of an EPL event, which corresponds to the metadata field sag.type (see also Metadata values) when you are using the apama.eventMap host plug-in. The Classifier codec can inspect the message payload and metadata in order to classify messages to the correct type. If it finds a match, it sets the sag.type appropriately, overwriting anything which was there before.
To reference the Classifier codec, an entry such as the following is required in the connectivityPlugins section of the configuration file (see also Configuration file for connectivity plug-ins):
classifierCodec:
libraryName: ClassifierCodec
class: ClassifierCodec
You then need to add classifierCodec into your connectivity chains with the configuration for that instance. An example configuration may look as follows:
classifierCodec:
rules:
- SomeType:
- payload.someField: someValue
- payload.anotherField:
- AnotherType:
- metadata.metadataField: true
- ThirdType:
- regex:payload.field2: /bar/([0-9]{3})([a-zA-Z]{3})/[!@#%\^&\*]+
- payload.field3: something
- FourthType:
- regex:payload.field1: Valid PLAIN String
- FallbackType:
The top-level configuration element is just rules. It contains a list of one or more types which can be assigned to messages. Each type contains a list of rules to match against the type with the following properties:
*Types are evaluated in order and the first one to match is assigned to a message.
*If the list of rules for a type is empty, then it matches any message. There should be only one such type and it must be last. With FallbackType in the above example configuration, it is always guaranteed that a type is set on a message (because FallbackType is a last resort).
*Rules within a type are evaluated in order, and comparisons stop on the first failure so that common cases are evaluated first.
*Field names must start with metadata. or payload., or with regex:metadata. or regex:payload. if you are using regular expressions.
*Metadata and payload field names which contain a period (.) refer to nested map structures within the metadata or payload. For example, metadata.http.headers.accept refers to a map called http within the metadata, which contains a map called headers, which contains an element called accept.
*Empty rules match if the field is present (even if empty) with any value. With SomeType in the above example configuration, this rule matches if anotherField in the payload contains any value. This does not apply for regular expressions where empty rules are not allowed.
*A non-empty rule usually looks for an exact string match, unless the field name begins with regex:. In this case, the rule looks for a regular expression match against the entire field value. For example, if field2 of the payload in the above example configuration is equal to /bar/123aBc/&& or another matching string, and field3 contains something, then the message can be classified as being of type ThirdType.
*Regular expression matches are performed using the ICU library (see the ICU User Guide at http://userguide.icu-project.org/strings/regexp for detailed information) with the default flags - single line and case sensitive.
*All rules within a type must be true to match that type. For the above example configuration, this means that if anotherField in the payload exists, but someField does not contain someValue, then SomeType does not match.
*If no types match, then the sag.type metadata field remains unchanged.
*For payload. rules to match, the payload must be a java.util.Map (Java) or map_t (C++) with string keys.
*Messages coming from the direction of the host do not interact with the Classifier codec at all. Use the apama.eventMap host plug-in, which always sets a sag.type for messages going from the host towards the transport.
If you want to encode an or rule, then you can list the same type twice with different sets of rules.