I am finally starting to get up to speed with Automated Configuration Management (ACM) Plugins. ACM is something that the guys over at psadmin.io have been talking about for some time now and I think this is a great new PeopleTools functionality. I have experienced an unfortanute limitation around the allowed character length of the input configuration properties for the some of the ACM plugins that I am currently working on. It turns out that the input configuration properties for ACM plugins are limited to a measly 254 characters. This is a problem for plugins that require lengthy configuration properties. For the plugins that I am creating, I wanted a way to easily create and mange plugin configuration properties without having any character length constraints.
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.
There are many times where I come across some sample PeopleCode on the internet and I want to execute the PeopleCode in my environment to see the output. The route I take to test drive some PeopleCode usually involves me opening up an existing object in App Designer, pasting in the sample code, and then going to the PIA to see the results. I find this process rather tedious to perform just to see the output of some sample code. Not to mention, I have to make sure I go back into App Designer and clean up the object I modified. More often than not, I already have a PeopleSoft session open in my web browser when I am exploring PeopleCode online. So what I decided to do was build an online utility for compiling and running PeopleCode directly in the PIA. In this post, I will share this helpful utility for anyone that is interested in this functionality.
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.