MessageObjects Tutorial: Message Checking
IV. Message Checking
Step 1: Checking Example
Go back to III.3 and create an MT200. We can now check the validity of the message by using function MsgCheck.
Click "GO" to call sx.MsgCheck(True).
You should receive an empty return value, indicating
that the MT200 is correct.
Now go back to III.4
and create an MT502.
Click "GO" to call sx.MsgCheck(True).
You should now receive an HTML table containing a list
of error messages.
How the message is checked:
First of all the mandatory branches of the messages are checked, i.e. if any field is filled inside any hierarchy, then all mandatory branches and their mandatory children of this hierarchy must exist as well, and then all existing fields are checked for valid data types. Finally, the correct usage of code words is checked.
If all of these checks returned no error then dependency
is checked (so-called network validation rules).
While MT200 does not have any network validation rules,
MT502 has 10 of them (some of them quite complex).
What is not checked:
MsgCheck will not check for valid currency codes, country codes and BIC codes. If you want to do this, you must subscribe to the BIC-directory from SWIFT. SWIFT issues the updates 4 times a year, so any changes happening in-between updates need to be done by hand. Also, some BICs are not published (because not intended for the wider public) but are nevertheless valid. On the other hand, not every BIC can be used for every message type (categories of SWIFT users), and some BICs which can be used in the header cannot be used inside the message body.
In other words, BIC-checking is a bit "iffy", and in our own interface we merely issue a warning for not-found BICs, but do not prevent the user from sending the message. Anyway - if you require currency code, country code and/or BIC checking, then you must implement this yourself. A rough scetch of how to do this can be found in Step 3.
Step 2: How to use Fieldcodes
Fieldcodes and their usage depend heavily on the current standards implementation and the fields which they belong to. MessageObjects provides the fieldcodes as an xml file and also has functions to deal with them. See the example below.
If you go back to II.2 or II.3 you will now see that the long text is displayed for the fieldcodes.
Step 3: How to use BIC codes, currency codes and country codes with MessageObjects
You can find all relevant XML nodes by searching for attribute "Format" as in the following example.
If you fill attribute "Digits" before using
function MsgCheck, then MsgCheck will use this attribute
to validate whether the amount belonging to the currency
code has equal or less digits.
If you fill attribute "CodeText" before applying
an XSLT such as view2.xsl (using function getHTMLView),
then the long names will be displayed in the output.
If you go back to II.2 or II.3 you will now see that the long text is displayed for the BIC/currency/country codes.
Details versus Speed
In the Step 1, you learned how to use MsgCheck for message validation. The whole purpose of MessageObjects and the underlying structure of the XML representation of SWIFT messages is to enable detailed feedback and processing options for the user.
If you have an application creating SWIFT messages for sending messages automatically to SWIFT, you may require a check of the message before sending, so as to ensure that there is no bug in the program, which could cause thousands of messages to be NAK'd by SWIFT and thereby creating unnecessary costs and delays.
Obviously, transforming SWIFT to the detailed, nested representation in XML, then checking the message in its very detailed layout is not going to be the speediest way of doing this. We have therefore created a "quick" checker for such usage, now available as AnaSys.net SWIFT Validation Service. It is based on XML-Schema (which always performs detailed data-checking directly from the parser), it is optimised for checking only (not for data handling or transformation) and is therefore not a part of MessageObjects, but a separate product.