Saturday, October 22, 2022

REST Consumer Base URL Maintenance Idea

"Legacy" Integration Broker used nodes to identify endpoints, and we migrated nodes separately from Messages and modern Service Operations. This design offered the following benefits:

  • Reuse across 8.47- Messages and 8.48+ Service Operations,
  • Different endpoints between development and production, and
  • The ability to test node connectivity without invoking a live service.
Modern PeopleSoft REST consumption, however, requires us to specify the full endpoint URL on every Service Operation. Here is an example. Let's say I want to send absence requests to the Oracle HCM cloud. Since the current version is, I would post to a URL that looks something like: If I also wanted to create workers, I would post to Do you see the similarities? I would have two service operations pointing to the same URL base. And that is just for POST. There are also GET, PUT, and PATCH operations, which would result in further redundancy. Now, let's say I need to change my server domain name or service version. That would require me to locate and update every Service Operation that uses the old base URL.

My other concern with the current design relates to the separation between development and production. Since the full endpoint URL is stored with each Service Operation, a migration from development through to production may require an update to the endpoint URL. In a sense, this requires us to place untested configurations in production.

To work around the current design, many developers resort to code-only metadata-less integrations where they use simpler metadata constructs such as URL definitions, App Classes, and Message Catalog entries for shared reusable fragments.

We believe there is value in Integration Broker metadata, but I think we just need one change. I just proposed the following idea in the PeopleSoft IdeaLabs to simplify the maintenance of both REST Service Operations and the new 8.60 Application Services Framework consumer services. Please vote for this idea if you believe it would be beneficial.

No comments: