Java Message Service
Use
You use a Java Message Service (JMS) to send framework events based on create, read, update, or delete (CRUD) operations.
Structure
A JMS message contains the attributive information of an entity for which the event has been sent. This includes the type of operation and information about the entity instance itself. This information is not stored in a separate class and sent as a serialized JMS message otherwise every subscriber would need a reference to the caf~runtimeapplication. Instead a framework event is sent as a JMS message of type map.
Message Structure
In the following table, you can see which properties a message contains. They are stored in the header of the message as name-value pairs.
Name |
Type |
Description |
operation |
String |
Is the type of operation of the event which has been sent. There are three possible values: create, upgrade, and delete. |
objectKey |
String |
The primary key (GUID) of the entity instance of the event which has been sent. |
entityName |
String |
Full qualified name of the entity to which the instance with the key that is contained in objectKey. |
committed |
Boolean |
Indicates if the transaction that is associated with this event was committed and written to the database or if the transaction was rolled back In case of a rolled-back transaction, the event can be used to restore the data image in a remote system. The data in the remote system has to be restored to the before imagine as contained in the event. As CAF does not offer distributed transaction to roll back transaction in a remote system, this mechanism and e used to restore the data. |
Message Body
The body of the message contains an instance of java.util.Map which stores all attributes and instance values. All values are stored as java.lang.Object.
In situations where the basic data type is, for example, integer or long, the value is put into the corresponding wrapper class. A collection is used to store all values for attributes with cardinality n.
For complex attributes, another map class is used to act as a container for the subattributes. The attribute name acts as an index for the map to access the value of the attribute. Maps also include relations to other entities; whereas only the keys of the related entities are sent as part of the message. No data of related entities is passed as part of the message.
Dynamic Attributes and JMS
The event should also cover the values of dynamic attributes. The names of all dynamic attributes can be determined using the application service Metadata that is available in the caf.tc application. Values of these attributes can be read using the generic method getProperty that is available in each valueObject.
To allow an event receiver to determine whether an attribute is dynamic or static, the name of the dynamic attribute should be defined with the prefix “dynamic”. You define this in the service modeling tool of the Composite Application Services plug-in to SAP NetWeaver Developer Studio.
The JMS message contains both values of the attribute before and after the change. To distinguish between these values, the attribute name has either the prefix “new::” or “old::”. In case of an event with type create, there no old values. No new value are available In case of type delete.
See next: