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.
Using Event Mapping to perform field level data masking is an idea that I have toyed with since the release of Event Mapping in PeopleTools 8.55. Event Mapping is a desirable tool for field level data masking in PeopleSoft because it can allow for bolt on runtime application logic to determine if a user should have the ability to view a particular piece of data. I am unfortunately not here to say that Event Mapping can deliver us a (much needed) data masking framework for PeopleSoft applications. However, I have recently found that Event Mapping is capable of satisfying one particular field level data masking requirement that I threw at it. In this post, I will be sharing a proof of concept project that I’ve used to perform conditional data masking on a read only data field within a delivered Fluid page.
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.
I recently got my hands on a PeopleSoft environment running the new 8.56 PeopleTools. I have been most curious to see the advancements in the Related Content Framework Event Mapping functionality in the new Tools release. One huge limitation with Event Mapping in the 8.55 PeopleTools was the inability to inject custom styling into Fluid pages. The framework did not disallow this practice, but injecting custom styles into Fluid pages would generally result in the page becoming incorrectly rendered and unusable. One particular interesting use case of injecting custom styling with Event Mapping is to change the Fluid Homepage background. This use case was proposed by a member of the psadmin.io Community and I had previously tried this in 8.55 and it did not work well. However, it seems to work great in the new 8.56 PeopleTools. Below I will walk through how one can go about changing the Fluid homepage background with Event Mapping.
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.
Menu pruning is the process of limiting the items that show up in a menu for a user. This process is desirable in situations where you want to prevent a user from accessing certain content references. An example scenario of this could be that you don’t want to let administrators access Query Viewer when they are not coming in from a trusted location. The fashion in which the administrator’s access is limited in this scenario is the process of location-based security. With location-based security, you can let the location that a user is coming from dictate the type of access that a user has in the application. So if we put these two terms together, we get location-based menu pruning. Location-based menu pruning is the process of limiting the items that show up in the menu for a user based on the user’s location. In this post, I will discuss how we can perform location-based menu pruning on the PeopleSoft Fluid Navigator.
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.
A common desire among organizations that adopt the Fluid user interface (UI) is the ability to keep the Classic UI for administrative users. The loudest argument backing the need for the Classic UI for admins is that the Fluid UI does not have breadcrumbs. The response to this argument is that the adoption of Fluid is more than just mobile-enabling the application, but it also entails leveraging the new Fluid navigation paradigm which means using homepages, tiles, navigation collections, search, etc., to give users an avenue to perform the transactions that they need to perform. A proper adoption of the Fluid UI means leveraging these tools to “create your own navigation” for not only self-service users, but admin users as well. While I don’t necessarily have a dog in this fight, I would like to provide a proof-of-concept example on how one can go about keeping administrative users Classic in a Fluid environment.