SWIFT domain model

Java classes representing the structure and content of a SWIFT MT (ISO 15022) message

The message model is a central part of the library suited for messages creation, parsing and persistence.
It is designed in three layers of specific use; each provide a different level of abstraction.

Core Layers

Persistence - Lightweight Layer

The upper layer is a generic representation for all messages mainly intended for messages persistence. The model includes specific attributes for headers and trailer information, while the body content (business payload) is kept as single String attribute (not parsed).

Since this model is generic, message objects can be instantiated without prior knowledge of the specific type of message. This design is therefore optimal for database persistence because all message types can share a simple and efficient database structure. It can be thinked of as a wrapper of a swift message file.

Besides messages content, the model provides several metadata containers very useful for a message management application, such as a holder for message status, attached notes and extendable properties.

The default database representation derived from the JPA annotations can be further customized in your own environment using XML mappings.

Parse/Build - Functional Layer

The middle layer is a functional view of a specific message, for example an MT103. The provided API allows you to read data from a known message easily, as well as API to build new messages or manipulate a specific message content.

This layer provides a specific class for each message type, with getters for its inner sequences and fields. Also a specific class for each possible field of the message, for example Field32A, with methods to retrieve any internal component (subfield), for example the Calendar, Currency and Amount of Field32A.

This specific classes can be thinked of as a facade or view of the internal message content.

Notice this objects are not intended for message modification because when you read content with a getFieldNN the returned object is detached from the underlying model. Details on how to modify a message are described in MT content modification.

Backbone - Structure Layer

The lower layer is the internal backbone of the upper one, and in most use cases there is no need to use this API from an application.

The message representation at this level handles the message content as simple tuples of field name and field value and implements low level handling of sequences and block. This model is quite simple, generic and loosely coupled to specific messages, therefore being very efficient and requiring minimal construction constraints.

This layer is also the one used for content modification.

Model use case examples can be found at Github