Consuming Enormous Datasets with PeopleSoft

Integration Broker is built on the DOM concept, which means it parses data into an in-memory structured document before transforming, processing, or transmitting it. This is fantastic for small and incremental integrations designed to keep two systems synchronized on a per-transaction basis. However, it fails when processing datasets that exceed the amount of available system memory.

An alternative is to use a SAX or stream-based parser that emits events. This type of parser only consumes the memory necessary to emit the next event. Stream-based parsers are highly efficient for one-way, one-time reads through large datasets. Unfortunately, Integration Broker does not support stream-based processing.

While reviewing PeopleSoft's Java class path, I noticed the Jakarta JSON stream-processing Java library. You can find a simple PeopleCode example of processing a JSON file using Jakarta JSON streams in our blog post JSON Stream Processing with PeopleCode. Now that we know how to use Jakarta's stream processing, the next challenge is reading an input stream from an external service. Since Integration Broker does not support streams, we need alternatives. Here are a few Java-based alternatives that readily integrate with PeopleCode through delivered APIs:

• Java Sockets
• Java HttpURLConnection
• Apache HttpClient

Although PeopleCode offers incredible support for Java, the real challenge lies with method and constructor overloading. PeopleCode identifies target Java methods and constructors through parameter count, not parameter type. Java overloading doesn't play well with PeopleCode. The solution I use to overcome method overloading is to leverage Java's support for JavaScript as a translation layer or a "glue." PeopleSoft exposes all functions and objects to Java. Therefore, all PeopleCode functions and objects are also available to JavaScript.

The following is a sample JavaScript that can run from PeopleCode to stream load data into a PeopleSoft table. It uses Jakarta for stream processing and Apache HttpClient to connect to the external service. Both of these external libraries are included with PeopleTools. Notice the use of PeopleCode functions, such as CreateSQL, as well as Java objects such as HttpGet.

I use PeopleCode similar to the following to run JavaScript from PeopleCode. You can find several examples of using Java's ScriptEngineManager on our blog.

Local JavaObject &manager = CreateJavaObject("javax.script.ScriptEngineManager");
Local JavaObject &engine = &manager.getEngineByName("JavaScript");
Local String &script = "JavaScript goes here";
Local Any &result;

&engine.eval(&script);

&result = &engine.get("result");

At JSMpros, we teach PeopleTools and PeopleCode tips like this in every class. Check out our online schedule to see what we're offering next. Would you prefer to learn at your own pace? Purchase a subscription to access all of our on-demand content at discounted rates!

Five Ways to Consume a REST Service with PeopleSoft

PeopleSoft includes facilities for providing and consuming REST. A service provider is a listener. A provider waits for requests and responds accordingly. To provide web services, we must register metadata with Integration Broker. The process is pretty well fixed. Consumption, on the other hand, is much more flexible. Consuming a REST service means invoking (or calling) someone else's listener. The consumer initiates the conversation. In a consumption scenario, we might be sending data, receiving data, or both.

Here are five ways a PeopleSoft developer might invoke a REST service:

1. Metadata

This is the traditional PeopleSoft approach and follows the same pattern as providing services through Integration Broker. Here are a few of the metadata items a developer would create:

• Documents,
• Messages,
• Service, and
• Service Operation.

After creating and registering somewhat reusable metadata, the developer would then write PeopleCode to:

• Create Document structures,
• Invoke the service, and
• Parse the response.

Even though this approach requires the most effort and offers the least reuse, it takes full advantage of Integration Broker's capabilities, including logging, security, etc.

Metadata, in general, offers the following benefits:

• Reuse (ability to use the same definition multiple times),
• Documentation (describes an object),
• Reporting (query and analysis), and
• Transformation (ability to upgrade and transform based on architecture changes).

Pure code solutions are much harder to query and transform. Metadata is what allowed PeopleSoft to switch from a Windows-based Client/Server solution to its Pure Internet Architecture in (mostly) one release. Metadata is what allowed Integration Broker to transform from an XML-focused solution into an SOA solution in one release (the 8.48 transform). If these benefits sound appealing, then metadata may be the right choice for you.

2. Application Services Framework

Created initially as a REST provider to support digital assistants, the Application Services Framework can now consume REST services. The Application Services Framework is a developer-friendly configuration layer tightly integrated with Integration Broker metadata. Rather than directly working with SOA-oriented metadata, the Application Services Framework allows developers to create solutions using REST terminology and REST patterns.

To use the Application Services Framework for consumption, a developer would:

• Register the target service with the Application Services Framework, which includes describing the URL, parameters, headers, and payload (both request and response).
• Write PeopleCode to invoke the endpoint service.

This is one of the most important chapters in our updated Integration Tools curriculum. You may find basic information (including code samples) on consuming a REST service in PeopleBooks.

3. %IntBroker.ConnectorRequestURL

If your request is a simple URL with no special headers (request or response headers) and any parameters may be passed through the URL, then this is the most straightforward approach:

Local string &response = %IntBroker.ConnectorRequestURL("http://rest.example.com/endpoint");

Unfortunately, this solution offers no logging, header control, or any typical Integration Broker or integration features. It is strictly for the simplest GET requests. Nevertheless, by using URL definitions, this alternative may be one of the better alternatives for cross-environment migrations.

4. Code-only

The challenge with the first option, Metadata, is that it requires creating, migrating, and maintaining a significant number of definitions that provide little (if any) value for REST. For example, the URL of a PeopleSoft REST consumer service becomes part of the metadata. If you have different targets between DEV, TEST, and PROD, then you must modify the metadata after every migration. Implementing a true PeopleSoft Metadata-focused solution (such as option 1) may require you to violate development best practices by making changes after each migration.

Since all approaches require PeopleCode, why not skip the Integration Broker metadata in favor of your own reusable best practice-based metadata? You may find an example of this approach in our blog post Simple Code-only REST Request. With this approach, you are responsible for managing URLs, Credentials, etc., but you may store them in a manner that allows for reuse and better migration management. For example, you might create URL definitions that point to different endpoints in DEV, TEST, and PROD.

It is important to note that this approach DOES use metadata, but it reuses generic PeopleTools-delivered definitions, so we don't have to create new definitions.

As mentioned earlier, code doesn't report or transform well, so this alternative may miss out on future automated transforms, such as the 8.48 automated transform. Likewise, integrations launched in this manner won't log details in the Synchronous Service Operation Monitor. Nevertheless, this approach is becoming one of our favorite alternatives to overly complicated metadata.

5. Java

Using Java allows a PeopleSoft developer to bypass Integration Broker altogether. We put this option last because it should be the choice of last resort. However, it is probably the most flexible option available, allowing for everything from simple low-level sockets to convenient libraries, such as Apache's HttpClient (now included with PeopleTools).

There are many reasons to choose this option, but here are the two most common:

• Processing binary data: Integration Broker is pretty much an XML workhorse. Everything passing through Integration Broker is wrapped in XML at some point. Unfortunately, that might not work well with binary data. Therefore, skipping Integration Broker may be appropriate.
• Processing large amounts of data: Integration Broker works with DOM. It requires all data to be loaded in memory at one time. This makes it a poor choice for handling large datasets. An alternative is to use stream processing with an event-based parser, such as a SAX parser. With Java, you can read bytes, process them through an event-based processor, and then discard the processed bytes.

The challenge with using Java directly from PeopleCode is that many Java methods and constructors use overloading. As a workaround, we devised a strategy for invoking Java through JavaScript from PeopleCode. With a small PeopleCode fragment, we can invoke a JavaScript, and JavaScript handles Java really well. Details about this strategy are available in our Blog Post JavaScript on the App Server: Scripting PeopleCode.

The following is a sample JavaScript we used at Reconnect 2024 to stream-processed a large amount of JSON data from a REST service.

At JSMpros, we teach all five options in our Integration Tools and Integration Tools Update courses. Check out our website for on-demand and live course offerings. Alternatively, subscribe to gain access to all of our on-demand courses.

Triggering FieldChange from JavaScript

We love a challenge, and we believe anything is possible with PeopleTools. It is never a question of "can you?" but "how?" A customer recently shared a challenge with us:

We use a handheld scanner to enter values into a text field of a Fluid Page. After scanning, we want FieldChange PeopleCode to load data into the remainder of the page. Our solution worked great in PeopleTools 8.58, but quit working after upgrading to 8.59.

Since many scanners act as automated keyboards, sending keystrokes derived from barcodes, there are several ways to handle this. The simplest way is to include a button immediately following the data entry field and use this button to trigger FieldChange. But this got us thinking about another scenario:

How do you trigger FieldChange if you use JavaScript to update a data entry field?

 The process involves three steps:

1. Use JavaScript to update a data entry field. The JavaScript might look something like this:

document.getElementById('MYRECORD_MYFIELD_ID').value = 'The new value';

2. Stage field changes by triggering the onchange handler

document.getElementById('MYRECORD_MYFIELD_ID').onchange();

3. Trigger PeopleSoft's Ajax processing

submitAction_win0(document.win0, id);

Notice the win0 in step 3? That is a system-generated name that reflects the current window ID. PeopleSoft uses the Meta-HTML %FormName at design time.

Here is a short example I put together for the PeopleTools 8.59 Event Mapping configuration page, complete with HTML element IDs, that demonstrates using %FormName. The purpose of the fragment is to set the service name for an event and trigger PeopleSoft processing:

Please note: this is an unsupported example that worked for a specific use case but may not work for others. We provide it as an example of what's possible and as a starting point for your own solution.

Are you interested in learning more PeopleSoft Fluid tips and tricks? Be sure to enroll in one of our upcoming events!

Configuring Fluid Job Data Drop Zones

The new Fluid Job Data component is incredibly configurable. I love the four new Drop Zones right in the middle of the page. But there is just one problem: they are labeled Drop Zone 1, Drop Zone 2, Drop Zone 3, and Drop Zone 4. And they are collapsed, so a user would have to expand each one to find out what is inside. Wouldn't it be great if we could use Page and Field Configurator to change the labels or hide unused regions? The Drop Zone labels come from Group Boxes, and today, Page and Field Configurator doesn't support Group Boxes. Since the code is trivial, we believe this is a simple oversite the development team could remedy. If you agree, please up-vote our idea Page and Field Configurator: Add Group Boxes fields list.

The good news is Event Mapping supports any record and field combination. If we can locate the record and field associated with any group box, we can use Event Mapping to hide it or change its label. This brings us to another challenge. At this time, none of the Drop Zone group boxes are associated with fields. We put in an idea for this: Make Drop zone 1-4 on Fluid Job Data Configurable through PFC and/or Event Mapping. If you think this is a good idea, please up-vote it as well.

While we wait for a proper Oracle-delivered configurable solutions, I want to share with you how we used Event Mapping, JavaScript, and CSS to solve this problem:

PeopleSoft Fluid Accordion: Default to Open State

The Fluid Accordion is fantastic for organizing information. My favorite place to use it is in the left sidebar (Side Page 1, Master/Detail, and PSL_TWOPANEL). But it has one interesting quirk: it defaults to closed. Wouldn't it be nice to have PeopleSoft default one of the accordion headings to expanded? We haven't found a property or delivered approach, but we do have a workaround. Check out the 10-minute video below for details. Here is our solution in a nutshell:

1. Add a custom style class to the accordion heading group box you want to be expanded (we named ours jsm_expanded). This CSS style class acts as an identifier or selector.
2. Add JavaScript to locate the selector and invoke the click action of the chosen heading.

Here is what that JavaScript would look like:

document.querySelector('.jsm_expanded .ps-link').click();

You can use this JavaScript as-is with the AddOnloadScript PeopleCode function but as the video demonstrates, Master/Detail requires a slightly different approach.

I love the flexibility of Fluid. It is so much easier to inject JavaScript and CSS into Fluid. Are you interested in learning more? We cover the Accordion and related challenges and workarounds in our Fluid 2 course. Be sure to check out the details and register for our next offering.

Did enjoy this PeopleTools Sound Byte? There is more where that came from! Check us out on YouTube and be sure to subscribe for more content!

A Refresh-able URL

I find development to be an iterative process. I often create a shell of a program (module, component, page, etc.), just enough to test, and then run my first test. I then iteratively enhance the program (module, component, page, etc.), verifying and validating each change. For online PeopleSoft pages and components, this often means pressing the browser refresh button a LOT! But here is the problem: each time I refresh a PeopleSoft component, PeopleSoft reverts to the search page. After selecting a search value, I'm then directed to the first page in the component. What if I'm testing a different page? Is it possible to craft a URL to bypass component search and open a different page within the component? Yes! We can bypass component search by placing level 0 search key field names and values in the URL. Likewise, we can specify the starting page by placing the Page=... parameter in our URL. But if you don't know the component's search keys and the target page's name, do you have to find them in Application Designer? Fortunately, no. Every PeopleSoft page contains a JavaScript variable named strCurrUrl. This variable contains the current full URL, including search keys and Page parameter. Here is an example of a URL we might use to open the Job Earnings Distribution page of the JOB_DATA component for an employee with the ID KU0001:

http://hr92u030.example.com:8000/psp/ps/EMPLOYEE/HRMS/c/ADMINISTER_WORKFORCE_(GBL).JOB_DATA.GBL?EMPLID=KU0001&EMPL_RCD=0&PAGE=JOB_DATA_ERNDIST

For the last several years, we have been showing customers a simple JavaScript console trick to move the strCurrUrl JavaScript variable into the browser's address bar, allowing us to bypass search and navigation when testing PeopleSoft pages. The real trick to this, though, is that Fluid and Classic behave a little differently, requiring different JavaScript. So today, I want to share a simple JavaScript fragment that you may use across Classic and Fluid. This small snippet is "smart" enough to apply the correct rule on Fluid or Classic. It also has a little logic to detect Classic content in Fluid Activity Guides and Fluid WorkCenters. Please note that using this script with a Fluid Activity Guide/WorkCenter will open Classic content outside of the WorkCenter/Activity Guide frame, but then for testing purposes, that is often desirable.

OK... so... wait, it gets better. Why copy and paste that script into the JavaScript console every time you want to invoke it? Why not just create a browser bookmark or favorite to accomplish this task (also known as a bookmarklet)? Here is the same script in bookmark form. Simply drag this hyperlink into your browser's bookmarks bar and you have a bookmark you may use on almost any PeopleSoft component to get a refresh-able URL.

PS Refresh-able

Are you interested in more tips like this? Jim Marion shares tons of them in his training classes. Register today for one of our upcoming classes!

Changing the Search Page Operator Version 2

In 2011, just after PeopleTools 8.50 released, I wrote the post Changing the Search Page Operator. In that post, I demonstrated how to Monkey Patch PeopleSoft to do something you can't do with core PeopleTools: change the default advanced search page operator from Begins With to Between. A lot has changed since I wrote that initial post:

• PeopleSoft switched from net.ContentLoader to net2.ContentLoader,
• PeopleSoft released Branding System Options, which supports global JavaScript injection,
• We began using RequireJS to manage JavaScript dependencies, and
• The default user experience switched from Classic to Fluid.

Let's create a new version. Before writing any code, let's discuss that last bullet point. This post will focus on Classic. Why? Two reasons:

1. Fluid doesn't use traditional search pages built from search record metadata and
2. Roughly 95% of the components in PeopleSoft are still Classic.

This new version of the code will take advantage of Branding System Options and JavaScript dependency management. Our scenario will use the Job Data component (Workforce Administration > Job Information > Job Data. We will cause the Name search operator to default to between:

Let's start by creating JavaScript definitions for each library. Download the following libraries directly from their sources:

• RequireJS
• jQuery

In your PeopleSoft system online, navigate to PeopleTools > Portal > Branding > Branding Objects. Switch to the JavaScript tab and create a JavaScript definition for each item. So that your names match our RequireJS configuration, use the names JSM_JQUERY_JS and JSM_REQUIRE_JS. For compatibility reasons, we should also protect our version of jQuery from any other versions of jQuery that may be loaded by PeopleTools. To do this, we create a library named JSM_PRIVATE_JQ_JS that contains the following code:

Next we need a RequireJS configuration that tells RequireJS how to locate each library we intend to use. I named mine JSM_REQUIREJS_CONFIG_JS, but this name is less important because we will select it from a prompt when configuring Branding System Options. Here is our RequireJS configuration:

Note: I snuck an extra library into the RequireJS configuration. Can you figure out what it is? I will be demonstrating this extra library at my session for OpenWorld 2019. Don't worry about removing it, however. As long as we don't reference it, RequireJS will never attempt to load it.

We must create one more JavaScript library to "listen" to page changes, waiting for PeopleSoft to load an advanced search page. Create a library containing the following code. As with the previous, name isn't as important because we will select the name from a list of values during configuration. But in case you are struggling with a creative name, I named mine JSM_SEARCHOP_JS.

Your list of JavaScript files should now look something like:

After uploading our libraries, we can turn our attention to configuration. Navigate to PeopleTools > Portal > Branding > Branding System Options. In the Addtional JavaScript Objects (this should really be named libraries) section, insert the following three libraries in order. Order matters. We first want RequireJS. We then configure RequireJS. Finally, we use RequireJS.

1. JSM_REQUIRE_JS
2. JSM_REQUIREJS_CONFIG_JS
3. JSM_SEARCHOP_JS

About the code that makes all of this happen (JSM_SETSEARCHOP_JS)... It is incredibly similar to the first version. One important difference is that this version is loaded globally whereas the prior iteration was locally scoped to the component. We therefore include a component-specific test. The %FormName Meta-HTML in our JavaScript helps us derive the HTML element that contains the component name. The fieldMap variable contains the mapping between component names and fields that should be changed.

Will this work in Fluid? Unfortunately, no. Fluid does not use search record metadata to generate search pages. It can (with a little work), but not in the same fashion. Fluid also doesn't support branding system options Additional JavaScript Objects. JavaScript automation is still possible, but requires a different approach (Event Mapping to inject, different variables, etc).

Are you interested in learning more about PeopleTools, JavaScript, and HTML? Attend one of our courses online or schedule a live in-person training session.

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
• JSON.org 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: JSON.org 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 json.org 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

JSON.org 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 json.org? 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 JSON.org 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 jsmpros.com.

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 jsmpros.com.

Event Mapping: Fluid Landing Page "Dot" Buttons

The bottom of a Fluid landing page contains dots that identify how many landing pages the user can view as well as the position of the current landing page within the user's landing page collection. This piece of information is quite useful on a swipe-enabled mobile device, but somewhat meaningless on my mac. A few months ago I was helping a PeopleSoft customer with their Fluid implementation. This rather brilliant customer made those dots clickable to navigate between landing pages. To implement this behavior, the customer modified delivered PeopleTools JavaScript and CSS definitions, which, unfortunately, presents a bit of an upgrade problem. In a recent webinar I mentioned that one of the things that excites me about Fluid is that everything is a component. What that means is we can use Event Mapping anywhere. Landing Pages are no exception. With that in mind, I wondered what this solution would look like with Event Mapping.

Those little dots at the bottom of the page are created through JavaScript. To enhance them, therefore, we will need to write some JavaScript. Because the original implementation of this behavior modified delivered PeopleTools JavaScript, the author was able to leverage existing JavaScript variables and functions. To avoid customizing PeopleTools, we will need to extract the relevant JavaScript and rewrite it in a standalone manner, meaning no dependencies on PeopleTools JavaScript. We'll start with a CSS selector to identify dots: .lpTabIndicators .dot. We will iterate over that dot collection, adding a click event handler to each dot. That click event handler needs to know the target tab on click so we need another CSS selector to identify tabs: .lpTabId span.ps_box-value. For compatibility reasons, I'm not going to use any libraries (like jQuery), just raw JavaScript:

(function () {
    "use strict";
    // include protection just in case PS inserts this JS twice
    if (!window.jm_config_dots) {
        window.jm_config_dots = true;
        var originalSetTabIndicators = window.setTabIndicators;

        // MonkeyPatch setTabIndicators because we want to run some code each
        // time PeopleSoft invokes setTabIndicators
        window.setTabIndicators = function () {

            // JavaScript magic to invoke original setTabIndicators w/o knowing
            // anything about the call signature
            var returnVal = originalSetTabIndicators.apply(this, arguments);

            // The important stuff that adds a click handler to the dots. This
            // is the code we want to run each time PS invokes setTabIndicators
            var dots = document.querySelectorAll('.lpTabIndicators .dot'),
                tabs = document.querySelectorAll('.lpTabId span.ps_box-value'),
                titles = document.querySelectorAll('.lpnameedit input');

            [].forEach.call(dots, function (d, idx) {
                d.setAttribute('title',titles[idx].value);
                d.addEventListener("click", function () {
                    lpSwipeToTabFromDD(tabs[idx].innerHTML);
                });
            });

            return returnVal;
        };
    }
}());

Funny... didn't I say we would start with a CSS selector? Looking at that code listing, that CSS selector and the corresponding iterator don't appear until nearly halfway through the listing. When testing and mocking up a solution, the objects you want to manipulate are a good place to start. We then surround that starting point with other code to polish the solution.

This code is short, but has some interesting twists, so let me break it down:

• First, I wrapped the entire JavaScript routine in a self-executing anonymous JavaScript function. To make this functionality work, I have to maintain a variable, but don't want to pollute the global namespace. The self-executing anonymous function makes for a nice closure to keep everything secret.
• Next, I have C-style include protection to ensure this file is only processed once. I don't know this is necessary. I suspect not because we are going to add this file using an event that only triggers once per component load, but it doesn't hurt.
• The very next line is why I have a closure: originalSetTabIndicators. Our code needs to execute every time PeopleSoft invokes the delivered JavaScript setTabIndicators function. What better way to find out when that happens than to MonkeyPatch setTabIndicators? setTabIndicators creates those little dots. If our code runs before those dots are created, then we won't have anything to enhance. Likewise, when those dots change, we want our code to be rerun.
• And, finally, redefine setTabIndicators. Our version is heavily dependent on the original, so first thing we want to do is invoke the original. As I stated, the original creates those dots, so it is important that we let it run first. Then we can go about enhancing those dots, such as adding a title and a click handler.

In Application Designer (or online in Branding Objects), create a new HTML (JavaScript) definition with the above JavaScript. I named mine JM_CLICK_DOTS_JS. You are free to use whatever name you prefer. I point it out because later we will reference this name from an Application Class, and knowing the name will be quite useful.

If we stop our UX improvements here, the dots will become clickable buttons, but users will have no visual indicator. It would be nice if the mouse pointer became a pointer or hand to identify the dot as a clickable region. We will use CSS for this. Create a new Free formed stylesheet for the following CSS. I named mine JM_CLICK_DOTS.

.lpTabIndicators .dot:hover,
.lpTabIndicators .dot.on:hover {
    cursor: pointer;
}

With our supporting definitions created, we can move onto Event Mapping. I detailed all of the steps for Event Mapping in my post Event Mapping: Extending "Personal Details" in HCM. According to that blog post, our first step is to create an App Class as an event handler. With that in mind, I added the following PeopleCode to a class named ClickDotsConfig in an Application Class appropriately named JM_CLICK_DOTS (noticing a pattern?). Basically, the code just inserts our new definitions into the page assembly process so the browser can find and interpret them.

import PT_RCF:ServiceInterface;

class ClickDotsConfig implements PT_RCF:ServiceInterface
   method execute();
end-class;

method execute
   /+ Extends/implements PT_RCF:ServiceInterface.execute +/

   AddStyleSheet(StyleSheet.JM_CLICK_DOTS);
   AddJavaScript(HTML.JM_CLICK_DOTS_JS);
end-method;

After creating a related content service definition for our Application Class, the only trick is choosing the Landing Page component content reference, which is a hidden content reference located at Fluid Structure Content > Fluid PeopleTools > Fluid PeopleTools Framework > Fluid Homepage

Probably the trickiest part of this whole process was identifying which event to use. For me the choice was between PageActivate and PostBuild. The most reliable way I know to identify the appropriate event is to investigate some of the delivered component PeopleCode. What I found was that the same code that creates the dots, PTNUI_MENU_JS, is added in PostBuild. Considering that our code MonkeyPatches that code, it is important that our code run after that code exists, which means I chose PostBuild Post processing.

Using Event Mapping we have effectively transformed a customization into a configuration. The point of reducing customizations is to simplify lifecycle management. We now have two fewer items on our compare reports. If Oracle changes PTNUI_MENU_JS and PTNUI_LANDING_CSS, the originally modified definitions, these items will no longer show on a compare report. But!, and this is significant: you may have noticed my JavaScript is invoking and manipulating delivered PeopleSoft JavaScript functions: setTabIndicators and lpSwipeToTabFromDD. If Oracle changes those functions, then this code may break. A great example of Oracle changing JavaScript functions was their move from net.ContentLoader to net2.ContentLoader. I absolutely LOVE Event Mapping, but we can't ignore Lifecycle Management. When implementing a change like this, be sure to fully document Oracle changes that may break your code. This solution is heavily dependent on Oracle's code but no Lifecycle Management tool will identify this dependency.

Question: Jim, why did you prefix setTabIndicators with window as in window.setTabIndicators? Answer: I am a big fan of JSLint/JSHint and want clean reports. It is easier to tell a code quality tool I'm running in a browser than to define all of the globals I expect from PeopleSoft. All global functions and variables are really just properties of the Window object. The window variable is a browser-defined global that a good code quality tester will recognize. The window prefix isn't required, but makes for a nice code quality report.

New Window Bookmarklet

I am a "New Window" link junkie. I use that link ALL THE TIME! If it were possible to wear it out, mine would be worn out. I wish all PeopleSoft pages had the "New Window" link. For some reason, however, certain developers chose to remove it from specific PeopleSoft pages (such as Structure and Content). I'm sure there is a good reason... there just has to be. So seeing it missing from Fluid has been a significant struggle for me. I'm thankful for Sasank's Fluid UI - New Window Feature - Workaround customization. For quick access to a new window without customization, I have a Bookmarklet, which is a JavaScript fragment masquerading as a favorite (or bookmark). Here is the JavaScript:

(function() {
  var parts = window.location.href.match(/(.+?\/ps[pc])\/(.+?)(?:_\d+?)*?\/(.*)/);
  window.open(parts[1] + '/' + parts[2] + '_newwin/' + parts[3], '_blank');
}())

To add it to your bookmark toolbar, drag the following link into your link toolbar:

PS New Window

This solution is simple, but may not satisfy your requirements. This bookmarklet assumes you want to open a new window to the URL displayed in the address bar. That URL may or may not match the actual transaction. If you want a bookmarklet that opens a new window specifically targeting the current transaction, then try this bookmarklet:

(function() {
  var href = window.location.href;
  var parts = (!!frames["TargetContent"] ? !!frames["TargetContent"].strCurrUrl ? frames["TargetContent"].strCurrUrl : href : href).match(/(.+?\/ps[pc])\/(.+?)(?:_\d+?)*?\/(.*)/);
  window.open(parts[1] + '/' + parts[2] + '_newwin/' + parts[3], '_blank');
}())

To use it, drag the following link into your bookmark toolbar:

PS New Window

Special shout out to David Wiggins, who posted a similar bookmarklet on my Where is My New Window Link? post as I was writing this blog post.

Dynamic Java in PeopleCode

The PeopleCode language has a lot of features and functions. But sometimes, it seems there are tasks we need to accomplish that are just out of reach of the PeopleCode language. It is at these times that I reach for Java. I have written a lot about Java, so I'm sure many of you already know how to mix Java with PeopleCode. While certainly a rational solution, one of the pain points of a Java solution is managing custom Java on the app and process scheduler servers. Each time you update your compiled class (or jar) files, you have to restart the server. That might be OK in a stable production environment, where you don't intend to change code often, but in development, it is a real pain! Likewise, maintaining custom Java class and jar files through upgrades can be a little sketchy. Specifically, if you redeploy PeopleTools or rewrite psconfig, then it is possible you may miss some of your custom Java code. PeopleBooks tells us how to setup psconfig for custom Java classes, but again, that is just one more thing to manage through upgrades. Now, imagine being able to update your custom Java code with a Data Mover script. Further, imagine being able to run custom Java without making any changes to your application server. Imagine what it would be like to run Java without having to beg (or bribe) your admin for a "no customization" exception. It is possible today. The answer: Use JavaScript to interface between PeopleCode and the delivered Java Runtime Environment. Through the embedded Mozilla Rhino JavaScript script engine of Java, we have full, dynamic access to the JRE. When and how would you use this? Let's review some examples.

Custom HTTP Connections

For various reasons, some customers choose not to implement Integration Broker. These customers find themselves requiring integration, but without IB's networking features. An alternative to %IntBroker.ConnectorRequestURL is to use Java's HttpURLConnection.I strongly discourage this approach, but the question arises. The JRE is there, well integrated with PeopleCode, and ready for use. From PeopleCode, it is possible to create a Java URLConnection using CreateJavaObject("java.net.URL", "http...").openConnection(). A problem arises when we try to invoke methods of a HttpURLConnection, the real return value of URL.openConnection. Unfortunately, PeopleCode doesn't see it that way, which leads down the reflection path (we don't want to go there). This is where JavaScript can help us. JavaScript doesn't mind that URL.openConnection returned an HttpURLConnection even though it said it would just return a URLConnection. Here is an example:

var result = (function() {
    // declare pointers to Java methods to make it easier to invoke the methods
    // by name later
    var URL = Packages.java.net.URL;
    var InputStreamReader = Packages.java.io.InputStreamReader;
    var BufferedReader = Packages.java.io.BufferedReader;
    var StringBuilder = Packages.java.lang.StringBuilder;
    
    var serverAddress = new URL(
            "http://hcm.oraclecloud.com/hcmCoreApi/atomservlet/employee/newhire"
        );
    
    
    // Creates an HttpURLConnection, but returns URLConnection. If I was using
    // PeopleCode, PeopleCode would see this as a URLConnection. To invoke
    // HttpURLConnection methods, I would need to resort to reflection. This is
    // the power of JavaScript in this scenario...
    var connection = serverAddress.openConnection();

    // ... for example, setRequestMethod is NOT a method of URLConnection. It is
    // a method of HttpURLConnection. PeopleCode would throw an error, but
    // JavaScript recognizes this is an HttpURLConnection and allows the method
    // invocation
    connection.setRequestMethod("GET");
    
    // Timeout in milliseconds
    connection.setReadTimeout(10*1000);
    
    // Finally, make the connection
    connection.connect();

    // Read the response
    var reader  = new BufferedReader(
        new InputStreamReader(connection.getInputStream()));
    var sb = new StringBuilder();
    var line;
    
    while ((line = reader.readLine()) !== null) {
      sb.append(line + '\n');
    }
    
    // Return the response to PeopleCode. In this case, the response is an XML
    // string
    return sb;
}());

Excel Spreadsheets

PeopleTools 8.55+ has a PeopleCode API for Excel, which means this solution is now irrelevant. I'm listing it because not everyone is up to PeopleTools 8.55 (yet). If you use this idea to build a solution for 8.54 and later upgrade, Oracle recommends that you switch to the PeopleCode Excel API. The solution will still work with 8.55+, but just isn't recommended post 8.54.

This solution uses the Apache POI library that is distributed with PeopleTools 8.54+ to read and write binary Microsoft Excel files. As with the networking solution above, it is possible to use POI directly from PeopleCode, but a little difficult because POI uses method overloading in a manner that PeopleCode can't resolve. Furthermore, POI uses methods that return superclasses and interfaces that PeopleCode can't cast to subclasses, leading to awful reflection code. Here is an example that reads a spreadsheet row by row, inserting each row into a staging table for later processing.

// endsWith polyfill
if (!String.prototype.endsWith) {
  String.prototype.endsWith = function(searchString, position) {
      var subjectString = this.toString();
      if (typeof position !== 'number' || !isFinite(position) ||
            Math.floor(position) !== position ||
            position > subjectString.length) {
        position = subjectString.length;
      }
      position -= searchString.length;
      var lastIndex = subjectString.indexOf(searchString, position);
      return lastIndex !== -1 && lastIndex === position;
  };
}

// open a workbook, iterate over rows/cells, and then insert them into a
// staging table
var result = (function() {
    // declare pointers to Java methods to make it easier to invoke the methods
    // by name
    var FileInputStream = Packages.java.io.FileInputStream;
    
    var HSSFWorkbook = Packages.org.apache.poi.hssf.usermodel.HSSFWorkbook;
    var Workbook = Packages.org.apache.poi.ss.usermodel.Workbook;
    var XSSFWorkbook = Packages.org.apache.poi.xssf.usermodel.XSSFWorkbook;
    
    // declare a PeopleCode function
    var SQLExec = Packages.PeopleSoft.PeopleCode.Func.SQLExec;

    // internal "helper" function that will identify rows inserted into 
    var guid = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g,
        function(c) {
            var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
            return v.toString(16);
        }
    );
    
    // open a binary Microsoft Excel file
    var fis = new FileInputStream(fileName);
    
    var workbook;
    
    if(fileName.toLowerCase().endsWith("xlsx")) {
        workbook = new XSSFWorkbook(fis);
    } else if(fileName.toLowerCase().endsWith("xls")) {
        workbook = new HSSFWorkbook(fis);
    }
    
    var sheet = workbook.getSheetAt(0);
    var rowIterator = sheet.iterator();
    var roleName,
        descr,
        row;

    // iterate over each row, inserting those rows into a staging table
    while (rowIterator.hasNext()) {
        row = rowIterator.next();
        roleName = row.getCell(0).getStringCellValue();
        descr = row.getCell(1).getStringCellValue();
        
        // TODO: turn this into a stored SQL definition, not hard coded SQL
        SQLExec("INSERT INTO PS_JM_XLROLE_STAGE VALUES(:1, :2, :3, SYSTIMESTAMP)",
            // notice that the SQLExec parameters are wrapped in an array
            [guid, roleName, descr]
        );
    }
    
    // return the unique identifier that can later be used to select the rows
    // inserted by this process
    return guid;

}());

Here is an example of writing/creating a Microsoft Excel spreadsheet:

var result = (function() {
    // import statements
    var XSSFWorkbook = Packages.org.apache.poi.xssf.usermodel.XSSFWorkbook;
    var FileOutputStream = Packages.java.io.FileOutputStream;

    // variable declarations
    var workbook = new XSSFWorkbook();
    var sheet = workbook.createSheet("Countries");
    var fileName = "c:/temp/countries.xlsx";
    
    var row = sheet.createRow(0);
    var cell = row.createCell(0);

    cell.setCellValue("United States of America");
    cell = row.createCell(1);
    cell.setCellValue("USA");

    row = sheet.createRow(1);
    cell = row.createCell(0);
    cell.setCellValue("India");
    cell = row.createCell(1);
    cell.setCellValue("IND");

    row = sheet.createRow(1);
    cell = row.createCell(0);
    cell.setCellValue("Denmark");
    cell = row.createCell(1);
    cell.setCellValue("DNK");

    var fos = new FileOutputStream(fileName);
    workbook.write(fos);
    fos.close();
    
    return "Created workbook " + fileName;

}());

JSON Parsing

If your goal is to convert a JSON string into SQL insert statements, then this is a very painless alternative:

/* Sample JSON data that will be selected from a record definition
[
    {"emplid": "KU0001", "oprid": "HCRUSA_KU0001"},
    {"emplid": "KU0002", "oprid": "HCRUSA_KU0002"},
    {"emplid": "KU0003", "oprid": "HCRUSA_KU0003"}
];*/

var result = (function() {
    var CreateRecord = Packages.PeopleSoft.PeopleCode.Func.CreateRecord;
    var Name = Packages.PeopleSoft.PeopleCode.Name;
    var SQLExec = Packages.PeopleSoft.PeopleCode.Func.SQLExec;
    
    // example of how to reference a PeopleCode record definition from
    // JavaScript. Later we will select JSON_DATA from this table
    var rec = CreateRecord(new Name('RECORD', 'NAA_SCRIPT_TBL'));

    var count = 0;
    var json_string;
    var json;

    var guid = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {
        var r = Math.random()*16|0, v = c == 'x' ? r : (r&0x3|0x8);
        return v.toString(16);
    });
    
    // Select JSON string from a table. Normally this would come from a variable,
    // a service, etc. Here it makes a great example of how to select rows from
    // a record definition
    rec.GetField(new Name('FIELD', 'PM_SCRIPT_NAME')).setValue('JSON_TEST_DATA');
    rec.SelectByKey();
    json_string = rec.GetField(new Name('FIELD', 'HTMLAREA')).getValue();
    
    // now convert that received string into an object.
    json = JSON.parse(json_string);

    // Iterate over json data and...
    json.forEach(function(item, idx) {
        // ... insert into a staging table
        SQLExec("INSERT INTO PS_NAA_TEST_TBL VALUES(:1, :2, :3, SYSTIMESTAMP)",
            // notice the array wrapper around SQLExec bind values
            [guid, item.emplid, item.oprid]
        );
        count += 1;
    });
    
    return "Inserted " + count + " rows";
    
}());

I could go on and on with examples of creating zip files, encrypting information, base64 encoding binary data, manipulating graphics using Java 2D, etc, but I think you get the idea.