Stratégies d’intégration entre Cityworks et les systèmes externes (1 sur 3)

Ces dernières années, nous avons assisté à une soif insatiable de puissance de calcul et de meilleure performance, notamment de la part des scientifiques et des analystes de données. Pour répondre à cette demande, les fournisseurs ont développé des outils et des techniques innovants. Cette innovation a permis des améliorations considérables à différents niveaux de l’architecture, tels que la conception des bases de données, la conception des applications, l’architecture technologique et l’architecture commerciale. Dans le présent article, nous allons aborder l’un des aspects essentiels de la conception de l’architecture, à savoir les stratégies d’intégration (ou de synchronisation).

L’intégration de données provenant de sources multiples est très courante dans toute organisation, notamment aux fins de veille stratégique dans les municipalités. De même, dans les SIG, il est souvent nécessaire d’interfacer un système avec des applications externes, non seulement pour la production de rapports ou l’analyse de données, mais aussi pour les tâches quotidiennes. Bien que les intégrations soient largement influencées par les logiciels et outils disponibles dans votre infrastructure informatique actuelle, les stratégies de synchronisation des données abordées dans le présent billet de blogue s’appliquent quels que soient l’infrastructure et l’environnement informatiques. Ces stratégies de synchronisation peuvent très bien être appliquées lors de l’intégration avec des systèmes tiers depuis ArcGIS Enterprise, de Cityworks aux progiciels de gestion intégrés (ERP), d’ArcGIS Indoors à des solutions de gestion du travail et des actifs ou d’ArcGIS Roads and Highways à des systèmes de gestion du travail.

Nous explorerons les stratégies de synchronisation communes entre les applications, en particulier autour des trois principales catégories d’intégration, avec une attention particulière à Cityworks et ArcGIS :

1. synchronisation unidirectionnelle;

2. synchronisation bidirectionnelle;

3. synchronisation en temps réel.

Nous couvrirons diverses techniques et méthodes dans chaque catégorie tout en évitant de tomber dans les processus d’extraction, de transformation et de chargement des logiciels et outils, par exemple la synchronisation unidirectionnelle des enregistrements entre Cityworks et d’autres applications. L’accent sera mis sur la stratégie qui permet de répondre à une exigence fonctionnelle plutôt que sur les particularités de tel ou tel logiciel d’intégration. Ce premier billet couvre principalement deux domaines de l’intégration de Cityworks : les données de base et données de transaction :

1. les données qui arrivent dans Cityworks par l’intégration des données de la paie, comme les données de base d’un employé; 

2. les données qui sortent de Cityworks, par exemple l’intégration des coûts de main-d’œuvre avec la paie ou l’intégration des coûts d’équipement avec les finances.

Cityworks a été intégré à des systèmes financiers, notamment Agresso UNIT4, JD Edwards, Microsoft Great Plains Dynamics, Microsoft Navision, Oracle PeopleSoft, SAP, SmartStream, Bellamy, Kronos et de nombreux autres systèmes afin de suivre les coûts des ressources (transactions relatives à la main-d’œuvre et aux salaires, transactions relatives aux stocks, coûts d’équipement et coûts des entrepreneurs, etc.).L’intégration permet à l’organisation de distinguer les coûts des travaux externes facturables ou internes récupérables sur ses immobilisations corporelles (et incorporelles). Elle permet également de suivre le coût des ressources dans la solution d’exploitation en tant que grand livre auxiliaire et dans le grand livre ERP. Cette fonctionnalité permet au personnel municipal de déterminer les coûts de propriété des actifs et de gérer les informations budgétaires aux niveaux requis ainsi que de fournir un budget résumé.

Esri Canada a mis en place des interfaces avec Cityworks pour plusieurs des systèmes ci-dessus grâce à diverses techniques d’interfaçage de systèmes. Ces techniques vont de l’importation par lots de base à l’importation basée sur l’architecture orientée services ou web (voir la section ci-dessous sur les mécanismes d’intégration pris en charge par Cityworks). Plusieurs intergiciels ont également été utilisés pour les interfaces, comme iWay, FME, BizTalk, SSIS (SQL Server Integration Services), des applications et des API web personnalisées et autres, pour développer des interfaces avec Cityworks. 

Cityworks fournit une API RESTful, un gestionnaire d’actions pour les webhooks (rappels web) et la mise à jour des activités ainsi que des trousses de développement logiciel dans divers langages comme C#, Python et Typescript. Les intégrations de Cityworks avec des solutions tierces dépendront de divers facteurs, mais seront généralement dictées par la gouvernance des données et le système d’information. Le système d’information est l’emplacement principal de l’élément de données, voir par exemple le tableau ci-dessous :

Synchronisation unidirectionnelle

Concevoir et mettre en œuvre une synchronisation incrémentielle demande plus d’efforts que de simplement synchroniser tous les enregistrements à chaque fois et empêche de dépasser les limites de l’API. Nous couvrirons en détail la synchronisation incrémentielle entre Cityworks et d’autres applications. Une synchronisation incrémentielle (ou « delta ») est une synchronisation qui ne traite que les enregistrements de données qui ont changé (créés ou modifiés) depuis la dernière exécution de l’intégration, au lieu de traiter l’ensemble des données à chaque fois. Il s’agit de l’approche de prédilection couramment utilisée pour la plupart des scénarios d’intégration, car, en limitant le nombre d’enregistrements traités à ce qui a été modifié, l’intégration s’exécute plus rapidement et plus efficacement et peut donc se faire à fréquence accrue de manière à garder les systèmes à jour. Voici quelques approches recommandées; selon votre situation, l’une ou l’autre sera la meilleure stratégie : 1) extraire par la valeur du champ indicateur, 2) extraire par la date de dernière modification, 3) saisir les données de modification.

Les données de base et les données de transaction provenant de sources officielles impliquent généralement que les enregistrements soient synchronisés de manière incrémentielle dans un sens. Par exemple, les données de base, telles que les employés et les codes de rémunération du système de paie (ERP), sont mises à jour dans Cityworks. Dans ce cas, le système de paie est la source officielle, l’intendant des données et le gardien des données.
 
Prenons l’exemple de l’interface d’un employé; le noyau de Cityworks identifie l’employé par son nom dans plusieurs composantes du logiciel (par exemple, les relations avec les employés, les bons de travail, les destinataires, etc.). Il est essentiel que la combinaison des colonnes du prénom, de l’initiale du milieu et du nom de famille constitue un identifiant unique pour l’enregistrement de l’employé dans Cityworks. Lorsqu’un processus de synchronisation est en exécution, les champs indiqués ci-dessus peuvent contribuer à créer, à mettre à jour et à désactiver des employés dans Cityworks. La stratégie de synchronisation peut être grandement améliorée en tirant parti des codes personnalisés et des champs de données personnalisés. Les codes personnalisés peuvent être créés et gérés à l’aide de Cityworks Designer. Ils peuvent être utilisés pour configurer les paramètres par défaut pour toute exécution du processus d’interface; par exemple les paramètres par défaut de la licence et du domaine Active Directory peuvent être configurés à la fin de l’exécution du processus d’interface.

D’autres exemples d’implémentations utilisant la synchronisation unidirectionnelle pour les données de base ou les données de transaction sont décrits ci-dessous. Le diagramme qui suit donne quelques exemples d’intégrations de données de base de synchronisation unidirectionnelle entre divers systèmes sources et Cityworks.

La figure ci-dessus montre les différents éléments de données des données de base des systèmes sources vers Cityworks

Approfondissons les trois approches de la synchronisation unidirectionnelle entre Cityworks et d’autres systèmes : 

1. extraction par la valeur du champ indicateur;
2. extraction par date de dernière modification;
3. saisie des données de modification.

Extraction par la valeur du champ indicateur

Prenons une situation dans laquelle l’interface devra maintenir Cityworks à jour avec des données sur les employés provenant d’un système de paie ou ERP externe. Afin que la base de données des employés soit synchronisée avec la paie, les dossiers des employés sont extraits en fonction de la valeur d’un certain indicateur. Une fois l’extraction effectuée, l’intégration entraîne la mise à jour du champ à une valeur différente, de sorte que cette dernière ne sera pas extraite de nouveau. Cette option offre beaucoup de flexibilité et permet aux utilisateurs finaux de contrôler facilement le comportement de la synchronisation en modifiant les valeurs dans l’application finale. À mon avis, il s’agit de la meilleure approche des trois, étant donné que le logiciel tiers (celui de la paie dans ce cas-ci) permet de modifier l’un de ses champs utilisés pour l’indicateur ou d’utiliser une table intermédiaire pour donner plus de flexibilité entre les systèmes.

En outre, le principal avantage de cette méthode est qu’elle permet de synchroniser des dossiers indépendamment les uns des autres. Si un dossier d’employé du groupe ne se synchronise pas, les autres peuvent être mis à jour sans problème et n’auront pas à être traités de nouveau. De plus, si le champ est accessible aux utilisateurs finaux, ceux-ci peuvent facilement réinitialiser, réessayer ou ignorer certains dossiers d’employés eux-mêmes sans avoir à dépendre de l’équipe d’intégration. C’est également un moyen de conserver l’intégration sans état, ce qui signifie que rien n’est stocké sur la couche d’intégration, comme la date de la dernière exécution. 

Sur le plan de l’architecture technique, l’interface peut être conçue de manière à sélectionner les dossiers ayant certaines valeurs pour les champs indicateurs et à effectuer la synchronisation. Après avoir réussi à synchroniser l’enregistrement, l’interface peut alors s’assurer que le processus met à jour correctement le champ indicateur dans l’application source. Le champ indicateur peut être de différentes formes et dépendra du système source externe. Il peut s’agir d’un champ d’état (particulier à l’intégration ou propre à l’entreprise), d’un champ « prêt à synchroniser » vrai-faux, de l’existence d’un « ID externe », etc. Il peut également s’agir d’une combinaison de champs et de valeurs. Ce processus est idéal pour les dossiers qui doivent être synchronisés une seule fois, comme les données de transaction telles que les coûts d’équipement ou les heures de travail.

La figure ci-dessus montre les différents éléments des données de transaction d’un système source vers Cityworks.

Extraction par date de dernière modification

Cette méthode de synchronisation unidirectionnelle est plus simple et est particulièrement utile lorsqu’il n’y a aucun moyen d’utiliser l’option des champs indicateurs mentionnée ci-dessus et lorsque les applications externes capturent automatiquement l’horodatage du moment où les dossiers sont créés ou modifiés. C’est très utile lorsque vous souhaitez uniquement obtenir les dossiers qui ont été créés ou modifiés depuis la dernière exécution de l’intégration. Dans cette approche, les dossiers sont extraits si la valeur de leur champ de date de dernière modification est ultérieure à une autre date, comme la dernière fois que l’intégration a été exécutée ou que les dossiers ont été synchronisés. 

Essentiellement, le processus capture l’horodatage du système lorsque l’intégration commence et l’enregistre une fois qu’elle est terminée. Pour éviter tout écart de temps (généralement minime), il est préférable de saisir la date de dernière modification la plus récente à partir des dossiers eux-mêmes et de conserver cette valeur une fois l’opération terminée. Comme l’horodatage provient de l’application source elle-même, vous pouvez être sûr qu’aucun dossier ne sera oublié en raison du décalage horaire du serveur. Cette conception de l’intégration est plus simple que l’approche du champ indicateur, car il n’est pas nécessaire de mettre à niveau l’application source à la fin de la synchronisation.

Saisie des données de modification

La saisie des données de modification est l’une des seules méthodes dont vous disposez lorsque vous ne pouvez pas utiliser de champ indicateur, qu’il n’y a pas de date de dernière modification et que l’application ou l’API ne vous donne que l’ensemble des données à chaque fois. Avec cette option, l’intégration doit se souvenir de l’ensemble des données de la dernière exécution dans un « cache » ou une table intermédiaire pour pouvoir y comparer l’ensemble des données courantes. Cette comparaison met en relief les dossiers qui ont été ajoutés, modifiés ou supprimés. C’est une approche qui peut être utilisée pour les données de base et, avec prudence, pour les données de transaction également. Il est important de s’assurer que l’ensemble des données est obtenu de la source à chaque fois, ce qui rend l’application dynamique. Certains logiciels de veille stratégique et d’intégration, tels que les services d’intégration de SQL Server, SAP Business Objects et Talend, proposent la saisie de données de modification comme solution rapide pour l’exécution efficace de chargements incrémentiels des tables sources vers les entrepôts de données.

L’obtention de données entre un point A et un point B s’accompagne d’un certain nombre d’options et de considérations. Gardez ces techniques de synchronisation incrémentielle à l’esprit lors de la conception de votre prochaine intégration unidirectionnelle et vous serez sur la bonne voie pour créer une synchronisation efficace. Dans le prochain billet de blogue, nous aborderons les techniques d’intégration d’applications pour les synchronisations bidirectionnelles et en temps réel et la manière dont elles sont utilisées aujourd’hui lors de l’intégration avec ArcGIS Indoors et ArcGIS Roads and Highways.

Ce billet a été écrit en anglais par Abdul Mannan Mohammed et peut être consulté ici.