Contents

Service Operation Routings

A routing is a key piece of configuration in service operations. They play different roles depending on if you are using REST or non-REST operations.

  • REST Routings

    • There is only ever one routing
    • The routing is created automatically by the Service Operations pages.
    • The routing can control logging and other advanced behavior.

  • Standard Service Operations (non-REST) Routings

    • Controls what NODE the Service Operation can publish and subscribe
    • Are generally manually configured

Synchronous Logging

A routing is where you can turn on or off logging. By default, a Synchronous operation will not log it’s request.

Todo

Why no Async logging?

Todo

  • Operation Alias
  • Transformations

Local-to-Local Routings

One usage scenario that is not as commonly understood is the “local-to-local” routing. This is where a business event in the local database creates a service operation and the same local database subscribes to that message and does some processing.

Delivered Example

In HCM, the USER_PROFILE service operation has a local subscription which runs USER_PROFILE1:HCM_Refresh_SJT_OPR_CLS:onNotify. This allows HCM to “watch” for changes to user profiles and update flattened row-level security tables without modifying PeopleTools objects.

The HCM group could have placed this code in the USERMAINT.GBL.SavePostChange component PeopleCode, but that would require modifying a PeopleTools object that should be identical across all PeopleSoft applications (FS, HCM, CRM, etc.). The local-to-local routing solves this cleanly.

Design Advantages

Watching for business events without intrusive customizations. Since activating a routing is just an entry in an IB setup table, it is not really a customization. A routing tells the integration engine to “run this code when you get a message like X.”

Background tasks outside the Process Scheduler. You can use a local-to-local routing as a queue to offload processing to a background thread. For example, if a user uploads a file with thousands of student IDs and you need to update 3C tables for each, doing this at save time would time out. Instead, publish a local service operation at save time, and the subscription handler updates the 3C tables asynchronously via Component Interface – without consuming Process Scheduler slots.

Loosely coupled architecture between modules. Instead of tightly coupling termination logic in the HR component’s SavePostChange, you can subscribe to the WORKFORCE_SYNC message and have subscription code inspect the message and lock out user accounts in response to termination events. If this functionality is no longer wanted, just deactivate the subscription handler instead of migrating a code change.

Best Practices

  • When configuring Service Operation Routings be sure to never use “Any to Local” routings. Always explicitly define your nodes in the routings to tell the systems what integrations go where.
    • This can be self documenting of who uses the integration as well as more secure if someone improperly configures a node.
  • For Synchronous Operations you likely want at least header logging so we can have some visibility in the usage of your service. Otherwise, there is no other way to see successful operations.
Author Info
Chris Malek

Chris Malek s a PeopleTools® Technical Consultant with over two decades of experience working on PeopleSoft enterprise software projects. He is available for consulting engagements.

Work with Chris