Copying Integration Metadata Between PeopleSoft Databases

Services.

You can use Project Copy to copy services between databases.

WSDL documents that exist for a service are not automatically copied with a service. You must include them in the copy project.

WSDL documents.

To copy WSDL to another PeopleTools 8.55 system, use Project Copy. To copy WSDL to earlier releases of PeopleTools, you must use data mover scripts to copy the data to the target database.

Service operations.

A service operation is tied to a service. If you copy a service operation in a project, the target database must already contain the service to which the service operation is tied in the database. If it does not, you must include that service in the copy project.

Service operations cannot exist in a database without at least one service operation version - the default version. So when copying a service operation between databases, you need to be aware what the default service operation is and that you may possibly have to copy it to the target database as well.

In addition, keep in mind that the relationship between services and service operations is stored as part of the Service object. So for example, if a service contains three operations and you delete one of the three operations, you must include the service in the project. After the operation delete, the service is now linked to the remaining two operations and so it has changed and would need to be copied to the target database. It is not be enough to only copy the deleted operation in a Delete project; Deleting just the service operation doesn't delete the link to the service. If you don't follow this recommendation, you'll have orphaned data.

Service operation versions.

A service operation version refers to a specific service operation. If you copy a service operation version, the target database must already contain the service operation. If it does not, you must include that service operation in the copy project.

In addition, service operation versions refer to messages. If you copy a service operation version, the messages that are referenced for that service operation version must exist on the target database. If they do not, you must include them in the copy project.

If WSDL documents have been generated for a service operation version, they are not automatically copied during the Project Copy process. Further, once you have copied a service operation version to the target database, it may appear that WSDL documents exist for a service operation version, when they do not. To avoid this situation, after you copy a service operation version to the target database, open the service definition to which the service operation belongs.

If the View WSDL link appears, and when you click it WSDL appears, go back to the source database and export the generated WSDL documents to the target database. Another option is to delete the WSDL documents associated with a service operation before the Project Copy, and regenerate them on the target database.

Service operation handlers.

A service operation handler refers to a specific service operation. If you copy a service operation handler, the target database must already contain the service operation to which the handler refers. If it does not, you must include that service operation in the copy project.

Service operation routings.

Routing names are keys in the system.

If you copy a routing, the sending and receiving nodes must defined on the target database. If they are not defined on the target database, you must include them in your copy project.

Routings reference a specific service operation version. If you copy a routing, the target database must already contain the service operation version to which the routing refers. If it does not, you must include that service operation version in the project.

Routings also reference nodes. If you copy a routing, the target database must already contain the nodes being referenced. An exception to this is the local default node. During project copy, any routing referencing the local default node will be modified to reference the default local node of the target system.

If the system detects a duplicate routing definition during the project copy process, the routing definition in the project being copied overwrites the routing definition in the database. This internal check occurs only when you use the Copy from File option during project copy. If during the copy process the system overwrites a duplicate service operation routing on the target system, you may receive a system message that the service operation routing was deleted. The service operation routing deleted is the service operation routing that resided on the target system before the project copy process. To identify duplicate routings when using the Database to Database option during project copy, or to detect and delete any duplicate routings in the database outside the project copy process, run the duplicate routings check using the Delete Duplicate Routings section of the Service Administration–Routings page.

See Deleting Duplicate Routing Definitions.

Messages.

Container messages and message parts must have message schemas to function properly. You should also move message schemas along with your messages.

Service operation queues.

NA

Message schemas.

To copy message schemas to another PeopleTools 8.55 system, use Project Copy. To copy message schemas to earlier releases of PeopleTools, you must use data mover scripts to copy the data to the target database.

You should copy message schema along with all messages you copy from one database to another.

Documents

When you include a document in a copy project, the system inserts the document and all related definitions into the project.

To copy a document message type, when you specify the message, you must also include the document as a related definition.

Integration Groups

NA