SWIFT Message Validation Using BizTalk Accelerator for SWIFT

If you have hit this blog post, I would assume you already know BizTalk and you are looking out for ways to validate SWIFT message using BizTalk Accelerator for SWIFT.

Messages can be validated at any stage in BizTalk. It can be at the receive port, orchestration or at the send port based on the messaging needs. At receive port, inbound message can be validated for data constraints using Xml schema validation. I have to mention this here, flat file message schemas that comes through BizTalk Accelerator Message Pack has implemented data constraints and validations as per the SWIFT standards. We can leverage the Xml schema validation to validate the structure and data constraints of the message. In a typical BizTalk solution to validate the message, you can implement Xml Validator pipeline component in a receive pipeline and configured at receive location. Xml Validator pipeline component reports only first error and does not list all the errors present in the message. It does not make sense to correct\report one error at a time for a business partner.

SWIFT Disassembler Pipeline component that comes with BizTalk Accelerator for SWIFT has a robust functionality and can save us a lot of time developing a custom solution. Key functionality of this component is to dynamically discover the inbound message type, parse the flat file to Xml, de-batch messages, Invoke Xml validation and perform BRE validation. Most of the functionality can be controlled through configuration of properties.

Fig: SWIFT Disassembler pipeline component properties

SWIFT Disassembler Validation functionality perform a validation on entire message and reports all errors present in an inbound message. Also, we can control to perform either only Xml Validation or only BRE validation or both. SWIFT Disassembler component publishes parsed Xml message, validation error and promotes A4SWIFT context properties.

Validations errors are reported in the form of Xml as shown in the sample here.

<?xml version="1.0" encoding="Windows-1252"?>
<SWIFT_ERROR MessageType="101">
  <XmlValidationError Severity="Error" SchemaName="http://schemas.microsoft.com/BizTalk/Solutions/FinancialServices/SWIFT/Category1/MT101#SWIFT_CATEGORY1_MT101_Interchange" LinePosition="1482" LineNumber="1" ExceptionType="System.Xml.Schema.XmlSchemaException: The 'Line1' element has an invalid value according to its data type.">
    <Message>Incorrect format in Line1 for tag 59.</Message>

Messages with errors can be subscribed by a separate orchestration process to handle errors by setting up a filter as below.

Microsoft.Solutions.A4SWIFT.Property.A4SWIFT_Failed == True

Came through the word BRE above and wondering why it is required? Well, it is time to talk about it. BizTalk SWIFT schemas define data constraints. For example, an amount field is a positive integer and a valid format. But, it does not define cross field validation and Business Rules. For example, a MT101 Request for Transfer message which is sent to bank can be used for multiple scenarios. 1. A customer sending a request to bank for credit transfer initiation, 2. Interbank settlement. Set of fields would be populated based on the scenario MT101 message is used for. This would require a complex cross field validation to validate business rules. BizTalk Accelerator for SWIFT implements this as Business Rules Engine (BRE) Policies. In-addition, BRE policies also includes SWIFT network and usage rules with error codes. More information about SWIFT BRE Policies can be found here.

BRE Validation can be turned-on in SWIFT Disassembler pipeline component by setting the property. However, I have to caution here. Installation of SWIFT Accelerator does not deploy the Policies. It has to be deployed beforehand for each message type that will be used in the solution to successfully validate.

SWIFT Disassembler can be used to validate the message at the receive location. There might be many scenarios where we might need to implement the validation functionality in Orchestration process. For example, we might be constructing a SWIFT message to send it to bank by pulling the information from various backend systems. In this scenario, it makes sense to implement the validation functionality in orchestration.

BizTalk Accelerator for SWIFT has set of Utility API’s that can be consumed in orchestration and call a method for validation.

MessageValidator class can be found in the namespace Microsoft.Solutions.FinancialServices.SWIFT.Shared. This class offers the same functionality that is found in SWIFT Disassembler that include dynamic discovery of message type and apply appropriate schema for Xml validation and appropriate policy for BRE validation.

Note: I wrote this post based on BizTalk Accelerator for SWIFT 2010.


BizTalk Server ‘2012’ Road Map

Microsoft announced Integration platform road map focusing next version of BizTalk Server and Azure in a TechEd on June 14, 2012 held in Orlando. A well-known BizTalk veteran Kent Weare has put together a round up in his blog.

Here is the link for the blog:


TechEd Webcast:


BizTalk : Feature: [Group] Failed to configure with error message [Error -2147217394 occurred configuring feature WMI]

Encountered an error Feature: [Group] Failed to configure with error message [Error -2147217394 occurred configuring feature WMI]”
while configuring BizTalk Server 2010 ? This is an issue with the BizTalk WMI configuration corrupt or not added to WMI repository.


  1. Open command prompt in administrator mode
  2. Change the Path to “C:\Windows\System32\wbem\”
  3. Execute command Mofcomp “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\BTSWMISchema.mof”
  4. Execute command Mofcomp “C:\Program Files (x86)\Microsoft BizTalk Server 2010\Bins32\BTSWMISchema.mfl”

Above commands add BTS WMI configuration to repository. You should now be able to configure BizTalk Group using BizTalk configuration wizard.

BizTalk Host Separation Strategy

There is no one thumb rule for separating BizTalk hosts. It is a good practice to separate hosts in a standard way. Consider following guidelines.

  • Create separate hosts for Receive, Send and Processing operations
  • Create new host if a specific throttling configuration to be used by Interface. Low latency, High throughput, Interface optimizations
  • Create send and receive hosts specific to functionality\adapter
  • It is necessarily not required for every Interface to create a new Host and Host Instances. Increasing number of host instances will cause a contention on a MessageBox database and resources may saturate and bring down overall performance.
  • Host Instances can be shared across Interfaces. Share host Instances based on operation and functionality.
  • Create new host if a Interface is memory\cpu intensive or critical or if it is experiencing throttling issues. This has to be assessed during performance tests.

 It is important to follow naming conventions  for proper separation strategy. Following is the guide line for naming hosts.

<type>_<bit support>_<sequence>_<functionality\adapter>

Eg: RxHost_x64_1_SQL . This is a receive host , with 64-bit, sequence 1 and running SQL adapter.