Understanding Migrated Integration PeopleCode

The following table summarized how PeopleCode has been migrated between PeopleTools 8.4x releases and PeopleTools 8.48:

PeopleTools 8.4x PeopleCode

(PeopleTools 8.47 and Earlier)

PeopleTools 8.48 and Higher PeopleCode

Message and subscription PeopleCode.

Application classes.

PeopleCode events.

Service operation handlers.

All PeopleCode referenced in a message is converted to an application class, which is in turn then referenced by a handler that is created in the service operation generated by the converted message.

PeopleCode defined on messages in PeopleTools 8.47 and earlier releases is migrated into application classes in PeopleTools 8.48 and higher releases.

Application classes have to belong to an application package. The message name becomes the application package name and description. The exception for this naming convention is when an application package already exists on the PeopleTools 8.48 or higher system that matches the message name. In this case the application package is stripped of all underscores and the number 1 is appended to the end of the name.

For every subscription event associated with a message, an application class is created in the PeopleTools 8.48 or higher system with a similar name as the subscription event. Since application class names cannot contain special characters, those found in the subscription event name are simply replaced with an underscore.

Default values for application class names are used for the other message events.

If a PeopleTools 8.47 or earlier message has no PeopleCode defined on it, no application package is generated for it in the PeopleTools 8.48 or higher system.

Application classes that fail to compile are saved and commented out. In these cases, a deprecated handler is created to invoke the old message or subscription event, to behave, runtime-wise, as it did in PeopleTools 8.47 and earlier systems. The user, however, is responsible for correcting any application classes that failed to compile and modifying any service operation definition that makes use of the deprecated handler.

See Correcting Integration PeopleCode That Did Not Migrate.

The following table describes how PeopleCode events from PeopleTools 8.47 and earlier releases map to PeopleTools 8.48 and higher methods.

PeopleTools 8.4x Integration PeopleCode Events

(PeopleTools 8.47 and Earlier)

PeopleTools 8.48 Integration PeopleCode Base Classes and Methods

(PeopleTools 8.48 and Higher)

OnRequest

IRequestHandler:OnRequest

OnAckReceive

IReceiver:OnAckReceive

OnRouteReceive

IRouter: OnRouteReceive

OnRouteSend

IRouter:OnRouteSend

OnSend

ISend:OnRequestSend

Subscription

INotification:OnNotify

Many PeopleCode built-in functions have been deprecated for the new PeopleSoft Integration Broker model. Most of the PeopleTools 8.47 and earlier built-in functions have been internally redirected to work with the PeopleTools 8.48 and later equivalent. When compiling PeopleCode that uses the PeopleTools 8.47 and earlier built-in functions, an informational message appears that explains that the given built-in has been deprecated.

The following constructs are also migrated during the upgrade process:

  • Import statements.

  • Function libraries.

  • Variables not explicitly declared.

During the upgrade process, any special characters that used in the name of PeopleCode constructs in the PeopleTools 8.47 or earlier PeopleCode, such as slashes (“/”), single quotation marks “ ' ' “, and periods ( . ) are replaced with underscores ( _ ).