Repos_copy est une interface de ligne de commande permettant de gérer les composants d'intégration et les référentiels InterChange Server. Cette commande vous permet de déployer un module, jeu de composants d'intégration, sur un référentiel de serveur ou d'exporter des composants du référentiel vers un module.
Repos_copy permet également de migrer des composants de versions plus anciennes vers la version en cours. Si vous utilisez des composants d'ancien format, faites d'abord migrer vos composants. Pour plus d'informations, consultez le guide d'installation de WebSphere Business Integration Server Express pour Windows, pour Linux ou pour OS/400 et i5/OS. Repos_copy ne prend pas en charge les options "-ar, -arp, -vr, -vp -xCompilePackage" et comporte des limitations pour "-o" et toutes les options -xCompile en cas d'utilisation de composants d'anciens formats.
Pour exécuter repos_copy, entrez la commande dans une fenêtre d'invite de commande MS-DOS (Windows) ou à une invite shell (Linux). Sous OS/400 et i5/OS, entrez la commande QSH dans la ligne de commande puis, à partir de l'environnement QSHELL, exécutez le script repos_copy.sh. Le répertoire RépProduit/bin, où se trouve l'utilitaire, doit être dans la variable d'environnement PATH après l'installation. Sous OS/400 et i5/OS, le script se trouve dans le répertoire /QIBM/ProdData/WBIServer44/bin par défaut.
Le présent chapitre comporte les sections suivantes :
Pour plus d'informations sur la sauvegarde du système, voir WebSphere InterChange Server: Guide d'administration du système.
Le tableau 14 décrit les options de repos_copy et leurs arguments ; il montre également l'utilisation de la casse correcte pour les options et l'absence d'espace entre l'option et son argument. La syntaxe montre que les options entre accolades ({}) représentent un ensemble d'options dont au moins une est requise. Si vous n'indiquez pas les options -u, -p, -i, -o ou -s en ligne de commande, repos_copy vous les demande. Si vous ne répondez pas à l'invite, repos_copy ne s'exécute pas. Les options entre crochets ([]) sont facultatives.
Syntaxe : repos_copy [-sNom_serveur][-unom_utilisateur][-pmot_passe] | [-inom_fichier [-ai| -ar| -arp] [-k] [-ncENCODING] [-xcompilepackage] [-xdi] [-xdn][-r[[Nom_relation1[:Nom_relation2]: ...]|*] ]| [-onom_fichier_JAR [-xnoclasses]] | [-eentityType:nom_entité1[+entityType:nom_entité2]+... [-deep] [-oJARfilename] ] [-fentityfilename [-deep] [-oJARfilename] ] | [-xCompileAll [-wi] ] | [-xCompileAllCollabs [-wi]] | [-xCompileAllMaps [-wi] ] | [-xCompileCollab:Nom_modèle1[+Nom_modèle2]+...[-wi] ] | [-xCompileMap:Nom_mappe1[+Nom_mappe2]+... [-wi] ] | [-mode] | [-d] | [-doentityType:nom_entité1[+entityType:nom_entité2]+... [-deep] | [-dfoentityType:nom_entité1[+entityType:nom_entité2] -deep] | [-summary [-oXML_nom_fichier] ] | [-vp [-iJAR_nom_fichier] ] | [-vr]
Option | Description |
---|---|
-ai |
Ignorer et ne pas charger les objets dupliqués (objets métier, mappes, relations, modèles et objets de collaboration et connecteurs) trouvés lors du déploiement d'un module. |
-ar |
Remplacer les objets dupliqués (objets métier, mappes, relations, modèles et objets de collaboration et connecteurs) trouvés lors du déploiement d'un module. |
-arp |
Remplacer les composants dupliqués. Il s'agit d'une version interactive de l'option -ar. Si les composants du module en cours de déploiement existent déjà dans le référentiel, le système vous invite à ignorer ou remplacer le composant. |
-d |
Supprimer les composants dans le référentiel, à l'exception des données d'état. Cette option vous permet de supprimer tous les composants du référentiel. |
-deep |
Utilisez avec l'option -e pour inclure tous les composants dépendants. Si vous omettez l'option -deep, seul le composant spécifié par l'option -e est inclus. |
-dfoType_Entité:Entité[+Type_Entité:Entité2] |
Force la suppression du composant même si le composant comporte des référents dépendants. Cette option fonctionne uniquement sur le référentiel d'un serveur s'exécutant en mode conception. Un serveur s'exécutant en mode production n'autorise pas les dépendances et les références non résolues. Voir aussi l'option -do. |
-doType_Entité:Entité[+Type_Entité:Entité2] |
Indiquez les entités à supprimer du référentiel. Voir le tableau 15 pour connaître la liste des types et mots clés d'entité. Si l'objet n'a pas de référent, composant dépendant, la suppression est effectuée. Si l'objet comporte des référents, la suppression échoue et un message apparaît. Le comportement est identique en mode conception et en mode production. Pour plus d'informations sur le démarrage du serveur en mode conception ou en mode production, voir le Guide d'implémentation du système. |
-eType_Entité:Entité1[+Type_Entité:Entité2...] |
Exporter une ou plusieurs entités de première classe référencées. Une entité de première classe est un objet métier, un objet de collaboration, un modèle de collaboration, un connecteur, un pool de connexions de base de données, une mappe ou une relation. Vous identifiez l'entité à charger ou décharger en indiquant l'un des mots clés mentionnés dans le tableau 15. Faites suivre le mot clé Type_Entité du signe deux-points (:) et du nom de l'entité. Utilisez le signe "+" pour indiquer plusieurs entités. Associée à l'option -o, l'option -e décharge les données dans un fichier de sortie. |
-fFichier_entité |
Similaire à l'option -e, mais utilise les noms des entités du fichier Fichier_Entité. Le fichier doit contenir des références aux entités, avec les conditions suivantes :
Associée à l'option
|
-inom_fichier |
Déployer le fichier de module spécifié sur le référentiel. Si vous omettez d'indiquer la valeur du nom du fichier d'entrée, la commande vous invite, de manière interactive, à entrer le nom du fichier d'entrée. Il peut s'agir d'un fichier .jar contenant des objets au format XML ou d'un fichier .in contenant des objets au format texte. Les fichiers .jar créés par repos_copy ou System Manager ont une structure spécifique qui doit être actualisée afin que les importations des fichiers de ce type aboutissent. Vous ne devez donc pas modifier un fichier d'entrée manuellement. |
-k |
Remplacer le comportement par défaut de repos_copy lorsque cette commande détecte une mappe Mercator dans le fichier de module qu'elle charge. Par défaut, repos_copy s'arrête lorsqu'elle détecte une mappe Mercator. Si vous utilisez l'option -k, repos_copy ne tient pas compte des mappes Mercator du fichier de module et poursuit le processus de déploiement. |
-mode |
Renvoyer le mode du serveur. Pour plus d'informations sur les modes d'InterChange Server Express, voir WebSphere InterChange Server: Guide d'implémentation pour WebSphere InterChange Server. |
-ncencoding |
Consultez la documentation Java relative à la classe String pour connaître la liste des codages de caractères corrects. Lors du déploiement d'un référentiel créé à l'aide d'InterChange Server Express version 4.1.1, indiquez le codage de caractères utilisé dans l'environnement 4.1.1. |
-onom_fichier_sortie |
Exporter les composants du référentiel vers le fichier de module indiqué. Vous devez indiquer le nom du fichier de module. Si le fichier existe déjà, la commande repos_copy vous demande si vous souhaitez le remplacer ou non. Le fichier de sortie est au format .jar et contient les définitions de composant au format XML ainsi que les fichiers source .java pour les composants associés. Vous ne pouvez pas utiliser cette option avec les options -i ou -d ni l'utiliser pour exporter des composants au format texte, comme dans les éditions précédentes. Repos_copy n'ajoute pas l'extension .jar, vous devez donc la préciser lorsque vous indiquez le nom du fichier de sortie. |
-pmot_de_passe |
Indique le mot de passe correspondant au nom d'utilisateur fourni avec l'option -u. Ce mot de passe respecte la distinction majuscules/minuscules. Si vous n'indiquez pas cette option, repos_copy vous invite à entrer un mot de passe. |
-r* |
Importer des définitions de relation et ne pas créer les diagrammes d'exécution correspondants. Voir aussi l'option -r. |
-rNom_relation1[:Nom_relation2] |
Charger la ou les définitions de relation désignées dans le référentiel sans créer de diagramme d'exécution correspondant. |
-sNom_serveur |
Spécifiez le nom de l'instance d'InterChange Server Express dont repos_copy doit être l'interface. Ce nom respecte la distinction majuscules/minuscules. Si vous n'indiquez pas de nom de serveur, l'utilitaire vous invite à entrer un nom. |
-summary |
Répertorier les composants du référentiel du serveur (ils sont identifiés en tant qu'"artefacts" plutôt que comme composants dans la sortie). La sortie est au format XML. Vous pouvez associer cette option à l'option -o pour imprimer la sortie dans un fichier plutôt que sur la console. |
-unom_utilisateur |
Indiquez le nom d'utilisateur pour la connexion à InterChange Server Express. Si vous n'indiquez pas de nom, repos_copy vous invite à le faire. |
-v |
Imprimer le numéro de version du programme exécuté par l'utilitaire repos_copy. |
-vp |
Valider un fichier de module. Le serveur valide les modules en les comparant au référentiel et vérifie que les dépendances entre les composants du module sont résolues. En cas d'échec de la validation, repos_copy imprime la liste des dépendances manquantes. Cette option ne modifie pas le référentiel ; elle ne fait que valider le fichier de module. Avec l'option -vp, vous devez également utiliser l'option -i pour indiquer le fichier de module à valider. |
-vr |
Valider le référentiel. Le message de sortie indique si la validation a abouti ou non. En cas d'échec de la validation, repos_copy imprime la liste des dépendances manquantes. |
-wi |
Ne pas afficher les messages d'avertissement générés pendant la compilation des modèles ou des mappes de collaboration. Seules les erreurs de compilation sont affichées. Cette option permet à l'utilisateur de ne pas tenir compte des avertissements relatifs aux méthodes déconseillées, par exemple. |
-xCompileAll |
Compiler tous les modèles de collaboration et toutes les mappes du référentiel. |
-xCompileAllCollabs |
Compiler tous les modèles de collaboration du référentiel. |
-xCompileAllMaps |
Compiler toutes les mappes du référentiel. |
-xCompileCollab:Nom_Modèle_collab[+Nom_Modèle_collab] |
Compiler les modèles de collaboration spécifiés du référentiel. |
-xCompileMap:Nom_Mappe_native[+Nom_Mappe_native] |
Compiler les mappes spécifiées du référentiel. |
-xCompilePackage |
Indique au serveur de compiler les fichiers Java de mappe et de modèle de collaboration. Si le module contient des fichiers de classe précompilés, n'utilisez pas cette option. En mode production, sauf si tous les fichiers de classe sont dans le module, cette option est sélectionnée par défaut. Pour une description complète des modes InterChange Server Express, consultez le Guide d'implémentation du système. |
-xnoclasses | Détermine si des fichiers de classe doivent être inclus lors de l'exportation de composants depuis le serveur. |
-xdi<chemin_fichier_descripteur_déploiement> |
Cette option utilise le descripteur de déploiement spécifié à la place de la valeur par défaut dans le fichier du référentiel. Pour une description complète des modes InterChange Server Express, consultez le Guide d'implémentation du système. |
-xdn |
Cette option ignore le fichier .dfg dans le fichier .jar du référentiel et envoie le package de déploiement au serveur sans modifier les valeurs des propriétés. Pour une description complète des modes InterChange Server Express, consultez le Guide d'implémentation du système. |
-xmsp |
Cette option permet l'importation et l'exportation de données d'appartenance et de sécurité, d'où la possibilité d'effectuer une mise à niveau sans avoir à recréer les règles relatives aux rôles et à la sécurité. Pour obtenir une description complète des modes InterChange Server, consultez le Guide d'implémentation du système. |
Type d'entité | Mot clé |
---|---|
Objet métier | BusObj |
Objet de collaboration | Collaboration |
Modèle de collaboration | CollabTemplate |
Pools de connexions à une base de données | ConnectionPool |
Connecteur | Connector |
Mappe | Map |
Relation | Relationship |
Cette section décrit la plupart des situations courantes dans lesquelles vous pouvez utiliser repos_copy. Elle contient les sections suivantes :
Vous pouvez exécuter repos_copy sans argument pour afficher la commande et ses arguments. L'exemple ci-après montre la commande repos_copy exécutée sans argument et la sortie de résultat :
Aucun argument de ligne de commande de ReposCopy n'a été spécifié Syntaxe : repos_copy [ [-sNom_Serveur] [-uNom_Utilisateur] [-pMot_de_passe] ] | [-iNom_Fichier [-ai| -ar| -arp] [-k] [-ncEncoding] [-xcompilepackage] [-xdi] [-xdn] [-r[[Nom_relation1[:Nom_relation2]: ...] |
*] ] | [-oNom_fichier_JAR [-xnoclasses]] | [-eentityType:Nom_Entité1[+entityType:Nom_Entité2]+... [-deep] [-oNom_Fichier_JAR] ] | [-fENTITYFILENAME [-deep] [-oNom_Fichier_JAR] ] | [-xCompileAll [-wi] ] | [-xCompileAllCollabs [-wi]] | [-xCompileAllMaps [-wi] ] | [-xCompileCollab:Nom_Modèle1[+Nom_Modèle2]+... [-wi] ] | [-xCompileMap:Nom_Mappe1[+Nom_Mappe2]+... [-wi] ] | [-mode] | [-d] | [-doentityType:Nom_Entité1[+entityType:Nom_Entité2]+... [-deep] | [-dfoentityType:Nom_Entité1[+entityType:Nom_Entité2] -deep] | [-summary [-oXML_Nom_Fichier] ] | [-vp [-iNom_Fichier_JAR] ] | [-vr]
Vous pouvez valider un module de composants avant de déployer ce module sur un serveur. Cette opération est très utile car lorsque vous déployez un module sur un serveur en mode production, toutes les dépendances doivent être résolues, faute de quoi le déploiement échoue. Vous ne pouvez pas valider un projet utilisateur ou une bibliothèque de composants d'intégration dans System Manager pour vous assurer que les dépendances sont résolues ; par conséquent la seule façon de vérifier la validité d'un module lors du déploiement avec System Manager est de tenter le déploiement et, en cas d'échec, de résoudre les dépendances à l'aide des informations sur les erreurs. Si le module contient de nombreux composants, ce processus peut être très long.
Si vous ne pouvez pas valider une bibliothèque de composants d'intégration, vous pouvez toutefois l'exporter dans un fichier de module, puis valider ce fichier à l'aide de la commande repos_copy.
Pour valider un fichier de module à l'aide de repos_copy, spécifiez le nom du fichier de module à valider à l'aide de l'option -i et validez le fichier sans le déployer à l'aide de l'option -vp.
Par exemple :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -vp
Repos_copy valide le contenu du module et affiche un message pour indiquer si les dépendances sont résolues ou non.
L'option -i vous permet de déployer un module de composants sur le référentiel. Si vous n'indiquez pas le nom du fichier de module, la commande vous demande de le préciser.
L'exemple suivant illustre le déploiement du fichier WebSphereICS420DEVServer.jar sur un référentiel :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar
Si un module contient des fichiers Java de modèle de collaboration ou d'implémentation de mappe, mais ne contient pas de fichiers de classe associés, utilisez l'option -xcompilepackage lors du déploiement du module sur le référentiel. En effet, les fichiers de classe doivent exister lorsque ces mappes ou ces modèles s'exécutent (voir Exemple de compilation et de création de schémas).
Si le module contient également des fichiers de classe précompilés, vous pouvez utiliser ces fichiers directement après le déploiement sans compiler les fichiers Java sur le serveur. Vous augmentez ainsi les performances (car il n'y a pas de durée de compilation supplémentaire) et le comportement est le même que pendant un déploiement habituel.
L'exemple suivant illustre le déploiement sur un référentiel du module WebSphereICS420DEVServer.jar contenant des fichiers de classe précompilés :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar
Généralement, certains composants du fichier de module portent le même nom que des composants du référentiel. Dans ce cas, vous devez déterminer si vous souhaitez remplacer les composants du référentiel par ceux du fichier de module. L'option -ai indique que les composants dupliqués ne doivent pas être chargés dans le référentiel :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar
Pour remplacer tous les composants dupliqués dans le référentiel, utilisez l'option -ar comme dans l'exemple suivant :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iCustomerSyncInterface.jar -ar
Vous pouvez indiquer l'option -arp pour remplacer de façon interactive les composants dupliqués dans le référentiel. Cela vous permet de préciser pour chaque composant dupliqué s'il doit être remplacé ou non.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iCustomerSyncInterface.jar -arp
Pour que les mappes et les objets de collaboration soient lancés en phase d'exécution, vous devez compiler les mappes et les modèles de collaboration définis dans le référentiel. Pour que les relations fonctionnent correctement en phase d'exécution, vous devez créer les schémas correspondants.
Lorsque vous déployez des composants sur un serveur s'exécutant en mode production, tous les modèles sont automatiquement compilés et tous les schémas de relation sont créés. Pour que le déploiement aboutisse, le code de la mappe et des modèles de collaboration doit alors être valide et InterChange Server Express doit être en mesure de communiquer avec les bases de données spécifiées dans les paramètres des définitions de relation.
Lorsque vous déployez des composants sur un serveur s'exécutant en mode conception, les modèles ne sont pas automatiquement compilés ; les schémas de relation sont automatiquement créés. Toutefois, certaines options vous permettent de compiler les modèles et d'autres options vous permettent de ne pas créer de schéma de relation.
L'exemple suivant utilise l'option -xCompilePackage et n'utilise aucune forme de l'option -r. Il en résulte qu'une fois déployé le module précisé par l'option -i, les mappes et les modèles de collaboration sont compilés et les schémas sont créés pour les relations :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -xCompilePackage
Vous pouvez aussi choisir de ne pas créer de schéma de relation lors d'un déploiement. Par exemple, si vous déployez un module d'un environnement à un autre et n'avez pas modifié les propriétés des relations afin que ces dernières utilisent les ressources de base de données du nouvel environnement, vous devez modifier les propriétés correspondantes avant de créer les schémas. L'exemple suivant utilise l'option -r* afin de ne pas créer de schéma pour toutes les relations du module en cours de déploiement :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -xCompilePackage -r*
Le référentiel doit être valide pour que le serveur puisse traiter les flux correctement. Utilisez l'option -vr pour valider un référentiel de serveur, comme dans l'exemple ci-dessous :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -vr
Si le serveur est valide, repos_copy affiche la sortie suivante sur la console :
Validation effectuée avec succès. Toutes les dépendances ont été résolues.
Si le référentiel n'est pas valide, repos_copy affiche la liste des dépendances qui doivent être résolues.
Si vous avez déployé des mappes ou des modèles de collaboration sur le référentiel et que vous ne les avez pas compilés pendant le déploiement, vous pouvez utiliser repos_copy pour les compiler ultérieurement. Cette opération peut être utile si vous devez déployer un grand nombre de composants : dans ce cas, le déploiement peut être très long et la compilation peut rendre le traitement encore plus long. Attendez que le déploiement ait abouti pour exécuter la compilation : vous réduirez ainsi le risque de devoir patienter encore plus longtemps pour la migration de l'environnement si une erreur se produit.
L'exemple suivant montre l'utilisation de l'option -xCompileAll pour compiler toutes les mappes et tous les modèles de collaboration dans le référentiel :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileAll
Certaines options permettent également de compiler les deux types de composant. Utilisez
-xCompileAllCollabs pour compiler tous les modèles de collaboration et
-xCompileAllMaps pour compiler toutes les mappes. L'exemple ci-dessous montre l'utilisation de
-xCompileAllMaps :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileAllMaps
De même que vous pouvez compiler la totalité d'un type de composant, vous pouvez également compiler un composant isolé. Pour ce faire, utilisez l'option -xCompileCollab ou -xCompileMap suivie du signe deux-points et du nom du modèle de collaboration ou de la mappe. L'exemple ci-dessous permet de compiler le modèle de collaboration CustomerSync :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileCollab:CustomerSync
Plusieurs options fournies par repos_copy permettent de supprimer des composants dans le référentiel. Vous pouvez supprimer la totalité du référentiel, certains composants ainsi que des composants et les composants qui les référencent.
Utilisez l'option -d pour supprimer tous les composants du référentiel. L'exemple suivant contient la syntaxe :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -d
Repos_copy présente une invite vous demandant de confirmer la suppression de la totalité du référentiel.
Si un composant ne comporte pas de référent (d'autres composants qui y font référence et qui dépendent de son existence pour exécuter leur fonction dans le système), vous pouvez supprimer le composant isolé.
Utilisez l'option -do suivie du type d'entité, du signe deux-points et du nom du composant. Les types d'entité sont répertoriés dans le tableau 15. L'exemple suivant permet de supprimer la relation Customer :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -doRelationship:Customer
Si un composant est associé à des référents (d'autres composants qui y font référence et qui dépendent de son existence pour exécuter leur fonction dans le système), vous pouvez supprimer le composant uniquement si le serveur s'exécute en mode conception et en utilisant certaines options.
Si un composant comporte des référents, repos_copy ne vous permet pas de le supprimer à l'aide de l'option -do. Vous devez utiliser l'option -dfo pour forcer la suppression d'un composant avec référents. La suppression forcée d'un composant comportant des référents rend l'état du référentiel incohérent et un serveur s'exécutant en mode production ne permet pas cette opération, cette option ne fonctionne donc que sur un serveur en mode conception. L'exemple suivant montre l'utilisation de l'option -dfo pour supprimer l'objet métier Order malgré le fait que d'autres composants du système (telles que des mappes et des relations) y font référence :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -dfoBusObj:Order
Vous pouvez supprimer un composant et ses référents à l'aide de l'option -deep. Cette option permet de supprimer le composant et tous les composants qui y font référence. L'exemple suivant montre l'utilisation de l'option -deep avec l'option -do pour supprimer l'objet métier Customer :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -doBusObj:Customer -deep
Contrairement à l'option -dfo, cette option est prise en charge par des serveurs s'exécutant en mode production car la suppression des référents et du composant garantit la validité du référentiel. Notez, toutefois, que de nombreux composants peuvent être supprimés ; tenez compte des implications de cette action avant de l'exécuter.
L'option -o vous permet d'exporter des composants du référentiel vers un module. Vous devez indiquer le nom du fichier de module. L'option -o utilisée seule permet d'exporter la totalité du référentiel vers un fichier, comme dans l'exemple suivant :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -oWebSphereICS420DEVServer.jar
Vous pouvez spécifier des composants individuels à exporter à l'aide de l'option -e. Vous devez utiliser l'option -e avec le mot clé Type_Entité approprié, affiché dans le tableau 15 et vous devez faire suivre ce mot clé du nom du composant. Vous pouvez préciser plusieurs composants en les concaténant à l'aide du signe plus (+). Dan l'exemple suivant, l'objet métier Customer et le modèle de collaboration CustomerSync sont exportés vers le module CustomerSyncInterface.jar.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -eBusObj:Customer+CollabTemplate:CustomerSync -oCustomerSyncInterface.jar
Généralement, les fichiers de classe des mappes et des modèles de collaboration (lorsqu'ils existent) sont également exportés avec leurs fichiers Java dans le fichier du module. Si vous n'en avez pas l'utilité, utilisez l'option -xnoclasses pour ne pas tenir compte de ces fichiers de classe, par exemple :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -oWebSphereICS420DEVServer.jar -xnoclasses
Vous pouvez utiliser l'option -deep pour exporter les dépendances d'un composant également. Dans l'exemple précédent, l'objet métier Customer a été exporté, mais aucun de ses objets métier enfants ne l'a été. L'exemple suivant utilise l'option -deep pour exporter l'objet de collaboration CustomerSync_ClarifyToSAP et toutes ses dépendances.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -eCollaboration:CustomerSync_ClarifyToSAP -oCustomerSyncInterface.jar -deep
Pour exporter des composants spécifiques sans avoir à entrer le mot clé du type d'entité et les noms de composant, vous pouvez stocker ces composants dans un fichier texte et utiliser l'option -f. Cette opération est très utile lorsque vous devez exporter fréquemment les mêmes composants. L'exemple suivant utilise l'option -f pour charger les composants répertoriés dans le fichier texte Components.txt :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -fComponents.txt -oCustomerSyncInterface.jar -deep
Le contenu du fichier Components.txt est affiché ci-après ; un retour chariot suit chaque combinaison de mot clé de type d'entité et de nom de composant :
BusObj:Customer Relationship:Customer CollabTemplate:CustomerSync
Utilisez l'argument -summary lorsque vous exécutez repos_copy pour imprimer la liste des composants dans le référentiel. La sortie est présentée au format XML. Bien qu'il ne soit pas particulièrement utile d'afficher la sortie en ligne de commande, vous pouvez associer l'argument -summary à l'argument -o pour rediriger la sortie vers un fichier et visualiser ce fichier dans un navigateur ou un éditeur XML. La syntaxe de la commande dans ce cas est la suivante :
C:\>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -summary -oRepository.xml
L'utilitaire repos_copy lit les métadonnées dans le référentiel et écrit les données dans des fichiers en Unicode (format UTF-8). Il lit également ces fichiers et les charge dans le référentiel au format Unicode (UTF-8 ou UCS-2, selon le format requis par la base de données de référentiel sous-jacente).
Les fichiers repos_copy créés avec les niveaux de version d'InterChange Server Express antérieurs à 4.1.1 peuvent être chargés dans le référentiel correctement uniquement si les dates et les heures des planifications de composants sont au format US complet (cela ne pose généralement pas de problème. Repos_copy sauvegarde toutes les dates de planifications uniquement au format US complet. Une incompatibilité peut se produire si les fichiers repos_copy ont été édités manuellement).
En outre, lors du déploiement des référentiels 4.1.1, indiquez l'option '-nc' pour le codage des caractères.