Setting headers and message properties for event types

If you are already familiar with JMS and HTTP, you can set the JMS message properties or HTTP headers of outbound messages for individual event types. For example, you might want to specify the values of JMS message properties that enable subscribers to identify messages by using a message selector.

About this task

You can add a header or message property for each outbound event type in your outbound binding.

The outbound binding syntax includes the following JMS message properties:
  • "setting the jms correlation id" specifies a value for the JMSCorrelationID of a JMS message.
  • "setting the jms type" specifies a value for the JMSType of a JMS message.
To add a header to an event type, use the following syntax:
  • "setting the header 'name'" specifies a value for an HTTP header or JMS message header field. The specified name must conform to the requirements of HTTP or JMS.

The named headers and message properties must be specified with a compatible protocol. If you specify the binding from an endpoint of an incompatible protocol, the incompatible headers or message properties are ignored. For example, if you use an HTTP endpoint to reference a JMS binding that sets the jms type, then the HTTP message is sent without the header.

The value of a header or message property is specified either as a constant string or as an attribute of the event type. If you specify an attribute, the header or message property value is a string representation of the value of the attribute of the emitted event. If the attribute value is an entity relationship, the value is the referenced entity ID. If the attribute value is a collection, is a concept, or is null, then the value is the empty string.

HTTP header values must contain only ASCII (American Standard Code for Information Interchange) characters. A character that is not an ASCII printable character (codes 32 - 126 inclusive) is replaced with a question mark (?) when you send an HTTP message.

When you have event types with inheritance in your business model definitions, the message headers and properties are applied to all subtypes of the event type that is named in the outbound binding, unless otherwise specified. For example, if your business model definition defines an urgent response event is a response event and the outbound binding specifies a message header for response event and not the urgent response event, then the response event and urgent response event types are bound using the response event header. To apply different message headers to the urgent response event and response event types, you must add a setting for the inherited event types.

Procedure

  1. Create the outbound binding. In the following example, you specify the message format and protocol.
    define outbound binding 'FraudAlert' 
       using 
          message format application/xml , 
          protocol HTTP , 
  2. Decide which event types that you want to bind.
  3. Set the values for the HTTP header, JMS type, or JMS correlation ID. You can add the settings in any order and combination. In the following example, the parent and the inherited event type have different settings for the JMS correlation IDs:
       - response event ,
          setting the jms correlation id to the bound entity id 
       - urgent response event , 
          setting the jms correlation id to the request id of this response event .
    In the following example, the transformation and properties are set only for the response event. The urgent response event type inherits these settings from its "parent":
       - response event , 
          transform using "alertevents.xsl"
          setting the jms correlation id to the bound entity id
       - urgent response event .
  4. Finish creating the binding. End your statement with a period (.)
  5. Save your work.

Example

define outbound binding 'FraudAlert'
   using
      message format application/xml , 
      protocol JMS , 
   delivering events : 
      - fraud alert, 
         transformed using "fraudalert.xsl" 
      - credit limit reached , 
         transformed using "creditlimit.xsl"
      - alert event , 
         setting the jms correlation id to the bound entity id
      - response event , 
         setting the jms correlation id to the request id of this response event .