This section describes many of the common situations in which you will use repos_copy. It contains the following sections:
You can run repos_copy without any arguments to have the command and its arguments printed out. The example below shows repos_copy when executed without any arguments, and the resulting output:
C:\>repos_copy No Command line arguments to ReposCopy were specified Usage: repos_copy {-o[outputFile] | -i[inputFile]} [-sserverName] [-uuserName] [-ppassword] [-ai] [-ar] [-arp] [-d] [-k] [-v] [-eentityType:entityName1[+entityType:entityName2] -deep] [-fentityFileName] [-rrelationshipName1[:relationshipName2] ] [-xCompileAll] [-xCompileAllCollabs] [-xCompileAllMaps] [-xCompileCollab:collabTemplateName[+collabTemplateName]] [-xCompileMap:nativeMapName[+nativeMapName]] [-xcompilepackage] [-mode] [-doentityType:entityName1[+entityType:entityName2] -deep] [-dfoentityType:entityName1[+entityType:entityName2] -deep] [-summary] [-vp] [-vr]
You can validate a package of components before deploying the package to a server. This is very useful because if you deploy a package to a production-mode server all the dependencies must be resolved or the deployment will fail. You cannot validate a user project or integration component library in System Manager to make sure that the dependencies are satisfied, so the only way to find out if a package is valid when deploying with System Manager is to attempt the deployment and use the error information when it fails to resolve the dependencies. If there are many components in the package, this can be a very time-consuming process.
Although you cannot validate an integration component library, you can export it to a package file and then validate the package file using repos_copy.
To validate a package file using repos_copy, use the -i option to specify the name of the package file to be validated and the -vp argument to validate it rather than deploy it.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -vp
Repos_copy validates the contents of the package and displays a message to indicate whether or not the dependencies are resolved.
The -i option allows you to deploy a package of components to the repository. If you do not specify the name of the package file then you are prompted to enter it.
The following example shows a a file named WebSphereICS420DEVServer.jar being deployed to a repository:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar
If you have created the repos_copy file from System Manager, the deployment time properties will automatically be included. When this file is copied to the server, these properties will be applied to the components before they are sent to the server. If the repos_copy file was created by copying the content out of the server, it will not contain the deloyment time properties. In that case, you can export the deployment time properties from System Manager as a deployment descriptor file by using the -xdi option. If the -xdi option is used when the deployment time properties are already present in the repos_copy file, the properties specified in the deployment descriptor file will override those specified in the repos_copy file.
The syntax for the repos_copy command is as follows:
reposcopy -sservername -uusername -ppassword -ireposcopyfile -xdideploymentdescriptorfile
The deployment configuration of the repos_copy file can be ignored by using the -xdn option as follows:
reposcopy -sservername -uusername -ppassword -ireposcopyfile -xdn
Commonly there will be components with the same name in the package file as there are in the repository. In this case you must decide whether or not you want to replace the components in the repository with those in the package file. The -ai option specifies that duplicate components should not be loaded into the repository:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iCustomer.jar -ai
If you want to replace all the duplicate components in the repository, use the -ar option as in the following example:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iCustomerSyncInterface.jar -ar
You can use the -arp option to interactively replace duplicate components in the repository. This lets you decide for each individual duplicate component whether it should be replaced or not.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iCustomerSyncInterface.jar -arp
For maps and collaboration to execute at runtime, the maps and collaboration templates defined in the repository must be compiled. For relationships to function properly at runtime, their schemas must be created.
When you deploy components to a server running in production mode, all templates are automatically compiled and all relationship schemas are created. For the deployment to succeed, then, the code of the map and collaboration templates must be valid and InterChange Server must be able to communicate with the databases specified in the settings of the relationship definitions.
When you deploy components to a server running in design mode, the templates are not automatically compiled; relationship schemas are automatically created. There are options you can use to compile the templates, however, and there are options to not create relationship schemas.
The following example uses the -xCompilePackage option and does not use any form of the -r option. The result is that when the package specified by the -i option is deployed, the maps and collaboration templates are compiled and schemas are created for the relationships:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -xCompilePackage
You may not want relationship schemas created when you do a deployment. For instance, if you are deploying a package from one environment to another and did not change the properties of the relationships to use the database resources in the new environment then you will not want the schemas created until after you have changed the relevant properties. The following example uses the -r* option to not create schemas for all of the relationships in the package being deployed:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -iWebSphereICS420DEVServer.jar -xCompilePackage -r*
Membership and security information can be imported and exported from repos_copy by using the -xmsp option, as shown in the follwoing example:
repos_copy -sServerName -uUserName -pPassword -oOutputfile -xmsp
The repository must be in a valid state for a server instance to start in production mode. The reason for this is that ultimately the repository must be valid for the server to process flows successfully. Use the -vr option to validate a server repository, as in the example below:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -vr
If the server is valid then repos_copy writes the following output to the console:
Validation Succeeded.All Dependencies Resolved.
If the repository is not valid then repos_copy prints a list of the dependencies that must be resolved.
If you deployed maps or collaboration templates to the repository and did not compile them during deployment, you can use repos_copy to compile them afterwards. This can be useful in situations where there are many components to deploy because deployment can take a long time and compiling can make the operation take even longer. Waiting until after the deployment has succeeded to do the compilation task can reduce the risk of spending an even greater amount of time migrating the environment if an error occurs.
The following example shows the use of the -xCompileAll option to compile all maps and collaboration templates in the the repository:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileAll
There are options to compile all of either type of component as
well. Use
-xCompileAllCollabs to compile all the collaboration templates,
and
-xCompileAllMaps to compile all the maps. The example below
shows the use of
-xCompileAllMaps:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileAllMaps
Just as you can compile all of one type of component, you can also compile an individual component. Use the -xCompileCollab or -xCompileMap option followed by a colon and the name of the collaboration template or map to compile a single component. The example below would compile a collaboration template named CustomerSync:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -xCompileCollab:CustomerSync
There are several options provided by repos_copy for deleting components in the repository. You can delete the entire repository, individual components, and individual components as well as any components that reference them.
Use the -d option to delete all of the components in the repository. The following example shows the syntax:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -d
Repos_copy presents a prompt asking if you want to delete the entire repository or not.
If a component does not have any referents--other components that reference it and require it to exist in order to perform their function in the system--then you can delete the individual component.
Use the -do option followed by the entity type, a colon, and the name of the component. The entity types are listed in Table 11.The following example deletes the relationship named Customer:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -doRelationship:Customer
If a component does have referents--other components that reference it and require it to exist in order to perform their function in the system--then you can only delete the component if the server is running in design-mode, and by using certain options.
If a component has referents, repos_copy will not let you delete it with the -do option. You must use the -dfo option to force deletion of a component with referents. Forcing deletion of a component that has referents will leave the repository in an inconsistent state, and a server running in production mode does not permit that, so this option only works with a design-mode server. The following example shows the use of the -dfo option to delete the Order business object in spite of the fact that other components in the system (such as maps and relationships) have references to it:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -dfoBusObj:Order
Another way you can delete a component that has referents is to use the -deep option to delete the referents as well. This deletes the component and all of the components that have references to it. The following example shows the use of the -deep option when using the -do option to delete the Customer business object:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -doBusObj:Customer -deep
This option, unlike the -dfo option, is supported with servers running in production mode because the deletion of the referents along with the component guarantees that the repository remains valid. Keep in mind, however, that it can result in many components being deleted; you should be aware of the implications of this action prior to taking it.
The -o option allows you to export components from the repository to a package. You must specify the name of the package file. When the -o option is used alone the entire repository is exported to a file, as in the following example:
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -oWebSphereICS420DEVServer.jar
You can specify individual components to be exported by using the -e option. You must use the -e option with the appropriate EntityType keyword listed in Table 11,and must follow the keyword with the name of the component. You can specify multiple components by concatenating them with the plus (+) sign. In the following example, the Customer business object and CustomerSync collaboration template are exported to a package named CustomerSyncInterface.jar.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -eBusObj:Customer+CollabTemplate:CustomerSync -oCustomerSyncInterface.jar
You can use the -deep option to export the dependencies of a component as well. In the previous example, the Customer business object was exported, but none of its child business objects were. The following example uses the -deep option to export the CustomerSync_ClarifyToSAP collaboration object and all of its dependencies.
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -eCollaboration:CustomerSync_ClarifyToSAP -oCustomerSyncInterface.jar -deep
If you want to export specific components, but do not want to have to enter the entity type keyword and component names, you can store them in a text file and use the -f option. This is very convenient when you want to frequently export the same components. The following example uses the -f option to load the components listed in a text file named Components.txt :
C:\WebSphereICS420DEV>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -fComponents.txt -oCustomerSyncInterface.jar -deep
The contents of the file Components.txt are shown below; a paragraph return follows each entity type keyword and name combination:
BusObj:Customer Relationship:Customer CollabTemplate:CustomerSync
You can use the -summary argument when executing repos_copy to print a list of the components in the repository. The output is presented in XML format. Although it is not particularly useful to view at the command line, you can combine the -summary argument with the the -o argument to redirect the output to a file and then view the file in a browser or XML editor. The command usage in this case would be the following:
C:\>repos_copy -sWebSphereICS420DEVServer -uadmin -pnull -summary -oRepository.xml