Vue d'ensemble de l'exportation et de l'importation

Qu'est-ce que la modularité des actifs ?

La modularité des actifs se réfère à la capacité de transférer des actifs entre les comptes ou les instances de Tulip. Cette fonctionnalité est cruciale pour les industries réglementées, les clients avec des déploiements Tulip globaux, et plus encore.

Le transfert d'actifs entre les sites permet au travail effectué par un site d'être partagé entre tous les sites, réduisant ainsi le temps nécessaire pour créer de la valeur avec Tulip.

Où Tulip exploite-t-il la modularité des actifs ?

Typiquement, nous considérons la modularité des actifs dans le contexte de l'exportation et de l'importation des applications, mais cette fonctionnalité est utilisée dans l'ensemble du produit.

La Bibliothèque Tulip, Enterprise App Exchange, et App Export & Import sont les domaines les plus importants où cette fonctionnalité est utilisée. Certains actifs, tels que les connecteurs, peuvent être déplacés indépendamment d'une application ou d'une automatisation.

Principes fondamentaux

Les applications et les automatismes ne fonctionnent pas de manière isolée ; ils s'appuient sur divers actifs. Un automatisme peut dépendre d'un connecteur, ou une application peut dépendre d'une machine. Ces composants de support sont connus sous le nom de dépendances.

Lorsqu'une application est exportée, ses dépendances sont collectées et exportées avec elle. Cependant, toutes les dépendances ne sont pas incluses dans l'exportation.

Cette documentation a pour but de définir le comportement attendu de chaque dépendance d'une application Tulip, ainsi que les actions requises après une exportation.

Dépendances

Généralement, les dépendances sont des composants qui peuvent être partagés entre les applications ou les automatismes et qui peuvent être explicitement référencés dans une application ou un automatisme. Cela inclut : * Connecteurs * Machines * Utilisateurs * Analyses * Tables * Etc.

Exportation

Qu'est-ce qui est utilisé?

Lors de l'exportation, il est essentiel d'évaluer quels actifs sont utilisés dans une application ou une automatisation et devraient être exportés avec elle. Il existe des règles complexes régissant l'exportation de certains actifs avec une application.

L'importation

Lors de l'importation, l'objectif est d'éviter de dupliquer les dépendances si l'actif existe déjà sur le site d'importation. Au lieu de cela, l'actif existant dans le site cible est utilisé, à condition que l'actif dans les sites source et cible soit fonctionnellement identique.

Cela soulève deux questions fondamentales auxquelles il faut répondre pour chaque ressource :

Qu'est-ce qui est identique?

Lorsqu'un bien est importé, nous vérifions s'il existe déjà dans l'instance cible. Les règles définissant l'égalité varient en fonction du bien.

Considérons le scénario suivant : 1. Le connecteur A avec la fonction A est exporté puis importé dans le site 2. 2. Le connecteur A, fonction A, est modifié pour ajouter une autre entrée. 3. Le connecteur A est à nouveau exporté et importé sur le site 2. 1. Le connecteur A est-il le même ? Oui, aucune modification du comportement n'a été apportée au connecteur. 2. La fonction A est-elle la même que lors de sa dernière importation ? Non, elle a une nouvelle entrée et une nouvelle fonction doit donc être créée.

Que faire si l'on trouve la même chose ?

Si une correspondance est trouvée, la question suivante est de savoir ce qu'il faut faire. Comme principe de base, Tulip respecte toujours la configuration de l'instance cible (importateur) par rapport à l'instance source (exportateur).

Flux d'importation d'applications

Plus d'informations

Les documents suivants fournissent des informations détaillées sur la façon dont chaque actif est traité pendant l'exportation et l'importation :

• Import Export - Connecter les fils
• Tableau Import Export
• Importation de connecteurs et de fonctions de connecteurs