JD Edwards Development & You: Event Rules Compare

Smartbridge
4 min readJun 29, 2016

--

Event Rules Compare

A Special Tips & Tricks Series

View previous articles:

Software updates are released to address bugs, enable features and improve functionality. But how do you know exactly what updates were released? One way is to utilize Event Rules Compare.

JDE Enterprise One is setup with multiple environments, with some of them being:

PS — Pristine
DV — Development
PY — Prototype
PD — Production

This setup enables the use of a developmental life cycle to control what objects are released into production. Therefore, the objects in production are usually different when compared to the others. This is usually because a customized business process requires a change. Then, the standard objects (APPL, UBE etc.,) are then retrofitted to meet the business needs.

Furthermore, custom reports and applications are also developed based on standard reports provided by Oracle. In both cases, when you need to identify what changes have occurred, Event Rules Compare is a handy tool that can be used to note the differences between the objects.

JDE Development Lifecycle overview

In this article, we’ll compare an object to introduce you to the subtleties of Event Rules Compare. Plus, we’ll help you focus on key items that can help make your job easier when comparing two objects.

You will need access to a JDE FAT Client, and an application (APPL) or a report (UBE) that you would like to compare. We’ll be using the application P01012, and we will be comparing Production against Pristine.

To access Event Rules Compare, Login to your FAT Client and access Object Management Workbench.

  1. Add and select the report — P01012, in your project
  2. Select “Row”, then “Advanced Get”, from “PD900”
  3. Then select the report “P01012”, and select “Design”
  4. Select “Design Tools”
  5. Select “ER Compare”
  6. Type the environment to which we will compare the object — “PS900”

Event Rules Compare

Event Rules Compare

There are three views to get accustomed to upon initial loading of Event Rules Compare:

1 — Events with Differences

2 — Event rules window (Target [Blue]/ Local [Green])

3 — Application Tree View

Within events with differences, you’ll notice marked in one of four colors:

RED — There’s a difference in Event Rules

GREEN — The difference exists only in your local specification

BLUE — The difference exists only in your target

BLACK — No difference

You can navigate through the difference, in one of many ways as well. You can:

  • Swiftly browse through events with differences, identifying all sections marked in red
  • Use the green arrows, on top of events with differences
  • Cycle through the application tree view, as it only lists all the differences

This is helpful when troubleshooting applications and reports that have seen modification but contain no comments to mark the specific changes. Comparing the object in production to pristine will list all the differences, including any updates or bug fixes released by Oracle.

Furthermore, the updates released by Oracle are also marked as Software Action Request (SAR). Any code introduced into the object will be commented by Oracle, including a SAR number. Therefore, any code that is not commented is most likely a custom change that was introduced.

This ability provided by the application to identify the differences immensely helps, when changes are required or when a system upgrade is necessary. But the icing on the cake, has to be the merge functionality. But be warned, improper use of this functionality could result in undesired results, as you will have consider a few things before merging the code between two different objects. You can also selectively copy or remove single lines of code as needed. However, the changes should be reversed if copying the code invalidates the event rules. A few items to take into consideration are:

  • Variables — Do they exist in both environments? Are there duplicates?
  • IF ELSE — Verify the logic of all conditions
  • WHILE ENDWHILE — Verify the logic of all conditions

Alternatively, I’d strongly suggest that you make note of the changes that exist, and alter them through Form or Report Design Aid, while continuously validating the event rules to verify the functionality of the report or application.

Event Rules Compare is a handy tool, and its applications are intuitive. From software updates, bug fixes to code changes and system upgrades, the tool has a very specific purpose to compare and help JDE developers perform. Not to mention, while the developmental life cycle requires this separation of objects in the different environments, it also helps with maintaining the integrity of a production system. Event Rules Compare is just another tool to help support that developmental life cycle, in continued maintenance and development of a production system.

--

--

Smartbridge
Smartbridge

Written by Smartbridge

We’re geeks for the enterprise systems and tech that sustains and strengthens business. Simplifying business transformation. Smartbridge.com

No responses yet