As many already know, IFS has launched IFS Cloud. It’s built entirely around standards-based Open APIs, so everything you can do in IFS Cloud you can also do through open APIs. From IFS 10, they have enabled connection through OData RESTful APIs to use standard HTTP methods (GET, POST, PUT, PATCH, DELETE) to call the API.
All customers sitting on PL/SQL scripts and integrations face the challenge of moving from the PL/SQL API to the OData API.
The ecosystem surrounding any ERP and central business system of an organization is complex. The transition needs to be handled correctly, so the choice of partners and solutions will be important.
Suppose you plan the inevitable move “migration to IFS Cloud”. In that case, you must consider that the new OData API introduced by IFS Cloud (and eliminating the existing PL/SQL API) might be a severe problem if you don’t know how to plan it and mitigate risks. But this problem can be effectively handled.
Checklist of barriers
As mentioned in our previous article, we don’t want customers to get lost in translation. Therefore, we’ve paid much attention to providing a new tool and educating customers that use IFS Applications. We want to share our experience and discuss all known challenges with OData in our blog.
You should consider the following list as your checklist when you plan the migration to OData:
- Authentication / Security – OData requires a new method of authentication. Existing PL/SQL routines should be replaced to meet these new requirements.
- Efficiency aspects – although OData itself is an efficient way of communication between remote systems, there are specific situations where changing from PL/SQL to OData might negatively impact the performance (efficiency). Especially in all these situations, the external system applies changes to large sets of records at once.
- Cloud installation consequences – if you decide to install your IFS Cloud in the cloud (and not in your private data center), you must consider what impacts this change will have on your integration. There might be some security problems or efficiency issues.
- Database transactions handling – With PL/SQL, you can roll back all operations in a transaction. With OData, you must manage the reversal operation manually.
- Backward compatibility – you can’t access the old PL/SQL API even if it still exists there. So, it would help if you planned the migration for all the integration points (no shortcuts).
- Legacy systems – new systems written in new technology (like Java and .Net) natively offer support for OData. But how about old systems or systems owned by other Parties (your customers/ suppliers)? Some old technology can’t even connect to OData and you have to think about some workarounds to reach the only possible OData interface.
- Existing IFS modifications – your IFS Applications might have a lot of modifications – which means there might be a lot of custom PL/SQL objects and procedures. With the IFS Cloud, you can’t use them directly and you have to think about how to reach them via OData.
- The “stateless” nature of OData – in PL/SQL, there was not a “stateless” foundation, so some “stateful” philosophy might exist in your real integration with IFS. You should identify it and change how you interact with the new IFS via OData.
- What is missing in Projections – not all previously available PL/SQL methods are available now as Projections. But some workarounds could be applied.
What to do with these barriers?
All customers that plan to migrate to the IFS Cloud should independently analyze the impact of the problems listed above on their individual IFS infrastructure. Different installations might expose different problems and some problems might not occur at all in some cases. We at Novacura know, that analyzing these potential problems is a complex task, especially because the O-Data interface is new and there is not enough practical knowledge about it in the market. And what is especially important here, when planning the migration companies can’t base only on theoretical assumptions – aspects like efficiency or security might need specific tests to evaluate the scale of the problem.
But there is also some positive information – we at Novacura feel responsible for IFS Customers and we want to share our expertise in the IFS O-Data API area. Therefore we have analyzed and done several tests for all the listed barriers above and gained in-depth knowledge during the process. We want to share our findings with you, so we are releasing a weekly series of articles for the upcoming weeks.
We will start by showing some specific replacement patterns: a few typical situations like updating data, reading data, calling a simple method. We will show an example of an API from an old standard method, PL/SQL and replace it using the new OData method.
We will also clarify how you choose installation location – in the Cloud or on-prem. And don’t worry, we will also help you plan and estimate the scale of a “prepare for IFS Cloud” project.
