No description, website, or topics provided.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.settings
lib/biz/c24
messages
src/main
.classpath
.gitignore
.project
mule-project.xml
pom.xml
readme.md

readme.md

Simple C24-iO Mule Demo Flow

This simple example shows how C24-iOs message handling capabilities can be used within a Mule flow.

Overview

The flow represents a fictitious scenario where a system wishes to intercept outbound MT103s for 2 purposes:

  • To create an audit record of outbound messages
  • To add a sender charge where the payment is in GBP

For the purposes of simplicity all reads & writes are to files although in practice it is more likely that queues and data stores would be used; this is simply a matter of changing the Mule flow endpoints.

The basic flow is:

  1. The inbound file adapter picks up MT103 messages from the file system

  2. C24-iO is used to parse and validate the files

  3. If the message currency is GBP it is routed to a transformer which adds a sender charge to the message using the model-specific & type-safe Java API generated by C24-iO. If not it is passed through unchanged.

  4. The resultant message to passed to 2 subflows. The first uses a C24-iO transform to convert the message to an internal payment record format which is marshalled and written to the filesystem. The second converts back to SWIFT wire format and also writes it to the filesystem.

There is also an error handling flow which catches any exceptions (e.g. from invalid messages) and writes the cause to the filesystem.

Pre-requisites

The SWIFT MT103 used in this example is a C24 licensed message model and requires an appropriate licence; please contact C24 if you need a licence to try out this example.

Running the flow

Updating the configuration

Configuring the licence file

By default C24-iO will look for your licence in a directory pointed to by the ${IO_HOME} environment variable. Alternatively you can update the C24-iO Connector configuration (under Global Elements) to specify the full path to the licence.

Updating the inbound and outbound directories

The file adapters are configured to use the following directories:

  • Inbound SWIFT files - reads from /tmp/demo/in and moves files to /tmp/demo/processed
  • Outbound SWIFT Message - writes to /tmp/demo/out
  • Audit Files - writes to /tmp/demo/audit
  • Store Error - writes to /tmp/demo/invalid

Please update these for your environment or create the directories above as required.

Starting the Flow

Right-click on src/main/app/paymentdemo.xml and select Run As->Mule Application with Maven.

To use the supplied sample messages, copy the contents of the messages directory into the directory that the Inbound SWIFT files endpoint is reading from (/tmp/demo/in by default).

Analysing the Output

As the input files are processed, you will see them move from the in to the processed directory.

valid.usd.dat

As this is a valid file, after parsing the routing step will determine that the currency is USD and pass the message through unchanged. This message will then be converted back into a SWIFT message into the out directory (note that the resultant file is identical to the original one) and also converted into a payment record which will be written to the audit directory.

valid.gbp.dat

Although broadly similar in processing to the previous message, this time the router will determine that the currency used in the payment is GBP and hand the message off to the transformer which creates a sender charge of 1.50 GBP and adds it to the message.

Like the valid.usd.dat message we will see entries in both the out and audit directories for this message but this time note that the outbound SWIFT message now contains our additional charge:

:71F:GBP1,5

invalid.gbp.dat

Although syntactically valid, this message is semantically invalid as it contains an invalid enumeration in field 23B:

:23B:CROD

This will cause an exception to thrown during validation which, if you have left Mule's ERROR logging enabled, you'll see on the console:

12:28:52,538 org.mule.module.logging.DispatchingLogger org.mule.exception.CatchMessagingExceptionStrategy ERROR CatchMessagingExceptionStrategy:337 - 
********************************************************************************
Message               : Message is invalid.. Message payload is of type: MT103Message
Code                  : MULE_ERROR--2
--------------------------------------------------------------------------------
Exception stack is:
1. /MT103Message/Block4/Field23BBankOperationOrOptionCode/B/BankOperationOrOptionCode : T36: Bank Operation or Option Codes: The value 'CROD' does not match an entry in the enumeration {CRED, CRTS, SPAY, SPRI, SSTD} (biz.c24.io.api.data.ValidationException)
  biz.c24.io.api.data.ValidationManager:361 (null)
2. Message is invalid.. Message payload is of type: MT103Message (biz.c24.io.mule.C24Exception)
  biz.c24.io.mule.C24Connector:285 (null)
--------------------------------------------------------------------------------

This exception is handled by our exception handling strategy and results in the generation of a file in the invalid directory:

/MT103Message/Block4/Field23BBankOperationOrOptionCode/B/BankOperationOrOptionCode : T36: Bank Operation or Option Codes: The value 'CROD' does not match an entry in the enumeration {CRED, CRTS, SPAY, SPRI, SSTD}

In practice it is likely that far more sophisticated error handling flows would be implemented to route the message to the appropriate party or even return it to the sender, along with the failure information. While the failure message above is a clear and exact description of the reason for failure, the actual C24-iO exception thrown allows you to retrieve even more contextual information on the failure.

C24-iO also enables multiple validation failures to be captured in a single pass - these operations are not yet exposed through the C24-iO Mule connector (which operates in a fail-fast mode) but can be easily added in future updates.

error.dat

This SWIFT message is syntactically invalid hence cannot even be safely parsed. This time the exception is thrown during the parse step and is again handled by our exception strategy. As well as creating a file in the invalid directory which contains details of the fault, we also see the same information logged by Mule:

12:36:52,884 org.mule.module.logging.DispatchingLogger org.mule.exception.CatchMessagingExceptionStrategy ERROR CatchMessagingExceptionStrategy:337 - 
********************************************************************************
Message               : Failed to parse message.. Message payload is of type: ReceiverFileInputStream
Code                  : MULE_ERROR--2
--------------------------------------------------------------------------------
Exception stack is:
1. Probable Cause:
   Invalid SWIFT field found. Invalid SWIFT field found while parsing MT103Message/Block4/SenderRef at line 2 column 1 (offset 71 from the start of the message). While parsing '20:8861198-0706' and expecting ':20' (biz.c24.io.api.ParserException)
  biz.c24.io.api.presentation.NonSdkSwiftSource:217 (null)
2. Failed to parse message.. Message payload is of type: ReceiverFileInputStream (biz.c24.io.mule.C24Exception)
  biz.c24.io.mule.C24Connector:221 (null)
--------------------------------------------------------------------------------

We can clearly see the problem is a missing ':' at the start of field 20; the thrown exception again allows us to retrieve further structual context of the failure if required.