Copying Integration Metadata Between PeopleSoft DatabasesThis chapter discusses how to:
Copy integration metadata between PeopleSoft databases.
Use data mover scripts to copy message schemas and WSDL.
Converting message schemas and WSDL to managed objects.
Manage nodes copied between databases and upgraded from earlier PeopleTools releases.
Copying Integration Metadata Between PeopleSoft DatabasesThis section provides an overview of copying metadata between PeopleSoft 8.52 databases and discusses data dependences and relationships when copying data.
Understanding Copying Integration Metadata Between PeopleSoft DatabasesYou can use PeopleSoft Application Designer's Project Copy functionality to copy integration metadata between PeopleSoft databases.
Message schema and WSDL became managed objects beginning with the PeopleTools 8.50 release. As a result, you can use Project Copy to copy message schemas and WSDL documents between PeopleTools 8.50 and higher databases. However, to copy schema and WSDL between PeopleTools 8.50 and higher databases and PeopleTools 8.49 or PeopleTools 8.48 databases, you must use the provided data mover scripts. These data mover scripts are discussed elsewhere in this chapter.
See Using Data Mover Scripts to Copy Message Schema and WSDL Data.
See Also
Copying Projects and Definitions
Understanding Data Dependencies and Relationships for Copying Data
When copying data between databases, you must be aware of data dependencies and relationships to ensure that no errors occur and to lessen the chance of encountering orphaned data.
Note. References to 'Project Copy' in the following table are references to the Project Copy feature in PeopleSoft Application Designer.
|
Object Name |
Comments |
|
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.52 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. 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. |
|
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.52 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 |
See Also
Using Data Mover Scripts to Copy Message Schema and WSDL Data
Using Data Mover Scripts to Copy Message Schema and WSDL Data
The following table lists the data mover scripts that PeopleSoft provides to move message schema and WSDL documents between PeopleTools 8.52 databases and PeopleTools 8.48 databases or PeopleTools 8.49 databases. These scripts are located in the <PS_HOME>\scripts directory.
|
Object |
Script Name |
Description |
|
Message schema. |
PSIBMSGSCHEMA_EXP.DMS |
Export a message schema from a PeopleTools 8.52 database. |
|
Message schema. |
PSIBMSGSCHEMA_IMP.DMS |
Import a message schema into a PeopleTools 8.52 database. |
|
WSDL document. |
PSIBWSDL_EXP.DMS |
Export a WSDL document from a PeopleTools 8.52 database. |
|
WSDL document. |
PSIBWSDL_IMP.DMS |
Import a WSDL document into a PeopleTools 8.52 database. |
The WSDL data mover scripts move WSDL by WSDL name, not service name. Therefore it is possible to select specific WSDL for importing/exporting for a given service.
You may encounter errors while moving large WSDL documents and schemas from a Microsoft SQL, Oracle or Informix platform to a Sybase or DB2 (UNIX or OS/390) platform, because of size restrictions in Sybase and DB2. The maximum size of WSDL documents from Microsoft SQL, Oracle or Informix platforms to DB2 or Sybase platforms is described in the following table:
|
Platform |
Maximum WSDL Size (Bytes) |
|
DB2 – UNIX |
32700 |
|
DB2 – OS/390 |
31744 |
|
Sybase |
32000 |
Converting WSDL Documents and Message Schemas to Managed Objects
This section discusses how to:
Use the Metadata WSDL/Schema Convert page.
Convert WSDL documents and message schemas to managed objects.
Convert message schemas to managed objects.
Delete data from the deprecated data repository.
Understanding Converting WSDL Documents and Message Schema to Managed
ObjectsThis section discusses converting WSDL documents and XML message schema to managed objects. It also discusses the deprecated data repository.
WSDL Documents and Message Schema as Managed Objects
Beginning in PeopleTools 8.50, WSDL documents and XML message schema became managed objects.
After you copy WSDL and schema from earlier releases, PeopleSoft Integration Broker enables you to convert the data to managed objects. (To copy WSDL and XML message schema from earlier versions of PeopleTools, use the data mover scripts described previously in this chapter.)
See Using Data Mover Scripts to Copy Message Schema and WSDL Data.
In addition, during the PeopleTools upgrade process the system automatically attempts to convert WSDL and schema metadata into managed objects. However, if the system is unable to convert the copied or upgraded data, you can convert it in the PeopleTools 8.52 system.
WSDL documents and XML message schema data that you copy from earlier PeopleTools releases to a PeopleTools 8.52 database is stored in a deprecated data repository in the database. WSDL and schema that do not property convert to managed objects during the upgrade process are also stored in this repository.
After you convert WSDL and schema to managed objects, the system moves the data to the metadata repository.
You can leave data that you do not convert in the deprecated data repository, or you can delete if from the system.
Using the Metadata Convert/Schema Convert PageUse the Service Administration – Metadata Convert/Schema Convert page (IB_META_CONV) to convert WSDL documents and message schemas to managed objects. To access the page select PeopleTools, Integration Broker, Service Utilities, Service Administration and click the Metadata WSDL/Schema Convert tab. The following graphic shows the Service Administration – Metadata Convert/Schema Convert page:
Use the top portion of the page to convert WSDL documents to managed objects. Use the bottom portion of the page to convert XML message schemas to managed objects. The page enables you to work with one WSDL document or message schema at a time, or you can work with all data in the deprecated data repository at once.
When working with message schema, you can also use the provided View Schema link on the page to view schemas before converting them.
This page also enables you to delete data from the deprecated data repository that you do not want to convert to managed objects or that you no longer need.
The following sections describe how to accomplish these tasks in greater detail.
Converting WSDL Documents to Managed ObjectsThis section discusses how to convert WSDL documents to managed objects.
To convert a WSDL document to a managed object:
Access the Service Administration – Metadata Convert/Schema Convert page (PeopleTools, Integration Broker, Service Utilities, Service Administration, Metadata Convert/Schema Convert).
Select the WSDL document(s) to convert:
To select a specific service for which to convert WSDL, in the Service field, enter the service name.
To select from all services in the deprecated data repository, click the Search button under the Service field.
Search results appear in the Non-Metadata WSDL grid.
In the Non-Metadata WSDL grid, check the box next to each service name for which to convert WSDL.
If a check appears in the WSDL Exists box, WSDL already exists as a managed object for the service. You can choose to use the existing WSDL, or select the box in the Select column to convert the WSDL again and overwrite the existing WSDL.
Click the Convert button under the Non-Metadata WSDL grid.
The status of the conversion for each service you selected appears in the Results field.
Converting Message Schemas to Managed ObjectsThis section discusses how to convert XML message schema to managed objects.
To convert message schemas to managed objects:
Access the Service Administration – Metadata Convert/Schema Convert page (PeopleTools, Integration Broker, Service Utilities, Service Administration, Metadata Convert/Schema Convert).
Select the XML message schema(s) to convert:
To select a specific schema to convert, in the Message Name field, enter the message name.
To select from all schema in the deprecated data repository, click the Search button under the Message Name field.
Search results appear in the Non-Metadata Schemas grid.
In the Non-Metadata Schemas grid, check the box next to each message name that contains the schema to convert.
If a check appears in the Schema Exists box, XML message schema already exists as a managed object for the message. You can choose to use the existing managed object schema, or select the box in the Select column to convert the schema again and overwrite the existing schema.
Click the Convert button under the Non-Metadata Schemas grid.
The status of the conversion for each message schema that you converted appears in the Results field.
If you are unable to convert a schema to a managed object, rebuild the schema:
For rowset-based messages, open the message in the Messages-Message Definition page and save the message. Upon Save, PeopleSoft Integration Broker automatically builds the schema for the message.
For nonrowset-based messages use one of the following options to rebuild the schema:
Access the schema using the View Schema link on the Metadata Convert/Schema Convert page and copy it to the Messages-Schema page and correct and save the schema.
Access the schema using the View Schema link on the Metadata Convert/Schema Convert page and copy it into an XML editor and correct the schema. Then upload it into the system using the Messages-Schema page.
Upload or create a new schema using the Messages-Schema page.
See Also
Managing XML Message Schemas for Rowset-Based Messages
Adding XML Message Schemas to Nonrowset-Based Messages
Deleting Data from the Deprecated Data RepositoryThis section discusses how to delete WSDL documents and XML message schemas from the deprecated data repository.
To delete data from the deprecated data repository:
Access the Service Administration – Metadata Convert/Schema Convert page (PeopleTools, Integration Broker, Service Utilities, Service Administration, Metadata Convert/Schema Convert).
Select the WSDL document(s) or XML message schema(s) to delete:
To select a specific WSDL document to delete, in the Service field, enter the service name.
To select from all services in the deprecated data repository, click the Search button under the Service field.
To select a specific schema to delete, in the Message Name field, enter the message name.
To select from all schema in the deprecated data repository, click the Search button under the Message Name.
Search results appear in the appropriate WSDL or schema grid.
In the WSDL or schema grid, check the Select box next to the data to delete.
Click the Delete button under the grid in which the data to delete appears.
Managing Nodes Copied Between Databases and Upgraded from Earlier PeopleTools
Releases
The user ID on any nodes that you copy to a database using Project Copy or that you upgrade from earlier PeopleTools releases must be:
Valid in the target database.
Assigned to the permission lists of any service operation that you intend to use.