IFS customizations in OData
Custom actions added in OData allow the implementation of non-standard procedures with extended interfaces. Customizations in the OData processing code create pipeline-exposed events through which users can implement other customization and extension code logic. To create a customized model in OData, queries are processed by other code logic injected into the actual query provider. In the real case, we can apply more complex code logic to change the default update/modification behavior to the target entity sets to create more sophisticated business solutions for different industries.
Novacura is exploring custom models in OData for the IFS environment. We had the opportunity to talk 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.
Can we individually write our own projections and endpoints to make our custom Cloud logic available to external systems?
Yes, this is possible. You can choose to extend an existing projection, or you can write a custom projection from scratch to handle your own custom logic. In order to these customizations, you need the usual custom development setup with IFS developer studio. Also the usual customization rules and best practices apply for development.
Is there any method to automate each customization to present it as a projection and avoid manual work?
As far as I’m aware there is no automated process for this. Because the customizations vary in size and complexity. There is no one-to-one mapping between PLSQL packages and Projections.
What about existing customizations created in versions previous to IFS Cloud? How to make them available via API (previously there was a PLSQL API)?
This depends on the type and complexity of the customization. The first thing would be to consider if the customization is simple enough to be implemented as configurations by extending the existing data model in IFS Cloud. If its not then these customizations need to be moved into IFS Cloud via custom projections/custom clients depending on the implementation. Most customizations contains both server-side logic and client-side logic. In client-side logic heavy customizations it might be the case that some of this logic might need to be moved server-side. The IFS Aurena client is a thin client and not designed to handle complex custom logic like IFS Enterprise Explorer client.
Looking at the subject from another angle, let’s assume that the customer had an Oracle Enterprise license and wrote some PLSQL packages that performed custom logic, calling previous IFS PLSQL API functions. How to convert this logic now?
In IFS Cloud there is no database access from the outside. But if you have a development setup for IFS cloud you can deploy your custom plsql packages to the database. To expose the custom PL/SQL logic to the outside world (client/integrations) you need to create custom projections that in turn call your custom PLSQL packages. The category of the new custom projection depends on the context. If it is meant to be accessed by the Aurena client then it is of the type “Users”. If it is meant to be used by integrations then it is of the type “Integration”
What happens to custom entities and custom fields that I have configured in previous versions of IFS?
IFS says that exporting an ACP from one major version (e.g. IFS Applications 10) and importing it into another major version (e.g. IFS Cloud 21R1) is not supported. It is a non-automated process thus it isn’t supported. Since there is no support from IFS we need to do it manually. We need to recreate the custom entities and custom fields in IFS Cloud.
System modifications can influence better operability with good customization but can be very risky and cause needless difficulties. Many companies have already appreciated the concept of Evergreen in IFS. Is there a way to replace previous modifications by migrating to IFS Cloud?
Not exactly. The evergreen concept in IFS is to keep customers up to date with the latest changes delivered by IFS core. It can be new functionality, security/quality enhancements, innovation etc. With IFS Cloud the customer-specific code (aka customizations) will sit in the customer solution layer, while the baseline layer is kept free from customizations. This way IFS can keep delivering the latest changes to the customers while the customer has the ability to choose when to update and plan ahead. Having a clear understanding of what is included in an update and what kind of impact it will have on the existing solution is key. With Evergreen, IFS has created this visibility which eventually helps decision-making for customers.
Novacura’s flagship tool, Novacura Flow, is built to utilize these OData standards, ensuring seamless integration with IFS Cloud and a robust, high-performance solution for data management and process automation. This powerful tool, coupled with Novacura’s team of experienced professionals, enables organizations to unlock the full potential of OData while addressing its limitations and risks.
Learn more about OData and IFS Cloud along with IFS Apps that improved the operations of more than 200 companies from various industries worldwide. Contact with us today and see what we can do for your business.
INTERESTED IN LEARNING MORE ABOUT IFS CLOUD ODATA?
This article is part of a 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:
Below we present more articles in the IFS Cloud OData series:
- The OData basics in the context of IFS Cloud
- How to replicate database transactions in OData for IFS Cloud
- Alternatives for OData in IFS Cloud
- Authentication, Authorization and Initialization in the OData API of IFS Cloud
- OData Efficiency with remote cloud installation
- IFS customizations in OData
- Dealing With Legacy Systems