REST @ RedLink: Using APIs to modernize BASE24 and the NonStop Ecosystem

Andrew: Hi, Gustavo.  Could you please tell us a bit about RedLink, and the roles you play there?

Gustavo: RedLink is the biggest national switch for Argentina, owned by the major banks here (Banco Nacion, Banco Provincia de Buenos Aires, Banco Ciudad de Buenos Aires, Grupo Petersen and other important institutions).  We work mainly with public banks (the largest being here in Argentina). RedLink processes more than 27+ million transactions on peak days, driving more than 10,000 ATMs all around the country. We work with more than 60 financial institutions and have more than 1,000 employees.

We are focused mainly on the debit business, although we are starting to get involved in other businesses related to the payment industry, including credit cards, instant payment, instant transfers and others.

For most of the events covered in this interview, I was heading up an internal R&D lab that has the responsibility of investigating new technologies and new ways of doing things on the NonStop and other platforms.  We run trials and POCs to confirm that new technologies will benefit RedLink. We often show the results of our POCs to the board of RedLink, which is made up of our owner banks and IT managers at RedLink, to show how these new technologies can be used in a quick manner.

I am currently in charge of the NonStop Engineering department. We cooperate closely with the Innovation Lab, the BASE24 development group, the architecture team, and open platform departments that need a way to access to BASE24 or the NonStop in order to obtain different kind of services (reading files, initiating transactions, updating files, checking transactions completions, etc).

Andrew: What was your first experience with REST-based Web services?

Gustavo: For a number of years we have been using HPE’s NonStop SOAP to expose a number of BASE24 Pathway transactions as Web services, which are used from our ATMs. One of these services implements a quick cash function that allows a customer to press a single button to withdraw the same amount, from the same account, as was done previously.  Back in 2017, we wanted to use the same Web service, but with REST, as our ATM developers greatly preferred REST.  We simply replaced NonStop  SOAP with LightWave Server^TM, without making any changes to our Pathway server that contained the business logic.  This proved to us just how easy it was to move from SOAP to REST without involving the BASE24 development group.

Andrew: Why did you look at moving from SOAP to REST?

Gustavo: We are finding more and more that our developers are much more comfortable with REST – SOAP is no longer so popular.  When we have been forced to use SOAP recently, we have found that development often takes longer than it would with REST.

Andrew: Have you performed other POCs with REST?

Gustavo: Yes, around the same time, we did another proof of concept, this time using LightWave Client^TM.  We made a small modification to BASE24 to consume a Linux-based funds transfer REST service.  This POC was run in only a couple of days, with little prior knowledge of REST.  It was a great illustration of how simple REST can be: it was up and running with no fuss.  This POC showed us how easily we could consume REST services from our core BASE24 application.  While this POC did not progress beyond trial stages, the experiences we gained were used in future projects.

Andrew: Were there any technical challenges to working with BASE24?

Gustavo: When we initially implemented LightWave Server^TM with BASE24/XPNET, we used a homegrown bridge process.  This bridge process ran as a Pathway server, and sat between LightWave Server^TM and XPNET, allowing traffic to be routed into XPNET via a local loopback TCP/IP connection.  After some discussion with NuWave, we realised that we could connect with XPNET directly via the XPNET Common Transport Subsystem (CTS) protocol, which we now use, removing the need for the bridge process.  Once again, our lab allowed us to learn the best way to implement these solutions in our own environment.

Andrew: What came next?

Gustavo: Once we had shown connectivity between LightWave Server^TM and XPNET, we moved on to an Amazon Alexa POC.  Our goal was to show that voice commands could be used to retrieve account balance information.  This POC was once again completed quickly and was shown to the board so that they could see what was possible.

This POC was an opportunity for us to work more closely with RedLink’s web development group, which has a significant focus on Alexa and other new technologies.  The POC showed another major benefit of REST.  This group has previously used ISO8583 to communicate with BASE24, with all its complexities, as there was no other option.  With LightWave Server^TM implemented, this group can now use REST services, which are a much simpler way of accessing BASE24.  This realisation was one of the biggest benefits of our POC – a real turning point in the minds of the developers on other platforms.  From then on, the NonStop has been viewed as a much more standard, open platform than it ever was previously.

Andrew: Have any of the POCs led to a production implementation?

Gustavo: We are now working on a project that we expect to implement in production, based on the first POC we did with LightWave Client^TM.  The new API-based open infrastructure at RedLink is exposing a REST Web service that needs to be consumed when a specific transaction takes place in BASE24. RedLink exposes many internal APIs using REST so different platforms (being NonStop, Unix, Linux, Windows) can interchange information between them improving the time to market of different solutions.  APIs are the normal paradigm today so having tools on every platform that can “talk” easily with REST is a must.  If a transaction is received in BASE24, regardless of the channel, we need to check if the card number was enrolled in a new business program.  Based on that check we approve or decline the transaction and depending on the REST reply we may show a different menu on the ATM providing access to the new program.  We expect this project to be live about a month after this interview.

LightWave Client^TM will allow us to simplify the transaction in a very easy way.  The LightWave products allow us to improve our time to market by integrating all of our platforms (NonStop, which is the core, and the surrounding platforms) using REST.

Andrew: Are there any other REST projects on the horizon?

Gustavo: We want to create a mobile application for internal use by our technical support teams and in the future, offer this application to bank managers so they can get information in near real-time about different technical concerns between the bank and RedLink .  This app would display key indicators of NonStop performance and would expose its data via REST, to be consumed by the mobile app.

Additionally, we currently use SFTP for file transfer, and we would like to move to REST-based interfaces for some of our file transfers to allow response codes to be returned to the user.  This approach has less transient processes running on NonStop, so less CPU consumption, and it allows us to create a complete online workflow so the consumer always knows the status of their transfer information.

We are excited about other future possibilities for the LightWave products, which will become clearer once additional internal stakeholders start to see what is possible.

Gustavo Martinez has over 22 years of experience in the NonStop space. He has a degree in Systems Engineering and has always been involved mainly with the financial industry. After working at Banelco he moved to RedLink where he is currently working. Gustavo has been working for more than 18 years at Redlink and today he is in charge of the NonStop Engineering department although he was in different positions, including the Head of the Innovation Lab. Focusing on having a team with a strong knowledge of different products and technologies that can be used with NonStop, Base24 and all of the ecosystem that support the platform.