One of the biggest pain points with using Integration Broker to consume third-party REST web services is the creation of all of the required metadata definitions. If I want to perform a simple REST request to a third-party URL, then I am stuck having to create Message, Service, Service Operation, and Routing definitions. Sometimes I just want the ability to test an API without having to create all of these definitions. It turns out that there are a couple of delivered methods within the %IntBroker class that allow developers to code the consumption of a REST API without the need to create all of the metadata definitions listed above. The two methods that I will be discussing are the ProvideRestTest and ConnectorRequest methods.
What in the world is the Portal Custodian? I asked myself this very question when I came across a delivered file named portalCustion.xml on the PeopleSoft web server. The Portal Custodian is an undocumented functionality that allows for regular expression pattern matching replacements on the portal content served by the web server. The portal content is the “wrapper” that the psp servlet puts around the page content. This means that we have the ability to modify the contents within the portal header and footer before the client receives the response from the web server. I discovered and tested this functionality in a PeopleSoft application running PeopleTools 8.56, but it is quite likely that this feature exists in older Tools releases. In this post, I will walk through how we can use this interesting feature to manipulate response data.
When navigating in a PeopleSoft system that uses Fluid Navigation, it can be easy to lose your bearings in terms of where you actually are in the Portal Registry. Knowing the exact Content Reference (and how to get to it) in Structure and Content is sometimes crucial when troubleshooting issues. The problem is that the new Fluid Navigation does not directly correlate to the structure of the Portal Registry like it used to in Classic (breadcrumb) Navigation. This results in there being no easy way to determine where a given Fluid page is in Structure and Content. I have recently found that using the combination of a simple Bookmarklet and IScript to be sufficient enough to reveal the Portal Registry path for the pages that I navigate to. In this post, I will share the implementation details of this helpful utility.
I recently made a post discussing the %metadata application package in PeopleSoft. I provided an overview of the package as well as examples of how to use it. To support my research efforts in understanding this package, I made a simple web-based PeopleCode editor to edit PeopelCode events in the PIA. My initial plan was to try build out a web IDE for accessing and modifying PeopleTools objects. I have found myself busy working on other projects and wanted to at least share what I was able to create. This project is simply an IScript that serves a basic interface to view and modify PeopleCode events using the %metadata application package. In this post, I will walk through how to install and use this online PeopleCode editor project. Please note that this project is a proof of concept and it is not intended to be used in any production PeopleSoft environments.
The Fluid Navigator is the new navigation technique that most closely resembles to old Classic style drop down menu navigation. If you have not yet had the chance to convert your entire menu structure to use more modern navigation techniques, then you are stuck having to rely on the Fluid Navigator to get you where you need to be in some cases. One major limitation of the Fluid Navigator is that is does not show you breadcrumbs when drilling down into the menu structure. Not having breadcrumbs displayed makes it much harder to quickly jump around the menu. In this post, I will demonstrate how you can add breadcrumbs to your Fluid Navigator.
The %metadata application package in PeopleSoft is very intriguing. This app package is unlike any other as we (PeopleSoft Developers) do not have access to the implementation of this package. When you try to open this package in App Designer, the IDE acts as if the package does not exist. However, if you correctly reference this package’s contents (sub-packages, classes, methods, properties, etc.) then App Designer does not bat an eye. It should be well understood that (our) usage of this package is not supported by Oracle as it is undocumented. However, there are currently no measures in place to prevent blind usage this app package. While I definitely do not advise the usage of this package in any legitimate PeopleSoft system, I thought it would be a fun educational exercise to try to understand this mysterious app package.
A while back I presented a solution to manage configuration data on the web server. This solution involved a servlet-based cache managing utility that was responsible for the storage and caching of data to the PeopleSoft web server. I have been experimenting with ways that I can get custom data cached to the PeopleSoft web server without being so intrusive to the web-tier. I recently came across the PT_METADATA app package which can be used to create object types such as HTML, Style Sheet, and Images. These object types are nice because they are PeopleTools-managed and they have the flexibility to store custom data expressed in any form. Another great perk of these object types is that they can be cached to the web server using the %Response class. I am going to demonstrate a technique that I use to get PeopleTools to manage and cache my custom data.