Join us Thursday, June 10th for a full day of free fantastic live virtual PeopleSoft education sessions led by PeopleSoft community experts from around the world! Check out the agenda. Times are listed in Central Europe, Eastern, and Pacific.
Wednesday, June 02, 2021
As programmers, we look for patterns. And when we find them, we refactor them into reusable code. Keep it DRY: Don't Repeat Yourself. PeopleCode offers two reusable code containers:
- Function Libraries
- Application Classes
And this brings us to the great debate. Which is better? Object-oriented App Classes or procedure-based Function Libraries? I often ask my students this question. And if they prefer one over the other, why? Let's review the benefits of each:
- Must be declared
- Dynamic execution
There are other differences, but they are irrelevant for this comparison. For example, Application Classes have inheritance (some would say inheritance is NOT a benefit). The value of inheritance is reuse, but then a function can call a function, which is also reuse.
When asking students about their preference, here are a few of my favorite answers:
- Choose App Classes because they are new.
- Choose App Classes because they are object-oriented.
- Choose App Classes because we are supposed to.
- Choose App Classes because everyone is doing it.
- Choose Function Libraries because they work!
One of the most valuable features of App Classes is dynamic PeopleCode. Unlike Function Libraries, App Classes do not have to be imported/declared before use. This is how every PeopleTools framework works. As a developer, we create an App Class and register it with the framework. At runtime, the framework reads the metadata and invokes the App Class. A framework such as AWE, for example, knows nothing about my custom App Class. But it invokes my code nevertheless through functions such as CreateObject, ObjectDoMethod, ObjectGetProperty, and ObjectSetProperty.
Which one do I choose? Here are my decision criteria:
- If I need dynamic PeopleCode, meaning no declaration, then the only solution is an App Class. Another way to think about it is if I'm writing code that invokes another code block and I don't know that code block at design time, but will fetch the name from the database, then I have to use an App Class.
- If I'm writing code to plug into another framework, such as Event Mapping or Integration Broker, I will use an App Class.
- If I want testable code to test through PSUnit, I will create an App Class (because PSUnit is a framework that will invoke dynamic code).
- If I need to maintain state between method invocations, I'll choose an App Class.
- Otherwise, I choose a Function Library.
Which do you prefer and why? What are other benefits of one over the other? Leave a comment to let us know what you think!
At JSMpros, we recognize the value of Application Classes and offer a two-day course dedicated to teaching object-oriented best practices. In fact, our next session starts on August 9, 2021. Register now!
Tuesday, May 25, 2021
Do you have customzations? Do customizations slow down selective adoption? The answer, of course, is "Yes" to both questions. Our best practice is to move customizations into configurations through Event Mapping, Page and Field Configurator, Drop Zones, etc. Configuration alternatives remove changes from lifecycle management, allowing us to alter the PeopleSoft experience without the impact and overhead of a customization... or do they? It is true; configuration alternatives don't show on compare reports. They move our "customizations" into a separate layer, a runtime injected layer, allowing Oracle to swap the backend code. Another way to think of it is that configuration alternatives automate applying customizations.
Let's review a quick scenario. Let's say there is a field on a page, and you are supposed to remove it. Simple task. The PeopleCode would be
record.field.visible = False; If we customized, we would add that code to a design-time event, such as PostBuild. As a configuration, however, we would put that code in an App Class and then use Event Mapping to inject the code at runtime. So the value of configuration is that you don't have to reapply code changes. They are injected at runtime.
So here is a question:
When you re-apply a customization, is design-time code merge (copy/paste) the only thing you do?
Of course not! You also analyze. You investigate. Is the customization still necessary? Is it still relevant? Do you need to refactor around Oracle's changes? You still need to ask all of those questions. Even as a configuration, not a customization, you still must answer the same questions because it is the same code. It is the same solution. It solves the same problem. And, if you customized, you would have a compare report showing you what to review and where. Context. This is proactive. But with configuration? Silence. Without a compare report, how do you know what to review? How do you know what changed? Wait for testers to catch it? Wait for go-live? This is reactive.
Let's continue with the hidden field/Event Mapping example, and you go through a selective adoption or get current cycle. Since you used Event Mapping, your code is still there. But again, should you review it? How do you know what to review? What if Oracle agrees with our "hidden field" assessment and removes that field? Because we used Event Mapping, our code is still there, but it would refer to a field that is no longer in the component buffer, and will fail. What proactive lifecycle management tool is going to help you identify this issue? Without a compare report, how do you know what requires analysis? These are fantastic questions!
One way to locate conflicts is through regression tests. Each time I create a configuration (Drop Zone, Event Mapping, Page and Field Configurator, etc.), I record a test. That test proves my configuration still works. After each get current, I can run my regression test suite and see what fails. Test metadata will point to the change request, etc. so I know what to repair and where. I bet you are already doing regression testing. Everyone does. We usually call it "End User Testing." It might be a formal process but may not include change request documentation, etc. It is more like, "Hey, that thing that used to work is broken again." Alternatively, we recommend PeopleSoft Test Framework (PTF). The PTF metadata (comments, etc.) would contain the change request details. When the test fails, we can easily drill to the supporting documentation. This is proactive.
At this point, you might be saying, "We would LOVE to do that, but we haven't implemented PTF." But here is my question. Do you have to "implement" PTF to use it? Can't you, as a developer, just start recording regression tests against your configurations? That is what we recommend, and that is what we teach in our two-day PTF training course. You already have it. It's just waiting for you to start using it.
Our next PTF course starts in a couple of days, so be sure to register here ASAP! Or, purchase our On-demand PTF training course and get 60-days access to digitally mastered content to learn PTF whenever and wherever.
New to configuration? We regularly offer event mapping, drop zones, and Page and Field Configurator classes. Check out our website to see what we are offering next! Prefer On-demand? Take a look at our new On-demand Drop Zones course and learn on your own time.
Wednesday, March 24, 2021
Announcing PeopleSoft Integration Day! Are you ready to learn Fluid? Or, do you already know Fluid, but want to learn more? Join us online Thursday, May 20, 2021 for a full day Fluid Development Experience! Space is limited so register now!
Here are some of the topics we will cover and questions we will answer:
Classic versus Fluid
Both Classic and Fluid use App Designer to create solutions. Both support drag and drop page design. So what are the differences? And if you know Classic, what do I need to learn to be proficient with Fluid?
Isn't Fluid mobile? If so, why aren't my grids responsive? What mobile-friendly options exist for grids?
Drag and Drop
PeopleSoft homepages allow us to drag and drop tiles. AWE allows us to drag and drop fields. How can I implement Drag and Drop on my own Fluid pages?
What does it take to create a branding theme for a PeopleSoft instance? How do you brand both Classic and Fluid? Do I have to use Branding Macros with Fluid? Are there alternatives?
Where can I use Drop Zones? What can I do with them? What if a component doesn't have Drop Zones? Are there limitations with Drop Zones? Since Drop Zones and Event Mapping don't appear in compare reports, how do we know what to review after a system update?
PeopleSoft Test Framework (PTF)
How do you implement PTF? Are there any challenges to using PTF with Fluid? Are there special considerations for PTF with Event Mapping and Drop Zones?
Do you have a group of 10 or more? Contact us at firstname.lastname@example.org for a quantity discount!
Wednesday, March 17, 2021
Most PeopleSoft implementations have some sort of firewall/load balancer appliance in front of PeopleSoft. As an administrator, one question we have to answer is, "Where do we terminate SSL?" And the answer seems so obvious, most don't even ponder the question. What is the obvious answer? Terminate at the load balancer. Why? Because that is why they exist. SSL/TLS is what they do, and they do it well. What's the alternative? Carry SSL all the way to Weblogic, and terminate at the PeopleSoft web server. Weblogic is amazing at what it does, but it isn't a security appliance. And that is why the obvious answer is to terminate at the load balancer. But here is my question:
Are you reencrypting the traffic between the load balancer and PeopleSoft?
Do you encrypt all the way to Weblogic or do you terminate at the load balancer, thereby passing sensitive information in plain text behind the firewall?
Over the last several years I have heard fantastic security presenters recommend SSL termination at the load balancer level (for good reason). But they always end encryption at the load balancer. They don't encrypt behind the firewall. Why not? The most common reason is performance. Encryption isn't free. And if encryption is expensive, why encrypt behind the firewall? Here are two reasons:
- Your network might not be as secure as you think it is. A great example is NASA's breach implemented through a Raspberry PI.
- PeopleSoft-delivered service operations expect encryption.
- Carry SSL/TLS all the way to Weblogic or
- Modify the Service Operation.
Monday, March 01, 2021
Did you know there is a vibrant PeopleSoft Open Source community? PeopleSoft is the most flexible ERP solution available. If we need additional functionality, we can build it. And that is exactly what several talented developers have done, and they've shared their solutions with us. Check out some of these amazing open-source projects and repositories:
- PeopleSoft Directory Viewer, Slack Plugin, Read/Write Excel
- Trace Viewer, Versioning, DMS Viewer
- Online PeopleCode editor, JSON Classes
- PeopleSoft Admin Utilities such as psadmin+, ps-vagabond, etc
- UMN Admin Scripts and Resources
- PSUnit Unit Testing Framework
- Kafka Streams and PeopleSoft
- Ricardo Wood's PeopleSoft Projects
- PeopleSoft XML Library
- Dialog Parameters, PeopleCode Templates
- PeopleTools OAuth Project
- Sasank Vemana's Github Repo
- Universal CI Handler
- Dynamic JSON Parser
- Sample REST Handler
Wednesday, February 24, 2021
In our Integration Day 2021 One-day Webinar, we showed how to send SMS from PeopleSoft through Twilio. What makes Twilio interesting is that Twilio expects URL encoded form data. As you may know from using Integration Broker, PeopleSoft is quite happy sending and receiving JSON or XML. But what about other content types, such as
application/x-www-form-urlencoded? You may know that you can set most HTTP headers using something like:
&request.IBInfo.IBConnectorInfo.AddConnectorProperties("Content-Type", "application/x-www-form-urlencoded", %Header);
That's a mouth full! But the weirdest thing happens when trying that trick with URL encoded form data. PeopleSoft URL encodes the entire body! Wait, isn't that correct? No, actually. When you and I create the body, we create the proper key=value&key2=value2 pairs. Proper URL encoded form data would look something like this:
Keys, ampersands, and equals signs should not be encoded (unless part of the value). But PeopleSoft URL encodes everything as if there were no keys. Here is what that same string above looks like when PeopleSoft finishes with it:
It is just supposed to URL encode the values. Or better yet, just let us URL encode the values. What's the workaround?
&request.SegmentContentType = "application/x-www-form-urlencoded";
This solution is a little strange because we aren't using a multi-part, segmented message, but it works!
While performing research for this post, I came across MOS Doc ID 2187249.1, which asks for an enhancement to allow additional, hopefully even custom, Content Types, so it appears URL encoded form data isn't the only issue. But lucky for us, we have
SegmentContentType as a workaround!
Are you interested in learning more about PeopleSoft Integration Broker and integration strategies? Join one of our live virtual top-rated Integration Tools Update courses!