Tableau de bord/Chapter 3/1.10 — Integration Framework (MIF)
Chapter 3 · leçon 10 sur 12
CertaviaEnd Points) pour la communication externe.Object Structures et des Enterprise Services dans l'intégration de données.Automation Scripts dans l'extension des capacités d'intégration.Object Structures — Elles définissent la structure des données échangées, regroupant un ou plusieurs objets Maximo (tables) et leurs relations, servant de base aux services d'intégration.Enterprise Services (Entrant) — Utilisés pour recevoir des données de systèmes externes vers Maximo Manage, souvent via des services web SOAP/REST, des fichiers ou JMS.Publish Channels (Sortant) — Permettent d'envoyer des données de Maximo Manage vers des systèmes externes, déclenchés par des événements spécifiques (ex: sauvegarde d'un enregistrement).End Points — Configurables, ils définissent les détails techniques de la connexion à un système externe, incluant l'URL, les paramètres d'authentification et le type de protocole (HTTP, JMS, JSON REST).max integration admin) ne nécessite pas de licence spécifique. L'intégration de données dont un système tiers est le maître ne requiert pas de licence Maximo Manage, sauf si l'application tierce initie des mises à jour d'enregistrements Maximo.Automation Scripts — Ces scripts (Jython ou JavaScript) peuvent être utilisés pour étendre la logique métier et les capacités d'intégration sans développement Java, notamment pour les transformations complexes.Le Maximo Integration Framework (MIF) est la pierre angulaire des échanges de données entre Maximo Manage et son écosystème applicatif. Il fournit une architecture flexible et configurable pour gérer les flux de données entrants et sortants, garantissant l'intégrité et la cohérence des informations. Le MIF est conçu pour être indépendant des technologies de messagerie sous-jacentes, offrant une grande adaptabilité.
Cette architecture repose sur plusieurs composants interconnectés qui collaborent pour acheminer, transformer et traiter les messages. La configuration de ces éléments se fait principalement via des applications dédiées dans Maximo, permettant aux administrateurs de définir des intégrations complexes sans nécessiter de développement de code lourd. Le MIF supporte des modes d'intégration en temps réel et en batch, répondant ainsi à divers besoins opérationnels.
Object Structures, Enterprise Services, Publish Channels et End Points.Le MIF propose différents types de canaux pour gérer les flux de données, chacun adapté à des scénarios d'intégration spécifiques. La distinction principale se fait entre les canaux entrants (pour recevoir des données dans Maximo) et les canaux sortants (pour envoyer des données depuis Maximo). Comprendre leurs rôles et leurs configurations est essentiel pour une intégration efficace.
Cette table compare les principaux canaux d'intégration, leurs fonctions, et les applications Maximo associées pour leur configuration. Elle met en évidence la flexibilité du MIF à s'adapter à diverses exigences d'échange de données avec des systèmes externes, qu'il s'agisse de mises à jour en temps réel ou de synchronisations par lots.
| Code MIF | Élément | Description Maximo | Type de Flux | Application Maximo |
|---|---|---|---|---|
INT-OST | Object Structures | Définit la structure des données échangées (objets et relations). | N/A (Structure) | Object Structures |
INT-SRV | Enterprise Services | Canal entrant pour la réception de données de systèmes externes. | Entrant (Inbound) | Enterprise Services |
INT-CHP | Publish Channels | Canal sortant pour l'envoi de données vers des systèmes externes. | Sortant (Outbound) | Publish Channels |
INT-CHA | Invocation Channels | Permet à un système externe d'appeler une action ou un service dans Maximo. | Entrant (Inbound) | Invocation Channels |
INT-EPT | End Points | Configure les détails techniques de la connexion à un système externe. | N/A (Configuration) | End Points |
INT-EXT | External Systems | Définit les systèmes externes avec lesquels Maximo interagit. | N/A (Configuration) | External Systems |
INT-WSV | Web Services | Permet d'exposer des services SOAP/REST de Maximo. | N/A (Exposition) | Web Services Library |
INT-OSL | OSLC | Ressources OSLC pour l'intégration basée sur les standards Linked Data. | N/A (Standard) | OSLC Resources |
La mise en œuvre d'une intégration via le MIF implique une série d'étapes de configuration dans Maximo Manage. Ces étapes garantissent que les données sont correctement structurées, transformées et acheminées entre Maximo et les systèmes externes. L'administrateur du système utilise diverses applications Maximo pour définir chaque aspect de l'intégration, depuis la structure des données jusqu'aux détails de la connexion.
Un exemple typique pourrait être l'intégration de données d'un système RH externe pour créer ou mettre à jour des enregistrements de personnel dans Maximo, ou l'envoi d'informations sur les bons de commande vers un système ERP. Le MIF permet de gérer ces scénarios avec une grande granularité, y compris la définition de règles de mappage et de transformation pour s'assurer que les données sont compatibles entre les systèmes.
Object Structures — Dans l'application Object Structures, on sélectionne les objets Maximo (ex: WORKORDER, ASSET) et leurs relations pour créer une structure de données logique qui représente l'information à échanger. Cette structure sert de modèle pour les messages d'intégration.End Points — L'application End Points est utilisée pour définir les destinations des messages. Cela inclut l'URL du système externe, le type de protocole (HTTP, JMS, JSON REST), les informations d'authentification et d'autres paramètres de connexion. Un End Point peut être réutilisé par plusieurs canaux.External Systems — Dans l'application External Systems, on déclare le système externe avec lequel Maximo va communiquer. C'est ici que l'on associe les End Points et les canaux d'intégration (Enterprise Services ou Publish Channels) à ce système.WORKORDER depuis un système tiers), on configure un Enterprise Service. On y associe une Object Structure et on définit les options de traitement, y compris les règles de mappage et de transformation.WORKORDER), on configure un Publish Channel. On y associe une Object Structure, un End Point et on spécifie les événements déclencheurs (ex: sauvegarde, changement de statut).Enterprise Services ou Publish Channels, des règles de mappage peuvent être définies pour faire correspondre les champs entre Maximo et le système externe. Des Automation Scripts peuvent être utilisés pour des transformations de données plus complexes, permettant une flexibilité maximale sans modification du code source.Le processus d'envoi de données de Maximo Manage vers un système externe via un Publish Channel suit un cycle de vie bien défini. Ce workflow garantit que les informations sont capturées, traitées, transformées et acheminées de manière fiable. Chaque étape est cruciale pour la réussite de l'intégration et peut être configurée pour répondre à des exigences spécifiques.
Ce diagramme illustre les étapes clés, depuis le déclenchement d'un événement dans Maximo jusqu'à la réception du message par le système externe. La flexibilité du MIF permet d'insérer des logiques de transformation ou des scripts d'automatisation à différentes phases du processus, offrant un contrôle précis sur le contenu et le format des données envoyées.
Publish Channel dans Maximo Manage, détaillant les étapes de la détection de l'événement à l'envoi du message au système externe.max integration admin
Les candidats peuvent penser que toute intégration avec Maximo Manage nécessite une licence utilisateur Maximo Manage pour le système externe ou l'utilisateur d'intégration. Cependant, le rôle max integration admin est un utilisateur spécial du MIF qui ne requiert pas de licence spécifique. De plus, si un système tiers est le "maître" des données et que Maximo Manage réplique ces données pour son usage interne, aucune licence Maximo Manage n'est requise pour cette réplication. Un piège courant serait d'affirmer qu'une licence est toujours nécessaire, même pour des synchronisations passives de données dont Maximo n'est pas le système maître. La nuance est cruciale : une licence est requise si l'application tierce initie des mises à jour d'enregistrements Maximo (ex: création de WORKORDER, modification d'ASSET, fonctions de chaîne d'approvisionnement initiées par le tiers).
Enterprise Services et Publish Channels
Il est facile de confondre les rôles des Enterprise Services et des Publish Channels. Un piège d'examen pourrait présenter un scénario où Maximo doit envoyer des données à un système externe et suggérer d'utiliser un Enterprise Service. La distinction est fondamentale : les Enterprise Services sont des canaux entrants (inbound) pour recevoir des données dans Maximo, tandis que les Publish Channels sont des canaux sortants (outbound) pour envoyer des données depuis Maximo. Se tromper de canal pour un flux de données donné mènerait à une intégration non fonctionnelle ou incorrecte. Il faut toujours associer "entrant" à Enterprise Services et "sortant" à Publish Channels.
Object Structures et leur flexibilité
Les Object Structures sont souvent perçues comme de simples regroupements de tables. Le piège réside dans la sous-estimation de leur flexibilité. Elles ne se limitent pas à une seule table ou à des relations simples. Une Object Structure peut inclure plusieurs objets Maximo liés, permettant de définir des messages d'intégration complexes qui représentent des entités métier complètes (ex: un WORKORDER avec ses WORKORDERLINE, ASSET associé, etc.). Ignorer cette capacité peut conduire à des intégrations fragmentées ou à la nécessité de multiples messages pour une seule transaction métier, augmentant la complexité et le risque d'erreurs.
Object Structure dans le MIF et pourquoi est-elle essentielle ?
Une Object Structure définit la structure logique des données échangées entre Maximo et les systèmes externes. Elle regroupe un ou plusieurs objets Maximo (tables) et leurs relations, servant de modèle pour les messages d'intégration. Elle est essentielle car elle garantit la cohérence et l'intégrité des données en définissant précisément ce qui est envoyé ou reçu.
Publish Channel serait-il utilisé et quels sont les éléments clés à configurer pour son fonctionnement ?
Un Publish Channel est utilisé pour envoyer des données de Maximo Manage vers un système externe, généralement déclenché par un événement (ex: création ou mise à jour d'un enregistrement). Les éléments clés à configurer sont l'Object Structure définissant les données, l'End Point spécifiant la destination technique, et les règles de transformation/filtrage si nécessaire.
Non, si le système RH est considéré comme le maître des données et que Maximo Manage réplique ces données pour son usage interne, cette intégration ne nécessite pas de licence Maximo Manage pour l'utilisateur d'intégration. La licence serait requise si le système RH initiait des mises à jour d'enregistrements Maximo qui impactent directement des fonctions métier de Maximo (ex: création de LABOR avec des rôles actifs).
Automation Scripts peuvent-ils améliorer les capacités d'intégration du MIF ?
Les Automation Scripts (en Jython ou JavaScript) peuvent être utilisés pour implémenter des logiques de transformation de données complexes, des validations personnalisées ou des traitements conditionnels au sein des Enterprise Services ou Publish Channels. Ils permettent d'étendre les fonctionnalités du MIF sans nécessiter de développement Java, offrant une grande flexibilité pour adapter les messages aux exigences spécifiques des systèmes intégrés.
Bonne réponse : A
Pourquoi cette question existe — STU §3.10 — la question identifie l'option technique précise permettant l'export/import de données au format fichier plat (CSV), distincte des options orientées API REST ou requêtes. En pratique, oublier de cocher cette option bloque les migrations de données par fichier plat.
Le contexte théorique d'abord — Un Object Structure coché Support Flat Structure peut être exposé pour des échanges au format flat file (dont CSV), en plus du XML/JSON standard. Cette option active une représentation simplifiée (à plat) de la hiérarchie de l'object structure, compatible avec les outils d'import/export par fichier.
Ce que Maximo en fait — version opérationnelle — Dans Object Structures > sélectionner ou créer la structure > cocher Support Flat Structure > Save. L'object structure devient alors utilisable par les composants d'Integration Framework gérant l'import/export de fichiers plats, dont les CSV.
Exemple chiffré — Un import de 2 000 lignes d'items via CSV s'appuie sur 1 object structure avec Support Flat Structure activé, contre une intégration JSON/XML classique qui ne nécessiterait pas cette option.
Analogie quotidienne — C'est comme aplatir un classeur à onglets multiples en une seule feuille de calcul : Support Flat Structure transforme une hiérarchie d'objets en une structure « à plat » exploitable par un simple fichier CSV.
Pourquoi B est faux — Pattern D5 champ-frère : Primary API désigne l'object structure principal utilisé par défaut pour une application, sans lien avec le format CSV.
Pourquoi C est faux — Pattern D2 inventé : « Internal » n'est pas une option standard d'Object Structures pilotant l'export CSV.
Pourquoi D est faux — Pattern D5 champ-frère : Load Query From All Apps concerne la réutilisation de requêtes sauvegardées, pas le format d'échange de fichier.
Bonne réponse : B
Pourquoi cette question existe — STU §3.10 — la question identifie précisément l'action permettant de réduire le périmètre d'un object structure à un sous-ensemble de champs. Les distracteurs citent des actions réelles d'Object Structures (Alias) mais qui répondent à un autre besoin (renommage, pas restriction de champs). En pratique, exposer tous les champs d'ASSET sans filtrage alourdit inutilement les payloads d'intégration.
Le contexte théorique d'abord — L'action Exclude/Include Fields permet, pour un attribut persistant donné d'un object structure, de spécifier s'il doit être exclu ou inclus dans la structure exposée. Appliquée à plusieurs champs de l'objet ASSET, elle permet de construire un object structure ne contenant qu'un sous-ensemble volontairement limité.
Ce que Maximo en fait — version opérationnelle — Dans Object Structures > sélectionner la structure basée sur ASSET > action Exclude/Include Fields > pour chaque attribut, cocher Excluded (le retirer) ou le laisser inclus > OK, puis Configure Database pour appliquer.
Exemple chiffré — Sur les ~150 attributs natifs de l'objet ASSET, un object structure d'intégration limité à 12 champs essentiels (assetnum, description, status, siteid...) réduit la taille du payload JSON de plus de 90% par rapport à l'exposition complète.
Analogie quotidienne — C'est comme imprimer une fiche de synthèse ne contenant que 5 champs utiles d'un dossier complet de 50 pages : Exclude/Include Fields sélectionne ce qui doit apparaître, rien de plus.
Pourquoi A est faux — Pattern D5 champ-frère : Add/Modify Alias renomme un champ exposé pour l'intégration, mais ne contrôle pas son inclusion/exclusion.
Pourquoi C est faux — Pattern D2 inventé : « Advanced Configuration » n'est pas le nom de l'action réelle limitant les champs d'un object structure.
Pourquoi D est faux — Pattern D2 inventé : « Inbound Setting Restrictions » n'existe pas comme action standard des Object Structures.
Bonne réponse : D
Pourquoi cette question existe — STU §3.10 — la question précise la cause réelle de l'« Alias Conflict » : la collision de noms de champs entre plusieurs objets sources combinés dans une même hiérarchie d'object structure. Les distracteurs proposent des causes plausibles mais erronées (champs non-persistants, source unique, homonymie de nom de structure). En pratique, un object structure à source unique ne déclenche jamais ce conflit.
Le contexte théorique d'abord — Un Object Structure peut combiner plusieurs Objects sources en hiérarchie (Object, Parent Object, Relationship). Lorsque deux objets de cette hiérarchie possèdent un attribut de même nom, Maximo détecte un Alias Conflict et exige la résolution via la case Alias Conflict avant de pouvoir sauvegarder/utiliser la structure.
Ce que Maximo en fait — version opérationnelle — Dans Object Structures > lors de l'ajout d'un objet enfant en relation avec un objet déjà présent > si un nom de champ entre en collision, la case Alias Conflict se coche automatiquement > l'administrateur résout le conflit en attribuant un alias distinct à l'un des deux champs.
Exemple chiffré — Une structure combinant ASSET et WORKORDER (tous deux porteurs d'un champ « description ») déclenche 1 alias conflict à résoudre sur les 2 champs homonymes, sur un total de 300 champs combinés.
Analogie quotidienne — C'est comme fusionner deux tableaux Excel ayant chacun une colonne « Date » : il faut renommer l'une des deux pour éviter toute confusion lors de la fusion.
Pourquoi A est faux — Pattern D4 demi-vérité : les champs non-persistants peuvent poser d'autres problèmes de configuration, mais ne sont pas la cause de l'Alias Conflict.
Pourquoi B est faux — Pattern D3 inverse : c'est l'exact opposé — une structure à source UNIQUE ne peut pas générer de collision de nom entre deux objets distincts.
Pourquoi C est faux — Pattern D9 quasi-synonyme : le nom de l'object structure lui-même n'a aucun rapport avec la collision de noms de champs entre objets sources.