Introduction : Interfaces externes

Les grands systèmes logiciels sont composés de différents composants. Cela permet entre autres de réduire la complexité des composants individuels, de répartir la charge ou d’utiliser de manière ciblée des ressources limitées et de garantir la possibilité d’extension. Une exigence fréquemment rencontrée dans le contexte de l’extensibilité est l’intégration d’un système logiciel existant avec un nouveau composant ou même un autre système. Les questions qui se posent à ce sujet sont largement indépendantes du système logiciel spécifique, de la plateforme choisie ou du langage de programmation. Dans un scénario d’intégration concret, il est également nécessaire de choisir la technologie et l’architecture d’interface adaptées aux conditions générales.

La première partie de l’article énumère différents aspects jouant un rôle dans l’intégration de systèmes logiciels et décrit leur impact sur des facteurs tels que la performance, le temps de réponse, la consommation de ressources, etc. La deuxième partie décrit des possibilités concrètes d’intégration d’un système logiciel, en accordant une attention particulière aux spécificités liées à l’intégration avec Comarch ERP Enterprise.

Il convient de garder à l’esprit qu’il n’existe aucune technologie d’interface qui réponde de manière optimale à toutes les exigences. Le choix approprié dépend du scénario concret et des conditions générales. La meilleure solution peut être aussi bien l’échange de fichiers dans un système de fichiers qu’un appel d’un service web via Internet.

Les aspects liés au contenu de l’intégration, c’est-à-dire les services, structures de données et données que l’interface doit offrir, ne font pas partie du présent article et ne sont pas influencés par celui-ci.

Client et serveur

Lorsque les processus dans les systèmes logiciels sont distribués, un composant joue le rôle de client, envoyant des requêtes, tandis qu’un autre composant joue le rôle de serveur, répondant à ces requêtes. Il existe entre le client et le serveur un réseau permettant la transmission des requêtes selon un protocole et un encodage définis. Dans certains cas, les rôles de client et de serveur peuvent changer au cours de la communication ou avec le temps. Par exemple, le Comarch ERP Enterprise Application Server est le serveur pour le client navigateur, mais lui-même est également client du serveur de base de données. Dans la suite du texte, le composant envoyant une requête est toujours appelé client.
Comme le serveur doit généralement être capable de traiter plusieurs clients simultanément, il nécessite une gestion des clients connectés et, si nécessaire, plusieurs unités d’exécution pour répondre aux requêtes entrantes.

Qualité des systèmes logiciels

Lors de l’extension d’un système logiciel, il faut veiller à ce que l’extension elle-même soit de qualité suffisante et que l’influence sur le système logiciel existant ne détériore pas sa qualité. Lors de l’implémentation d’un client et d’un serveur, les caractéristiques qualitatives suivantes doivent notamment être prises en compte :

• Débit — le fonctionnement de la plupart des systèmes logiciels repose sur des transactions. Le débit décrit le nombre de transactions dans un laps de temps donné.
• Temps de réponse — en particulier dans les systèmes interactifs, dans lesquels les utilisateurs attendent des réponses immédiates à leurs saisies, ce temps ne doit pas dépasser un certain seuil (environ 0,5 à 2 secondes). Il convient de noter qu’un débit élevé n’est pas synonyme de temps de réponse faible et inversement.
• Consommation de ressources — les ressources peuvent être des ordinateurs, la mémoire principale, la capacité du disque dur, les cartes réseau, les connexions réseau, les processeurs, les threads. La quantité de ressources dans un système logiciel est limitée. Pour pouvoir traiter autant de requêtes que possible, aussi rapidement que possible, une requête doit consommer le moins de ressources possible et ces ressources doivent être libérées dès que possible. Les ressources partagées doivent être protégées par des mécanismes de verrouillage. Cela peut avoir un impact sur le débit.
• Scalabilité — le système doit pouvoir croître avec un nombre croissant de clients et ainsi augmenter le débit sans allonger les temps de réponse. Cela est notamment réalisé en minimisant la communication réseau, en utilisant le caching (mémoire cache de la base de données, mémoire cache du serveur, mémoire cache du client) et en exécutant certaines tâches en parallèle dans le cadre d’une seule requête.
• Portabilité — afin de pouvoir utiliser un matériel différent ou plus performant si nécessaire, l’extension doit être portable. Les facteurs suivants influencent la portabilité :
  • langage de programmation
  • plateforme du système d’exploitation, qui détermine par exemple la syntaxe des chemins
  • SGBD utilisé, car malgré la normalisation SQL, les différents SGBD utilisent des syntaxes différentes et offrent différents types de données
  • protocole de communication entre client et serveur
• Disponibilité — si l’extension doit être installée plusieurs fois, il faut s’assurer que les correctifs et nouvelles versions, apparaissant lors de la maintenance et du développement, peuvent être distribués de manière contrôlée et installés avec un minimum d’interruption.
• Sécurité — afin de garantir la disponibilité du système et de protéger les données contre tout accès non autorisé, le système doit être en mesure de se protéger contre les requêtes non autorisées. Il existe pour cela différents mécanismes d’authentification et d’autorisation. Les extensions ne doivent pas contourner les mécanismes de sécurité du système existant.
• Testabilité — les extensions du système doivent être aussi faciles à tester que possible afin de vérifier leur bon fonctionnement et d’identifier d’éventuels problèmes.

Utilisation de l’infrastructure

Lorsqu’une extension d’un système logiciel est créée, elle doit être intégrée de manière appropriée dans l’infrastructure du système existant. Cela signifie que les services existants, tels que le caching, le verrouillage, les autorisations, etc., doivent être utilisés afin d’économiser des ressources et de minimiser l’effort d’administration. En même temps, là où ces services ne sont pas utilisés volontairement ou nécessairement, aucune erreur ou conflit ne doit apparaître.

Exemples de services à prendre en compte :

• mémoire cache du navigateur
• mémoire cache partagée sur le Comarch ERP Enterprise Application Server
• mémoire cache des pages sur le serveur de base de données

Verrous :

• sémaphores en Java (utilisation de synchronized)
• verrous des objets métiers et verrous logiques dans Comarch ERP Enterprise
• verrous de tables, de pages et de lignes dans la base de données

Autorisations :

• certificats clients
• autorisations et rôles d’autorisation de Comarch ERP Enterprise
• autorisations de la base de données pour les objets et utilisateurs du SGBD

Réseau

Lors de la connexion à une interface distante, chaque requête du client est transmise par le réseau. Lorsque le nombre de clients augmente, l’influence du réseau augmente également. Les propriétés suivantes caractérisent un réseau :

• taille des blocs — les réseaux envoient par défaut des données sous forme de blocs individuels. Dans le cas de TCP/IP, ces blocs sont appelés paquets et peuvent transporter des données utilisateur jusqu’à une taille standard de 4 kilooctets.
• débit du réseau — quantité d’informations pouvant être transmise simultanément sur une bande passante
• latence — l’infrastructure réseau ISO-OSI définit différentes couches de transport. Chaque passage d’une couche à une autre et chaque transfert d’une requête, par exemple le transfert d’un paquet TCP/IP d’un routeur à un autre, nécessite du temps.
• topologie — le nombre de nœuds et leurs connexions mutuelles influencent le chemin du paquet depuis la source jusqu’à la destination.

Cela entraîne les conséquences suivantes :

1. Chaque requête ne peut recevoir une réponse qu’aussi rapidement que la latence le permet. Cela ne peut pas être influencé, quelle que soit la largeur de bande disponible.
2. Le temps de transmission des données tenant dans un seul paquet est pratiquement déterminé uniquement par la latence. Par conséquent, transmettre des données en blocs plus petits que la taille du paquet est contre-productif.
3. L’augmentation de la bande passante contribue à réduire le temps de transmission de grandes quantités de données. Lorsque de grandes quantités de données sont transmises, elles doivent l’être en blocs afin d’exploiter la bande passante.

Protocole

Pour communiquer via le réseau, le client et le serveur utilisent un protocole. Celui-ci définit la manière d’établir la connexion, d’envoyer les requêtes, de recevoir les réponses et de terminer la connexion. De plus, le protocole définit également quels états d’erreur peuvent survenir et comment ils doivent être traités. Les propriétés suivantes du protocole sont particulièrement importantes :

• Protocole avec état ou sans état

Le serveur conserve-t-il un état pour chaque client ou chaque requête est-elle interprétée comme une nouvelle requête provenant de n’importe quel client ?

• Protocole chiffré ou non chiffré

Le client et le serveur établissent-ils un chiffrement de la connexion ou les données sont-elles transmises sans chiffrement ?
Les protocoles avec état suivent le principe d’une connexion permanente, comparable à une communication téléphonique entre deux participants. La connexion est établie une fois, l’identification des participants n’est effectuée qu’une seule fois et toutes les requêtes suivantes ne transmettent que les données utilisateur. Les opérations coûteuses ne sont donc exécutées qu’une seule fois. Le protocole clé dans cette catégorie est celui utilisé par les Object Request Broker pour communiquer via le protocole TCP/IP dans le cas de CORBA.

Le protocole sans état le plus connu est HTTP (Hypertext Transfer Protocol). Dans ce protocole, une requête avec des paramètres est envoyée à une adresse à laquelle le serveur répond en envoyant une page HTML. Comme le serveur ne connaît ni le client ni l’utilisateur du client, il ne peut pas reconnaître les requêtes successives comme faisant partie d’une séquence continue. Cela ne pose pas de problème pour des pages web simples, mais n’est pas suffisant pour réaliser des processus complexes.

Les processus tels que la banque en ligne, l’utilisation de Comarch ERP Enterprise ou l’exportation de grandes quantités de données nécessitent le stockage d’états pour chaque client. Si, pour des raisons techniques, l’utilisation d’un protocole avec état n’est pas possible, l’existence d’un tel protocole doit être simulée. Cela requiert davantage de logique, aussi bien côté client que côté serveur. Si le client ne dispose pas de cette logique et ne peut pas être étendu, cela doit être compensé, par exemple en procédant à une nouvelle authentification à chaque requête.

À condition que le client dispose de la logique nécessaire (par exemple les cookies dans le cas d’un client navigateur web), dans des cas très simples, l’état peut être stocké sur le client lui-même et envoyé en tant que paramètre avec chaque requête. Dans ce cas, le serveur est sans état et les ressources ne sont conservées que pendant le traitement de la requête. Dans des cas plus complexes, l’état doit être stocké sur le serveur. Dans ce cas, le client ne conserve et n’envoie généralement qu’un « identifiant de session » qui a été attribué par le serveur après l’authentification initiale.

Requêtes

Les requêtes des clients peuvent être décrites par les propriétés suivantes :

• Nombre de clients – Combien de clients envoient des requêtes en parallèle ?
• Fréquence des requêtes – Combien de requêtes un client effectue-t-il pendant une période donnée ?
• Temps de réponse attendu – La réponse doit-elle être disponible rapidement ?
• Volume de données – Quelle quantité de données est envoyée avec la requête et quelle quantité est attendue en réponse ?
• Format des données – Les données sont-elles codées en binaire ou en texte ? La structure des données est-elle propriétaire ou standardisée ? Les données sont-elles chiffrées dans la requête elle-même ?
• Accès en lecture ou en écriture – Le client souhaite-t-il seulement interroger des données ou également les modifier ? À quel point les données lues doivent-elles être à jour ?
• Connexion synchrone ou asynchrone – Quelle partie de la réponse le client attend-il immédiatement ?
• Connexion active ou polling – Le client envoie-t-il une requête explicite ou vérifie-t-il périodiquement la présence de certaines données à un emplacement donné ?
• Connexion sans état ou avec état – Le serveur maintient-il un état sur plusieurs requêtes ?

Avant de concevoir ou de choisir une interface, toutes ces questions doivent être clarifiées, car elles ont une influence significative sur la conception. Les conséquences des différentes propriétés sont énumérées ci-dessous.

Nombre de clients

Pour les serveurs avec état, chaque client connecté implique une quantité de mémoire principale réservée sur le serveur pendant toute la durée de la connexion.
Cette mémoire est rarement utilisée et reste occupée pendant une période relativement longue. Pour les serveurs sans état, la quantité de mémoire par requête est dominante et généralement plus élevée que pour une requête à un serveur avec état. Si la transmission de la réponse au client ne peut pas être répartie sur plusieurs connexions, des quantités potentiellement très importantes de mémoire principale sont temporairement allouées.

Fréquence des requêtes

Si un grand nombre de requêtes est attendu pendant une période donnée et si la logique du serveur le permet, plusieurs unités d’exécution sur le serveur doivent traiter les requêtes client en parallèle afin d’atteindre le débit nécessaire.

Temps de réponse attendu

Afin que la latence du réseau ne devienne pas un problème trop important, les requêtes des clients doivent toujours être regroupées (c’est-à-dire envoyées par blocs). Ce n’est qu’ainsi que la bande passante réseau disponible peut être utilisée efficacement.

Volume de données

Lors d’une requête, seules les données réellement nécessaires doivent être envoyées et interrogées. Par exemple, lors d’un accès SQL à une base de données, le nombre de colonnes et de lignes du résultat doit être aussi faible que possible.

Format des données

L’utilisation de formats de données binaires réduit la quantité de données à transmettre et est à privilégier pour la transmission de volumes importants. La mesure dans laquelle les données binaires peuvent être correctement interprétées sur différentes plateformes dépend également d’autres facteurs. CORBA, par exemple, offre un format binaire compatible avec différentes plateformes, qui est converti si nécessaire par la couche intermédiaire ORB en fonction des spécificités de la plateforme (ordre des octets : little ou big endian, codage des caractères).
L’utilisation de formats textuels est judicieuse pour de faibles volumes de données et lorsque les clients et serveurs impliqués n’utilisent qu’une faible logique ou des technologies très différentes (par exemple serveur C++ et client Perl). En principe, l’utilisation de formats textuels augmente le volume des données à transmettre pour une même quantité de données utilisateur. Selon le format, ce facteur varie d’environ 1,5–4 (codage Base64, codage hexadécimal) à 10–15 (XML avec balises ouvrantes, fermantes et méta-informations). L’augmentation du volume de données peut être partiellement compensée par la compression. Il convient toutefois de se demander si l’effort supplémentaire en termes de calcul et de matériel est justifié.

L’utilisation de structures de données propriétaires peut être judicieuse dans des systèmes fermés, dans lesquels client et serveur proviennent de la même source. En cas de modification des exigences, il est alors possible de réagir plus rapidement et de manière plus ciblée. En cas de communication au-delà des frontières de son propre système, il est en principe recommandé d’utiliser des formats standard (par exemple EDI).

Lors de la communication au-delà des frontières de son propre système, le chiffrement des données est important lorsqu’elles doivent être transmises via des canaux non sécurisés, par exemple via Internet avec le protocole HTTP ou sous forme de message e-mail. Les procédés utilisés à cet effet nécessitent une logique supplémentaire et des métadonnées de chiffrement côté client et côté serveur.

Accès en lecture ou en écriture

Un accès en lecture nécessite généralement moins de ressources qu’un accès en écriture. Si le résultat de la lecture n’a pas besoin d’être à 100 % à jour, il est possible de renoncer à un verrouillage strict et de retourner des données provenant du cache.

Connexion synchrone ou asynchrone

Dans le cadre d’une connexion synchrone, le client attend immédiatement une réponse du serveur. Il s’agit du cas standard, car il faut tenir compte de la confirmation que la requête a été acceptée par le serveur. Si la réponse réelle n’est pas nécessaire ou seulement à un moment ultérieur, le serveur peut attendre que les ressources nécessaires soient disponibles.

Connexion active ou polling

Lorsque le serveur est appelé activement par le client, le client et le serveur doivent communiquer de manière synchrone au moins pendant une partie du temps. L’avantage est que le serveur ne fournit des données que lorsque le client les attend. Dans le cas du polling, le client vérifie périodiquement si des données, par exemple sous forme de fichier, sont disponibles à un emplacement auquel les deux parties peuvent accéder sans requête préalable au serveur. Le polling est adapté à la transmission de grands volumes de données pouvant être fournis par le serveur sans paramètres d’entrée supplémentaires. Des retours d’erreur du client vers le serveur n’ont généralement pas lieu. Il est également possible de combiner les variantes connexion active et polling.
Dans ce cas, le client envoie d’abord une requête au serveur, puis seulement ensuite commence le polling.

Connexion sans état ou avec état

Lors de l’utilisation de connexions sans état, l’authentification doit être effectuée à nouveau pour chaque requête, ce qui a un effet négatif si la fréquence des requêtes est élevée. De plus, dans le cas de connexions sans état, les processus complexes doivent toujours être encapsulés dans une seule requête et l’ensemble du résultat doit être envoyé dans une seule réponse. Il en résulte des interfaces composées de peu de modules, mais très complexes. Comme les requêtes et les réponses doivent généralement être entièrement conservées en mémoire principale, au moins temporairement, pour traiter la requête, ce type de connexion ne convient pas non plus à la transmission de données volumineuses. Dans le cas de connexions avec état, le surcoût lié à l’authentification n’apparaît qu’une seule fois, les interactions complexes peuvent être réparties en parties réutilisables et la transmission des paramètres d’entrée peut être effectuée en plusieurs blocs.

Technologies d’interface

Cette section présente les technologies d’interface pouvant être utilisées pour intégrer des systèmes logiciels. Le niveau de prise en charge qu’offre Comarch ERP Enterprise dans ce domaine en standard y est également décrit.
La solution concrète à un problème d’intégration repose généralement sur une combinaison de plusieurs de ces technologies, comme le montrent certains exemples.

Fichiers

Lorsque les données sont transmises sous forme de fichiers, elles sont mises à disposition dans un emplacement central auquel le serveur dispose d’un accès en écriture et le client au moins d’un accès en lecture.
Les fichiers conviennent également bien aux grands volumes de données. Un exemple d’utilisation de fichiers pour l’échange de données entre différents systèmes est BIS, qui permet l’importation ou l’exportation automatique de données.

L’un des inconvénients des fichiers est l’absence de transactions. Le moment où un fichier devient visible ou accessible pour un autre processus, et celui qui le lit, dépend dans une large mesure du système d’exploitation.

Comarch ERP Enterprise prend en charge le système de fichiers du serveur d’applications et le Knowledge Store.

Système de fichiers du serveur d’applications

Comarch ERP Enterprise peut accéder au système de fichiers du serveur d’applications. En fonction de la configuration du système d’exploitation, le système de fichiers local ainsi que les systèmes de fichiers distants (« lecteurs réseau ») sont disponibles.

Les fichiers sont adressés via leur chemin d’accès. Il convient de noter que les chemins d’accès dépendent de la machine et de son système d’exploitation et qu’ils ne peuvent donc pas être utilisés de manière uniforme sur différents serveurs d’applications. Une manière de retrouver une indépendance consiste à utiliser des chemins relatifs au dossier « semiramis/usr ». Le chemin du serveur de fichiers vers le dossier « semiramis » peut être déterminé sur chaque serveur d’applications Comarch ERP Enterprise dans la notation qui lui est propre[1]. Les variables correspondantes (« {semiramis} ») sont déjà disponibles à cet effet dans BIS, dans les sorties de documents ainsi que dans les réorganisations.

Knowledge Store

Le Knowledge Store fournit un système de fichiers géré par la base de données. Les chemins de fichiers sont valables pour tous les serveurs d’applications et sont indépendants du système d’exploitation.
Les logiciels externes peuvent accéder au Knowledge Store via WebDAV en utilisant le protocole https. Cela permet un accès direct depuis des postes clients qui n’ont pas accès au système de fichiers du serveur d’applications. Étant donné que WebDAV est un standard relativement récent, ce type d’accès n’est pas encore proposé par tous les systèmes d’exploitation et toutes les applications. L’authentification s’effectue à l’aide d’un certificat ou d’un mot de passe.
Des informations détaillées peuvent être trouvées dans l’article Knowledge Store.

Bases de données

SQL (accès direct)

L’accès direct aux bases de données est possible depuis le langage Java, par exemple via l’interface JDBC, un pilote JDBC devant être utilisé pour la base de données concernée. L’accès à la base de données peut dépendre du SGBD utilisé malgré l’utilisation de JDBC.

Accès aux bases de données externes

L’accès aux bases de données externes peut être effectué depuis Comarch ERP Enterprise. Pour cela, l’interface JDBC standard du JDK peut par exemple être utilisée.

Accès aux bases de données Comarch ERP Enterprise

D’un point de vue technique, un accès direct aux bases de données Comarch ERP Enterprise est également possible. Cependant, cela n’est pas recommandé pour les raisons suivantes :

• Le mapping des Business Objects Comarch ERP Enterprise et des types de données correspondants est spécifique au SGBD, et sa forme n’est pas garantie par Comarch ERP Enterprise Software AG.
• Au niveau du SGBD, il existe un modèle de données technique dans lequel les identifiants GUID sont des données binaires et les horodatages sont stockés dans un format compact qu’aucun SGBD ne peut interpréter directement.
• L’accès en lecture contourne le caching de Comarch ERP Enterprise, ce qui réduit la rapidité des accès.
• L’accès en écriture contourne le caching et le verrouillage de Comarch ERP Enterprise, ce qui peut entraîner la lecture de données potentiellement incohérentes.
• Aucun contrôle d’autorisation n’est effectué, à l’exception des mécanismes propres au SGBD.
  Il convient d’utiliser à la place Comarch ERP Enterprise ODBC ou Comarch ERP Enterprise Persistence Service.

ODBC Comarch ERP Enterprise

ODBC Comarch ERP Enterprise permet un accès aux bases de données Comarch ERP Enterprise via une interface ODBC intégrée, utilisable par des logiciels externes. L’accès est indépendant du SGBD utilisé par Comarch ERP Enterprise.
Pour ODBC Comarch ERP Enterprise, il convient de noter qu’un accès aux bases de données n’est possible qu’en mode lecture. Techniquement, l’accès nécessite l’utilisation du protocole HTTPS.
ODBC Comarch ERP Enterprise met à disposition un schéma de base de données enrichi sur la base des métadonnées Comarch ERP Enterprise. En tant qu’attributs virtuels, il contient les clés métier issues des relations, ainsi que la description des valeurs de valueset en langage naturel. En outre, des tables virtuelles permettant l’accès au Knowledge Store et aux objets dynamiques sont disponibles. Il est également possible de mettre à disposition ses propres données supplémentaires et calculs sous forme de tables virtuelles et de fonctions virtuelles. Pour chaque attribut du schéma de base de données, une description traduisible est disponible.
Les autorisations au niveau de l’unité métier sont évaluées lors de l’accès à ODBC Comarch ERP Enterprise.

Persistance Comarch ERP Enterprise

Le service de persistance Comarch ERP Enterprise ne peut être utilisé qu’au sein de Comarch ERP Enterprise. Un accès distant peut toutefois être réalisé au moyen d’une couche intermédiaire.
Pour cela, il est possible par exemple de créer une application en tâche de fond dans Comarch ERP Enterprise, puis de l’appeler depuis l’extérieur via CORBA ou un service web. L’indépendance par rapport au canal appelant les applications en tâche de fond constitue une alternative pérenne, car les développeurs n’ont pas à gérer les particularités et dépendances entre versions des méthodes d’appel concrètes.
Le service de persistance Comarch ERP Enterprise est indépendant du SGBD. Il permet la lecture et l’écriture, ainsi que l’utilisation du caching, des verrous et, en option, des autorisations Comarch ERP Enterprise. Il prend en charge l’accès orienté objets et l’accès tuple, ainsi que les opérations unitaires et massives. Il permet l’exécution d’applications très simples en tâche de fond, par exemple un accès unique à la base de données via Comarch ERP Enterprise OQL, ainsi que des logiques complexes. En réutilisant les classes logiques existantes, un haut degré de réutilisation fonctionnelle peut être obtenu.

Connexion distante

Les appels distants sont utilisés pour exécuter de manière synchrone certaines opérations dans un système distant. Un protocole défini est utilisé pour la connexion.

CORBA

CORBA est un protocole pour les connexions distantes pouvant être utilisé sur diverses plateformes. CORBA peut fonctionner avec état et convient donc à la transmission de grandes quantités de données.

Comarch ERP Enterprise comme serveur CORBA

Comarch ERP Enterprise comprend un serveur CORBA. Le format des données de l’interface, auquel les clients doivent se conformer, est défini dans un fichier IDL.
Toute application en tâche de fond dans Comarch ERP Enterprise peut être appelée via l’interface CORBA. De plus, la fonction BIS (échange de données) est disponible.
Lors de la connexion des clients au serveur CORBA, l’authentification et la vérification des autorisations sont effectuées dans Comarch ERP Enterprise.
Des informations détaillées peuvent être trouvées dans l’article Interface CORBA.

Comarch ERP Enterprise comme client CORBA

Dans le cadre d’adaptations, il est également possible d’accéder à un serveur CORBA externe depuis Comarch ERP Enterprise. Comarch ERP Enterprise ne fournit que l’ORB, les bibliothèques associées et la documentation d’exemples de clients CORBA comme support standard, car la méthode d’accès est entièrement déterminée par le serveur CORBA concerné.

Web service

Un web service utilise le protocole SOAP pour les connexions distantes, qui peut être utilisé sur différentes plateformes. Une autre option consiste à implémenter le principe REST lors de la réalisation d’un service web. Ils constituent une alternative à CORBA lorsqu’il n’est pas nécessaire de transmettre des données volumineuses, car les services web ne prennent pas en charge les connexions avec état.

Comarch ERP Enterprise en tant que serveur de services web

Comarch ERP Enterprise contient un serveur de services web. Il requiert l’utilisation du protocole HTTPS. Il définit via un fichier WSDL le format des données d’interface (éventuellement SOAP) dont les clients doivent se servir.
Grâce à l’interface du service web, la fonctionnalité est disponible de manière analogue au serveur CORBA.
Lorsque les clients se connectent au serveur de services web, l’authentification par mot de passe ou certificat utilisateur et la vérification des autorisations dans Comarch ERP Enterprise sont effectuées.

Comarch ERP Enterprise en tant que client de services web

Les adaptations dans Comarch ERP Enterprise peuvent également accéder à un serveur de services web distant. Comarch ERP Enterprise fournit les bibliothèques associées et la documentation d’exemples de clients web service pour Comarch ERP Enterprise lui-même en standard, car la méthode d’accès est entièrement déterminée par le serveur de services web concerné.

Protocoles natifs

Il est également possible d’utiliser d’autres protocoles tels que TCP/IP, FTP ou Java RMI. Ils sont particulièrement intéressants lorsqu’il s’agit d’adresser des serveurs externes à partir de Comarch ERP Enterprise via ses interfaces. Cependant, Comarch ERP Enterprise n’offre ici aucun support standard.
Si une adaptation dans Comarch ERP Enterprise est destinée à mettre en œuvre un serveur pour un protocole natif, il est recommandé de créer ce serveur en dehors de Comarch ERP Enterprise et de lui permettre d’accéder à Comarch ERP Enterprise via CORBA.

Combinaison de différentes technologies

Questions liées aux performances

Protection contre les goulets d’étranglement des ressources

Les systèmes serveurs, tels que Comarch ERP Enterprise, ne peuvent pas fonctionner avec des performances optimales si trop de connexions distantes sont traitées simultanément par le serveur d’applications. Cela peut être évité en prenant des mesures appropriées.

Chaque session ouverte par un client dans Comarch ERP Enterprise via une connexion distante consomme des ressources telles que la mémoire, le temps CPU et les connexions à la base de données sur le serveur d’applications auquel le client se connecte. Si un scénario exige un très grand nombre de clients tous connectés en permanence au serveur CORBA, des goulets d’étranglement de ressources (réduction du débit) peuvent apparaître. Les ressources critiques dans ce cas sont principalement les sessions (et connexions à la base de données). Chaque session occupe un thread Comarch ERP Enterprise dès sa création, c’est-à-dire la mémoire heap pour la pile du thread (thread stack) ainsi que des ressources natives selon le système d’exploitation. Lors du traitement d’une requête, ce thread est utilisé. Si des données doivent être lues dans la base de données pour traiter une requête CORBA, des connexions temporaires supplémentaires à la base de données sont utilisées.

La mémoire, les threads et les connexions à la base de données sont des ressources limitées sur le serveur d’applications. Un goulet d’étranglement des ressources entraîne une augmentation du temps de traitement des connexions distantes. Dans le pire des cas, la stabilité de l’ensemble du serveur d’applications peut être compromise.
Il existe plusieurs moyens d’éviter de tels goulets d’étranglement. La question fondamentale est la coordination de l’accès aux ressources critiques afin d’éviter un trop grand nombre d’accès simultanés.

Dans la première solution illustrée ci-dessous, plusieurs serveurs d’applications Comarch ERP Enterprise sont utilisés pour répartir les accès des clients. L’exemple utilise des clients CORBA, mais le principe s’applique de manière générale.
En répartissant les accès sur plusieurs serveurs d’applications Comarch ERP Enterprise, la consommation de mémoire par serveur d’applications est réduite. Cependant, cette solution peut conduire à une charge importante sur la base de données si plusieurs serveurs d’applications reçoivent en même temps un volume élevé de requêtes.
Plus grand nombre de serveurs CORBA

Dans la seconde solution possible, un processus indépendant (CORBA Proxy Queue) est utilisé, séparé de Comarch ERP Enterprise. Les requêtes clientes arrivent d’abord dans ce processus, qui les met en file d’attente, puis transmet simultanément un nombre limité d’entre elles à Comarch ERP Enterprise. Cela limite le nombre de sessions CORBA et le nombre de connexions à la base de données dans Comarch ERP Enterprise. La CORBA Proxy Queue agit à la fois comme serveur pour les connexions distantes et comme client CORBA. Sa mise en œuvre peut donc être réalisée dans n’importe quel langage de programmation adapté au cas d’usage.
Dans les deux solutions, on suppose que chaque processus s’exécute sur sa propre machine et dispose ainsi d’un accès exclusif à ses ressources limitées. La solution CORBA Proxy Queue devrait également fonctionner sur sa propre machine.

Même lors de la création d’une connexion à Comarch ERP Enterprise via des connexions distantes, des tests doivent être effectués en tenant compte du nombre attendu de clients. Cela permet de déterminer si les mesures nécessaires pour protéger les ressources sont requises dans le cas spécifique.

Dans la seconde solution possible, un processus indépendant (CORBA Proxy Queue), séparé de Comarch ERP Enterprise, est utilisé. Les requêtes des clients arrivent d’abord dans ce processus, qui les met en file d’attente, puis transmet simultanément un nombre limité d’entre elles à Comarch ERP Enterprise. Cela réduit le nombre de sessions CORBA ainsi que le nombre de connexions à la base de données dans Comarch ERP Enterprise. La CORBA Proxy Queue agit comme serveur pour les connexions distantes et comme client CORBA. L’implémentation d’une telle file d’attente peut donc être réalisée dans n’importe quel langage de programmation adapté au cas d’usage.

Dans les deux solutions, on part du principe que chaque processus fonctionne sur son propre ordinateur et dispose ainsi d’un accès exclusif à ses ressources limitées. La solution CORBA Proxy Queue devrait également fonctionner sur son propre ordinateur.

Même lors de la création d’une connexion à Comarch ERP Enterprise via des connexions distantes, les tests doivent être effectués en tenant compte du nombre de clients attendu. Cela permet de déterminer si les mesures nécessaires à la protection des ressources sont requises dans le cas concerné.