This chapter contains the following topics:
Debugging is the method you use to determine the state of your program at any point of execution. Use debugging to help you solve problems and to test and confirm program execution.
Use a debugger to stop program execution so you can see the state of the program at a specific point. This enables you to view the values of input parameters, output parameters, and variables at the specified point. When program execution is stopped, you can review the code line-by-line to check such issues as flow of execution and data integrity.
You use Oracle's JD Edwards EnterpriseOne Event Rules Debugger to debug interactive applications, reports (batch applications), and table conversions.
Use the debugging process to determine where problems occur and then fix those problems. Isolate each problem to a particular area, and then examine exactly how the program operates in that area.
If you change your program while you are debugging with the JD Edwards EnterpriseOne Event Rules Debugger, you must:
Exit the application.
Rebuild debug information.
Reset breakpoints.
Rerun the application.
Features available in the event rule debugger are listed and described in this table:
| Feature | Description |
|---|---|
| Go | Command that resumes program execution after a breakpoint is reached. |
| Breakpoint | Command that tell the debugger to stop when a particular line is reached. You can set breakpoints on lines of code where you want to start debugging. |
| Delete Breakpoint | Command that removes all breakpoints that you currently have set. |
| Step, Step Over | Command that executes the current line of code. Step lets you run the program one line at a time. You can use this feature to determine the results of every line of code as it is executed. |
| Step Into | Command used when the current line of code contains a function call. The debugger will step into the function so that it can be debugged line by line. When the function is complete, the debugger returns to the next line of code after the function call in the calling routine. Step Into can be used to debug a second application that is called from within an application. |
| Disconnect | Command that disconnects the debugger from the current application. The application continues to run as if the debugger had not been started. |
You can use several strategies to make debugging faster and easier. Begin by observing the nature of the problem.
If the program is ending unexpectedly, the cause is likely an unhandled exception. It is an easy problem to track down if it is happening in the same place: simply set breakpoints at strategic points throughout the code and run the program until you find the problem.
If other objects are missing, termination is more abrupt. Remember to transfer all Media Object (also called Generic Text) objects correctly. If an application has a Row exit to an application that does not exist, an unhandled exception in the program occurs immediately.
Termination of the program is more abrupt and less helpful when other kinds of objects are missing. You must review all of the pieces of your application to verify that they are all present and correctly built. A common error is to overlook media objects. If you cannot enter your program at all, a missing object is most likely the problem.
Incorrect program output typically indicates a flaw within the logic of the code. To help find the error:
Set a breakpoint in the code prior to the point where the bad output is produced.
Step through the ER line by line, while monitoring the values of relevant ER variables.
At some point, a variable will probably take on an erroneous value that subsequently produces incorrect output.
If that point occurs before your breakpoint, set another breakpoint earlier in the code and restart the application.
Continue this process until you find the statement that is causing the wrong value to be assigned to the variable.
Spend some time thinking about where the source of the problem might be. If you don't know which ER event is causing an error, try to isolate it. For example, you might be able to temporarily disable the ER one event at a time to see if the error still happens. You can try to repeat the processing of a single event by doing unnatural actions in the GUI, like toggling up and down between grid rows to force the execution of the Row Is Exited event. There are no predefined debugging strategies that will work in any given situation. Be creative and be persistent, until you narrow down the problem to its source.
You can output to a file a log of SQL statements and events by changing the line in your jde.ini file under [DEBUG] from Output = NONE to Output = FILE, as in this sample. This is a useful debugging tool when you have narrowed a problem to a specific issue involving the JDEDB APIs.
[DEBUG] TAMMULTIUSERON=0 Output=FILE ServerLog=0 LEVEL=BSFN,EVENTS DebugFile=c:\jdedebug.log JobFile=c:\jde.log Frequency=10000 RepTrace=0
The jdedebug.log file can become very large when you set the Output=DEBUG flag. It is very difficult to work through all the log messages and correlate them to what was happening in the application. One way to aid in this process is to set breakpoints in the ER, and each time the application stops at a breakpoint, make a separate copy of the jdedebug.log file. Label each copy, and when you are done, you will have narrowed down the coverage of each portion of the jdedebug.log file a bit.
This section provides an overview of the JD Edwards EnterpriseOne Event Rules Debugger and discusses how to:
Debug an application with the JD Edwards EnterpriseOne Event Rules Debugger.
Inspect or modify a variable.
The JD Edwards EnterpriseOne Event Rules Debugger provides the essential debugging tools (such as breakpoints, step commands, and variable inspection) that you need to debug JD Edwards EnterpriseOne interactive and batch applications. You can debug both NERs and table ER. The generated debug information for an application includes NER and table ER information for that application.
Setting up and using JD Edwards EnterpriseOne Event Rules Debugger involves these steps:
Launch the ER Debugger.
Load into the Debugger the applications to debug.
Set any desired breakpoints.
Launch the application, report, or table conversion.
Step 4 may be done at any point before, during or after steps 1, 2, or 3.
Step 2 takes a few minutes. The Debugger must read all the specs for the application, and then translate them into a usable format (Debugging Information Archive, or DIA). For large applications, this is slow. Therefore, once you load an application, you don't want to have to reload it again any time soon (unless you modify the application, of course). For this reason, the ER Debugger provides a Deactivate feature. Deactivating an application prevents any debugging from occurring on that application. But when you are ready to debug the application later, you won't have to rebuild the DIA.
Any event on which you want the debugger to stop must have at least one line of ER code. You cannot set a breakpoint on a comment. When you debug an application and encounter a point at which the interactive or batch application fails, you can view the code that the application is currently executing, and inspect the live values of variables used in the code.
By observing specific variables while the program runs, you can isolate where the program begins to fail and what exactly it is doing. For example, if a counter is supposed to increment by 1, but you observe it incrementing by random numbers, you know there is a problem with the number or variable you are adding to the counter.
The JD Edwards EnterpriseOne Event Rules Debugger is a standalone tools program. Its screen interface consists of these main components:
Object Browse window.
Object Tree (those applications currently loaded in Debugger).
Event Rules window (ER listing).
Breakpoint Manager.
Variables List and Variable Watch window.
All windows except the Event Rules window are dockable to any side of the main application. You can click and drag a window to dock it. When you close the JD Edwards EnterpriseOne Event Rules Debugger, it saves your docking settings until the next time you run it. Most of these main windows may also be closed by clicking the large toolbar buttons which control them, or by clicking the 'X' in the top border of the window.
The Object Browse window is used to locate applications to load into the debugger. It provides three tab pages, one for interactive applications, one for UBEs, and one for TCs. You can find the object you want to debug in one of these lists, and then select it in order to bring it into the debugger.
Once you are done loading objects into the Debugger, you may want to close, or hide, the Object Browse window, because it takes up screen space that could be more usefully dedicated to one of the other Debugger windows. To hide this window, toggle the Object Browse Window button in the toolbar, or use the View menu.
The Object Tree view lists applications that have debug information built and are available for debugging. You can navigate through a tree structure to a specific event and open an Event Rules window for that event. If one of the objects is a power form with subforms, the subforms are listed under the power form. Form IDs appear next to the form name.
Each Event Rules window displays the ER for one event. The event name and path, along with an abbreviated description, appear in the title bar for each Event Rules window. The Event Rules window shows the line in the ER that is currently being executed when the runtime engine is stopped on a line break.
The left side of an Event Rule window displays icons that describe the state of a line in the ER. States include breakpoint, disabled, or current line of execution.
You can use the Event Rules window to set and remove breakpoints. You can use any of these methods:
Double-click the line in ER.
Right-click a line and select Insert Breakpoint or New Breakpoint from the pop-up menu.
Select a line and press F9.
Single click in the margin to the left of the ER text.
You cannot set a breakpoint on a comment line. The breakpoint automatically goes to the first code line after the comment. You cannot set a breakpoint on a data structure member displayed in the ER listing. The breakpoint will automatically go to the function call above it that "owns" the data structure.
The ER window is also useful to show the values of ER variables during a debugging session. The value of a variable in the ER listing can be instantly displayed by moving the mouse cursor over the variable. Its value will appear in a Tool Tip window when the ER Engine is paused (when stopped on a breakpoint or when stepping through code in the debugger).
Variables spelled differently in the ER listing and the variable list will not display.
When the program is halted at a breakpoint, you can examine the state of your runtime structures and evaluate ER variables using the Variable Tree and Variable Watch windows.
The Variable Tree and Watch window consists of two panes. The left pane is the Variable Tree pane. It contains a tree structure that lists the variable types as parent nodes and the variables of each variable type as child nodes. The variables displayed are those that are in scope of the currently displayed event in the Event Rule window. The right pane is the Watch pane. It displays variables you select and their most recently known values. Each variable is identified by its category, name, and the Id of the form, if any, to which it belongs. You can add a variable to the Watch pane by double-clicking the desired variable in the Variable Tree, or you can right click on the variable in the Variable Tree and select "Watch Variable" to add it to the Watch list.
You can change the value of variables while you are debugging an application, in order to better understand what effect that might have on subsequent ER execution. This is a powerful feature, which can also mess up your program execution and create unwanted side effects. Use it carefully. To change the value of a variable, the application must be stopped at a line of ER. Double-click the variable in the Watch pane and enter a different value. If the ER engine running the application accepts the new value, the new value appears in the Watch pane. If you enter an inappropriate value (for example, you change a numeric value to an alpha value) the new value is not set and the value is not changed. In any case, the Debugger displays the actual, resulting variable value.
These special values are displayed for variables:
blank
The value for the variable contains only blanks. This value applies to string and character types only.
null
The variable has no value, or a null or empty value.
unknown
The value for the variable could not be obtained from the runtime engine. When adding a variable to the watch list, the initial value is always unknown. The value is also unknown when the applications are not running, or when the variable is out of scope.
Note:
Variable inspection and modification is not available for debugging NERs and table ER.You use breakpoints to define where or when to halt the execution of a program. The Breakpoint Manager tracks the breakpoints that are set and the location of those breakpoints in an application. When you set a new breakpoint, the system creates an entry in the Breakpoint Manager. This entry contains the application name, form name, event name, ER line number, and the breakpoint conditions, if any.
Right-click within Breakpoint Manager to perform these operations:
Delete a breakpoint.
Delete all breakpoints.
Display the ER window in which the breakpoint is set.
Access breakpoint properties.
Enable or disable a breakpoint.
You can also double-click an entry in Breakpoint Manager to open the Event Rule window in which the breakpoint is set.
Normal breakpoints are indicated by a red circle.
Breakpoint conditions are indicated by a question mark inside the red circle.
A disabled breakpoint is indicated by a hollow circle in the ER listing.
Formerly, ER breakpoints existed with no apparent properties. Breakpoints now have Condition and Hit Count properties which may be set or examined in the Breakpoint Properties dialog.
To set a breakpoint condition in the form of a logical expression:
In the Breakpoint Properties dialog click the Condition button.
The Breakpoint Condition dialog will now display. In this window you may enter the condition in the available field or click the Help button. The Help button brings up a dialog that documents the syntax for breakpoint conditions to assist in creating a condition.
Note:
For example one might write a condition using the format of "VariableName = LiteralValue". The resulting condition might be PO cSelfServiceMode='1'.After entering a condition, the developer may use the Validate Condition button to validate the expression.
Note:
Checking the Condition checkbox in the Breakpoint Condition dialog enables the Condition. If the Condition checkbox is not checked then the condition is saved for possible later use, but is not effective.To avoid unnecessary problems it is best to:
Validate breakpoint conditions as you create them.
Spell variable names exactly as they appear in the variable list, including spaces and special characters where present.
It is possible to set an invalid condition on a breakpoint. There may even be times when you would do this intentionally. Invalid conditions fail when evaluated. It is good practice to utilize the Validate Condition button to validate conditions as you create them.
Misspelled variable names are invalid, of course. The official spelling for all variables is shown in the Debugger's variable list.
Out-of-scope variables are invalid, depending on the context of the breakpoint in which the condition is set.
Any other syntax violations make an expression invalid.
The Debugger does not validate date and number formats. This validation is done at runtime, and may depend on certain User Options.
The second Breakpoint property is the Hit Count condition. The Hit Count condition specifies a certain number of times the breakpoint must be reached before the debugger will stop on it.
The Hit Count dialog is used by the developer to specify a Hit Count condition. It also shows the current hit count, that is, the number of times the breakpoint has been reached since the hit count condition was created.
When both an expression Condition and a Hit Count condition are set on a single breakpoint, the debugger stops on the breakpoint if either condition is met.
A breakpoint may be disabled. A disabled breakpoint retains all its conditions and other properties, but the debugger does not stop on a disabled breakpoint.
Invalid breakpoint conditions are logged to jdedebug.log each time the breakpoint having the invalid condition is reached.
You can use the Search combo box on the tool bar to search for ER text. Enter the text that you want to find in the Search combo box and then press either Enter or F3. If the system locates the search text in your ER text, it highlights the text. If you press Enter or F3 again, the next occurrence of your search text is located and highlighted.
The search control accommodates regular expression searches. A regular expression search uses special characters to match text. For example, ^If: will find every line that starts with If and If$: will find every line that ends with If.
The special characters that you can use for advanced searches are described in this table:
| Character | Description |
|---|---|
| ^ | The caret (^) indicates the beginning of a line. For example, the expression ^A matches an A only at the beginning of a line. |
| ^ | The caret (^) immediately after the left bracket ( [ ) is used to exclude any remaining characters within brackets from matching the target string. For example, the expression [^0-9] indicates that the target character should not be a digit. |
| $ | The dollar sign ($) matches the end of a line. For example, the expression abc$ will match the substring abc only if it is at the end of a line. |
| | | The alternation character (|) enables the expression on either side of it to match the target string. For example, the expression a|b will match a as well as b. |
| . | The dot (.) matches any character. |
| * | The asterisk (*) indicates that the character to the left of the asterisk in the expression should match 0 or more times. |
| + | The plus (+) is similar to the asterisk except that at least one match of the character should occur to the left of the + sign in the expression. |
| ? | The question mark (?) matches the character to its left 0 or 1 times. |
| () | The parentheses affect the order of pattern evaluation and serve as a tagged expression that you can use to replace a matched substring with another expression. |
| [ ] | Brackets that enclose a set of characters indicate that any of the enclosed characters can match the target character. |
To debug an application with the JD Edwards EnterpriseOne Event Rules Debugger:
From the Cross Application Development Tools menu (GH902), select Debug Application.
Select the object that you want to debug.
Select a form (for interactive applications) or section (for batch applications) and an event to view.
Select the ER line on which you want to set a breakpoint.
Select Debug, Breakpoint.
A red dot appears on the line, indicating the breakpoint.o You can remove the breakpoint by choosing Debug, Breakpointagain. The Breakpoint command is a toggle, and you can also toggle the value using the Breakpoint toolbar button.
Run the application.
As your application encounters a breakpoint, the application will pause, and the focus will switch to the Event Rules Debugger.
When execution stops at a breakpoint, you can use the variables view to inspect and modify the values of runtime structures.
From the Debug menu, select one of these options:
Go
Disconnect
Step Over
Step Into