Ensure High Availability in Banking Systems using WSO2 Enterprise Integrator

9 min readJun 13, 2019

Downtime can strike at any point in time with applications and services from even multi-million dollar brands. Just one hardware/software issue can cause a business to lose hundreds of millions of dollars in the blink of an eye. Regardless of whether you are a fortune 1000 company or a smaller business any outage can be costly and painful. The key to keep IT systems operational in case of hardware/software failure is to reduce the risk by having a plan B. You could have redundant systems in place if there is a sudden outage or you could define a fault flow that would be executed in case of a failure which would still allow the users to interact with the systems smoothly without any ado.

This blog will demonstrate the capabilities of WSO2 EI that can be used to ensure high availability in banking systems when managing accounts.

Scenario

The use case is based on ABC bank. In this blog, we have simplified the use case to focus on Account Management in ABC bank. It would particularly focus on performing withdrawals.

Users can perform withdrawals with ABC Bank if their account balance is greater than the withdrawal amount.

If the withdrawal amount is less than the balance then the user is able to successfully perform the transaction. Suppose a user with account “1011” needs to withdraw $2200 and has only $3000 in the account, the transaction will be successful and the following success message will be returned.

{
    "message": "An amount of $2200.00 was withdrawn from account 
                with id 1011. Available balance is $800.00"
}

If the withdrawal amount is greater than the balance then the user is notified. Suppose user with account “1011” needs to withdraw $1500 and has only $1000 in the account, the following error will be returned.

{
 “error”: “Cannot withdraw from account with id 1011 since the            
           balance is less than the amount to be withdrawn”,
 “available balance”: “$1000.00”
}

Likewise, if there’s no account associated with the given account id or if there are any failures while retrieving the account details it will be notified to the user via error messages.

Let’s assume the bank system crashed due to a power failure, software failure, or operating system crash, still, the users should be able to do transactions without any ado.

By using WSO2 EI to expose the banking operations the users are still able to perform withdrawals smoothly without any issues even when the bank system is unavailable (downtime). WSO2 EI is configured to handle this fault scenario effectively as below:

A database will be used to store the transactions that were performed during downtime. Let’s call it the transaction database. This database will store the account id and the current balance and will be in sync with the database of the bank system. So this database will be updated with the new balance of the account every time we perform a transaction when the bank system is up and running.
When a user tries to perform a withdrawal when the system is down, the balance of the account will be retrieved from this transaction database (It’ll have the updated balances since it will be in sync with the database used by the bank).
A user is allowed to perform a transaction only if the balance is greater than the withdrawal amount. If a user performs a withdrawal successfully, then the new balance is calculated (available balance-withdrawal amount) and updated in this transaction database.
It will update a flag in the transaction database to denote that a transaction has been performed using the particular account during system downtime and that it has to be updated in the bank database once the bank system is up and running. The updated flag by default would be ‘0’ meaning that no transaction has been performed during system downtime. It would be changed to be ‘1’ to denote that a transaction has been performed during system downtime.
Once all the issues of the bank system have been fixed and the system is up and running (available), it will send a trigger to WSO2 EI. This would ideally invoke an API that will re-sync the updated account balances in the transaction database with the bank database. After updating the new balances in the bank database, the updated flag will be changed to the default value again to be ‘0’.

Points to Note

The back-end of ABC bank is mocked using Ballerina (version: 0.991.0). The back-end will only have the following resources needed for account management:

2. The back-end of the bank will be exposed via WSO2 EI. This will ensure that even if the actual back-end of the bank crashes, still the users will be able to perform transactions without any ado.

3. Following APIs are exposed via WSO2 EI

An API to expose the operations (actual back-end of the bank) of the bank and to handle fault scenarios i.e. when the back-end of the bank is down. Even if the back-end of the bank is down (has crashed) users can still perform withdrawals. To handle such situations WSO2 EI will have a temporary database where all the transactions that happened during the down-time will be saved. Once the back-end of the bank is up and running all transactions performed during the down-time period will be updated to the system.
An API to re-sync the transactions that were carried out when the back-end of the bank was down once it’s up and running.

Prerequisites

WSO2 EI 6.5.0
MySQL database and driver
Ballerina — To run the actual back-end of the bank

Configuring the database

Install the MySQL server.
We would need 2 databases. One to be used by the banking system and another to store the transactions that were performed temporarily during the downtime.
Execute the following database script to create the databases and the tables needed. Account records will be added to the banking system database.

Running the bank system

Back-end of the bank is mocked using Ballerina so download and install Ballerina
Download the JDBC driver for MySQL from and copy it to your , copy it to your <BALLERINA_HOME>/bre/lib
Save the following file in a directory of your choice.

Update the username and password of the MySQL Server.
Navigate to the directory where you saved the file and start the service.

$ ballerina run bank_service.bal

Configuring WSO2 EI

Before starting the EI server follow the steps given below:

Download WSO2 EI
Download the JDBC driver for MySQL from here and copy it to your <EI_HOME>/lib directory.
Start the EI server

Creating the artifacts

To create the artifacts we will be using the Integration Studio i.e. the tooling provided for WSO2 EI
Install WSO2 EI tooling using the instructions given here.
Open WSO2 Integration Studio and click ESB Project → Create New in the Getting Started.
In the New ESB Solution Project dialog that opens, enter the name for the ESB config project as “ABCBankSystem”. Select the check box to create a a Composite Application project along with the ESB Config project.
Click Finish to save the projects. You would have 2 new projects created: “ABCBankSystem” and “ABCBankSystemCompositeApplication”
Add the API that exposes the back-end operations of the bank. Right-click on “ABCBankSystem” in the Project Explorer and navigate to New -> REST API. Ensure Create a New API Artifact is selected and click Next. Provide the following values and click Finish to save the API.

Once the API is created, go to the source view by clicking on the Source tab at the bottom. Replace the content in it with the following:

Add the API that re-syncs the transactions that were carried out when the bank system was down once it’s up and running. Right-click on “ABCBankSystem” in the Project Explorer and navigate to New -> REST API. Ensure Create a New API Artifact is selected and click Next. Enter the following values and click Finish to save the API.

Once the API is created, go to the source view by clicking on the Source tab at the bottom. Replace the content in it with the following:

Packaging artifacts into composite applications

Right-click on “ABCBankSystemCompositeApplication” (this is the C-App project) in the Project Explorer and click Export Composite Application Project to create a CAR file out of that project.
Specify the location to save the CAR file.
Select the project/artifacts you want to include in the CAR file. Let’s select only the “ABCBankSystem” project out of the available projects since it will have all the artifacts we created in the previous steps.
Click on Finish

Deploying CAR files in WSO2 EI

Since we already started the EI server, log into the management console using https://localhost:9443/carbon as an admin. (username — admin, password — admin)
Click the Main tab on the Management Console, go to Manage -> Carbon Applications and then click Add
Click Choose File, select the CAR file we created in the previous step and click Upload.
After you upload the CAR file let’s check if the CAR file is successfully deployed. To check click the Main tab on the Management Console, go to Manage -> Carbon Applications and then click List. The Carbon Applications List screen appears. If successfully deployed, the C-App will be listed here.

Upload the data service

Since we have already configured the database, let’s upload the data service that is already created to EI. We can create data services via the Integration Studio or using the management console. To reduce the preparation time let’s upload the data service that has been already created.
Save the following data service configuration file as “AccountDataService.dbs” in to a directory of your choice.

Update the username and password of the MySQL server before uploading.
Click the Main tab on the Management Console, go to Manage -> Services -> Data Service and then click Upload. Upload the “AccountDataService.dbs” file that was saved.
After you upload the data service file, let’s check if the data service is successfully deployed. Click the Main tab on the Management Console, go to Manage -> Services and click List. The Deployed Service List screen appears. If successfully deployed, the data service will be listed here as “AccountDataService”

Let’s get started

We have configured all the systems as above to start with the demo. 2 scenarios will be show cased here.

Details of the transaction API that would handle the bank operations

1. Happy path scenario

In the happy path scenario the bank system would be up and running (ballerina service is running).

Use a client like Postman to invoke the transaction API with the details provided above. For a withdraw to be successful the account balance should be greater than the withdraw amount, provide each of the given XML payloads in the request body and send separate requests. This will directly invoke the back-end of the bank system.

<transaction>
    <id>110011</id>
    <amount>2000</amount>
 </transaction><transaction>
    <id>110022</id>
    <amount>500</amount>
 </transaction>

Use a MySQL client to check if the new account balances have been updated in the bank database.

Account ID : 110011, Current Balance : $10000Account ID : 110022, Current Balance : $15000

Use a MySQL client to check if this account id and balance has been added to the transaction database. Ideally both the databases should be synced.

Account ID : 110011, Current Balance : $10000, Updated : '0'Account ID : 110022, Current Balance : $15000, Updated : '0'

2. Fault scenario

In a fault scenario the bank system would be down i.e. the ballerina service will be stopped but the users will be able perform withdrawals smoothly without any ado.

Use a client like Postman to invoke the transaction API with the details provided. For a withdraw to be successful the account balance should be greater than the withdraw amount, provide each of the given XML payloads in the request body and send separate requests. This would go through the fault sequence since the system is down.

<transaction>
    <id>110011</id>
    <amount>5000</amount>
 </transaction><transaction>
    <id>110012</id>
    <amount>2500</amount>
 </transaction>

Use a MySQL client to check if the account balances has been updated in the transaction database.

Account ID : 110011, Current Balance : $5000, Updated : '1'Account ID : 110022, Current Balance : $12500, Updated : '1'

Use a MySQL client to verify that the account balances in the bank database has not been updated with the new balances.

Account ID : 110011, Current Balance : $10000Account ID : 110022, Current Balance : $15000

Restart the bank system i.e. start the ballerina service again. This will send a trigger to WSO2 EI and it will re-sync the updated balances in the transaction database with the bank database.
Use a MySQL client to verify that the account balances in the bank database has been updated with the new balances.

Account ID : 110011, Current Balance : $5000Account ID : 110022, Current Balance : $12500

Use a MySQL client to verify that the updated flag in the transaction database has been updated with the default value i.e. ‘0’.

Account ID : 110011, Current Balance : $5000, Updated : '0'Account ID : 110022, Current Balance : $12500, Updated : '0'

If the changes given above were observed you have been able to configure and understand the role played by WSO2 EI in core banking systems. This blog post only focuses on one aspect of account management. Likewise you can handle any complex integration scenarios related to core banking systems using the capabilities provided by WSO2 EI.

Now as for how to end with a bang? Well, that’s another blog post for another time so stay tuned:) :)