Comment utiliser les extensions DI-production

DI-Production est un outil visuel pour développer des scripts de production. Ces scripts vous aident à automatiser les processus simples ou complexes tels que :

• l'extraction de données,
• la transformation de données,
• le chargement de données,
• le déplacement de fichiers,
• la création de modèles de données.

Comment faire si la tâche à automatiser ne fait pas partie des standards proposés ? Comment s'assurer que tous les salariés utilisent la même solution pour une tâche déterminée? Les extensions DI-production interviennent à ce moment-là.

Les scripts DI-Production

Dans les versions les plus récentes de Diver, DI-Production est intégrée à Workbench. Dans les scripts de production, il existe deux types principaux de nœuds:

• les noeuds de processus qui exécutent des fonctions prêtes à l'emploi, telles que Builder, Integrator, Copy, Delete et FTP ;
• les nœuds de contrôle qui contrôlent le flux logique du script

En complément, il existe des nœuds de processus personnalisés par l'utilisateur : ce sont les extensions. Elle peuvent contenir n'importe quel code et l'exécuter sur votre serveur DiveLine. C'est particulièrement utile si vous avez un morceau de code générique que vous voulez réutiliser encore et encore et conserver à un seul endroit.

Exemple de script de production

Voici un exemple de script de production (Voir Figure 1) :

1. Il commence par un noeud "Démarrer", comme tous les scripts.
2. Puis un noeud conditionnel détermine si certaines conditions sont remplies : par exemple si un fichier existe ou si un paramètre contient une certaine valeur. Si les conditions ne sont pas remplies, le script se termine. Si toutes les conditions sont remplies, le script continue.
3. Le script se dirige vers un noeud de processus Integrator.
4. Puis il enchaîne vers un noeud de script de génération Specter.
5. Ensuite, un second nœud conditionnel vérifie si les nœuds Integrator et Specter ont été exécutés avec succès. Si c'est le cas, le script se termine avec succès. Sinon, le script échoue et envoie une alerte par email.

FIGURE 1 - Exemple de script de production

Le défi : déployer un script de production

Votre script est prêt à être déployé. Comment faire?

Prenons l'exemple d'un de nos clients en Europe. Il développe des scripts dans un environnement de développement. Son problème? comment gérer le code statique et la configuration du script? Le code du script est toujours exactement le même, mais la configuration diffère selon l'environnement. Par exemple, une configuration en développement peut être définie pour charger une quantité limitée de données tandis que la production doit traiter la totalité des données . Autre exemple, en développement, la configuration peut envoyer des alertes d'échec à une adresse email personnelle alors qu'en production, l'adresse email doit alerter une équipe.

De même, lors d'un test en développement, le nœud conditionnel peut avoir besoin de vérifier différentes conditions mais en production, la valeur du paramètre est probablement différente.

En résumé, vous voulez que votre code testé et confirmé en développement, corresponde aussi à l'environnement de production. Par conséquent, l'objectif est de créer du code statique et stable puis de le déployer et de gérer les différentes configurations dans tous les environnements.

Exemple: extension de configuration dynamique pour gérer les configurations d'environnement

Pour conserver un même code dans plusieurs environnements, de nombreuses solutions utilisent le contrôle de version. Vous pouvez ainsi envoyer du code statique au référentiel central à partir du développement, puis extraire le code du référentiel central vers les autres environnements, par exemple pour tester l'acceptation et la production. De cette façon, vous pouvez déployer des modifications ou les annuler si besoin (Voir la figure 2).

FIGURE 2 - Contrôle de version


Ce modèle fonctionne sans problème pour le code statique, mais qu'en est-il de la configuration, représentée en couleur dans le diagramme, qui est différente pour chaque environnement? Comment chaque environnement va choisir sa propre version de la configuration?

Une solution consiste à charger la configuration entière dans le référentiel central et à la distribuer dans chaque environnement avec le code statique. Ensuite, chaque environnement sélectionne de manière dynamique la bonne configuration (Voir Figure 3). Cette solution est implémentée en utilisant une extension DI-Production appelée DynaCon, l'abréviation de Dynamic Configuration Selector.

Figure 3: Contrôle de version des codes et de la configuration avec sélection dynamique

Vue d'ensemble de l'extension DynaCon

Comment fonctionne DynaCon? Un fichier de configuration contient toutes les entrées pour tous les environnements. Pour chaque environnement, la première colonne contient le nom de l'environnement, la deuxième colonne contient une clé et la troisième colonne contient une valeur. Dans la deuxième colonne, les clés référencées dans le code sont toutes les mêmes. Dans la troisième colonne, les valeurs clés sont spécifiques à l'environnement (Voir Figure 4).

Figure 4: Fichier de configuration DynaCon

Pour utiliser l'extension DynaCon, constituée d'un seul bloc de code, faites simplement glisser l'extension dans le panneau Flux du script (Voir Figure 5). Spécifiez le fichier de configuration en entrée et un emplacement pour enregistrer le fichier de résultats en sortie.

Figure 5: Extension DynaCon dans un script de production

Un script de production exécuté à partir d'une extension ne peut pas définir de paramètres. Vous devrez donc charger les résultats dans les paramètres. Pointez l'objet « Parameter » vers la sortie générée par DynaCon et créez des marqueurs (Voir Figure 6). Chaque fois que le script s'exécute, il exécutera tous ces nœuds.

Figure 6: Paramètres de passage du script de production DynaCon

Maintenant, un même code s'exécute dans différents environnements et définit différents paramètres à la volée (Voir Figure 7). L'extension rend dynamique la sélection des paramètres au sein de différents environnements et il est ainsi très facile d'utiliser l'extension là où vous en avez besoin.

Figure 7: Sortie de DynaCon dans l'environnement de développement

L'extension DynaCon en détail

Dans Diver version 7, vous pouvez utiliser des projets dans Workbench pour organiser votre code. L'extension DynaCon est dans un de ces projets appelé "extensions" où le client développe et maintient toutes les extensions.

Chaque extension a un identifiant global unique. En outre, chaque extension possède un fichier config.xml qui définit les propriétés de l'extension telles que son type et le script exécuté en premier lieu. Dans cet exemple de DynaCon, il s'agit d'un type de production et le premier script qui s'exécute s'appelle DynaCon.prd (Voir la figure 8).

Figure 8: Fichier de configuration DynaCon

Vient ensuite le script de production DynaCon.prd. Exécuté dans l'environnement Microsoft Windows, DynaCon.prd capture la variable % COMPUTERNAME%, qui est différente sur chaque serveur, et la mappe à un environnement qui correspond à une entrée dans le fichier de configuration. Ensuite, DynaCon exécute un script Integrator (Voir la figure 9).

Figure 9: Script de production DynaCon

Vient ensuite DynaCon.int, le script de l'intégrateur, qui permet de définir les valeurs de paramètre pour l'environnement. Il charge le fichier de configuration spécifié, compare le nom d'ordinateur à la table de recherche locale, filtre uniquement les valeurs de résultat correspondant à l'environnement défini et enregistre le résultat dans le fichier de sortie spécifié (Voir la figure 10).

Figure 10: Script de l'intégrateur DynaCon

Voyons comment faire fonctionner DynaCon!

Rappelons que le script intégrateur peut être n'importe quel code!

Compiler et installer une extension

Les extensions doivent être compilées et installées avant leur utilisation. C'est très simple. Pour compiler, allez dans le répertoire où se trouve la base du code d'extension, compressez les fichiers avec un utilitaire tel que 7-zip (voir Figure 11) et renommez le fichier ainsi compressé (.pre pour un fichier de production, voir Figure 12).
Il existe un répertoire avec l'identifiant global unique de chaque extension , qui contient les fichiers suivants:

• prd, le script de production
• int, le script intégrateur
• png, un fichier d'icône
• xml, le fichier de configuration
• autres fichiers à inclure dans la compilation

installation de l'extension

Depuis la version 7 de Diver, vous installez les extensions à partir de Workbench.
Connectez-vous au serveur Diver et allez dans Outils> Paramètres du serveur. Cliquez sur l'onglet Avancé. Dans la section Extensions, il y a une icône en forme de puzzle avec un petit signe + (Voir Figure 13). Lorsque vous cliquez sur cette icône, vous obtenez une boîte de dialogue pour parcourir vos fichiers .pre. Sélectionnez celui que vous voulez installer. Cliquez sur Ouvrir et le fichier .pre installe et crée l'extension.

Une fois installées, vos extensions sont immédiatement prêtes à être utilisées dans DI-Production (Voir Figure 14).


Remarque : lors de l'installation des extensions, si vous effectuez une mise à niveau vers une nouvelle version mais que vous n'avez pas modifié le numéro de version, vous pouvez recevoir un message d'avertissement: "Une version plus récente ou la même version de l'extension avec GUID xxx est déjà installée. Voulez-vous forcer l'installation ? ". Cela vous empêche d'écraser par inadvertance votre extension. Cliquez sur "Oui" pour continuer, ou cliquez sur "Non" pour réviser le numéro de version de l'extension. Utilisez l'éditeur d'extension dans Workbench sous Outils> Editeur d'extensions pour apporter des modifications.

Pour plus d'informations sur les extensions

consultez les rubriques d'aide de Workbench en ligne. En particulier, pour obtenir des instructions pas à pas sur la mise à jour des extensions, telles que la modification du numéro de version, reportez-vous à la section relative à la mise à jour des extensions de production.

Quelques exemples d'utilisation de l'extension

DynaCon n'est qu'un exemple d'extension créée pour résoudre un problème et rendre le code disponible pour une réutilisation. Comme DynaCon, les extensions sont utiles là où vous avez un code générique que vous voulez rendre facile à réutiliser.
Voici d'autres exemples que nous allons détailler: extraction de données, envoi d'email, récupération des données du site Web, mise en pause d'un script.

• Exemple: extraction de données

Notre client utilise une extension pour collecter des données XML à partir de services Web. l est facile d'y connecter un nouveau site ou de modifier l'extension existante. Cela simplifie beaucoup le codage et fonctionne pour tout système avec des données basées sur XML.

• Exemple: envoi d'email

Les extensions DI-Production constituent un excellent moyen d'envoyer des e-mails d'alerte en cas de problème. Vous pouvez également recevoir des e-mails à mi-chemin d'un flux, par exemple pour sélectionner un fichier et l'envoyer à un groupe de destinataires. Une extension d'envoi d'email peut effectuer ces actions de manière conditionnelle à tout moment du processus, enregistrer des pièces jointes ou générer des listes de destinataires dynamiques.

• Exemple : récupération de données à partir de services Web

Pour rationaliser les opérations, notre client devait trouver un moyen standardisé d'extraire les données d'un grand système de base de données transactionnelle pour plusieurs systèmes en aval. Les données extraites devaient correspondre exactement aux transactions. Pour cela, le client a construit une extension appelée MaX qui garantit que 100% des données arrivent sans doublon et sans perte. L'extension n'a jamais échoué depuis 2 ans avec sans doute plus d'un milliard d'enregistrements extraits.

• Exemple : mise en pause d'un script

Enfin, vous pouvez parfois avoir besoin de mettre en pause votre script pendant un certain temps ou jusqu'à une heure spécifique de la journée . Notre client a construit une extension pour les scripts qui nécessitaient cette capacité de temporisation. L'extension est configurable pour arrêter le script soit pendant X secondes soit jusqu'à une certaine heure spécifiée HH: MM: SS. Cette extension peut être utilisée pour gérer les goulots d'étranglement des ressources ou pour d'autres raisons.

 

Résumé

Ces extensions sont très puissantes et offrent des possibilités infinies : elles peuvent empêcher la duplication de code, accélérer rapidement vos efforts de développement et rendre simples les opérations complexes.
Quand vous construisez une fonctionnalité commune, avez-vous besoin de le répéter souvent? Voulez-vous résoudre ce problème de manière générique? Cela vaut-il la peine de transformer cette opération en extension? Si les réponses sont oui, n'ayez pas peur. La création et l'utilisation d'extensions peuvent faire partie des compétences de votre équipe de développement pour standardiser le code et rationaliser le développement.