How To Build A Financial Messaging And Enterprise Service Bus (Esb)

Transcription

1 Simplifying SWIFT Connectivity Introduction to Financial Messaging Services Bus A White Paper by Microsoft and SAGA Version 1.0 August 2009 Applies to: Financial Services Architecture BizTalk Server BizTalk Accelerator for SWIFT Enterprise Service Bus Toolkit Summary: Financial Messaging Services Bus (FMSB) is a vertical industry implementation of Microsoft s Enterprise Service Bus Toolkit 2.0 on top of BizTalk Server 2009 and BizTalk Accelerator for SWIFT. FMSB greatly improves time to market for many complex solutions in Banking and Capital Markets industries. This paper explains the rationale behind FMSB creation, provides a high level description of FMSB architecture, and discusses how FSMB is used to simplify application connectivity to SWIFT. FMSB helps software developers by encapsulating complex processes for transmitting any type of SWIFT message or file to any SWIFT service over specific SWIFT protocols. Additional in depth white papers will be released shortly to describe how FMSB can be deployed for Payments and Capital Markets messaging. This document assumes the reader has a basic understanding of generic ESB concepts. For further reading on the Microsoft ESB Toolkit, refer to: guidance.aspx Contents Introduction Financial Messaging and Enterprise Service Bus (ESB) FMSB Product Stack FMSB Architecture High Level Overview Architecture of FMSB and ESB FMSB Sample Service: SWIFT Service Router Conclusions References 1 P age

2 Introduction This section provides an overview of financial messaging, and it also introduces existing technologies that FMSB depends on. Financial Messaging and Enterprise Service Bus (ESB) Financial messaging, especially when built upon industry standards, can in fact form a foundation platform for the development of a payments or capital markets framework where integration technology, data transformation, and workflow management are used to orchestrate transaction flows among applications and clearing systems. In addition to messaging, some commonly used processes are required for transaction processing, e.g., validation, routing, exception management, and repair. By developing these processes as reusable services, the messaging infrastructure becomes more than an integration framework it takes on the nature of a bus architecture where the lifecycle of a transaction can be mapped, calling the appropriate services as necessary. This is the essence of the FMSB: taking BizTalk orchestrations, abstracting and bundling them as reusable services that can be configured at implementation time. In addition, such services can be exposed to third party applications to leverage the preconfigured processing of the bus components, therefore enhancing client value. When defining FMSB, it is important to note that these services are business services, as defined by Microsoft Enterprise Service Bus (ESB) 2.0. The over arching concept is to use ESB to orchestrate all services and reuse them as needed. The basic architectural elements of a financial services application can be categorized into the following segments or layers as shown in Figure 1. Figure 1: Financial Application Architecture When considering the architecture of a financial services application, the FMSB sits in the layer known as Business Process and Orchestration, which is covered by the Microsoft technology stack, and provides integration, orchestration, transformation, and workflow services. 2 P age

3 FMSB can be deployed directly to a financial institution client infrastructure project, but also embedded in a Microsoft partner financial application solution. FMSB Product Stack FMSB depends primarily on BizTalk Server 2009, the Enterprise Service Bus Toolkit 2.0, and a SQL Server 2008 database for a message repository. FMSB complements and extends the functionality of BizTalk Accelerator for SWIFT (A4SWIFT). FMSB and Microsoft ESB The FMSB is built principally on BizTalk Server because many of the services relate to BizTalk and Accelerator for SWIFT components. To conform to BizTalkESB architectural best practices, the FMSB was developed upon the BizTalk ESB Toolkit. For further information on the Microsoft ESB Toolkit, please see guidance.aspx). The base ESB architecture is also the base architecture for FMSB as shown in Figure 2. Figure 2: FMSB and ESB Basically, the Microsoft ESB Toolkit accepts inbound messages and operates on them by performing processes such as transformation, delivery, or any other custom defined process. To specify the operations required, the core processing components require a message to contain associated instructions or metadata that define the processes to apply and the tasks to execute with the message content. This approach provides loose coupling between services; this means that the ESB does not require prior knowledge of the specific processing for each message. It just has to know the possible range of processes and how to apply each process. The wide range of options for specifying the available processes and the mapping between the processes and the instructions within messages provides a 3 P age

4 flexible mechanism for configuring and adjusting behavior, without requiring changes to code and redeployment of components. BizTalk Accelerator for SWIFT The Microsoft BizTalk Accelerator for SWIFT (A4SWIFT) extends the BizTalk Server platform ( swift.aspx ) to provide reliable and secure delivery of financial messaging using the SWIFT format and network for customers in banking, capital markets, payments, and corporate finance. A4SWIFT is leveraged in the development of FMSB. The Microsoft BizTalk Accelerator for SWIFT solution has two adapters: BizTalk Adapter for FileAct provides connectivity between BizTalk Server and the SWIFTNet FileAct messaging service. The adapter uses the SWIFTNet Link (SNL) APIs to connect to SWIFTNet, and is able to send and receive files via FileAct over SWIFTNet using both real time and store and forward protocols. The BizTalk Adapter for SWIFTNet InterAct provides connectivity between BizTalk Server and SWIFTNet InterAct, allowing real time exchange of financial information based upon SWIFT XML message standards. It also supports real time and store and forward protocols. Microsoft A4SWIFT supports integration to SWIFT Alliance Access (SAA) software by using two common BizTalk adapters: 1. File or FTP for exchanging files with SAA 2. MQSeries for exchanging messages over WebSphereMQ A4SWIFT provides clients and partners with rich integration and mapping functionality, as the necessary SWIFT processing logic to fulfil the SWIFTReady for Financial EAI Label. To configure this solution, the user needs to have developer skills and also administration skills for BizTalk. FMSB abstracts and simplifies the use of A4SWIFT by making functionality available as services and itineraries to enable rapid development and deployment of solutions, and to reduce the complexity of solution engineering. This provides benefits to both clients (rapid implementation and configuration) and partners (faster product development). FMSB Compared to BizTalk Accelerator for SWIFT The fundamental difference between FMSB and standard A4SWIFT is decoupled flexibility of services. When following the FMSB pattern, BizTalk and A4SWIFT are viewed as a series of services and capabilities that can be used in a very dynamic way. With FMSB, messaging implementations no longer require the hard coding of heavy processes, map types, or service endpoints that have to be redeveloped and redeployed every time a change is required. FMSB services are dynamic, reusable services that can rapidly and flexibly chain together as needed at runtime instead of at design time. BizTalk no longer acts as a heavy authoritative Hub. Although the FMSB services are loosely coupled 4 P age

5 and dynamically requested, access to such services is through a centrally controlled administration and security configuration. This approach defines role based access to FMSB services for processes, services, and end users. FMSB Architecture This section describes FMSB architecture, services provided, and benefits to customers. High Level Overview FMSB decouples complex financial processes from each other (and also from complex BizTalk orchestrations), and integrates them into configurable processing itineraries. In Service Oriented Architecture (SOA), every service should be self contained and sustainable. In this manner, business users can select services and group them in meaningful scenarios that add business value. A given service can exist in multiple different scenarios, contributing different business values to the overall solution. FMSB Components FMSB contains a series of prebuilt functions as standard, and also message services that can be configured on implementation. These components are: Set of pre built services to aid implementation and integration.net assemblies specifically for handling financial messages BizTalk artifacts (maps, schemas, functoids) Message Database using SQL Server Simple Business Activity Monitoring (BAM) dashboard, extensible by partners to provide business operational views based on specific operational needs. Since FMSB is built on top of BizTalk Server, A4SWIFT and ESB Toolkit, these software components need to be deployed prior to working with FMSB. FMSB consists of the following components: 1. Resolvers Itinerary header Value header 2. Message broker Orchestration implementation Itinerary services for transaction orchestration through the ESB 3. Adapters Technology adapters from the BizTalk adapter library (eg: for WebSphereMQ) 4. Administration Role based security and permissions for service execution 5 P age

6 5. Tracking Assemblies BAM integration Configuration Dashboards 6. Services SWIFT Service Router Validation of MX messages Validation of MT messages Initiation of Message Repair process Ability to extend FMSB by creating new services A4SWIFT is a foundational element of FMSB and so configuration of some SWIFT processing services would depend on the configuration of A4SWIFT as well. It is important to note that A4SWIFT may be implemented with or without FMSB, depending on a design and architecture approaches. (ie: with or without an ESB architecture model). When implementing A4SWIFT with FMSB, it is important to know what functionalities are affected by FMSB configuration. FMSB and ISV Applications Figure 3 presents the relationship between FMSB core and different functional Independent Software Vendor (ISV) solutions. FMSB core services are building block services that simplify SWIFT usage and provide easy access to FMSB architecture. ISVs can also create reusable services/itineraries that can be leveraged to create a complete solution, e.g., Payments or a Capital Markets engine. Because of reusable and flexible nature of building block services, the Payments Engine in this example can also be included as part of the FMSB architecture. Payment application partners are therefore able to bundle BizTalk and FMSB components into their product solutions and so create a black box environment for SWIFT integration. Figure 3: FMSB Core Services and solutions 6 P age

7 Architecture of FMSB and ESB FMSB is delivered on top of ESB Toolkit 2.0. Because FMSB contains core services dedicated to the Financial Services vertical and focused on SWIFT messaging, it provides out of the box functionality that helps integrate BizTalk Server with predefined services. Together with ESB, FMSB provides a robust platform for building custom services/itineraries and extending the service ecosystem. Figure 2 shown earlier depicts the relationship between FMSB and ESB. Deeply connected with Microsoft ESB Toolkit, the FMSB architecture utilizes the ESB architecture stack, and adds some new features dedicated to financial services messages. In this regard, a key ESB component is the concept of Itineraries in transaction processing. FMSB Itinerary Concept Building upon the BizTalk ESB, FMSB employs the concept of message or transaction itineraries. A Payment Itinerary Service is used to define the lifecycle of a payment transaction type, and is a cornerstone of the FMSB architecture. This lifecycle is constructed from a series of payments services and payment maps. Some or all services or maps are used for a given itinerary. The creation of an itinerary provides FMSB with the knowledge of what is expected to happen to a given message. For example, as a high value, international payment is processed in FMSB, the actual path of the transaction can be mapped against the expected path, and any transaction deviations or exceptions can be quickly recognized. The itinerary concept inside ESB gives FMSB the ability to perform several actions on incoming messages. The processing steps (itinerary) which should be performed are always sequential. Those steps can t have any conditional steps, or wait for some other step to finish. For more information, please refer to the ESB Toolkit documents (see References section). An example payment workflow through FMSB is shown in Figure 4. Multiple payment types are received through the various input channels. The itinerary for each transaction is determined by attributes of the individual payment (high/low value, urgent/non urgent, currency etc). This in turn determines the mappings (in this case all payments are mapped through ISO20022 for validation consistency) and validations that are required. If the validations fail, the transaction is routed to a repair queue/status for manual repair. Once repaired, the transaction is resubmitted and sent for final formatting and queuing to the SWIFT FIN service. 7 P age

8 Figure 4: Example Payment workflow through FMSB Service Tracking Features FMSB provides a unique service tracking system designed as an add on to ESB runtime. It relies on Business Activity Monitoring (BAM) infrastructure to define Key Performance Indicators (KPI), and to store and retrieve data. The tracking system makes it easy to define with high level of granularity which KPIs to track, for which service, and on which Itinerary. The BAM capability of FMSB is extensible by partners, making it possible to easily visualize data that is critical to business decision making. FMSB Dashboard An example of the FMSB Dashboard is shown in Figure 5, which shows a dashboard developed with Microsoft Silverlight for a highly configurable user experience. In this example, the Dashboard shows settings for viewing SWIFT services provided by FMSB, with the ability to drill into the processing steps for a given service and message. The Dashboard uses SQL Server Reporting Services. 8 P age

9 Figure 5: FMSB Dashboard Example By using Microsoft Composite Application Guidance (Prism) for the Silverlight Dashboard, monitoring and administration functionality is exposed as a single module. Customers and partners may extend this dashboard to provide industry specific solutions. 9 P age

10 FMSB Sample Service: SWIFT Service Router FMSB provides a simpler integration to the SWIFT network by encapsulating the SWIFT rules as configurable services. One of the key services provided by FMSB is a SWIFT Service Router. It encapsulates complex processes for transmitting any type of SWIFT message or file to any SWIFT service over specific SWIFT protocols. The SWIFT Server Router reuses A4SWIFT functionality, and it implements A4SWIFT APIs for target scenarios. It comes with a configuration module for SWIFT network access implemented inside a SQL Server database. Building SWIFT solutions requires specific knowledge about business processes related to industry solutions, messages, and protocols. Moreover, if the solution is built using Microsoft technologies, additional knowledge of BizTalk Server, A4SWIFT,.NET development, etc., is also required. Table 1 shows efficiencies that can be realized through the use of FMSB relative to green field project implementation. Table 1. Required solution knowledge with and without FMSB Knowledge Requirements Without FMSB With FMSB SWIFT solution description SWIFT integration guide SWIFT protocols X SWIFT message standards SWIFT technical changes X SWIFT protocols messages (primitives) X SWIFT solution build MSFT BizTalk (pipeline, orch,maps,..) MSFT.NET X MSFT SQL * X MSFT BRE X MSFT A4SWIFT X MSFT ESB * * X * Denotes additional knowledge required or more complex implementations Common tasks in creating a SWIFT solution are shown in Figure 6: 10 P age

11 Collect information Process Handle Response Submit to SWIFT Figure 6: Tasks common to SWIFT solutions How transaction data is collected and processed is specific to the business rules and required processes, e.g., validations by message type. Some of these decisions may also be determined by the SWIFTNet integration scenario, whether by InterAct or FileAct. Once these transactions are processed and validated according to the business rules, the processes for sending information to SWIFT are common and reusable, as depicted by green boxes in Figure 6. The FMSB SWIFT Service Router implements the functionality shown in green boxes, and provides not only the appropriate SWIFT configuration rules, but also the processing rules for sending messages, receiving acknowledgements, and matching transactions. The service is capable of handling requests for sending a SWIFT MX message, an XML message, raw file, and also ISO15022 FIN messages. The service implements complex logic for transmitting data over specific SWIFT protocols like InterAct, FileAct, WebSphere MQ (MQSA), FTP, etc. Figure 7 shows how FMSB SWIFT Service Router can be used to automate third party application solution. 11 P age

12 FMSB ISV solutions External systems SWIFT Service router SCT Bulk payments Core Service Files Trade engine FIX Figure 7: FMSB SWIFT Service Router Benefits of the SWIFT Service Router One service to host access to any SWIFTNet service over any type of SWIFT protocol Support for third party software, creating custom services Works with payload messages and depends on configuration for specific SWIFT service to create primitives with requested fields Capable of hosting several external applications (sender of payload, application access rights which application is capable to send to which SWIFT service, etc.) External application interface could be.net, Java, ESB on ramp service interface, BizTalk adapters, etc. SWIFT service model (automatic update with Deployment package for Alliance or manual) Support environment prefix (doesn t support mode indicator in service name (read from configuration)) one definition for Live, Test, Pilot service 12 P age

13 Conclusions By providing pre built service components, the Financial Messaging Services Bus simplifies missioncritical financial messaging for banks, payments processors and other financial institutions, and provides a solution platform for Microsoft technology partners. FMSB allows for the abstraction and simplification of financial messaging and also integration to the SWIFT network. It can be deployed as part of a client bank implementation, but also embedded in partner applications. Doing so reduces the complexity of financial messaging and SWIFT network integration, and facilitates the integration of legacy and new financial applications to SWIFTNet. The Financial Messaging Services Bus is based on the BizTalk ESB Toolkit for data transformation, and transaction workflow management, and extends the standard ESB to add audit trail and business activity monitoring specific to financial services. The solution is further extensible to enable easy integration to Microsoft Office products, including Excel and SharePoint, for a complete operations management and business intelligence solution. FMSB IP component are available to clients through select partners. For more information about FMSB, and to discuss becoming an adopter, contact Microsoft at References Microsoft Financial Services Web site provides information about Microsoft solutions in Banking, Capital Markets, and Insurance. BizTalk Server BizTalk Accelerator for SWIFT swift.aspx Enterprise Service Bus Toolkit guidance.aspx SAGA Microsoft Gold Certified Development Partner 13 P age