IFS Cloud under the hood: exploring CRIM, APIs and the lifecycle

In this article, I will not discuss the functional part of IFS Cloud. Instead, I'll share what we discovered on the technical side: configurations, reports, interfaces, modifications, workflows, APIs and deployment cycle.

One of my clients chose IFS Cloud as part of an ERP migration project. The environment is now in version 25R2 and, at this client, I hold the position of manager of the applications division.

25R2version IFS Cloud used by the customer

4families of CRIM

2distinct spaces: Build Place and Use Place

CRIMUnderstanding CRIM

One of the first vocabulary items encountered in an IFS project is the term CRIM:

Configuration

Low-code adaptations, pages, fields, entities, projections and BPA.

Reports

Quick Reports, Business Reporter, editions and operational reporting.

Interfaces

REST/OData API, middleware, flat files and IFS Connect.

Changes

Developer Studio, Marble, PL/SQL, builds and Deliveries.

This classification seems simple, but the same need can mobilize several technical objects. Adding a field, for example, may require a configured attribute, a page edit, and possibly a validation workflow. A CRIM therefore does not always correspond to a single technical object.

CC as Configuration

A configuration is an adaptation made without directly modifying the IFS standard code. A significant portion of this work can be done from IFS Cloud Web.

Fields, entities, pages and projections

IFS Cloud screen used to configure or explore technical objects — Example of screen IFS Cloud used during the configuration phases.

It is possible to add custom attributes, create custom entities, configure pages or extend certain projections. However, we must avoid a common shortcut: an entity is not simply a table and a projection is not simply an SQL view.

An entity represents a data model object and can rely on multiple database objects. A projection exposes part of the functional domain as a REST service. It contains sets of entities, but also actions, functions, structures, enumerations, and other controls.

When a configuration is published, IFS can generate the necessary database objects, refresh the metadata, and make the new items accessible in the affected projections.

For a developer used to directly exploring the tables of an RDBMS, getting started can be confusing. The model is documented through entities, projections, system information and the Explorer API, but it does not always appear as a classic relational diagram.

BPAs and workflows

BPA workflow example with REST call in IFS Cloud — Example of BPA integrating a REST call in a workflow IFS Cloud.

Business Process Automations, or BPA, are based on a workflow designer inspired by BPMN. They allow you to add logic around the operations carried out in IFS Cloud without immediately customizing the standard code.

There are three main families in particular:

Validation: control an operation and prevent its validation when a rule is not respected;
Process Enrichment: enrich or modify the values transmitted during processing;
User Interaction: Request additional information from the user during the process.

BPAs are a real strength of IFS Cloud, but they do not replace a general programming language. The possibilities are framed and it is sometimes necessary to rethink the need to stay within the scope of the configuration.

Lobbies

Lobbies are personalized portals that provide an overview of a process, a role or a set of indicators. Users generally like them because they avoid going through multiple screens to find important information.

Lobbies do have page settings. These parameters can be stored in the user's profile or transmitted in a navigation URL. On the other hand, the proposed controls do not always offer the richness of a real list of business values. A user may therefore need to know a company, site or project code.

Best practice is to limit the number of parameters, use relevant default values and, when possible, build links that directly open the Lobby with the correct context.

RR like Reports

The word report covers several families of tools in IFS Cloud. It is important to distinguish between quick reports, operational reports and more advanced analysis tools.

Quick Reports

Quick Reports meet a need for ad hoc reporting. For a simple table, it is possible to use an SQL query or Query Designer, then export the result to Excel.

They are effective for quickly producing a list, but the parameters can become unusable when you multiply the filters. Default values can help, but you should avoid turning a quick report into a full application.

For more advanced Excel needs, IFS now directs towards Business Reporter. The old Excel plugin used for operational reporting has been deprecated for several versions and should not be confused with Business Reporter.

Editions and operational reports

Documents such as invoices, orders or delivery notes fall under operational reporting. IFS Cloud now offers two native tools: IFS Report Designer, installed on the workstation, and IFS Report Studio – Designer, accessible from the Web.

When our project began in 23R2, the experience with the available tool did not meet our expectations for stability and productivity. We have therefore chosen a complementary solution, Ootary, for certain editions and certain advanced screens.

This observation must be dated: the native offer has evolved since the start of the project, in particular with Report Studio. A third-party solution can save a blocking need, but it also introduces a new environment, a new language, specific skills and an additional dependency.

II as Interfaces

Exploring an interface and its projections in IFS Cloud — Identifying the projections used by a screen is often the starting point for integration.

In our context, exchanges between IFS Cloud and other applications mainly pass through the Blueway middleware.

The opening of IFS Cloud is one of its real highlights. The Explorer API lists available OData projections and services, with their entity sets and documentation. Calls rely on classic HTTP methods and JSON exchanges.

Finding the right API

IFS Cloud API Explorer with OData documentation — API Explorer allows you to find projections, entities, actions and associated documentation.

A practical method is to open the relevant screen, activate the IFS development tools and observe the network calls. It is then possible to directly open the corresponding projection in API Explorer.

This method allows you to quickly understand what the interface does, but the API used by a page is not necessarily the best API for system-to-system integration. IFS distinguishes in particular between Premium APIs, integration APIs, standard APIs and Entity Service APIs. The choice should depend on the use case, expected stability and level of support.

IFS Connect

When the integration relies on messages, files or more traditional protocols, IFS Connect acts as an integration broker. It supports different connectors, including HTTP/HTTPS, FTP/SFTP, Mail and JMS, with transformation mechanisms.

It therefore remains entirely possible to manage flat files when the target system does not offer an API. It works, although this approach generally requires more monitoring, error handling, and naming conventions.

MM for Modifications

Modification is the part that I master the least in practice. It intervenes when the configuration tools are no longer sufficient and it becomes necessary to extend the internal functioning of IFS Cloud.

In the IFS documentation, this approach is called extending on the inside or customization. It is carried out with IFS Developer Studio and can use IFS models, Marble for the client, PL/SQL for server logic and, in certain cases, Java.

Developments must be carried out in the customization layer, without directly modifying the standard files. Development is carried out with IFS Developer Studio and can use PL/SQL for the server part, as well as Marble for the IFS Cloud Web screens.

The Git, Sanity Build and Delivery cycle

The process of delivering a change is much more structured than a simple configuration done from the front. In our project, the theoretical progress is as follows:

1 create a new branch in the Customer Solution Git repository;
2 carry out the development and the first tests in the development environment of Build Place;
3 commit and push changes to the repository;
4 create a merge request, have the code checked, then merge the branch into the main branch;
5 launch a Sanity Build on the concerned commit;
6 correct any generation, database deployment or compilation errors until obtaining a status san-OK;
7 generate a Delivery from Build Place;
8 test this delivery in the environments provided for this purpose;
9 request its deployment in the environments of Use Place, in the correct order: test environment, staging or UAT, then production.

The Sanity Build doesn't just check that the files are present. In particular, it controls the generation of the database code, its deployment and the compilation of the solution. When successful, a sanity image is produced and the commit is identified with a tag san-OK. This step is essential before preparing a reliable delivery.

I am not going to pretend to master this whole part: I know the process and the delivery stages, but the most structuring customizations today remain mainly carried out by our integrator.

ACPTransport configurations with ACP

Mandatory rule in our project

In our project, the division of exports is mandatory. We create separate ZIP files depending on the nature and level of dependency of the configurations. We do not mix, for example, in the same ZIP the creation of an entity or a data attribute with the configuration of the screen which uses this element.

This division allows you to precisely control the installation order. The package that creates the data object must be imported and published before the package that modifies the projection, and then before the package that configures the page. If the ZIPs are imported in the wrong order, IFS logically returns errors: the screen or projection then attempts to use a field that does not yet exist in the target environment.

We therefore divide the ACP both by functional brick and by technical layer. This method produces more packages, but it makes it easier to identify dependencies, recover from failures, and understand what is actually installed in each environment.

Configurations made directly in IFS Cloud must be organized and transported from one environment to another. For this, IFS offers Application Configuration Packages, or ACP.

A ACP can contain several types of configuration objects: attributes, pages, configured projections, workflows, events, or other supported elements.

An important point: a configuration object can only belong to one ACP at a time. Additionally, removing an object from a source package does not automatically remove it from the target environment during a subsequent import.

BDRStart BDRs as early as possible

I end with a piece of advice that concerns the project more than the development: get users working on the BDRs as soon as possible.

In IFS vocabulary, BDRs correspond to Basic Data Requirements, that is to say the configuration data necessary for the operation of processes. This includes, for example, tax codes, payment terms, accounting groups, statuses, locations and many other repositories.

WEBA community resource that has helped us enormously

COMMUNITY RESOURCE

During the project, DSJ’s Blog helped us enormously. The official IFS documentation remains essential, but it is very broad and sometimes describes more the possibilities of the platform than the concrete way of solving a problem encountered in the field.

On the contrary, DSJ publishes directly usable examples, with practical cases around workflows, REST calls, authentication, integrations, troubleshooting and reports. Several times, his articles allowed us to quickly understand a mechanic that we had difficulty reconstructing solely from the documentation.

In our experience, this blog has often been more useful to us than the IFS forum. The forum contains a lot of interesting information, but specific technical questions can go unanswered for a long time. A detailed article, accompanied by a complete and reproducible example, then provides much more value than a discussion thread interrupted after the initial question.

A big thank you to the author of DSJ’s Blog for this sharing work. In an ecosystem as vast as IFS Cloud, this type of independent resource allows project teams to save considerable time.

✓Key takeaways from IFS Cloud

IFS Cloud is a powerful and particularly open platform. Its ability to create configurations, automate processes and expose APIs makes integration projects much easier.

This power comes with a vocabulary, a development model and a life cycle that takes time. You must learn to choose between configuration, report, interface and modification, but also accept that a seemingly simple need can mobilize several bricks.

Our team learned a large part of these concepts directly in the project phase. This article certainly still contains simplifications. Exchanges and corrections are therefore welcome in the comments.

As I write these lines, I am also participating in the IFS France Users Club, which is an excellent opportunity to compare our experience with that of other customers.

IFS Cloud under the hood: exploring CRIM, APIs and the lifecycle