Étendre ArcGIS à l’aide des SDK et des API

Les systèmes ArcGIS reposent généralement sur une base stable de composants logiciels existants et bien connus. Ces composants peuvent être déployés de différentes manières et configurés pour prendre en charge les processus et les exigences. Pour de nombreux systèmes, les applications, services, outils et fonctionnalités existants sont suffisants. Dans d’autres cas, les exigences ou les critères de conception peuvent nécessiter une personnalisation du logiciel ou du processus. La plateforme ArcGIS fournit un choix de kits de développement logiciel (SDK), de moteurs de script et d’automatisation, ainsi que d’interfaces de développement d’applications (API) qui peuvent contribuer à atteindre ces objectifs. Le site Esri Developer fournit une documentation et des conseils complets sur certains de ces SDK et API, ainsi que de la documentation sur les autres API REST et les fonctionnalités des composants ArcGIS de base.

Certains projets et certaines équipes peuvent commencer un processus de conception avec une idée claire du rôle du développement ou de la personnalisation du logiciel. À l’inverse, d’autres processus de conception peuvent mettre en évidence la nécessité de la personnalisation par le biais de l’examen des exigences ou d’étapes ultérieures du processus de conception. Dans les deux cas, il est important de déterminer clairement la démarche à adopter pour étendre ArcGIS et le périmètre concerné.

Critères de décision pour la personnalisation de l’application

La décision visant à ajouter le développement de logiciels personnalisés à un projet présente une série d’implications, d’avantages et de considérations. Il est préférable de considérer le rôle du développement dans les systèmes ArcGIS comme une palette d’options utiles tout au long du développement : depuis les systèmes essentiellement prêts à l’emploi obtenus par des configurations contextuelles légères, des scripts Arcade ou d’autres techniques, en passant par des processus Python destinés au déplacement de données ou au géotraitement, aux applications extensibles avec peu de code qui prennent en charge l’ajout de codes Arcade, CSS et HTML à l’interface. Le tout conduisant à des systèmes entièrement personnalisés avec des services Web front-end soigneusement conçus et personnalisés, ainsi qu’une automatisation significative des données et des processus.

Il est possible de décomposer cette palette de plusieurs façons, mais l’une des façons de l’examiner consiste à l’étudier par trois approches principales :

  • Configurez les applications pour répondre aux besoins de votre entreprise. ArcGIS fournit un ensemble d’applications configurables qui prennent en charge des processus allant d’un niveau élémentaire à un niveau avancé avec des expériences de configuration simples basées sur un navigateur. L’utilisation de ces applications nécessite le moins d’efforts et des coûts d’exploitation les plus faibles, mais peut être limitée par les configurations prises en charge. Les applications de cette catégorie incluent Instant Apps, StoryMaps, Dashboards, Field Maps or Survey123.
  • Utilisez des générateurs d’applications nécessitant peu de code. Esri propose une multitude de générateurs d’applications qui incluent une expérience nécessitant peu de code, notamment ArcGIS Experience Builder, StoryMaps, Dashboards, ArcGIS Hub, Enterprise Sites et ArcGIS Instant Apps. Ces applications permettent toutes la configuration d’un certain degré de codes HTML ou CSS personnalisés, ainsi que différentes implémentations ou profils d’Arcade. Elles permettent de créer des applications soigneusement personnalisées, conformes à la marque, qui ont l’apparence d’une application entièrement personnalisée tout en conservant la possibilité de modifications ou d’ajustements rapides des fonctionnalités. Experience Builder donne la possibilité de créer des widgets personnalisés, qui peuvent être développés et mis à disposition pour être utilisés dans plusieurs applications différentes.
  • Applications entièrement personnalisées à l’aide des SDK ArcGIS. Esri crée des SDK pour divers environnements et langages de programmation, chacun d’entre eux offrant une prise en charge robuste de la création d’applications cartographiques et axées sur les données contenant des couches ArcGIS, des interactions avec l’interface utilisateur, une authentification sécurisée et des fonctionnalités de cartographie complexes. Comme vous n’avez pas besoin de coder vous-même chacune de ces parties spécifiques, vous pouvez créer des applications métier pour tirer parti des fonctionnalités ArcGIS disponibles dans votre organisation, ce qui réduit les frais généraux liés au développement et à la maintenance des applications. Le site Esri Developer fournit des informations complètes sur la sélection des SDK disponibles, ainsi que des processus courants, des descriptions de fonctionnalités et des exemples de code. Esri fournit également une série de composants d’application pour faciliter le développement Web grâce à des approches d’interface utilisateur standardisées.

Il n’existe pas de solution universelle sur cette palette d’options allant de la configuration au développement complet : les décisions doivent être basées sur la capacité de développement de l’équipe, la philosophie architecturale de l’organisation en matière de personnalisation et la compréhension des implications à long terme pour toute décision prise dans ce domaine.

Facteurs et points forts du développement de logiciels courants

Avec une large gamme d’options de personnalisation et de développement de logiciels, il est important de comprendre également certaines des motivations d’adoption de l’une de ces options. En effet, chacune d’entre elles contribue à un ensemble différent de critères décisionnels en ce qui concerne l’approche de personnalisation ou d’extension qui pourrait convenir.

  • Les motivations de fonctionnalité et d’intégration sont principalement liées à l’absence de fonctionnalités spécifiques dans une application ou un processus existant, ou encore à la nécessité de prendre en charge une intégration avec un autre système pour lequel une application existante n’existe pas. Autre motivation : le désir d’intégrer plusieurs ensembles de fonctionnalités dans une seule interface unifiée.
  • Performances et évolutivité. Si les performances des services, des interfaces ou des processus existants ne répondent pas à vos exigences, il est possible qu’une option personnalisée instaure de nouvelles solutions pour atteindre le niveau de service souhaité ou apporte un raccourci vers un processus permettant de gagner un temps considérable et d’améliorer la satisfaction des utilisateurs.
  • Création. Si une application doit être personnalisée au-delà de ce que le style et les thèmes proposés par les applications ArcGIS existantes prennent en charge, une application personnalisée peut être en mesure d’atteindre les interfaces spécifiques ou les objectifs de conception de l’organisation. Le Calcite Design System d’Esri est une base commune pour des interfaces bien conçues et utilisables.
  • Audience et expérience utilisateur. La facilité d’utilisation est un critère de réussite clé pour les efforts de conception de la plupart des applications, et la compréhension des différents besoins des groupes d’utilisateurs en matière de fonctionnalités est une étape importante. Les processus guidés peuvent aider même les utilisateurs les plus expérimentés à trouver leur chemin pour être productifs le plus rapidement possible après l’ouverture de l’application.
  • Culture et capacité organisationnelles. Votre organisation peut avoir des préférences ou une tendance à utiliser certains modes de développement lors du processus de conception d’applications. La direction, les équipes de gestion de projet et les équipes techniques peuvent avoir des préférences, des automatismes ou une expérience pertinente dans la prise de décision concernant les options de personnalisation, et peuvent les utiliser pour éclairer la prise de décision en vue d’une nouvelle opportunité. En examinant attentivement la capacité de l’organisation à prendre en charge une personnalisation et la maintenance correspondante, ainsi que la maintenance non négligeable d’applications avec un niveau de configuration avancé, vous vous assurerez que les choix pris délibérément engagent votre application sur la voie du succès.
  • Coût. Tous les processus de création d’une application entraînent des frais, et il est important de ne pas s’attendre à ce que la personnalisation ait un coût systématiquement plus élevé : une application adaptée à l’usage peut avoir une durée de vie plus longue et plus efficace qu’une application configurée, en fonction de la durée de vie de l’application configurée, des fonctionnalités requises et des modifications attendues. Les considérations financières doivent tenir compte des coûts de construction initiaux, mais aussi de la maintenance continue et des risques introduits par la décision.
  • Durée de vie. Les applications ne doivent pas être conçues pour être utilisées indéfiniment : un intervalle de remplacement raisonnable au cours duquel d’autres options ou approches sont envisagées garantit que vous n’ignorez pas les nouvelles possibilités d’application et que vous ne laissez pas en place indéfiniment une application alors qu’une meilleure solution peut exister. Dans certains cas, la mise à jour d’une application personnalisée correspond simplement à l’extraction d’une nouvelle version d’un SDK, mais d’autres mises à jour peuvent être plus importantes ou entraîner un investissement plus important en fonction du calendrier de développement initial de l’application et du cycle de vie du SDK utilisé pour la créer.

Bonnes pratiques d’utilisation des SDK et des API

Lorsque le développement logiciel joue un rôle dans la création d’une application ou la construction d’un système, quelques bonnes pratiques peuvent être appliquées à la plupart des scénarios :

  • Utilisez des outils familiers à l’équipe : votre organisation ou votre équipe de collaborateurs peut avoir de l’expérience avec des langages, des méthodologies de développement de logiciels ou des méthodes de création d’applications spécifiques. Il est avantageux de suivre ces modèles existants dans la plupart des scénarios. Cela favorise l’efficacité en s’appuyant sur les compétences existantes, en apprenant des expériences précédentes et en ne demandant pas à l’équipe d’adopter une nouvelle technologie simplement pour le plaisir de la nouveauté.
  • Restez à jour avec la dernière version : comme les composants logiciels de base, les SDK et les API ArcGIS sont mis à jour régulièrement, il est recommandé de se mettre en conformité par rapport aux dernières versions de l’un de ces produits, car ils intègrent de nouvelles fonctionnalités ainsi que des améliorations de la sécurité et des performances. Pour chaque version, Esri documente soigneusement les nouvelles fonctionnalités et les modifications importantes afin d’aider les développeurs à utiliser les dernières versions avec le moins de perturbations possible.
  • Développer en gardant à l’esprit les piliers de l’architecture : les piliers de l’architecture décrits dans cette section sont tout aussi pertinents pour les systèmes axés sur le développement de logiciels que pour les systèmes prêts à l’emploi. Tenez compte de l’importance de la sécurité, des performances, de l’évolutivité et de l’observabilité lorsque vous développez une nouvelle application ou fonctionnalité, afin de vous assurer que l’application obtenue peut être prise en charge et exploitée efficacement par l’équipe pendant la durée de vie prévue.

Résumé

L’extension d’ArcGIS, que ce soit par la personnalisation d’interfaces existantes ou la création de nouvelles applications avec ArcGIS Maps SDKs, constitue une excellente solution pour atteindre certains des objectifs présentés ci-dessus. Au cours du processus de conception d’un système d’entreprise, un examen minutieux de la pertinence de l’extension et de la personnalisation de la solution en question peut avoir un impact significatif sur la livraison future et le coût du système. En cas de doute, tenez compte des capacités et de l’état de préparation de l’organisation, afin de déterminer si une expérience existante ou une solution personnalisée (ou le plus souvent une combinaison des deux) peut être plus adaptée.

Top