IFS Cloud côté technique : découverte du CRIM, des API et du cycle de vie

Dans cet article, je ne vais pas aborder la partie fonctionnelle d’IFS Cloud. Je vais plutôt partager ce que nous avons découvert du côté technique : configurations, rapports, interfaces, modifications, workflows, API et cycle de déploiement.

L’un de mes clients a choisi IFS Cloud dans le cadre d’un projet de migration d’ERP. L’environnement est aujourd’hui en version 25R2 et, chez ce client, j’occupe le poste de responsable du pôle applications.

CRIMComprendre le CRIM

L’un des premiers éléments de vocabulaire rencontrés dans un projet IFS est le terme CRIM :

Cette classification paraît simple, mais un même besoin peut mobiliser plusieurs objets techniques. L’ajout d’un champ, par exemple, peut nécessiter un attribut configuré, une modification de page et éventuellement un workflow de validation. Un CRIM ne correspond donc pas toujours à un seul objet technique.

CC comme Configuration

Une configuration est une adaptation réalisée sans modifier directement le code standard d’IFS. Une partie importante de ce travail peut être effectuée depuis IFS Cloud Web.

Champs, entités, pages et projections

Il est possible d’ajouter des attributs personnalisés, de créer des entités personnalisées, de configurer des pages ou d’étendre certaines projections. Il faut toutefois éviter un raccourci fréquent : une entité n’est pas simplement une table et une projection n’est pas simplement une vue SQL.

Une entité représente un objet du modèle de données et peut s’appuyer sur plusieurs objets de base de données. Une projection expose une partie du domaine fonctionnel sous la forme d’un service REST. Elle contient des ensembles d’entités, mais aussi des actions, des fonctions, des structures, des énumérations et d’autres contrôles.

Lorsqu’une configuration est publiée, IFS peut générer les objets de base de données nécessaires, actualiser les métadonnées et rendre les nouveaux éléments accessibles dans les projections concernées.

Pour un développeur habitué à explorer directement les tables d’un SGBDR, la prise en main peut être déroutante. Le modèle est documenté au travers des entités, des projections, des informations système et de l’API Explorer, mais il ne se présente pas toujours comme un schéma relationnel classique.

Les BPA et les workflows

Les Business Process Automations, ou BPA, reposent sur un concepteur de workflows inspiré de BPMN. Ils permettent d’ajouter de la logique autour des opérations réalisées dans IFS Cloud sans passer immédiatement par une personnalisation du code standard.

On retrouve notamment trois grandes familles :

• Validation : contrôler une opération et empêcher sa validation lorsqu’une règle n’est pas respectée ;
• Process Enrichment : enrichir ou modifier les valeurs transmises pendant le traitement ;
• User Interaction : demander des informations complémentaires à l’utilisateur pendant le processus.

Les BPA sont une véritable force d’IFS Cloud, mais ils ne remplacent pas un langage de programmation généraliste. Les possibilités sont encadrées et il faut parfois repenser le besoin pour rester dans le périmètre de la configuration.

Les Lobbies

Les Lobbies sont des portails personnalisés qui donnent une vision synthétique d’un processus, d’un rôle ou d’un ensemble d’indicateurs. Les utilisateurs les apprécient généralement parce qu’ils évitent de parcourir plusieurs écrans pour retrouver les informations importantes.

Les Lobbies disposent bien de paramètres de page. Ces paramètres peuvent être mémorisés dans le profil de l’utilisateur ou transmis dans une URL de navigation. En revanche, les contrôles proposés n’offrent pas toujours la richesse d’une véritable liste de valeurs métier. Un utilisateur peut donc devoir connaître un code de société, de site ou de projet.

La bonne pratique consiste à limiter le nombre de paramètres, à utiliser des valeurs par défaut pertinentes et, lorsque cela est possible, à construire des liens qui ouvrent directement le Lobby avec le bon contexte.

RR comme Reports

Le mot report recouvre plusieurs familles d’outils dans IFS Cloud. Il est important de distinguer les rapports rapides, les rapports opérationnels et les outils d’analyse plus avancés.

Les Quick Reports

Les Quick Reports répondent à un besoin de reporting ad hoc. Pour un tableau simple, il est possible d’utiliser une requête SQL ou Query Designer, puis d’exporter le résultat vers Excel.

Ils sont efficaces pour produire rapidement une liste, mais les paramètres peuvent devenir peu ergonomiques lorsque l’on multiplie les filtres. Des valeurs par défaut peuvent aider, mais il faut éviter de transformer un rapport rapide en application complète.

Pour les besoins Excel plus avancés, IFS oriente désormais vers Business Reporter. L’ancien plug-in Excel utilisé pour les rapports opérationnels est déprécié depuis plusieurs versions et ne doit pas être confondu avec Business Reporter.

Les éditions et rapports opérationnels

Les documents comme les factures, commandes ou bons de livraison relèvent du reporting opérationnel. IFS Cloud propose aujourd’hui deux outils natifs : IFS Report Designer, installé sur le poste, et IFS Report Studio – Designer, accessible depuis le Web.

Lorsque notre projet a débuté en 23R2, l’expérience avec l’outil disponible ne répondait pas à nos attentes de stabilité et de productivité. Nous avons donc retenu une solution complémentaire, Ootary, pour certaines éditions et certains écrans avancés.

Ce constat doit être daté : l’offre native a évolué depuis le début du projet, notamment avec Report Studio. Une solution tierce peut sauver un besoin bloquant, mais elle introduit également un nouvel environnement, un nouveau langage, des compétences spécifiques et une dépendance supplémentaire.

II comme Interfaces

Dans notre contexte, les échanges entre IFS Cloud et les autres applications passent principalement par le middleware Blueway.

L’ouverture d’IFS Cloud est l’un de ses vrais points forts. L’API Explorer recense les projections et services OData disponibles, avec leurs ensembles d’entités et leur documentation. Les appels reposent sur des méthodes HTTP classiques et des échanges JSON.

Trouver la bonne API

Une méthode pratique consiste à ouvrir l’écran concerné, activer les outils de développement IFS et observer les appels réseau. Il est ensuite possible d’ouvrir directement la projection correspondante dans API Explorer.

Cette méthode permet de comprendre rapidement ce que fait l’interface, mais l’API utilisée par une page n’est pas forcément la meilleure API pour une intégration système à système. IFS distingue notamment les Premium APIs, les API d’intégration, les API standard et les Entity Service APIs. Le choix doit dépendre du cas d’usage, de la stabilité attendue et du niveau de support.

IFS Connect

Lorsque l’intégration repose sur des messages, des fichiers ou des protocoles plus traditionnels, IFS Connect joue le rôle de broker d’intégration. Il prend en charge différents connecteurs, notamment HTTP/HTTPS, FTP/SFTP, messagerie et JMS, avec des mécanismes de transformation.

Il reste donc tout à fait possible de gérer des fichiers plats lorsque le système cible ne propose pas d’API. Cela fonctionne, même si cette approche demande généralement davantage de surveillance, de gestion des erreurs et de conventions de nommage.

MM comme Modifications

La modification est la partie que je maîtrise le moins en pratique. Elle intervient lorsque les outils de configuration ne suffisent plus et qu’il devient nécessaire d’étendre le fonctionnement interne d’IFS Cloud.

Dans la documentation IFS, cette approche est appelée extending on the inside ou personnalisation. Elle s’effectue avec IFS Developer Studio et peut mobiliser les modèles IFS, Marble pour le client, PL/SQL pour la logique serveur et, dans certains cas, Java.

Les développements doivent être réalisés dans la couche de personnalisation, sans modifier directement les fichiers standard. Le développement s’effectue avec IFS Developer Studio et peut mobiliser du PL/SQL pour la partie serveur, ainsi que du Marble pour les écrans IFS Cloud Web.

Le cycle Git, Sanity Build et Delivery

Le processus de livraison d’une modification est beaucoup plus structuré que celui d’une simple configuration réalisée depuis le front. Dans notre projet, le déroulement théorique est le suivant :

1. 1 créer une nouvelle branche dans le dépôt Git de la Customer Solution ;
2. 2 réaliser le développement et les premiers tests dans l’environnement de développement du Build Place ;
3. 3 committer et pousser les modifications dans le dépôt ;
4. 4 créer une demande de fusion, faire contrôler le code, puis fusionner la branche dans la branche principale ;
5. 5 lancer un Sanity Build sur le commit concerné ;
6. 6 corriger les erreurs éventuelles de génération, de déploiement de la base ou de compilation jusqu’à obtenir un statut san-OK ;
7. 7 générer une Delivery depuis le Build Place ;
8. 8 tester cette livraison dans les environnements prévus à cet effet ;
9. 9 demander son déploiement dans les environnements du Use Place, dans le bon ordre : environnement de test, staging ou UAT, puis production.

Le Sanity Build ne se contente pas de vérifier que les fichiers sont présents. Il contrôle notamment la génération du code de base de données, son déploiement et la compilation de la solution. Lorsqu’il réussit, une image de sanity est produite et le commit est identifié par un tag san-OK. Cette étape est indispensable avant de préparer une livraison fiable.

Je ne vais pas prétendre maîtriser toute cette partie : je connais le processus et les étapes de livraison, mais les personnalisations les plus structurantes restent aujourd’hui principalement réalisées par notre intégrateur.

ACPTransporter les configurations avec les ACP

Les configurations réalisées directement dans IFS Cloud doivent être organisées et transportées d’un environnement à l’autre. Pour cela, IFS propose les Application Configuration Packages, ou ACP.

Un ACP peut contenir plusieurs types d’objets de configuration : attributs, pages, projections configurées, workflows, événements ou autres éléments pris en charge.

Un point important : un objet de configuration ne peut appartenir qu’à un seul ACP à la fois. Par ailleurs, retirer un objet d’un package source ne le supprime pas automatiquement de l’environnement cible lors d’un import ultérieur.

BDRCommencer les BDR le plus tôt possible

Je termine par un conseil qui concerne davantage le projet que le développement : faites travailler les utilisateurs sur les BDR dès que possible.

Dans le vocabulaire IFS, les BDR correspondent aux Basic Data Requirements, c’est-à-dire aux données de paramétrage nécessaires au fonctionnement des processus. Cela comprend par exemple les codes de taxe, les conditions de paiement, les groupes comptables, les statuts, les sites et de nombreux autres référentiels.

WEBUne ressource communautaire qui nous a énormément aidés

✓Ce que je retiens d’IFS Cloud

IFS Cloud est une plateforme puissante et particulièrement ouverte. Sa capacité à créer des configurations, à automatiser des processus et à exposer des API facilite énormément les projets d’intégration.

Cette puissance s’accompagne d’un vocabulaire, d’un modèle de développement et d’un cycle de vie qui demandent du temps. Il faut apprendre à choisir entre configuration, rapport, interface et modification, mais aussi accepter qu’un besoin simple en apparence puisse mobiliser plusieurs briques.

Notre équipe a appris une grande partie de ces concepts directement en phase projet. Cet article contient certainement encore des simplifications. Les échanges et corrections sont donc les bienvenus dans les commentaires.

Au moment où j’écris ces lignes, je participe également au Club Utilisateurs IFS France, qui constitue une excellente occasion de confronter notre expérience à celle d’autres clients.

↗Sources officielles

• IFS Cloud – Tailoring Overview
• IFS Cloud – Build Place et Use Place
• IFS Cloud – Projections et modèle client
• IFS Cloud – API Explorer
• IFS Cloud – Business Process Automation
• IFS Cloud – Application Configuration Packages
• IFS Cloud – Customer Solution Development et dépôts Git
• IFS Cloud – Sanity Builds
• IFS Cloud – Build Place Deliveries
• DSJ’s Blog – Articles techniques consacrés à IFS