Project Background

The goal of this project was to eliminate the potential risk of the core banking system revamp project of a foreign bank in Hong Kong.

The Bank had been working on the migration of the legacy core banking system to a new innovative platform. The migration would change the message format and protocol that all of the client applications had been using. In order to make the changes transparent to client applications, an ESB messaging platform (implemented by using IIB) was acquired to sit between core banking back end and front end client applications.

This ESB platform handled the transformation of message protocols and fields mapping for both client and service provider apps, so that both sides changes were transparent to another. Thus, the potential risk of core banking revamp could be mitigated or even eliminated.

Functional Requirements

The ESB platform must fulfil the below functional requirements:

Transactional Volume: 100,000 tx per day for normal operation; 10 tx per sec for peak hours.
Response Time: < 4 secs for each message call, measuring from inbound request to ESB respond.
Disaster Recovery: PROD env identical DR site and recovery procedures are required.
Online Hours: Continuous operation, 7x24.
Message Domain: Deposit, TD, FX, ATM, securities trading, treasury, fund, KYC, etc.
Number of Message Types: 80+ message types to develop.
Number of Frontend Clients: 10+ client apps to connect with ESB.
Number of Backend Service Providers: 4+ service providers to connect with ESB.
Connection Protocols: It is required to handle TCP/IP, HTTP, HTTPS and MQ connections.
Message Formats: It is required to handle fixed-length, ISO8583 pre fixed-length, XML and JSON formats.

Application Architecture

IIB App (client adaptor) : Handling different protocol of clients, perform message fields mapping between clients & ESB.
IIB App (message dispatcher) : Transforming message format from/to ESB & service providers. Communicating with adaptors via MQ.
IIB App (service adaptor) : Handling different protocol of service providers, send outbound requests to service providers and get back result to dispatcher.

System Architecture

There are 2 servers in production site to perform onsite resilience, and 1 server in DR site for offsite resilience. PROD1, PROD2 and DR1 are in active-active mode, the load balancing are handled as below:

• For HTTP/HTTPS client connections, load balancing is handled by F5 Load Balancer.
• For TCP/IP client connections, F5 Load Balancer will route the requests to PROD1 and only route to PROD2/DR1 when PROD1 is not available.
• For MQ client connections, requests will be load balanced and routed by WebSphere MQ Cluster.

IIB Toolkit v10

IBM Integration Toolkit is an integrated development environment based on the Eclipse platform. Developers work with the Toolkit, using the IIB built-in nodes and Extended Structured Query Language (ESQL) to develop ESB message flows.

In this project, the following node types were applied as the connection backbone:

Purpose	Node Types
MQ connection
HTTP/HTTPS connection
SOAP connection
ESB connect to TCPIP service provider
TCPIP client connect to ESB
Routing
ESQL code logic
Exception handling

ESB Application Logging

The ESB application logging was implemented by using ESQL and Java log4j. The log output file would be stored under OS file system in plain text file format.

ESB Exception Handling

The ESB platform applied IIB Exception Plugin, together with itself logging mechanism to handle exception and error tracing.

Roles & Responsibilities

I worked as the software engineer and team lead, responsible for the below end-to-end implementation tasks:

Team Lead:  progress tracking, dev team co-ordinate, status update, cost control.
IIB Architect:  application and system architecture design.
IIB Developer:  IIB ESQL and Java coding, testing, IIB env setup & deploy.