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 11.13.18.05, I would post to a URL that looks something like: https://some.server.com/hcmRestApi/resources/11.13.18.05/absences. If I also wanted to create workers, I would post to https://some.server.com/hcmRestApi/resources/11.13.18.05/workers. 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.

Allow REST Consumer Base URL to be shared across Service Operations/ASF

What if Component App Classes Were Configurable?

With Fluid, PeopleSoft implemented an interesting design pattern: App Classes as Event Handlers. Properly implemented, there are some fantastic reasons to choose this pattern:

• Writing testable code (PSUnit)
• Code reuse

You can see Oracle's latest pattern on just about every Fluid component. A component that uses this pattern might have PreBuild PeopleCode that looks something like this:

import SOME_PACKAGE:SomeClass;
Component SOME_PACKAGE:SomeClass &handler;

&handler = create SOME_PACKAGE:SomeClass();
&handler.PreBuild();

But I had this idea... What if the code looked more like this:

import SOME_PACKAGE:SomeBaseClass;
Component SOME_PACKAGE:SomeBaseClass &handler;

Local string &className;

REM ** Select actual implementation of SomeBaseClass from a configuration table;
SQLExec("...", %Component, &className);

&handler = CreateObject(&className);
&handler.PreBuild();

Then we could override delivered behavior by subclassing and configuring our own handlers to override the delivered handlers. And I think this is the best reason to use App Classes as component event handlers. What would it take to implement this solution? Oracle would need to select the implementation class from SQL rather than hard-code its implementation into component PreBuild. But is it worth it? You know that is a fantastic question! You might say Event Mapping offers the same result but is more flexible. Let us know your thoughts in the comments!

At JSMpros, we teach PeopleTools and PeopleCode concepts like this regularly check out our website to see what we are offering next!