Hosted by Chandra Wobschall and Paul Houtkooper
How many of you have had a moment where the business says, “We need to control who can change that”? On this episode of The JDE Connection, we continue our conversation with Haiyan Wang, Senior Principle Software Engineer and the architect behind Logic Extensions (LEX) and take leveraging LEX one step further. Last time, we explored how LEX can help you control behavior inside JD Edwards forms. This time, we connect the dots between LEX, Form Extensions, and Workflow. Things get really interesting because now we’re not just talking about changing how a screen behaves; we’re talking about governing business processes.
When a Simple Change Isn’t So Simple
Think about something that seems straightforward on the surface: updating a vendor’s mailing address. In many organizations, that’s not just a quick edit. It’s something that needs oversight. Maybe someone needs to review the change. Maybe it needs approval. Maybe it needs to be tracked. Historically, solving that kind of requirement could easily lead to customization. But what if you could control that process directly inside the application without customizing it?
That’s exactly the scenario we explore in this episode.
Haiyan walks us through an example where a vendor address can’t simply be edited on the form. Instead, users trigger a specific action that initiates a governed process behind the scenes as illustrated below.
Figure 1 – Address Book Revision Before and After
Fields are controlled, behavior changes based on the application version, the user gets prompted with a new window to submit a change to the mailing address, and a workflow gets kicked off to review the change.
Figure 2 – Prompt for Address Change Workflow
All without modifying the underlying application.
The Real Power: Combining Extensions
One of the biggest takeaways from this conversation is how powerful the combination of Form Extensions and Logic Extensions can be.
Together, they allow you to:
- Control which fields users can interact with
- Change behavior depending on application versions
- Trigger workflows based on user actions
- Implement governance around sensitive changes
For example, below Haiyan associates multiple Logic Extensions with various events to display the Update Mailing push button based on version, disable the form controls, and initiate the Address Change Workflow.
Figure 3 – Form Extension with multiple Logic Extensions
And the key theme that keeps coming up in the conversation is de-customization. Instead of modifying the application itself and manipulating the behavior via Client-side Named Event Rules (see Figure 1 for a comparison), you’re layering behavior around it in a way that is far more upgrade-friendly and maintainable.
Figure 4 – Client-side Named Event Rule vs Logic Extension
That’s a big deal.
A Little Behind the Curtain
We also spend some time talking about something that many JD Edwards users have asked about over the years – form extensions by version.
If you’ve ever wondered why you cannot create a form extension for each version (ZJDE0001, ZJDE0002, etc,.) of an application, there’s actually a very good architectural reason for that – there’s only one version of the application itself, not multiple. There are multiple processing option versions. For those familiar with using Form Design Aid (FDA) to develop applications, Haiyan asks, have you ever checked out and modified a specific ZJDE version of an application? Once this explanation clicks, it becomes apparent why you can only have one Form Extension per form.
Does that invalidate the business requirement to control the behavior of a form by processing option version? Of course not and that is where LEX comes to the rescue!
For Business Analysts and Developers Alike
Another interesting theme that comes up in the episode is who this capability is really for.
On one hand, it opens the door for business analysts to prototype solutions and explore ideas without immediately jumping into customization requests. On the other hand, some of the concepts like events, conditions, and data structures still benefit from collaboration with developers.
In other words, it’s not about replacing developers. It’s about bringing more problem-solving capability closer to the people defining the requirements.
And that can accelerate how solutions come together.
Midwesternism of the Day
This week’s glimpse into Midwest cultural comes from the fine state of Minnesota, where winter isn’t just a season, it’s a community activity.
Every year, residents are invited to participate in a statewide tradition involving very large pieces of municipal equipment and an impressive amount of wordplay. Thousands of people submit their most creative ideas; the public votes, and a fleet of hardworking machines end up carrying names that sound suspiciously like rock bands, pop stars, and extremely enthusiastic dad jokes.
Let’s just say if you appreciate puns, snow, and civic pride wrapped into one delightfully quirky tradition, you would feel right at home.
Until next time, let’s keep learning, sharing, and most importantly, laughing together.
Toodles!
Missed an episode? Check out the full episode list! Also, be sure to subscribe on your favorite podcast provider, or select a provider below!
Learn More
Quest Oracle Community is where you learn. Ask questions, find answers, swap stories and connect to other JD Edwards customers and product experts in the JD Edwards Community, where you can also check out what’s happening in the Business Analyst SIG.