Understanding Migrated Integration Metadata
These topics provide an overview of metadata migrated from PeopleSoft 8.47 and earlier database to PeopleSoft 8.48 and later databases.
The following table summarizes how objects are migrated between PeopleTools 8.47 and earlier releases and PeopleTools 8.48 and later releases:
|
PeopleTools 8.4x Objects ( PeopleTools 8.47 and Earlier) |
PeopleTools 8.48 and Higher Objects |
|---|---|
|
Node. |
Node. |
|
Channel. |
Queue. |
|
Message. |
Message. |
|
Node transactions and relationships. |
Service, Service Operations, Service Operation Versions, and Routings. |
|
Message and Subscription PeopleCode. |
Application classes and service operation handlers. |
Note: All objects migrated to PeopleTools 8.48 and higher releases have the Owner ID of the message from which they were created. Any invalid Owner IDs are deleted at the time of upgrade. If no Owner ID exists for an object, you must manually define one in the PeopleTools 8.48 or higher database.
Upgraded node objects are assigned a Default User ID as defined in the upgrade script.
In PeopleTools 8.48 and higher releases security is implemented at the user ID level. The default user ID is used in conjunction with securing service operations.
Channels have been converted to queues.
The new queue name should be the same as the old channel name.
As part of the upgrade/conversion, any related language data associated with the channel should also be brought over to the newly created queue definition.
Messages are shapes that provide the physical description of the contents of a service operation transaction, and describe the data being sent, including fields, field types, and field lengths.
Unlike PeopleTools 8.47 and earlier releases, beginning with PeopleTools 8.48 messages do not contain any processing logic, such as PeopleCode events or subscriptions. All processing logic is created by extending a set of delivered application classes, and associating those application classes to service operations using service operation handlers.
Node transactions and relationships are migrated to services, service operations and routing definitions.
Service Objects
During the upgrade process, a service definition is created for each distinct message referenced in the node transaction table.
A service inherit most of its properties from the message, including description, long description, Owner ID, language code, and so on.
The service name in PeopleTools 8.48 and higher releases is the same as the message name in the PeopleTools 8.47 or earlier system.
Any related language data associated with the message is inherited by the service.
Service Operation Objects
Service operations have the same name as the service to which they are associated.
Complex transactions like asynchronous or synchronous transactions with transformations, hub transactions or async-to-sync are defined by grouping a set of node transactions and relationships together. As the complex cases are upgraded, the system separates node transactions that were created for these complex cases (for example an asynchronous hub case) from the simple cases (for example, outbound asynchronous requests with no transformation). Asynchronous and synchronous node transactions that do not participate in a relationship (for example, those that are left over after we settled the complex cases) in PeopleTools 8.47 and earlier releases become service operations in PeopleTools 8.48 and higher releases.
Warning! If there is no node transaction on the PeopleTools 8.47 or earlier system, no service operation is created on the PeopleTools 8.48 or higher system during upgrade.
In cases where a PeopleTools 8.47 or earlier node has both synchronous and asynchronous transactions, the first transaction defined on the node is migrated as a service operation; the second message cannot be created and an error is generated to the output log at the time of upgrade.
For asynchronous-to-synchronous transactions on a PeopleTools 8.47 or earlier system, the following occurs during the upgrade process to PeopleTools 8.48 or higher system:
The service operation is named after the outbound message name.
The request message is named after the outbound asynchronous message.
The response message is named after the asynchronous response message specified in the relationship.
In PeopleTools 8.47 and earlier systems the IsActive property of the Message class was used to check the active property on the message. In PeopleTools 8.48 and higher systems it checks the service operation. In cases where a service operation is not created for a message, the IsActive property returns False. Therefore there may be a behavioral change from previous releases. In cases where there is no service operation created, and you want the previous behavior preserved, you must create a service operation and set the operation state to match that which was on the message.
Routing Objects
The upgrade process creates point-to-point routing definitions in the PeopleTools 8.48 or higher system based on node transactions and relationships defined in the PeopleTools 8.47 or earlier system.
Only current relationships in the PeopleTools 8.47 or earlier system are migrated.
The Active/Inactive flag on the transaction in the PeopleTools 8.47 or earlier system determines whether the routing definition is active or inactive in the PeopleTools 8.48 or later system.
The connector information defined on the outbound transaction is used in the routing definition. You must manually update aliases on routing definitions that use custom connectors.
When the system creates routing definitions during the upgrade process, the external message name from the transaction is used as the routing alias, if one was defined. If there is no value in the external message name, messages on nodes that are marked as External use the PeopleTools 8.47 or earlier system alias message name. PeopleTools 8.47 and earlier system nodes marked as anything other then External use the PeopleTools 8.48 alias format of serviceoperation.version.
All routing definitions created during the upgrade process are point-to-point routings, with one exception. In cases where on the PeopleTools 8.47 or earlier system there is an inbound synchronous or asynchronous node transaction on the default local node without a corresponding outbound synchronous or asynchronous node transaction (via relationship) on the default local node, an any-to-local routing definition is created during the upgrade.