Albin Lundberg

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 […]

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 […]

We all know that the new IFS Cloud brings a new API based on the modern OData protocol. We know that OData can be a big challenge when companies migrate from previous IFS versions to this new version. In the previous blog, we listed some barriers that might accompany you in the migration to IFS Cloud’s new API. We begin a whole series of blogs to spotlight OData with this article. But because this is the first one, I think it is a good idea to start from the very beginning for those who just started their adventure with OData. This is mainly for ERP owners who might concentrate on business processes more than technology. We’ve talked to Albin Lundberg, Solution Manager at Novacura and asked a few questions about OData basics. Could you explain what OData is? OData (Open Data Protocol) is a standardized protocol for exposing your data using RESTful APIs. REST being the langue of the web means that any application with REST capabilities can easily consume OData resources. As a REST connector, it is state-less, which means that when you have the next request to the system using REST API, you can’t assume that the system remembers your previous requests. You should always send a message with a whole context. Therefore – if you do several operations linked together (order apartment, flight, car). Then you interrupt at some stage and can’t assume that the system will automatically roll back all previous operations. It will not remember your previous calls and requests. We will talk more about this in our upcoming articles. Would you say there are not many specialists in IFS OData API? I’m sure there are OData specialists in IFS. It’s just that consultants or developers rely on code libraries and tools for generating OData APIs. The developer typically writes the query in another language Like C# using LINK query syntax to define the CRUD operations that then translate to OData that can be transported via HTTP. You can write OData queries manually, but it’s cumbersome. To do this efficiently, you need some facilitator, like Novacura Flow!  In the case of IFS, every projection has its own specification or contract, if you will. These specifications are then used to generate the Client code for the interface, REST calls, payload formats, responses, etc.  OData is just a technical protocol, the way we technically connect to the system. And in fact, there is a lot of specialists in that area, but the new IFS API based on OData is an additional business layer. By analogy, OData is a transportation layer like GSM Telephony vs. previous fixed-line telephony. So, you can establish a connection between 2 points using GSM equipment. But the other thing that also changed is also a communication language – you don’t use the same words (functions/methods) – you need to learn the new language; you must know how new projections and endpoints replaced old procedures and views. There are not many experts right now who know this whole new language.  How complicated is this new language? There are 5800 projections in […]