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

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:

1. 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.
2. 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.
3. 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.
4. Authentication / Security – OData API requires a new method of authentication. Existing PL/SQL routines should be replaced to meet these new requirements.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.