Oswald Regular
OpenSans Regular
Co>Operating System®
Une architecture globale, pensée dans le moindre détail

Le Co>Operating System est un environnement permettant de créer, d'intégrer et d'exécuter des applications métier au sein d'une entreprise. Il s’agit de la « base » de toutes les solutions technologiques proposées par Ab Initio, notamment l'Enterprise Meta>Environment®, Continuous>Flows®, Conduct>It® et le Business Rules Environment. Cette architecture garantit un environnement complet et homogène pour le développement et l'exécution d’applications.

Le cœur du Co>Operating System® est un "moteur de flux de données", qui alimente une vaste bibliothèque de « composants » de traitement de données. Ces composants manipulent les données contenues dans les flux d’une application. La conception, la mise en œuvre et la maintenance des applications s'effectuent dans l'interface graphique du GDE® (Graphical Development Environment) Ab Initio.

La caractéristique essentielle du Co>Operating System est de permettre de concevoir et de développer des applications en dessinant leur architecture comme sur un tableau blanc ou sur une feuille de papier. Les sources d’entrée et de sortie sont représentées par des icônes facilement identifiables. Celles-ci sont ensuite connectées par des flèches à des composants de traitement (en forme de blocs) afin de définir le flux de traitement global. Les composants à assembler pour créer une application Ab Initio® peuvent être sélectionnés dans une vaste bibliothèque de composants.

Ab Initio offre une transparence totale entre la conception des applications et leur exécution : la représentation graphique est l'application. Il peut s'agir d'une application destinée à un traitement batch, à un traitement en temps quasi réel ou à un traitement instantané, voire d'une application combinant toutes ces fonctions. L'environnement de traitement ainsi obtenu est homogène et puissant.

En adoptant une approche graphique pour la représentation des flux de données, Ab Initio permet de développer la plupart des applications métier : systèmes opérationnels, intégration d'applications distribuées, traitement d'événements complexes ou entrepôt de données et systèmes de gestion de la qualité des données. Mais la conception et le développement graphiques ne sont qu'une partie de la solution. En effet, ces applications doivent également répondre à des exigences majeures en termes de fonctionnement et de gestion.

Les technologies de programmation graphique offrent généralement des interfaces réussies d'un point de vue esthétique mais leurs fonctions sont inadaptées aux besoins techniques des utilisateurs. En revanche, le Co>Operating System tient ses promesses : il fonctionne parfaitement. Voici des exemples concrets d'entreprises ayant choisi le Co>Operating System pour répondre à leurs besoins :

  • Une grande place boursière a remplacé des millions de lignes de code Cobol par des applications Ab Initio destinées à des opérations vitales pour l'entreprise. La solution mise en place constitue à présent une part essentielle du processus de traitement des opérations. Connectée en temps réel aux flux d'échanges, elle permet de traiter les transactions au rythme de 500 000 messages par seconde.
  • Un grand détaillant contrôle son inventaire et peut détecter d'éventuelles fraudes en recevant des données en temps réel de ses terminaux de vente dans des milliers de magasins.
  • Un opérateur téléphonique utilise Ab Initio pour traiter des informations de comptes rendus d'appels dans le cadre du calcul des coûts d'appel, du suivi d'utilisation et du contrôle du réseau. Des milliards d'enregistrements de données d'appel sont traités chaque jour ainsi que des millions de demandes relatives à l'utilisation.
  • Un grand producteur de puces électroniques a réussi à accroître son rendement en collectant en temps réel des données sur la qualité, provenant de la chaîne de fabrication.
  • Un réseau de cartes de crédit utilise la solution Ab Initio pour son infrastructure de données, ce qui lui permet de traiter toutes les transactions et de les transmettre en modes batch et temps réel aux systèmes dorsaux. Ce sont ainsi des milliards de données de transactions qui sont stockées chaque année dans un système d'archivage Ab Initio, permettant au service clientèle de répondre instantanément aux diverses requêtes.
  • Une grande société Internet traite chaque jour des dizaines de milliards d’annonces en ligne dans le cadre de ses services de facturation et d'optimisation du placement publicitaire.
  • Un des principaux acteurs du marché de l'assurance utilise Ab Initio pour de nombreux aspects du traitement des demandes d'indemnité. Le système de traitement de réassurance et de contrats, en place dans cette société, comporte des milliers de règles complexes qui sont toutes mises en œuvre avec la solution Ab Initio.
  • Une société de livraison confie aux applications Ab Initio l'ensemble de sa facturation ainsi que le calcul des rémunérations de ses équipes commerciales.
  • Une banque internationale utilise la solution Ab Initio pour consolider les informations relatives à l'ensemble des clients, tous secteurs confondus, dans un vaste entrepôt de données. Ab Initio lui permet également de personnaliser et de traiter tous les flux de transactions SWIFT entre ses filiales internationales.

Tous ces exemples font référence à des entreprises d'envergure internationale. Comment expliquer que toutes se soient tournées vers Ab Initio ? Les produits Ab Initio sont intuitifs et simples d'utilisation. Ils sont également capables de gérer les logiques applicatives les plus complexes ainsi que des volumes de données considérables. Alliant des performances exceptionnelles à une fiabilité remarquable, Ab Initio est une solution sans égal.

Ces exemples ne représentent qu'une partie des déploiements réalisés chez ces clients, et dont la mise en place s'effectue souvent à très grande échelle. Pour être en mesure de répondre aux conditions requises pour ces applications, de nombreuses caractéristiques fonctionnelles s'imposent :

  • Capacité de représenter des logiques complexes sous forme graphique simple.
  • Connectivité quasi illimitée ; par exemple de nombreuses bases de données, systèmes de files d'attente, fichiers plats, systèmes ERP, protocoles de messagerie standard.
  • Prise en charge native de structures de données complexes (tout type de données, quelle que soit leur origine). Données hiérarchiques (fichiers XML et hérités), jeux de caractères internationaux, objets volumineux, données de longueur variable, données compressées, entre autres.
  • Prise en charge de nombreux systèmes d'exploitation (Unix, Linux, Windows, mainframes) et traitement réparti entre ces plates-formes
  • Architecture ouverte permettant l'intégration rapide d'applications, de données et d'environnements hérités et tiers
  • Efficacité et évolutivité de haut niveau, offrant la possibilité d'une informatique de type "cloud" entre les réseaux de serveurs
  • Traitement batch et en temps réel performant (services Web et architectures orientées services, ainsi que diffusion en continu)
  • Capacité de réutilisation accrue des applications (sur des portions plus ou moins grandes), y compris les règles métier
  • Forte tolérance aux défaillances système et aux problèmes de données. Contrôle utilisateur important pour les réponses d’échec.
  • Fonctionnalités de gestion complètes. Prise en charge du cycle de vie d'une application, notamment contrôle de version et promotion. Planification, contrôle et alerte d'exécution. Analyse des applications.

Le seul moyen d'intégrer toutes ces caractéristiques à l’application consiste à les prendre en compte dans l'architecture dès le départ. En effet, une fois l'architecture définie, il est pratiquement impossible de lui ajouter des fonctionnalités fondamentales. Ces fonctions ont donc été incluses dans la conception de base du Co>Operating System. Sa technologie robuste et éprouvée est utilisée avec succès pour de nombreuses applications de traitement de données complexes.

Qu'est-ce qu'une application Ab Initio®?

Le cœur d'une application Ab Initio est un graphe de flux de données, appelé plus simplement "graphe". Celui-ci est constitué de composants, connectés entre eux par le biais de “flux" de données.

Considérons par exemple le graphe suivant : il s'agit d'une application simple qui lit chaque enregistrement d'un fichier plat contenant des transactions client, puis qui reformate les données (en appliquant des règles) avant de les trier et de les agréger. Les résultats de ce traitement sont ensuite intégrés à une table d'une base de données de type Oracle.

Grâce à l'utilisation de composants hautement configurables, le Co>Operating System apporte toutes les fonctions de base nécessaires au traitement des données métier, notamment :

  • Transformations de données
  • Sélection/filtrage
  • Déduplication
  • Jointure/fusion
  • Normalisation/dénormalisation
  • Compression/décompression
  • Agrégation/analyse
  • Tri
  • Génération et validation de données
  • ...

Le Co>Operating System est en outre doté d'une vaste bibliothèque de composants standard capables de gérer presque tout type de données source ou cible. Ces composants permettent notamment :

  • La connexion à tout type de fichier plat sous Unix, Windows et sur les mainframes
  • La connexion à toutes les bases de données courantes, et moins courantes, notamment Oracle, DB2, Teradata, SQL Server, Netezza, Greenplum, mainframe DB2, IMS, IDMS, Adabas.
  • La connexion à toutes les infrastructures standard de files de messages (IBM MQ, JMS, Microsoft MQ)
  • La connexion aux infrastructures de services Web (WebSphere, WebLogic, IIS, Apache/Tomcat, ...)
  • La connexion à de nombreux produits tiers (SAP, Siebel, SAS, PeopleSoft, Salesforce.com, ...)
  • L'analyse et la manipulation de structures de données hiérarchiques (XML, ASN.1, Cobol, ...)
  • L'analyse, la manipulation et la génération de formats de données spécifiques (Swift, FIX, EDIFACT, ...)
  • Le routage de messages en fonction de leur contenu
  • La connectivité des métadonnées à une large palette de produits de définition des données et d’informatique décisionnelle (ERWin, ERStudio, Microstrategy, Business Objects, Cognos, ...)

Si les applications de petite taille peuvent contenir de 3 à 5 composants, les applications de plus grande taille peuvent en avoir une centaine. Pour certaines applications de très grande envergure, le nombre de composants peut atteindre plusieurs milliers. Les applications peuvent également être dotées de nombreux graphes, chacun pouvant contenir de nombreux composants.

Quelle que soit leur envergure, les applications Ab Initio fonctionnent toutes avec des règles et des composants réutilisables, garantissant ainsi une réponse rapide aux besoins métier en constante évolution.

Une représentation purement graphique de la logique métier

Via les composants du Co>Operating System, l'utilisateur peut définir la règle ou la logique qui lui convient et l'appliquer à tout type de données. La méthode de spécification de ces règles est purement graphique, ce qui est une avancée majeure par rapport aux autres technologies. En effet, lorsque celles-ci proposent une définition graphique des règles, elles se limitent à des règles simples. Dès que la logique devient plus complexe, l'utilisateur se retrouve rapidement face à des obstacles infranchissables. Il n'a souvent d'autre choix que d'abandonner la technologie choisie et de se tourner vers des méthodes de programmation classiques, notamment Java, C++, scripts, procédures stockées, Perl.

Mais ces divergences s'effacent avec le Co>Operating System. Une fois le système en place, les utilisateurs réalisent à quel point il est plus simple de spécifier une logique complexe avec le Co>Operating System qu'avec d'autres technologies. Cette simplicité se reflète ensuite sur la productivité, la facilité d'utilisation et la transparence : les règles sont plus simples et plus rapides à spécifier par la méthode graphique, elles sont également mieux comprises par les utilisateurs métier.

Dans le Co>Operating System, le langage DML (Data Manipulation Language) Ab Initio est utilisé pour définir les règles qui résident ensuite dans des composants de "transformation", véritables piliers du traitement des données. Certains composants de transformation permettent de mapper un type de structure d'enregistrement à un autre, d'autres servent à agréger ou à filtrer des données, à normaliser ou dénormaliser des structures, ou encore à regrouper plusieurs flots d'enregistrements. Chaque composant peut appliquer des règles spécifiées en DML aux enregistrements, au fur et à mesure du traitement.

La capture d'écran ci-dessous illustre une règle simple permettant de calculer le résultat d'un composant de mapping. Les volets gauche et droit comportent respectivement les champs d'entrée et de sortie du composant ; les règles se trouvent dans le volet central.

Les règles peuvent être créées dans l’Éditeur d'expression, illustré ci-après. Cet éditeur permet de spécifier des expressions longues et complexes, et le langage DML dispose d'une multitude d'opérateurs et de fonctions intégrés.

Ab Initio propose également d'autres interfaces utilisateur permettant de spécifier des règles métier. Ces interfaces s'adressent avant tout aux utilisateurs moins techniques qui sont souvent des analystes ou des experts du domaine de l'entreprise. Ces professionnels, qui travaillent avec des termes métier non techniques, préfèrent généralement définir et organiser les règles dans un format de type "feuille de calcul".

Cliquez sur Business Rules Environment pour des informations supplémentaires.

Le Co>Operating System est conçu pour tout type de données.

Avec le Co>Operating System, les données conservent leurs caractéristiques ou s'adaptent aux souhaits de l'utilisateur. Ce n'est en aucun cas un système imposant une conversion des données dans un nombre limité de formats. À l’inverse, le Co>Operating System traite les données dans leur format natif, et cela de manière identique pour tous les systèmes d'exploitation pris en charge. Ainsi le Co>Operating System et l'ensemble des composants Ab Initio peuvent gérer des données de mainframe sur des serveurs Unix et Windows ou des données XML sur des mainframes. Ils peuvent également traiter des structures hiérarchiques et compressées complexes sur toutes les plates-formes ou encore des données internationales avec un transcodage automatique. Pour les mêmes données et la même application, le Co>Operating System produira des résultats identiques quel que soit le système d'exploitation utilisé.

Les données lues et écrites peuvent provenir de systèmes très hétérogènes, et leur format peut varier en différents points d'une application. Dans l'exemple qui suit, une application lit des données de mainframe dans un fichier plat, puis des données XML dans une file d’attente MQ, traite ces données avec différents formats intermédiaires et génère les résultats dans un fichier plat utilisant un jeu de codes international.

Le Co>Operating System sait où trouver les formats de données, quel que soit leur emplacement de stockage : des catalogues de base de données, des produits de définition de schéma, des copybooks Cobol, des DTD ou XSD XML, des fichiers WSDL, des feuilles de calculs ou encore dans des systèmes de format de données propres à l'entreprise.

Dans l'exemple précédent, la structure du flux intermédiaire indiqué par "ASCII hiérarchique" pourrait être la suivante :

Le Co>Operating System et ses composants détectent automatiquement s'il est nécessaire de procéder à une conversion des formats. Lorsque, par exemple, des données décimales compressées et des données de type EBCDIC sont reçues par un composant qui envoie ses résultats dans une base de données Oracle, le composant va automatiquement convertir les données au format décimal et ASCII s’il s’agit du format des colonnes de la base de données.

Performances et évolutivité

Dès le départ, le Co>Operating System a été conçu dans le but d'offrir des performances et une évolutivité maximales. Chaque aspect du Co>Operating System a été optimisé afin de tirer le meilleur parti des ressources matérielles. Ce système répartissant naturellement les traitements entre différents réseaux de serveurs, il est inutile de mettre en place une technologie informatique de type "cloud".

Le Co>Operating System opère à une vitesse au moins 4 à 5 fois supérieure à celle des technologies les plus rapides du marché. Cela s’applique également aux programmes à codage manuel en Java et en C++ : difficile en effet de trouver un programmeur capable d'écrire un programme dont l'exécution serait aussi rapide qu'avec Ab Initio. Ce programmeur serait probablement le seul de l’entreprise à savoir programmer en Java ou en C++ et il passerait des semaines au codage manuel, alors que la solution Ab Initio ne prendrait que quelques jours. Généralement, de tels virtuoses sont vite sollicités pour la conception, l'architecture et même la gestion de projets.

Comment Ab Initio parvient-il à allier l’évolutivité aux performances ? Quels sont les éléments de base qui garantissent ce succès ? Les plus importants sont une conception adéquate de l'architecture et une attention sans faille au moindre détail. Les "principes premiers" de l'architecture du Co>Operating System ont pour objectif de mettre en place un environnement de traitement évolutif.

Le Co>Operating System s'appuie sur une architecture dite “sans partage”. Étant donné que ce système n’implique aucun partage au niveau des unités centrales, celles-ci peuvent ainsi fonctionner de manière totalement indépendante les unes des autres. Une application peut utiliser autant d'unités centrales que nécessaire sur le nombre de serveurs souhaité. Les fonctions du Co>Operating System permettent de répartir la charge de travail uniformément entre les différentes unités centrales, ce qui se traduit par l'évolutivité linéaire de la plupart des applications. Ainsi, si l’on double le nombre d’unités centrales, les performances sont multipliées par deux. L’ajout de dix unités centrales signifie des performances dix fois plus élevées. En combinant le parallélisme des données et le parallélisme de "pipeline", le Co>Operating System optimise les opportunités d'exécution simultanée de plusieurs éléments d'une application.

Le schéma qui suit montre comment une application peut partitionner les données de telle sorte que le composant Score puisse être exécuté en parallèle sur plusieurs unités centrales (et serveurs). Le composant Partition by Round-robin répartit équitablement les données client entre des flux, un peu à la manière d'un joueur distribuant des cartes. Le Co>Operating System exécute ensuite plusieurs instances du composant Score, chacune travaillant sur un seul flux de données. Chaque instance du composant Score génère un enregistrement, et le composant Interleave fusionne à nouveau les flux avant d’écrire le résultat dans le fichier de sortie.

Les architectures "sans partage" sont parfaites, pour peu qu'aucun goulet d'étranglement n’est en vue. Mais il suffit d'un seul pour compromettre l'ensemble du système. Cet aspect nécessite une attention toute particulière. Chaque point du système susceptible de générer un goulet d'étranglement en série doit être conçu et mis en œuvre minutieusement afin d'empêcher tout blocage potentiel. Les algorithmes de tous les composants doivent fonctionner de manière optimale quel que soit le scénario, et les canaux les plus efficaces doivent être utilisés pour la communication et le transport des données entre les partitions et les composants. Seule la prise en compte de ces éléments essentiels, et de bien d'autres, pourra garantir l'évolutivité linéaire du système.

L'exécution des règles métier est elle aussi un point crucial. Si le système a été correctement pensé, cette exécution devrait représenter la majeure partie du temps d'unité centrale. Dans le Co>Operating System, les règles métier sont exécutées par le moteur de transformation. Il s'agit d'un moteur de conception particulière, appelé "compilateur à la volée" ou "compilateur JIT". Il permet au Co>Operating System de compiler les règles métier au tout dernier moment, une fois que l'ensemble des informations les concernant est disponible. Ce fonctionnement "à la volée" apporte une très grande flexibilité et ce "compilateur" est fortement optimisé pour exécuter une logique métier traditionnelle avec des performances inégalées. C'est pourquoi il est si difficile pour un programmeur travaillant avec les technologies classiques de rivaliser avec le Co>Operating System.

Le modèle de traitement du Co>Operating System

Le Co>Operating System est un système de traitement distribué pair-à-pair, qui doit être installé sur chacun des serveurs impliqués dans l'exécution d'une application. Chaque serveur peut être doté d'un système d'exploitation différent (Unix, Linux et zLinux, Windows ou z/OS).

Voici comment le Co>Operating System gère un ensemble distribué de processus sur un réseau de serveurs :

Comment fonctionne le Co>Operating System
1.
Le Co>Operating System est démarré sur le serveur "principal" qui reçoit des définitions d'application, des structures, des règles logiques, des paramètres, …
2.
Le Co>Operating System démarre les "agents" sur les serveurs.
3.
Le processus principal indique à chaque agent les composants à exécuter sur ce serveur,
ainsi que toutes les informations nécessaires aux composants pour effectuer leurs tâches.
4.
Les agents démarrent les composants et leur indiquent les règles, structures, paramètres, etc.
5.
Les composants connectés par les flux de données commencent à traiter les données.
Les agents contrôlent le traitement.

1. Le Co>Operating System est démarré sur le serveur "principal" qui reçoit des définitions d'application, des structures, des règles logiques, des paramètres, ...

2. Le Co>Operating System démarre les "agents" sur les serveurs.

3. Le processus principal indique à chaque agent les composants à exécuter sur ce serveur, ainsi que toutes les informations nécessaires aux composants pour effectuer leurs tâches.

4. Les agents démarrent les composants et leur indiquent les règles, structures, paramètres, etc.

5. Les composants connectent les flux de données et commencent à traiter les données. Les agents contrôlent le traitement.

Une seule application Ab Initio peut être exécutée sur un seul serveur ou sur un réseau de serveurs. La définition de l'application, c'est-à-dire la représentation graphique spécifiée par le développeur, reste la même dans les deux cas. Lorsqu'une application est exécutée sur plusieurs serveurs, seule la spécification du "lieu" d'exécution de chaque composant change ; l'application en elle-même n'est pas modifiée. Il est donc possible de faire passer une application d'un mainframe à un serveur Unix, ou encore d'un seul serveur à un réseau de serveurs, sans aucune modification.

Le Co>Operating System fonctionne tout aussi bien sous Unix, Windows, Linux et zLinux, que sous z/OS. La même application peut être exécutée sur un système combinant plusieurs de ces plates-formes. Chacun des composants d'une application Ab Initio peut être exécuté sur toute plate-forme dotée du Co>Operating System (à l'exception de quelques composants très spécifiques, tels que l'accès VSAM sur des mainframes). La complexité du transfert des données entre les machines est totalement gérée par le Co>Operating System, garantissant ainsi un traitement intermédiaire entièrement transparent. Il est en outre possible de modifier l'affectation des composants aux machines cibles avant chaque exécution d'une application.

Un composant ou un groupe de composants peut être affecté à une ressource informatique différente :

Le Co>Operating System, une solution unique pour les traitements batch, les traitements en temps réel et les services Web

Les applications de traitements batch et temps réel répondent à des besoins très différents, et les technologies qu’elles utilisent ne sont pas les mêmes. Mais ces divergences s'effacent avec le Co>Operating System : son architecture unique s'adapte tout aussi bien aux systèmes de traitement batch et de traitement en temps réel qu'aux systèmes de services Web (SOA). Inutile de multiplier les technologies et les équipes de développement en fonction de chaque système, et d'avoir probablement plusieurs implémentations de la même logique métier : le Co>Operating System, couplé à la solution Continuous>Flows, offre une seule technologie, et donc une seule équipe de développement, ainsi qu'un codage unique de votre logique métier qui peut ainsi être réutilisé sur différents systèmes.

Avec le Co>Operating System, ce qui va différencier une application de traitement batch d'une application de traitement en temps réel est le type de données lues et écrites par l'application. Examinons l'illustration suivante. Il s'agit de la même application, d'abord présentée dans le cadre d'un traitement batch (avec des fichiers plats en entrée et en sortie), puis dans le cadre d'un système de file d'attente en temps réel (avec un composant MQ en entrée et un composant JMS en sortie). La troisième représentation illustre un service Web (avec des requêtes de service provenant d'un système externe et l'envoi des résultats à ce même système) :

Une application, plusieurs modes d'utilisation

1. Batch

2. Mise en file d'attente

3. Services Web.

Cliquez sur Continuous>Flows pour des informations supplémentaires.

Intégration des codes hérités

Ab Initio offre la possibilité de concevoir, de bout en bout, des applications via l'interface graphique du GDE et de les exécuter uniquement dans le Co>Operating System. Il est toutefois fréquent que les utilisateurs aient des applications existantes ou des produits tiers qui fonctionnent parfaitement et dont la réimplémentation ne semble pas nécessaire C'est pourquoi Ab Initio a souhaité faciliter la réutilisation des applications existantes, qu'il s'agisse de programmes codés en C, C++, Cobol, Java, de scripts shell, ou autres. Le Co>Operating System permet en effet d'intégrer ces applications dans des environnements pour lesquels elles n'ont pas été initialement conçues.

Pour être intégrés aux applications Ab Initio, les codes hérités sont transformés en composants dont le comportement est semblable à celui des autres composants Ab Initio. Dans la majorité des cas, cette transformation s'effectue sans difficulté : il suffit de spécifier les entrées et les sorties du programme ainsi que ses paramètres de ligne de commande. Le schéma qui suit explique comment un programme Cobol lisant et écrivant des fichiers plats peut être intégré à une application Ab Initio. Le code Cobol, ainsi que les Copybooks et JCL associés, sont transformés en composant Ab Initio ; celui-ci est placé dans une application Ab Initio qui est exécutée sur des serveurs Unix et un Mainframe, puis l'application se connecte aux différentes sources et cibles de données (SAS et base de données). Afin d'optimiser les performances, la charge de travail est partitionnée, ce qui permet l'exécution en parallèle de plusieurs instances du code Cobol.

Intégration de code hérité
Les utilisateurs collectent et ajoutent une gamme
de données Cobol, notamment :
Ce composant peut être connecté à tout
élément d'un graphe pris en charge par
Ab Initio.
Le même code COBOL fait maintenant partie d'un système
allant d'UNIX au mainframe, connecté à SAS et à un SGBDR.
UNIX
MAINFRAME

Robustesse extrême face aux problèmes de données

L'un des points sensibles dans la conception et la maintenance de système est la gestion de données imprévues ou erronées. C'est une situation fréquente, et lorsque de telles données s'infiltrent dans le système, le comportement de la plupart des applications en est altéré. Avec un peu de chance, l'exécution de l'application s'arrête. Mais si, par malchance, l'application parvient à traiter ces données erronées, il est fort possible que personne ne s’en aperçoive jusqu’à ce que les résultats contaminent les systèmes en aval. Il est alors très laborieux de remédier à la situation, ce qui affecte la productivité générale.

De par sa nature, le Co>Operating System présente une très forte résistance aux données erronées. Il contrôle en permanence les données afin de vérifier qu'elles sont conformes à différents critères spécifiés par le système et par l'utilisateur. En cas de non-conformité, les données ne peuvent pas continuer leur transit sans une certaine forme d'intervention. Le développeur peut aisément prévoir une opération et une génération de rapports automatisées dans l'application. Cette intervention peut être conçue en vue de corriger les données erronées et de les réintégrer dans le système, ou en vue d'isoler les entités concernées pour qu'elles puissent être traitées ultérieurement de manière plus cohérente.

Le schéma qui suit montre comment un développeur conçoit une application Ab Initio qui 1 récupère les données problématiques, 2 leur applique un ensemble de règles de "nettoyage", 3 renvoie les données nettoyées dans le processus initial, 4 isole les données n'ayant pu être nettoyées, puis 5 génère un rapport sur les données problématiques qui est 6 envoyé via une file d'attente MQ.

Tous les composants Ab Initio qui traitent des données en fonction d'intérêts particuliers peuvent être associés à des ports de rejet ("reject"), d'erreur ("error") et de journal ("log"). Le port "reject" récupère toutes les données problématiques, le port "error" reçoit un enregistrement décrivant chaque problème rencontré avec ces données et le port "log" est destiné aux informations de débogage. Il est ainsi possible de mettre en place des pipelines extrêmement robustes pour le traitement des données.

Robustesse extrême face aux défaillances système

Défaillance au niveau des serveurs, panne au niveau des réseaux ou chargement impossible des bases de données : plus le nombre de serveurs impliqués dans une application est élevé, plus les risques de défaillance système sont importants. Il est difficile de concevoir des applications dotées d'une capacité de récupération fiable après de tels incidents. De nombreux développeurs pensent pouvoir surmonter cette difficulté ; mais concrètement, une architecture ne peut être considérée robuste que si elle a prouvé sa résistance à bon nombre de défaillances. Ce processus est un long parcours semé d'embûches.

Le Co>Operating System, lui, a été conçu dès l'origine pour garantir une récupération fiable après ce type de défaillance. Dès lors que la configuration de l'environnement empêche toute perte de données essentielles, la fonctionnalité de redémarrage et de point de reprise du Co>Operating System permet de relancer une application à partir du point où elle a été interrompue avant l'incident, et ce même si l'application utilise plusieurs réseaux, serveurs et bases de données. Cette fonctionnalité concerne les applications batch ou en temps réel. Le Co>Operating System utilise un mécanisme de validation à deux phases dont les performances sont bien meilleures que celles du protocole standard XA. L’utilisation de ce protocole reste toutefois prise en charge par le Co>Operating System lorsque certains environnements le nécessitent, même en cas de multiples bases de données et technologies de file d’attente provenant de différents fournisseurs.

Le Co>Operating System optimise la productivité par ses fonctions de réutilisation.

Compte tenu de la nature des logiques métier qu'elles doivent résoudre, les applications Ab Initio peuvent se transformer en programmes complexes et de très grande envergure. On constate toutefois que la plupart des systèmes comportent certains éléments très similaires ou pour lesquels seules quelques variantes les différencient. Avec les technologies de programmation classiques, les développeurs n'ont souvent d'autre choix que de faire des copies de ces éléments et d'apporter des modifications mineures à chacune d'elles. Ces manipulations deviennent difficiles en termes de maintenance et nuisent véritablement à la productivité.

Les mécanismes proposés par Ab Initio permettent d'optimiser la réutilisation de ces éléments d'application. Des éléments de tous types peuvent être stockés dans le référentiel centralisé d'Ab Initio, l'EME® (Enterprise Meta>Environment), puis réutilisés dans toutes les applications. Voici par exemple ce que ce référentiel permet de stocker, de gérer et de réutiliser :

  • Des structures
  • Des règles métier et de logique
  • Des sections d'application (les applications étant les "graphes" et les sections les "sous-graphes")
  • L'orchestration des applications, c'est-à-dire « les plans » dans la solution Ab Initio Conduct>It.

La capacité de réutilisation offerte par Ab Initio est très performante. Les éléments d’application réutilisés peuvent rester associés à la version centralisée d'origine et l'on peut suivre les modifications qui y ont été apportées. Parallèlement, ils peuvent aussi faire l'objet de personnalisations locales.

L'exemple qui suit présente l'un de ces modules d'application réutilisables, à savoir le sous-graphe. Un sous-graphe contient les composants d'une sous-section d'une application (graphe). Aucune limite ne s'impose à la dimension ou à la complexité d'un sous-graphe, et les imbrications sont possibles. Les sous-graphes se comportent en tout point comme des composants classiques, et ils peuvent être enregistrés dans une bibliothèque en vue d'être réutilisés dans de nombreuses applications.

Le sous-graphe présenté ici correspond à la section de gestion des erreurs de l'application précédemment décrite :

Notez que les composants de ce sous-graphe ne sont pas explicitement reliés à des composants d'entrée ou de sortie. Ils sont en revanche connectés aux ports d'entrée et de sortie du sous-graphe “Standard Error Handling Process”.

Voici à présent la même application, mais conçue cette fois avec le nouveau sous-graphe réutilisable de gestion des erreurs (les sous-graphes sont visuellement identifiés dans le GDE par une bordure externe supplémentaire) :

Conclusion

Le Co>Operating System est le logiciel de base de l'architecture Ab Initio. Tous les concepts essentiels de cette architecture sont repris dans le Co>Operating System. Toutes les technologies développées par Ab Initio étant liées au Co>Operating System, il en résulte une solution cohérente et parfaitement intégrée.

Voici les avantages que présente cette architecture :

  • Les systèmes d’application peuvent être entièrement conçus de manière graphique, sans recours au codage traditionnel.
  • Les équipes en charge du développement technique et de la maintenance sont plus productives dans un "contexte graphique" que dans un environnement de programmation classique.
  • Les équipes techniques répondent plus rapidement à l'évolution des besoins métier.
  • Les applications sont plus transparentes et donc plus simples à comprendre pour les utilisateurs métier et les analystes.
  • Les systèmes d’applications sont nettement plus robustes : leur évolutivité est sans limite, ils sont compatibles avec de nombreuses plates-formes, ils peuvent traiter tout type de données complexes, ils peuvent mettre en œuvre des règles métier extrêmement compliquées et leur robustesse face aux problèmes de données et aux incidents système est excellente.
  • La logique métier peut être réutilisée dans des applications de traitement batch, en temps réel et de services Web.

Tous ces avantages sont rendus possibles par la nature même du Co>Operating System, qui a été conçu dès le départ avec une architecture unique destinée à produire de tels résultats.

English
Langue :
Français
Español
Deutsch
简体中文
日本語