ERP Guidebook

Barriers you can meet when moving to IFS Cloud and OData APIs

January 31, 2022

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.

We talked to Irshad Hassan, developer at Novacura R&D, who works extensively with IFS OData implementations. Together with our expert, we talk about the OData protocol and programming models that extend OData standards with customizations.

We know for sure, that the IFS Cloud upgrade is a serious project that requires a good, reliable, and detailed plan. Every good plan should identify risks and potential barriers and should propose solutions to eliminate or mitigate these risks.

We know, that the identification of risks for the IFS Cloud upgrade project might be a serious problem for IFS Customers because it is still a relatively new and undiscovered area. The problem especially arises in the context of integration with IFS Cloud, where a fully new OData API replaces the previous PL/SQL-based API, that has been with us for years.

To help IFS customers plan the upgrade project and identify potential risks connected to the new OData API, below we summarized potential barriers that companies are most likely to face when upgrading to IFS Cloud.

You should consider the following list as your checklist when you plan the migration to OData:

The “stateless” nature of OData– in PL/SQL, there was not a “stateless” foundation, so some “stateful” philosophy might exist in your current integrations with IFS based on PL/SQL. You should identify it and change how you interact with the new IFS via OData.
Database transactions handling– With PL/SQL, you can roll back all operations grouped in a database transaction. With OData, due to its “stateless” nature, you can’t group multiple API calls in a transaction and you can’t roll it back. You must manage the reversal operation manually.
Backward compatibility – you can’t access the old PL/SQL API even if it still exists there, hidden somewhere in the “backend”. So, there is no other option than OData API, and no shortcuts are available. The integration routines must be rewritten.
Authentication / Security – OData API 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. Both solvable – but require some extra attention.
Legacy systems– new systems written in new technology (like Java and .Net) natively offer support for the modern REST / OData communication methods. 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 IFS 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 package them into OData Projections.
Differences between PLSQL and OData API – not all previously available PL/SQL methods are available now as Projections and end-points. But some workarounds could be applied.

The first step in planning the IFS upgrade project should be … a deeper analysis! In particular, you should go through the above checklist of barriers and analyze if these problems exist in your environment and in your company.

Most likely, you will be affected by the majority of them. The question is: to what extent will they affect you?…

To answer that question, you obviously need a deeper analysis. But first, you need to understand better what sits behind all these barriers.

To help IFS customers plan the upgrade project and better understand the IFS OData API nature, with this article, we introduce a series of blog guidebooks, where we present various aspects of the new IFS Cloud OData API:

The differences in the IFS API are not the only challenges that you should include in your IFS Cloud upgrade project plan. We at Novacura help our customers prepare, plan and run IFS upgrade projects. With our unique methodology, which expands the standard IFS methodology, the upgrade project is seamless and the final IFS Cloud installation is also ready for future upgrades (“evergreen”).

Let us help you plan your IFS upgrade project, identify potential barriers you may encounter, and find the right solutions to all your integration challenges.

ERP Guidebook

Barriers you can meet when moving to IFS Cloud and OData APIs

What are the main barriers?

What to do with these barriers?

Broader perspective

Do you have a question?: