Dealing With Legacy Systems

December 2, 2024

OData (Open Data Protocol) API is a standardized protocol for building and consuming RESTful APIs, which allows applications to interact with data over the internet in a consistent and interoperable way. Developed by Microsoft and approved as an OASIS standard, OData enables the creation, reading, updating, and deletion (CRUD) of data through a uniform and predictable interface, making it especially useful for data-centric applications and services.

The problem is definitely much wider, and it is not just limited to replacing the integration logic and calling the new set of API objects and methods instead of the old ones. For the legacy systems, there might be additional technical or organizational barriers, such as:

No support for OData protocol: The technology used in many legacy ERP systems doesn’t support the OData protocol, which complicates integration with legacy systems.
No state-less philosophy in the legacy system
Synchronous communication expectation
Technical Limitations: For successful integration with legacy systems, compatibility with HTTP(s) protocols, connectivity, and security requirements must be addressed. Some legacy systems may require additional support for cloud-based operations.
Organizational Challenges: Legacy system management is further complicated by limited documentation, lack of source code, and a shortage of resources knowledgeable in how to integrate legacy systems with modern platforms. These barriers are common when organizations seek to connect legacy systems to new cloud infrastructures.

When we think about legacy systems, we usually think about old systems built 10-20 years ago as hard-coded software programs, written in C / C++, Visual Basic or even more specific technologies (eg. when we think about specific machinery integrations). These systems were designed before the cloud computing concept has been introduced and the OData standard was defined. It might mean that there is no ready-made OData library for the technology used to implement the legacy system. All the common OData foundations (that reside below the business layer added by IFS) must then be implemented manually, which is a large additional cost of adjusting the legacy system. Keep in mind, that even if the OData support libraries exist for the language used to implement the legacy system (eg. C++), this library might be incompatible with the particular framework used to build the legacy system, so we must be very careful when checking it and before we formulate the proposal in a feasibility study.

As we know from Chapter 2, OData is a REST protocol implementation that uses a stateless foundation. The problem is, that many legacy systems might expect stateful communication with external systems (IFS in our context), where the other party of communication “keeps the context”. With that, the legacy system might expect the other system to remember many more parameters connected to the communication session – like the current Customer number, current Purchase Order number, or currently processed Invoice Number. Of course, it is possible to change the system’s logic to support the stateless paradigm, but if the stateful philosophy was widely implemented in almost all integrations, this process would require a lot of work, time and money. And it would definitely require a lot of runtime tests.

This is another problem that might (but also might not) appear. The majority of PL/SQL operations (used when calling the old IFS API) are performed in a synchronous mode, where the business result of the operation is immediately returned to the external system when the operation has been completed. In other words – the external system hangs until the API method is fully executed. The system gets the final result and can proceed with further operations being sure, that the previous API call was implemented. For example – the system can add invoice lines to the just-created invoice header, and the execution of the code responsible for adding these lines will not be started until the header is added.

The new OData API is not a 1:1 clone of the previous API, just in another technology. Some API calls are asynchronous in essence, and the external system can’t assume the immediate results. It means that the system should implement a polling process and repeatedly check if the result of the previous operation is available. This might require a lot of adjustments in the legacy systems – the simple “step-by-step” code must be interlaced with “results checking” loops.

All the problems described above might be considered as technical problems, but they are more connected to differences in the software’s behavior (logic). At this point, I would like to focus more on “hard” layers – connected to the network and infrastructure area.

First, the legacy system must be able to connect to the external systems that operates in the cloud by using HTTP(s) protocols. This might not be currently possible for the legacy system and the chosen technology and might require the use of additional libraries. Another problem might be the compliance with security rules (e.g. the ability to encrypt the data and not pass sensitive parameters directly to the other system) or the efficiency (the ability to set up more parallel instances of the legacy programs to increase the performance). It all might have a huge impact on the legacy program architecture and will require a lot of tests before going live.

Right – when we typically think about integration, we mainly focus on technical aspects. But, especially in the context of legacy systems – there are also a lot of organizational problems that might be solved at the IT Director or Project Management level. Let’s name them:

There are probably not so many resources knowledgeable in the legacy system area, who can help us well identify the problems upfront and prepare the correct feasibility analysis
The team capable of developing the changes in the legacy system (no matter if internal or by the system vendor’s side) might be very limited – for many years, this old system was only evolutionarily developed by a small team, that might be not enough for implementing all the big changes needed in a short time
There might be a lack of system documentation – and I’m not talking about user documentation or standard technical one, but about the documentation of all changes and integrations implemented over the years
The customer might not own the legacy system source codes, and the system vendor might not be eager to implement such big changes (due to the risks)

Well, It all boils down to how big the problems are, how old the system is and how large is its footprint in the customer’s organization.

Usually, when the legacy system is a highly specialized software and commonly used in the organization, the best option is to keep it alive and implement some communication proxy that will solve the integration problems. We promote the concept of implementing the communication gateway, where an additional software stays between IFS Cloud and the legacy systems, and helps them communicate together. It can offer legacy integration protocols on one side (like flat files or PL/SQL packages, tables and views), and fully support the new OData-based cloud technologies on the other side. Simply saying – such gateway can “open” old systems for new technologies. It can also offer additional functionality, for instance, it could cover the need for checking the API call results with a polling strategy.

Of course, if the problem is a hard blocker, the system is really old and used only in a specific niche, the implementation of a fully new solution might be the best idea to get rid of the old technologies. This might be not only cheaper and faster, but it will also reduce the risks and will be easier maintained in the future.

Sure! There will be no surprise when I say, that we use the Novacura Flow platform to support both concepts: to build a communication gateway and to “rewrite” smaller legacy systems if needed.

Novacura Flow can act as a bridge between the legacy system and the new APIs. It is designed to handle both OData protocol and the methods used by the legacy system. When the legacy system sends a request, Novacura Flow can translate it into an OData request and send it to IFS Cloud. When a response is received, it translates it back into a format the legacy system understands. This allows the legacy system to continue operating without significant changes while still benefiting from the features offered by the IFS Cloud.

In some cases, it may be more efficient to recreate the functionality of a smaller legacy system within Novacura Flow. This is especially true when the cost and complexity of maintaining the legacy system outweigh its benefits. Novacura Flow’s low-code platform allows for rapid development and deployment, which can drastically reduce the time and expense of a full system rewrite. Novacura Flow also provides a more future-proof solution, as it’s designed to easily adapt to new technologies and standards like OData.

In both scenarios, Novacura Flow provides a versatile and efficient solution to the challenges of integrating legacy systems with new technologies. It’s not just about compatibility, but also about improving efficiency, reducing maintenance costs, and preparing for the future.

INTERESTED IN LEARNING MORE ABOUT IFS CLOUD ODATA?

The article you are about to read is part of a broader series on the IFS Cloud OData API. Here's a link to the main article, which lists all the major barriers you may encounter when upgrading to IFS Cloud:

Introduction – barriers you can meet when moving to IFS Cloud and OData API

Below we present a whole list of articles belonging to the IFS Cloud OData series:

Dealing With Legacy Systems

What is OData API?

The new IFS OData API is a revolution especially for all the legacy systems integrated with previous IFS versions (that currently use PL/SQL API). Could we start with briefly defining the areas in which the problems might appear?

All the topics mentioned above sound serious, and definitely require additional clarification. Let’s focus on them all one by one. Could you start from the beginning and tell us a bit more about the lack of support for OData in the legacy system’s technology?

OK, let’s move to the 2nd point – the lack of state-less philosophy

It becomes more and more challenging, and we still have a lot more points to discuss. So how about the “synchronous communication” mentioned in point 3?

Thanks for your clarification. Let’s move to the 4th point – which is “technical limitations”

Thanks for your clarification. I see that we more or less covered all technical areas. Let’s move to the last one – which is more focused on the organizational aspects.

I see that there might be many serious problems when integrating the legacy systems into the new IFS OData API. It would be much easier if we could still use the previous API. Is there any chance to still use the previous PL/SQL API that still exists beneath the OData API?

If there is no “shortcut”, what can companies do when some of the problems described above become a “hard stops” for them (like for instance the lack of resources to change the legacy system)?

Can you quickly describe how you solve the above problems?

INTERESTED IN LEARNING MORE ABOUT IFS CLOUD ODATA?

Do you have a question?: