Introduction to Application Service Framework (ASF)

• The Application Service Framework (ASF) is a “new” way of building PeopleSoft REST services.

• It is a framework that sits on top of the PeopleSoft Integration Broker (IB) and provides new way to create RESTful services.

• It is available in PeopleTools 8.59 and later.

  • A framework by the same name was introduced before that but it seems to have been re-implemented in 8.59. We will only cover the 8.59+ version here.

• It is mainly for having PeopleSoft act as a RESTful service provider, allowing external systems to interact with PeopleSoft data and processes using RESTful APIs.

• It can also be used to consume RESTful services from external systems. This would be acting as an HTTP Client to call external HTTP services.

• Behind the scenes, ASF creates standard PeopleSoft REST Service operations that I have written about extensively in the PeopleSoft REST Services section of this book.

• It looks like one of the main goals of ASF to have the ability to create Open API (Swagger) documentation from the meta-data tables that it creates. We will cover this later. There is also many statements around “standards compliance” and “naming standard enforcement” in the documentation. I am not sure how much of this is really useful in practice. A solid development process with code reviews and internal standards can achieve the same goals without the additional complexity of ASF. Also there are times where you are integrating with a rigid external system that has its own standards and you have to adapt to those rather than enforcing your own standards.

From PeopleBooks:

The Application Services Framework simplifies the process of maintaining REST services and provides application developers a standardized approach for authorizing and validating message structure for application services.

My First Impressions

After looking at the documentation and creating some new web services I am not convinced switching to ASF over standard REST will provide much benefit. If you already know how to create and maintain standard PeopleSoft REST services, then you may not find much value in the ASF framework.

I see only meager benefits and some potential downsides. Of course this is coming from someone who has been working with standard PeopleSoft REST services for many years and I have deployed hundreds of web services in close to 100 PeopleSoft customers. I have a lot of experience with the standard REST service operations and the Integration Broker and I know how to use them effectively and where they fail and the edge cases.

So for me personally, I don’t need a “helper framework”.

• Behind the scenes ASF creates standard service operations. If you know your way around standard REST service operations, then you can create and maintain them with relative ease. The ASF framework does not provide any significant improvements in this area.
• You configure the web services with some new pages that end up behind the scene just configuring standard service operations. So there is another layer of abstraction and more data to maintain and a framework to learn.
  • Abstractions can be great if they simplify things or reduce complexity. There are always trade-offs with abstractions. In this case I am not sure that the abstraction is worth the additional complexity.
• The PeopleCode that you have to implement does provide a debatable improvement in terms of readability and syntax “sanity” and “sugar”. However, it is not a huge leap forward in terms of functionality or ease of use.

It also uses security in some “weird” ways. We will explore this in more detail in the security section below.

Since I am very familiar with standard PeopleSoft REST services, I find that I can create and maintain them with relative ease. I am not sure that ASF provides enough benefit to justify the additional complexity of learning a new framework and maintaining the additional configuration data.

My Use Cases - Probably Not Yours

My use cases are likely NOT the same as yours. I personally deliver web service “bolt-ons” for several integration products. So in much of my uses case, I intentionally do NOT want to use the latest thing from PeopleSoft because I need to be able to support older PeopleTools versions. I also need to be able to support PeopleSoft versions that are not on the latest patch level. I need a stable substrate to deploy reliably to all customers. I know that ASF was first delivered for some “Chatbot” function prior to PeopleTools 8.59. It was then re-implemented in 8.59 with a more stable and usable version. I have not yet seen any customers using it in production.

I have one customer that was trying to get the Chatbot authentication to work but they have some issues with their SSO infrastructure and the PeopleSoft side can be extremely limited.

My use cases are different than most PeopleSoft developers who are likely sitting inside a single organization. If you are in that situation, then you may find ASF to be a good fit for your needs. I would recommend that you try it out and see if it meets your requirements.

What are the Advantages of ASF?

I fed some of the YouTube videos from Oracle about ASF through an LLM and ask it to provide me some of the advantages of using the Application Services Framework (ASF) it produced the following. Since this was LLM generated some of these maybe a bit off, but it gives us a good starting point to explore the advantages of ASF. I annotated each of the points with my own take on them.

• Simplified Development & Maintenance

  • Application Services Designer: Simplifies the process of maintaining REST services and enforces naming standards automatically
    • Chris’s Take: I am NOT convinced that this is a significant improvement over the standard REST service configuration pages.
  • Built-in Testing: Includes an Application Service Tester Utility for testing both standard and chatbot application services
    • Chris’s Take: Lets explore these claims in more detail later.
  • Automated Metadata Generation: Creates necessary IB metadata and generates Open API documentation automatically
    • Chris’s Take: This is a nice feature, but it is not a huge leap forward. See my comments below about Open API documentation below.

• Standards Compliance

  • Oracle REST Standard Compliance: Services conform to Oracle REST standards and can be used anywhere provider REST services are supported
    • Chris’s Take: Any sort of standards can easily be handled with code reviews. There is no clear benefit here unless you rely on some very specific Oracle products.
  • Open API Documentation: Automatically generates Open API (Swagger) documents in JSON format for human-readable API documentation
    • Chris’s Take: See section below for more details on Open API documentation. This is a nice feature, but it is not a huge leap forward.
  • Naming Standard Enforcement: Built-in validation ensures parameter names adhere to Oracle’s naming conventions
    • Chris’s Take: Meh, code reviews can enforce the same standards.

• Flexibility & Customization

  • Service Aliases: Allows customers to change application logic in registered services without customization, providing upgrade-safe modifications
    • Chris’s Take: This is vague and there are many other ways to achieve this with standard REST services. I am not sure that this is a significant benefit.
  • Multiple Authentication Options: Supports OAuth2, Basic Auth, and other authentication schemes
    • Chris’s Take: This is also supported with standard REST services.
  • SSL Support: Optional SSL enablement for secure communications
    • Chris’s Take: This is also supported with standard REST services.

• Enhanced Integration Capabilities

  • Multi-Format Support: Handles both JSON and XML input/output
    • Chris’s Take: This is also supported with standard REST services. In fact you can support CSV and TEXT in standard REST.
  • URI Template Variables: Supports dynamic URI construction with embedded variables
    • Chris’s Take: This is also supported with standard REST services.
  • Multi-Row Data Handling: Can process single or multiple rows of input/output data
    • Chris’s Take: This is not an advantage or improvement. In standard REST you can parse “infinite” rows of data with the same PeopleCode logic.
  • HTTP Header Management: Full support for request and response headers
    • Chris’s Take: This is supported in standard REST and the limitations have to be the same for ASF since it is built on top of standard REST services.

• Administration & Security

  • Centralized Administration: Single interface for activating/deactivating services, setting security, and managing exports
    • Chris’s Take: This is already available in a different form with standard REST services. You can use the Integration Broker administration pages to manage REST services.
  • Granular Security: Set security at the root resource, index, and method level with permission lists
    • Chris’s Take: We will have to come back to this but much of this is already available with standard REST services. The security model is different in ASF and it is not clear that it is an improvement.
  • Bulk Security Updates: Apply security settings across multiple root resources and REST methods
    • Chris’s Take: This might be cool but a minor feature you may use once a year.

So I don’t see a lot of advantages to using ASF over standard REST services. The benefits are not clear and the additional complexity of learning and maintaining the ASF framework may not be worth it for many PeopleSoft developers.

You may feel completely differently and that is fine. I encourage you to try it out and see if it meets your needs. I am not trying to dissuade you from using ASF, but rather to provide a balanced view of its advantages and disadvantages.

OpenAPI Documentation and Its Long-Term Utility

One of the biggest “wow” features of the Application Service Framework (ASF) is its ability to generate OpenAPI documentation automatically. This is a significant improvement over the standard REST service configuration pages, which require manual documentation and can be error-prone.

OpenAPI Specification (OAS), often synonymous with Swagger, is a powerful ally in the early stages of API development. It shines during design and discovery, offering a standardized, machine-readable format that accelerates collaboration, enables automated tooling, documentation, and facilitates rapid prototyping. This “honeymoon phase” is where OpenAPI’s interactive documentation and code generation capabilities truly excel, allowing teams to quickly grasp an API’s functionality in tools like Postman or the Swagger UI in a web browser.

However, as an API matures and its integrations stabilize, especially with a limited number of clients, OpenAPI’s benefits often diminish and can even become an overhead.

Here’s why:

• Maintenance Burden: Keeping the spec perfectly in sync with every API change, particularly with a “code-first” approach, becomes tedious and prone to error. An outdated spec quickly loses its value as a single source of truth.
• Diminishing Returns on Client Generation: Once initial client SDKs are built and stable, continuous regeneration from the spec offers little ongoing benefit. Teams often prefer direct maintenance of client code.
• Over-Documentation for Known Integrations: For familiar clients, the comprehensive, interactive documentation of Swagger UI can be overkill. Simpler methods like release notes or direct communication are often more efficient for communicating updates.
• Added Complexity: Even minor API changes require spec updates, adding an extra step to the development pipeline that can feel cumbersome for agile teams with strong internal communication.

In my long career doing PeopleSoft development you rarely are opening up PeopleSoft to outside developments and clients where an OpenAPI specification is truly necessary. Most PeopleSoft integrations are with known internal systems or partners where the API is well understood and stable. Integrating with PeopleSoft is often more complicated than just a simple REST call as the client has to deal with PeopleSoft’s unique data structures, security models, and transaction handling.

In these cases, the overhead of maintaining an OpenAPI spec can outweigh its benefits.

Now that LLM’s have coming into the picture as well, you can often generate documentation by giving an LLM screenshots and your code. I have had great luck with this.

While OpenAPI remains invaluable for public APIs or large organizations with numerous internal teams, its long-term utility for stable, well-understood integrations with few clients warrants re-evaluation. The key is pragmatism: leverage OpenAPI where it maximizes value in the early stages, but be prepared to pivot to simpler, more agile documentation methods when its strengths no longer align with your API’s evolving needs.