Friday, June 29, 2018

101 Ways to Process JSON with PeopleCode

... well... maybe not 101 ways, but there are several!

There is a lot of justified buzz around JSON. Many of us want to (or must) generate and parse JSON with PeopleSoft. Does PeopleSoft support JSON? Yes, actually. The Documents module can generate and parse JSON. Unfortunately, many of us find the Documents module's structure too restrictive. The following is a list of several alternatives available to PeopleSoft developers:

  • Documents module
  • Undocumented JSON objects delivered by PeopleTools
  • Java implementation (now included with PeopleTools)
  • JavaScript via Java's ScriptEngineManager

We will skip the first two options as there are many examples and references available on the internet. In this post, we will focus on the last two options in the list: and JavaScript. Our scenario involves generating a JSON object containing a role and a list of the role's permission lists.

PeopleCode can do a lot of things, but it can't do everything. When I find a task unfit for PeopleCode, I reach out to the Java API. PeopleCode has outstanding support for Java. I regularly scan the class and classes directories of PS_HOME, looking for new libraries I can leverage from PeopleCode. One of the files in my App Server's class path is json.jar. As a person interested in JSON, how could I resist inspecting the file's contents? Upon investigation, I realized that json.jar contains the Java JSON implementation. This is good news as I used to have to add this library myself. So how might we use json.jar to generate a JSON file? Here is an example has this really cool fluent design class named JSONStringer. If the PeopleCode editor supported custom formatting, fluent design would be really, really cool. For now, it is just cool. Here is an example of creating the same JSON using the JSONStringer:

What about reading JSON using The following example starts from the JSON string generated by JSONStringer. It is a little ugly because it requires Java Reflection to invoke the JSONObject constructor. On the positive side, though, this example demonstrates Java Class casting in PeopleCode (hat tip to tslater2006 for helping me with Java Class casting in PeopleCode)

What is that you say? Your PeopleTools installation doesn't have the json.jar (or jsimple.jar) files? If you like this approach, then I suggest working with your system administrator to deploy the jar file to your app and/or process scheduler's Java class path

But do we really need a special library to handle JSON? By definition, JSON describes a JavaScript object. Using Java's embedded JavaScript script engine, we have full access to JavaScript. Here is a sample JavaScript file that generates the exact same JSON as the prior two examples:

... and the PeopleCode to invoke this JavaScript:

Did you see something in this post that interests you? Are you ready to take your PeopleTools skills to the next level? We offer a full line of PeopleTools training courses. Learn more at

Thursday, June 28, 2018

Using PeopleCode to Read (and process) Binary Excel Files

At HIUG Interact last week, a member asked one of my favorite questions:

"Does anyone know how to read binary Microsoft Excel files from PeopleSoft?"

Nearly 15 years ago my AP manager asked me the same question, but phrased it a little differently:

"We receive invoices as Excel spreadsheets. Can you convert them into AP vouchers in PeopleSoft?"

Of course my answer was "YES!" How? Well... that was the challenge. I started down the typical CSV/FileLayout path, but that seems to be a temporary band aid, and challenging for the best users. I wanted to read real binary Excel files directly through the Process Scheduler, or basically, with PeopleCode. But here is the reality: PeopleCode is really good with data and text manipulation, but stops short of binary operations. Using PeopleCode's Java interface, however, anything is possible. After a little research, I stumbled upon Apache POI, a Java library that can read and write binary Excel files. With a little extra Java code to interface between PeopleCode and POI's Java classes, I had a solution. Keep in mind this was nearly 15 years ago. PeopleSoft and Java were both a little different back then and today's solution is slightly simpler. Here is a summary of PeopleSoft and Java changes that simplify this solution:

  • As of PeopleTools 8.54, PeopleSoft now includes POI in the App and Process Scheduler server Java class path. This means I no longer have to manage POI as a custom Java library.
  • The standard JRE added support for script engines and included the JavaScript script engine with every deployment. This means I no longer have to write custom Java to interface between POI and PeopleCode, but can leverage the dynamic nature of JavaScript.

How does a solution like this work? The ultimate goal is to process spreadsheet rows through a Component Interface. First we need to get data rows into a format we can process. Each language and operating environment has its strengths:

  • PeopleCode can handle simple Java method invocations,
  • JavaScript can handle complex Java method invocation without compilation,
  • Java is really good at working with binary files, and
  • PeopleCode and Component Interfaces play nicely together.

My preference is to capitalize on these strengths. With this in mind, I put together the following flow:

  1. Use PeopleCode to create an instance of a JavaScript script interpeter,
  2. Use JavaScript to invoke POI and iterate over spreadsheet rows, inserting row data into a temporary table, and
  3. Use PeopleCode to process those rows through a component interface.

The code for this solution is in two parts: JavaScript and PeopleCode. Here is the JavaScript:

Next hurdle: where do we store JavaScript definitions so we can process them with PeopleCode? Normally we place JavaScript in HTML definitions. This works great for online JavaScript as we can use GetHTMLText to access our script content. App Engines, however, are not allowed to use that function. An alternative is to use Message Catalog entries for scripts. The following PeopleCode listing uses an HTML definition, but accesses the JavaScript content directly from the HTML definition Metadata table:

To summarize this PeopleCode listing, it first creates a JavaScript script engine manager, it then evaluates the above JavaScript, and finishes by processing rows through a CI (the CI part identified as a TODO segment).

This example is fully encapsulated in as few technologies as possible: PeopleCode and JavaScript, with a little SQL to fetch the JavaScript. The code will work online as well as from an App Engine. If this were in an App Engine, however, I would likely replace the JavaScript GUID section with the AE's PROCESS_INSTANCE. Likewise, I would probably use an App Engine Do-Select instead of a PeopleCode SQL cursor.

Did you see something on this blog that interests you? Are you ready to take your PeopleTools skills to the next level? We offer a full line of PeopleTools training courses. Learn more at

Sunday, June 10, 2018

Live Virtual Fluid Training in July

In the Northern hemisphere, with days getting longer, and temperatures rising, many of us seek wet forms of recreation to keep cool. With the heat of summer upon us, I can't think of a better topic to study than the cool topic of PeopleSoft Fluid. That is why we are offering a remote live virtual Fluid training class during the hottest week of July. Additional details and registration links are available on our live virtual training schedule page. I look forward to having you in our virtual class!

Wednesday, April 11, 2018

Fluid in Seattle! Special Fluid Training Event

May 23, 2018
PeopleTools Fluid UI Training
8.54 through 8.56
Led by Jim Marion

SpearMC and jsmpros are co-hosting a PeopleTools Fluid training event in Redmond, Washington immediately following the Spring PeopleSoft Northwest Regional User Group meeting. Through this event I will cover the exact same material I regularly teach online, but in person for a 40% discount off the online price. The event runs from Wednesday May 23 to Friday May 25 at the exact same venue as the Northwest Regional User Group meeting, the Seattle Marriott Redmond 7401 164th Avenue Northeast, Redmond, WA 98052. Additional details and registration information are available on the Registration Website.

Registration and More Information!

Monday, February 12, 2018

Alliance Event Mapping Stop and Share

Dave Sexton and I will be hosting a Stop and Share at Alliance 2018. Our primary subject is Event Mapping and Page and Field Configurator. We will be discussing:

  • Use cases,
  • Configurations,
  • Potential concerns, and
  • Lifecycle management

Please stop by Tuesday from 9:15 AM to 9:45 AM and share your experiences with Event Mapping and Page and Field Configurator or listen to experiences from others. I will bring a demo along with several use cases to spark discussion.

Friday, February 09, 2018

Collaborate 2018 Workshops

I will be delivering two workshops at Collaborate 2018:

  • Creating Fluid Pages // Sunday, April 22, 2018 // 12:30 PM - 4:00 PM // Through hands-on activities, students will gain experience and confidence building Fluid pages. Activities include building a Fluid page using the standard and two-column layouts, using delivered class names for layout, using PeopleCode to initialize the layout, and much more. Because this is a hands-on training class, bring your laptop to participate in exercises. This course is designed for Functional Business Analysts as well as Developers.
  • Using Fluid to Build Better-than-breadcrumb Navigation // Thursday, April 26, 2018 // 8:30 AM - 12:00 PM // The most common reason organizations retain Classic instead of migrating to Fluid is navigation. Users love their Classic breadcrumbs and do not appreciate the Navbar. Through hands-on activities, students will learn how to build next-generation navigation that rivals breadcrumbs. This is a hands-on training session, so bring your laptop to participate in exercises. This course is for subject matter experts, functional business analysts, developers, and administrators.

These are hands-on workshops. Please be sure to add these workshops to your registration when you register for Collaborate. If you are already registered, you may want to revisit your registration to add these workshops. A full list of workshops and workshop details is available on the Quest PeopleSoft Workshop page.

I look forward to seeing you in April!

Tuesday, January 16, 2018

Disable or Hide a Radio Button Instance

I ran across a few blogs and forum posts from people either asking or sharing how to hide or disable radio buttons. The answers I saw appeared to address only part of the story so I thought I would share a solution. PeopleCode includes functions, properties, and methods for disabling and hiding fields. As you would imagine, A field property such as Visible will show or hide a field. What makes a radio button challenging is that a radio button represents several values of the same field. The Visible property applied to a radio button's field would hide the entire radio set, not just a single radio button. Likewise, disabling a radio button's field would disable the entire radio set. What we require is a reference to one instance of a fieldset, not the base field itself.

PeopleCode includes two functions that return a reference to a field: GetField and GetPageField. The first, GetField, returns the same field reference as a standard Record.Field reference or Rowset.GetRecord.GetField. The GetPageField function, on the other hand, returns a pointer to a single instance. While this might seem like the answer, it is only part of the story. The GetPageField function does return a single instance and setting some of the properties of this single instance only manipulates the single instance. Other methods and properties, however, appear to be tied to the base field. Unfortunately, the Visible and DisplayOnly properties are two properties bound to the underlying field. Changing either of these on a GetPageField reference will hide or disable the entire radio set, not just a single instance.

The solutions I have seen, and the one I recommend, is to use CSS and/or JavaScript to hide or disable a radio button. Here is an example in Fluid:

   Local Field &compBtn = GetPageField(Page.HR_DIRTEAM_FLU, "COMPENSATION_BTN");

   rem ** hide a radio button instance;

   rem ** or disable a radio button instance;

From a visual perspective, you are done. You have successfully completed your mission. Unfortunately, however, this is only part of the answer. An important part, but only part. Hidden or disabled HTML still exists. That means I can use a standard browser tool, such as Chrome inspector or IE Developer Tools to show or enable this HTML. In fact, even if the HTML elements didn't exist, I could still invoke JavaScript to make the app server think I had selected the radio button.

The only way to ensure the server never receives the value identified by the hidden or disabled radio button is to either use FieldEdit PeopleCode or Event Mapping FieldChange Pre Processing to change the value before delivered PeopleCode ever sees that value. This is part two. This is the part that seems to be missing from other solutions I have seen.

What got me thinking about this? The Fluid My Team page contains a button bar that allows a manager to switch between alternate views. One of the radio buttons in the button bar is Compensation. Some organizations do not want managers to see compensation. My challenge was to remove the compensation radio button in a secure manner without customizing delivered definitions. Using Event Mapping on PageActivate I was able to hide the Compensation button. Event Mapping FieldChange PeopleCode ensures PeopleSoft never triggers FieldChange for the compensation button.