Conception de Jobs, de Routes ou de Services de données

Standards de nommage

Dans le Studio, définissez une convention de nommage pour les Jobs, les Routes ou les Services de données et les dossiers et respectez-la.

Dans ce document, la convention de nommage est la suivante, mais n'hésitez pas à l'adapter selon vos besoins : préfixes job_|route_|service_ pour les noms des Jobs, Routes et services de données respectivement, préfixe test_ pour les noms des Test Cases, préfixe pub_ pour les noms des tâches de publication et préfixe task_ pour les noms des tâches d'exécution.

Par exemple, nommez votre dossier xxx. Les dossiers doivent être utilisés pour regrouper des Jobs d'un type similaire. Créez ensuite un Job nommé job_xxx_description et son scénario de Test nommé test_xxx_description.

À un niveau plus granulaire, les composants du Job devraient également avoir un nom significatif.

Au niveau du projet, nommez votre projet en utilisant des majuscules, sinon le build échoue.

Contrôle des versions

Utilisez les branches et tags Git ainsi que le Studio pour gérer les versions des artefacts.

Pour plus d'informations concernant comment modifier la version de vos artefacts de façon centralisée et en une seule fois afin de les publier avec la version de votre choix, consultez Modifier la version de déploiement de chaque artefact en une fois.

Project identifier

Lorsque vous vous connectez au projet pour la première fois dans le Studio, modifiez les paramètres du Studio afin de configurer l'identifiant du projet (groupID) qui sera utilisé lors du déploiement.

Pour plus d'informations concernant l'identifiant de ce projet, consultez Changer l'identifiant de déploiement du projet en une seule opération.

Métadonnées

Utilisez les métadonnées de schéma dans vos Jobs, Routes ou Services de données pour partager les connexions aux bases de données entre plusieurs artefacts et aider à la conception des composants sources/cibles.

Contextes

Utilisez les contextes afin de réutiliser les variables (paramètres de contexte localement pour les artefacts, groupes de contextes globalement pour les projets), comme la connectivité aux bases de données, les noms des hôtes, les numéros de ports, etc. Si les valeurs nécessitent modification ou sont utilisées plusieurs fois, alors elles ne devraient pas être codées en dur et il est recommandé d'utiliser des contextes.

Ces contextes sont également utilies pour passer d'un environnement à un autre (contexte de Développement, puis de QA, puis de Production).

Disposition standard des Jobs

Utilisez une disposition standard pour assurer la lisibilité des Jobs, particulièrement importante lors d'un travail collaboratif.

Voici quelques exemples : aligner les flux de données de gauche à droite, présenter le flux de processus entre les sous-Jobs du haut vers le bas, les composants cible à droite, etc.

Complexité

Les Jobs doivent suivre une logique et, si nécessaire, être divisés en étapes, nommées sous-Jobs. Il est également recommandé d'utiliser des Jobs parents pour exécuter un Job enfant (ou plusieurs) afin de créer un flux de processus, et bien qu'il n'y ait aucune limite, évitez d'utiliser plus de 20 composants dans un Job.