The all-new IFS OData Connector for IFS Cloud

The OData programming model enables extensive product integration and improved data exchange performance. When building OData in an IFS Cloud environment, users can accelerate the entire innovative approach to optimize performance. But OData might be not the only alternative for IFS Cloud. In our previous article, we discussed several cases of how to replicate database transactions in OData. Now we will focus on finding an alternative to OData in IFS Cloud.  Novacura has been exploring the topic of OData for years and, as an experienced partner of IFS, has gained practical knowledge on how to create specific solutions for IFS Cloud. With the deep understanding of our experts, we are sharing our knowledge to increase awareness and confidence among our customers.  Novacura had the opportunity to speak with our expert Albin Lundberg, Novacura Manager Flow Solution and IFS Certified Practitioner – Supply Chain Consultant (IFS Cloud) – 2022. In this article we will generally present some cases that can be seen as an alternative to OData in IFS Cloud. Is IFS Cloud is still based on its previous functional resources? In a sense, yes. The Oracle database is still there underneath the FndODataProvider. So, the logical units, views and packages are still there, but in IFS Cloud, the business logic is instead accessed via the OData API. IFS Aurena Architecture – The most important key components. Does the PL/SQL API that refers to the .NET access Provider still exist in IFS Cloud? No. Referring to the data shared on the official IFS Community forum, it is possible to write new reporting plug-ins to meet the needs of third-party system providers, and IFS also provides some standard options for customers. How can third-party systems continue to access the IFS Cloud and avoid the problems that can arise from the lack of functionality of the OData APIs? The .NET Access Provider connectors won’t work in the IFS cloud; they are deprecated. There are still options to use IFS connect, External File Interface, and Data Migration. The legacy integration options are most commonly used for “system of records” related data such as invoices, payment files, etc. Other than that, external BI tools, that have complex queries and handles large datasets, can fetch data directly from the database or via Information Sources in IFS. But that topic needs its own blog post. Can official IFS Partners, such as Novacura, access APIs by implementing IFS customizations? Yes, it is possible to expose any package or view via customization and custom OData protections. In custom utility packages, you can write your own PL/SQL packages and expose them via OData. However, you need to have the proper skills and certifications to develop and deploy customizations. When IFS Cloud is installed on-premises in the customer’s data center, the company can access all the objects also available as PL/SQL API. Is there any risk in using them? In IFS cloud the end users doesn’t have Oracle accounts, they are maintained in the IFS IAM (Identity and Access Manager). It’s possible to configure a direct […]

Legacy systems implemented in old technologies can cause serious problems when integrating with cloud systems. In this chapter, we discuss the obstacles that might appear in the context of legacy systems when migrating to IFS Cloud and switching to OData API. To provide you with a wider perspective, we interviewed Paul Phillips, Vice President of Product Management at Novacura. What is OData API? 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 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? 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. 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? 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, […]

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. Free whitepaper: 48 Essential Questions About IFS Cloud Integration Answered! Click here to download 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 […]

System performance in an OData environment implies many options for storing and managing application data. To store custom structured data, cloud computing technology can support application development and hosting. An efficient OData implementation should be well-optimized for performance. Otherwise, OData can also involve some risks for a company. To prevent any risks associated with an OData implementation it is necessary to carry it out according to a complementary methodology that the right business partner can provide. We had a great opportunity to speak with Novacura’s expert in the OData environment, Paul Phillips, Vice President of Product Management at Novacura. Together with our speaker, we share insights on OData performance and important details of an OData-based implementation for IFS Cloud. Let’s take a closer look at how you can improve the performance of your network infrastructure with an IFS Cloud OData configuration. OData can have important impact for data efficiency. Does adding OData to the system transport layer PL/SQL, can cause any efficiency implications? OData can definitely have a positive impact on data efficiency since it enables efficient and standardized communication between different systems by using a RESTful API interface. However, adding OData to the transport layer of the system could potentially cause some performance implications if not properly optimized. In terms of PL/SQL, using OData can actually simplify the data access layer by removing the need for custom queries and providing a standardized way to access the data through the RESTful API. This can make the code more efficient and easier to maintain. That being said, it’s important to ensure that the OData implementation is properly optimized for performance. This includes using appropriate caching mechanisms, minimizing the number of round trips between the client and server, and properly handling large data sets. By following best practices and optimizing the implementation, OData can significantly improve data efficiency without negatively impacting performance. OData defines an HTTP-based interface for data services. Within this interface, high-level, general-purpose client libraries and components can use various services, and custom semantics are not required. When transferring a large dose of records to IFS, we may notice an impact on its performance. In previous versions, the PL/SQL connection and data upload to the IFS infrastructure was based on a sequence of “inserts” of separate records. What would this look like now? In the current OData-based implementation for IFS Cloud, the process of transferring a large number of records can be optimized using batch operations. OData allows for the grouping of multiple operations into a single HTTP request, which can help improve performance and reduce the overall network traffic.To use batch operations with OData, the client application would send a single HTTP POST request to the OData endpoint with the “Content-Type” header set to “multipart/mixed”. The body of the request would contain multiple individual requests, each representing an operation like creating, updating, or deleting a record, separated by a specified boundary string.By using batch operations, the IFS Cloud system can process multiple records in a single transaction, potentially reducing the time and resources needed to complete the data transfer. However, the actual performance improvement […]

Implementing OData service authentication may require custom HTTP Modules that can extend the default processing pipeline. In most known cases, developers will use an ASP.NET/IIS-based web application for hosting an OData service. Nevertheless, security authentication and authorization against incoming HTTP requests require infrastructure that combines more specific approaches. These will vary when it comes to certain specifics of each system provider. Creating OData services hosted in the IFS environment have its exclusive complexity regarding customization server-side extension interfaces. We’ll introduce the IFS Cloud OData API service handling processes with regard to the authentication and authorization of the processes in default mode for IFS Cloud. We had the opportunity to interview our Novacura expert Albin Lundberg, Novacura Manager Flow Solution, an IFS Certified Practitioner – Supply Chain Consultant (IFS Cloud) – 2022. We briefly explain how to use the built-in extension object model OData Service to apply custom service authentication, authorization, and initialization, as well as how to handle the upgrades. What are the different authentication options in IFS Cloud? Clients authenticate using the OAuth 2 Authorization Framework and the OpenID Connect Authentication protocol which is built upon it. The authentication process is handled by the IFS Platform and the configured Identity Provider(s). A part of the IFS Platform called the IFS Identity and Access Manager (IFS IAM) handles the authentication. This component is an OAuth2 authorization server that produces access tokens that can be used to access the backend API’s. It supports multiple OAuth2 flows which allow for different clients to authenticate in the manner which is appropriate to them. It can also be configured to handle a multitude of integration scenarios where a third-party app needs to get access.Out of the box, the IAM maintains its own user registry which is kept in synchronization with the IFS user registry in the database. This user registry is used when authenticating users directly with the IFS IAM which is the default mode for IFS Cloud. In addition, external identity services can be used by configuring the IAM to delegate its authentication. This allows services such as Azure Active Directory to provide single sign-on as well as a familiar login experience to the users. In prior versions of IFS Applications, an external system had to login to IFS and open a session using PLSQL APIs, to perform needed operations. Using REST ODATA APIs in IFS 10 you can use Basic Authentication. Is this no longer an option to Authenticate in IFS Cloud? One option is to use Basic authentication. However, it is not recommended. Since you host your instances in the cloud, these are reachable to anyone on the web. Basic authentication can be configured but you need a technical person to do that. The only exception to use it would be when performing migrations of data or when you upgrade or set up your IFS instances. Do not use basic authentication when integrating IFS Cloud with 3rd party applications. In rare occasions, where you simply cannot use any other authentication than Basic Authentication, you can still use it with IFS Cloud, […]

In the very first article on OData in our blog, we presented design rules engineered for this type of REST API to provide clear and concise answers to the respective questions for full deployment. We will continue to explore the subject of OData in our series and explain more about how to handle operation sequences that need to be performed as a business transaction. Relying on Novacura’s knowledge and experience, we have the opportunity to engage our experts in an interview that will help us create a rules-based presentation. For the following article, we interviewed our expert Albin Lundberg, Novacura Manager Flow Solution. In this article, we will review alternative approaches to communicating complementary dependencies and constraints in OData. From the previous blog, we know that OData is a typical REST API that is stateless. As a result, you cannot roll back a previously made API call (or a series of calls). What if there is such a need? It depends on the integration case and requirements. But generally, the client must track each transaction. In some cases, you can do batch calls with several transactions in one call. This is however limited by the implementation of the service or projection itself. From what I have seen there’s seldom support for the creation of a complex structure with just one batch call. Parent and child entities must be created in separate calls. Calls for creating child entities often require the key value of the parent. If the client software doesn’t support the tracking of calls and rollback on any creation errors, there’s the option to do a database customization and deploy a Custom Projection.Hopefully, we will see better support for complex payloads in future versions of IFS Cloud. The example above shows a sample batch request with the operations as follow:  Retrieve → a change set that contains the following requests: Insert and Update → a second retrieve request Source: https://www.odata.org/ What if there is a whole set of operations that are executed sequentially and are treated as a single business transaction in the real world (and were supported by database transactions in the previous PLSQL-based API)? What to do then? As mentioned above on the topic of rollback. The same rules apply to sequential operations. Sometimes Batch calls are possible if the projection supports it, Projection Configurations can be a solution for creating new basic entity relationships. But in most cases, you must do each API method call individually. If standard API calls still aren’t enough for some reason your last resort is deploying custom projections. Let’s take the example that you want to create a customer in a transaction and add several options like bank accounts for this one customer. How to track a full entity structure in IFS to not lose data like bank accounts or/and addresses? The client system needs to track if the full entity structure is created or not. The fact that a single PL/SQL block can result in many OData calls results in new demands on the client or middleware. Not only individual calls; but the business logic also needs to be implemented in […]