Correcting Integration PeopleCode That Did Not Migrate

This section provides an overview of integration PeopleCode that did not migrate and how to correct it.

This section discusses the reasons why integration events and subscriptions might not successfully migrate to application classes during the upgrade from PeopleTools 8.47 and earlier systems to PeopleTools 8.48 and higher systems and the Deprecated type service operation handler used to manage such PeopleCode.

Reasons Why Integration PeopleCode Does Not Migrate

Integration events and subscriptions might not successfully migrate to application classes for the following reasons:

  • Use of global variables.

  • Use of component variables.

  • Use of constants.

  • Use of local functions.

  • Inability to determine the return type or the return type is incorrect.

Deprecated PeopleCode Handler

The PeopleSoft system creates a deprecated PeopleCode handler for any integration PeopleCode that cannot be migrated to the PeopleTools 8.48 or higher system.

Deprecated handlers enable you to run PeopleTools 8.47 and earlier PeopleCode (subscription or OnRequest). However, PeopleSoft recommends that you correct the PeopleCode and migrate the code into an Application Class type handler for use in the PeopleTools 8.48 or higher system.

See Correcting Non-Migrated Integration PeopleCode.

This section discusses correcting non-migrated PeopleCode and creating an Application Class type handler.

The following example shows an application class created for the PeopleTools 8.47 or earlier message PT_CDB_SECURITY. During the upgrade process, the system was unable to migrate the integration PeopleCode defined on the message.

Image: PeopleSoft Application Designer

This example illustates a PeopleTools 8.48 application class created for the PeopleTools 8.4x message PT_CDB_SECURITY.

PeopleSoft Application Designer

To correct non-migrated integration PeopleCode:

  1. In PeopleSoft Application Designer, open the migrated application package.

    The package name is generally the same as the message name in the PeopleTools 8.47 or earlier system.

  2. Remove the “<*” and “*>” symbols, as well as the comments from the code.

  3. Compile the code.

    If the code did not migrate for one of the following reasons, the system displays a meaningful error message to assist you in correcting the problem:

    • Use of component scope variables.

    • Use of global variables or constant variables

    • Incorrect return type for handler.

    If the reason for the failure is due to the use of a local function, modify the PeopleCode to ensure that the function is passing appropriate types for the context in the application package.

  4. Correct the PeopleCode and save the changes.

  5. Delete the deprecated handler.

    1. Select PeopleTools > Integration Broker > Service Utilities > Service Administration. Click the Deprecated PeopleCode tab.

      The Deprecated PeopleCode page appears.

    2. In the Service Operation field, enter the name of the service operation that contains the deprecated handler to delete and click the Search button.

    3. In the Select column, select the check box next to the service operation name that contains the deprecated handler to delete.

    4. Click the Delete button.

  6. Add an Application Class type handler to the service operation definition that references the modified PeopleCode.

    See Adding Handlers to Service Operations.

  7. In the message definition that was migrated to the PeopleTools 8.48 or higher system, delete the PeopleCode event or Subscription that is defined on the message.

    Open the PeopleCode editor for the respective event and null out the program that exists there. Several warnings appear when saving the program, but your changes will be committed.