Top Five PeopleTools Technologies to Learn in 2021

Today is the first day of 2021! Have you set training goals? To finish 2020, we sorted courses by enrollment. Based on training interest and enrollment, here were the top five requested courses from 2020:

1. Fluid

It is no surprise that Fluid tops the list of training initiatives. Here are some reasons why

• Strategy: Fluid is PeopleSoft's strategic direction. All new PeopleSoft development happens in Fluid.
• Modern and mobile: Unlike Classic, Fluid is awesome on a mobile device.
• Support: Some Classic components have retired, replaced by their Fluid functional equivalent.

2. Integration Technologies such as REST and JSON

What do Chatbots, Texting (Twilio), Elastic Search, Multi-factor authentication, and Cloud have in common? They are all services outside PeopleSoft that require REST integration. So, just like Fluid, seeing integration at the top of the priority list is no surprise.

3. Application Classes

We've had object-oriented PeopleCode for decades, but without much adoption. I believe today's interest in Application Classes is based on PeopleTools frameworks. Here are a few of the PeopleSoft features that require Application Classes:

• Integration Broker
• Approval Workflow Engine
• Event Mapping
• Campus Solutions COMMGEN

Add to that nearly every new Fluid page using an Application Class as its PeopleCode container, and we can see why Application Classes are in the top five!

4. PeopleSoft Test Framework (PTF)

One of the primary benefits of Cloud is that Cloud solutions are always current. With Selective Adoption, your on-premise PeopleSoft has the same potential, but only if you can stay current. And end-user testing is a clear barrier to staying current. The more we can automate, the faster we can apply maintenance. There seems to be a direct relationship between currency and automation.

But with that said, I have one reason I think everyone should implement automated testing, and that is Configuration. Event Mapping, Page and Field Configurator, and Drop Zones are fantastic ways to transform customizations into configurations. But here's my problem with configurations: no compare reports. Every customization offers a compare report showing changes. Configurations don't. In fact, that is the point of a configuration. Our whole reason for configuring is to move changes into a layer above Oracle's delivered code. But configuration doesn't eliminate review. For example, configurations may reference fields that no longer exist, and will therefore fail at runtime. This is one of the challenges with configurations: no formal review process. This is a gap that I believe PTF can fill. I believe we should pair every configuration with a PTF test (or several tests). After each maintenance cycle, we can run our battery of tests to prove our configurations are still valid. Test failures immediately show us which configurations require review. Here's a short video showing an example:

5. Configuration

With selective adoption, continuous delivery, cloud pressure, support policies, and a steady stream of amazing new features, it is more important than ever that we stay current. And customizations are the enemy of currency. We can therefore, reduce the cost of getting current by replacing customizations with configurations. Page and Field Configurator, Drop Zones, and Event Mapping are some of the most important recent PeopleTools and Enterprise Components additions. Keep an eye on our online learning portal. We'll be releasing several configuration modules as on-demand recorded training.

6. Learn Something Outside PeopleTools

This is supposed to be a top-five list, but I couldn't stop. And I don't want you to stop either. Don't stop with PeopleTools. Learn something outside the traditional PeopleTools stack. If I could recommend one language to learn, it would be JavaScript. JavaScript is not a traditional PeopleTools technology, but it is the primary language of the PeopleSoft user interface. It is also the primary language of every website and the core of many Oracle PaaS frameworks.

At JSMpros, we teach all of these technologies regularly. Check out our website for our latest course offerings. Do you have a group of developers to train? Contact us for discounted group rates!

Is PeopleSoft Fluid Mobile-ready? Setting the Browser Viewport

Zoomed-out Fluid page on an iPhone

Have you created a Fluid component yet? Have you tested it on mobile? What did you see? Did it work as expected? When I created my first Fluid component, what surprised me was the zoom factor. My mobile device rendered Fluid content as if it were Classic. Sure, it had nice big Fluid buttons, but my mobile browser zoomed out so much that I thought I was looking at Classic, not Fluid. My first question was, "Why? Why is it doing that?" Without contrary instruction, a mobile browser will scale to fit a page. You would think a responsive page would scale accordingly, but it doesn't. It scales at large form factor, which is zoomed out. My next question was, "Isn't Fluid mobile?" Actually, Fluid has the potential to be mobile, but no. Fluid by itself is not mobile. The Fluid framework seems to be missing the meta Viewport tag, the tag that tells a mobile browser how to scale content. So how do we set the Viewport? At its core, we set the Viewport using the AddMetaTag PeopleCode function, and you are welcome to use it, but I don't recommend it. Instead, use PT_PAGE_UTILS:Utils.SetDefaultViewport. This App Class method handles the Viewport meta tag for us, including known operating-system issues. With that said, a basic Fluid component without a Flex grid is fully mobile if we set the Viewport. So is Fluid mobile? The correct answer is Fluid + PeopleCode = Mobile.

With which event should we invoke SetDefaultViewport? I've seen it in a lot of PageActivate code, but let's think about that for a minute... every time you switch between pages within a single component, PeopleSoft invokes PageActivate. Do we need to call SetDefaultViewport with every page change? No, just once per component. Meta tags exist in the head section of the rendered HTML, downloaded on the first component load, and subsequently updated upon request. So which event then? I prefer component PreBuild. Either PreBuild or PostBuild will work just fine. PostBuild triggers after the component buffer loads and usually contains a lot of component buffer manipulation logic. Setting the meta tag has no impact on the component buffer, and I hate to clutter a messy PostBuild with unrelated PeopleCode 😉.

How does Oracle handle this meta-issue? Any new component uses PT_PAGE_UTILS:Utils.SetDefaultViewport almost exclusively in one of those three events: PageActivate, PreBuild, or PostBuild. But if you review original Fluid components (early HCM, for example), you will find a mixture of AddMetaTag and SetViewPort Function library calls.

Setting the Viewport is a fundamental principle we teach in our Fluid Basic (Fluid 1) course. Checkout fluid.jsmpros.com to see when we are offering it next. Would you prefer to learn at your own pace? We cover this topic in our one-day on-demand training course Fluid Basic Development. Or, purchase the Fluid 1 Bundle and save! Do you have a group of developers to train? Contact us for special group pricing!