JD Edwards EnterpriseOne Tools

Development Tools: Event Rules Guide

Release 8.98 Update 4

E14705-02

March 2011

JD Edwards EnterpriseOne Tools Development Tools: Event Rules Guide, Release 8.98 Update 4

E14705-02

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark licensed through X/Open Company, Ltd.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

List of Figures

JD Edwards EnterpriseOne Tools: Event Rules Preface

- Audience

- Documentation Accessibility

- Related Documents

- Conventions

1 Introduction to JD Edwards EnterpriseOne Tools: Event Rules

- 1.1 JD Edwards EnterpriseOne Tools: Event Rules Overview

- 1.2 JD Edwards EnterpriseOne Tools: Event Rules Implementation

- 1.2.1 JD Edwards EnterpriseOne Tools Development Tools: Event Rules Implementation Steps

2 Understanding Events, Event Rules, and Runtime Processing

- 2.1 Events

- 2.2 Event Rules

- 2.2.1 Event Rules Fundamentals

- 2.2.2 Named Event Rules

- 2.2.3 Embedded Event Rules

- 2.2.3.1 Application Event Rules

- 2.2.3.2 Table Event Rules

- 2.3 Runtime Processing of Event Rules

- 2.3.1 Fundamentals of Runtime Processing of Event Rules

- 2.3.2 Runtime Data Structures

- 2.3.2.1 Available Objects and Runtime Data Structures

- 2.3.2.2 Processing Available Objects

- 2.3.2.3 Control is Exited Processing

- 2.3.3 Form Flow

- 2.3.3.1 Pre-Dialog Is Initialized

- 2.3.3.2 Dialog Is Initialized

- 2.3.3.3 Post Dialog Is Initialized

- 2.3.3.4 Building SQL SELECT

- 2.3.3.5 Fetching Records

- 2.3.3.6 Page-at-a-Time Processing

- 2.3.3.7 BC Assigned Database Values

- 2.3.3.8 Grid Record Is Fetched

- 2.3.3.9 Write Grid Line-Before

- 2.3.3.10 Write Grid Line–After

- 2.3.3.11 Last Grid Record Has Been Read

- 2.3.3.12 Select Button Processing

- 2.3.3.13 Button Clicked

- 2.3.3.14 Add Button Processing

- 2.3.3.15 Delete Button Processing

- 2.3.3.16 Delete Grid Rec Verify–Before

- 2.3.3.17 Delete Grid Rec Verify–After

- 2.3.3.18 Delete Grid Rec From DB–Before

- 2.3.3.19 Delete Grid Rec From DB–After

- 2.3.3.20 All Grid Recs Deleted From DB

3 Using Event Rules Design

- 3.1 Understanding Event Rules Design

- 3.2 Understanding Event Rule Validation

- 3.3 Understanding If and While Statements

- 3.4 Understanding ER Consistency

- 3.5 Understanding ER Variables

- 3.6 Prerequisites

- 3.7 Working with Event Rules Design

- 3.7.1 Understanding Assignments

- 3.7.2 Understanding Event Rules Design Tool Bar Buttons

- 3.7.3 Displaying Event Information

- 3.7.4 Assigning a Value

- 3.7.5 Creating an If or a While Statement

- 3.7.6 Creating an ER Variable

- 3.7.6.1 Using Event Rule Variables for Automatic Line Numbering

- 3.7.7 Attaching a System Function to an Event

- 3.7.8 Attaching a Business Function to an Event

4 Using BrowsER

- 4.1 Understanding BrowsER

- 4.2 Working with BrowsER

5 Debugging Event Rules

- 5.1 Understanding Debugging

- 5.2 The Debugging Process

- 5.3 Debugging Strategies

- 5.3.1 Is the Program Ending Unexpectedly?

- 5.3.2 Is the Output of the Program Incorrect?

- 5.3.3 Where Else Could the Problem Be Coming From?

- 5.4 Debug Logs

- 5.5 Debugging Event Rules

- 5.5.1 Understanding the Event Rules Debugger

- 5.5.1.1 Object Browse Window

- 5.5.1.2 Object Tree

- 5.5.1.3 Event Rules Window

- 5.5.1.4 Variable Tree and Watch Window

- 5.5.1.5 Breakpoint Manager

- 5.5.1.6 Breakpoint State Indicators

- 5.5.1.7 Breakpoint with Condition

- 5.5.1.8 Avoiding Problems with Breakpoint Conditions

- 5.5.1.9 Breakpoint with Hit Count Condition

- 5.5.1.10 Disabled Breakpoint

- 5.5.1.11 Invalid Breakpoints

- 5.5.1.12 Search Combo Box

- 5.5.2 Debugging an Application with the Event Rules Debugger

Glossary

Index

List of Figures

- 2-1 Content of runtime structures before Dialog Is Initialized fires

- 2-2 Content of runtime structures before Post Dialog Is Initialized fires

- 2-3 Content of runtime structures before SQL Select statement builds

- 2-4 Content of runtime structures when first record read

- 2-5 Content of runtime structures before Grid Record is Fetched fires

- 2-6 Content of runtime structures when first record is read

- 2-7 Content of runtime structures before Write Grid Line-Before fires

- 2-8 Content of runtime structures after Write Grid Line-Before fires

- 2-9 Content of runtime structures before Write Grid Line-After fires

- 2-10 Content of runtime structures after Write Grid Line After runs

- 2-11 Content of runtime structures before Last Grid Record Has Been Read fires

- 2-12 Content of runtime structures when user selects grid row that is other than the last fetched row

- 2-13 Content of runtime structures before Button Clicked fires

- 2-14 Content of runtime structures before Button Clicked for Add Button fires

- 2-15 Content of runtime structures before delete Button Clicked fires

- 2-16 Content of runtime structure when Delete Grid Rec Verify-Before fires

JD Edwards EnterpriseOne Tools: Event Rules Preface

Welcome to the JD Edwards EnterpriseOne Tools Event Rules Guide.

Audience

This guide is intended for system administrators and technical consultants who are responsible for assembling, building, and deploying packages.

This guide assumes you have a working knowledge of the following:

• The principles and customary practices of your business area.

• Event rules and runtime processing.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/us/corporate/accessibility/index.html.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.

Related Documents

You can access related documents from the JD Edwards EnterpriseOne Release Documentation Overview pages on My Oracle Support. Access the main documentation overview page by searching for the document ID, which is 876932.1, or by using this link:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=876932.1

To navigate to this page from the My Oracle Support home page, click the Knowledge tab, and then click the Tools and Training menu, JD Edwards EnterpriseOne, Welcome Center, Release Information Overview.

This guide contains references to server configuration settings that JD Edwards EnterpriseOne stores in configuration files (such as jde.ini, jas.ini, jdbj.ini, jdelog.properties, and so on). Beginning with the JD Edwards EnterpriseOne Tools Release 8.97, it is highly recommended that you only access and manage these settings for the supported server types using the Server Manager program. See the Server Manager Guide on My Oracle Support.

Conventions

The following text conventions are used in this document:

Convention

Meaning

Bold

Indicates field values.

Italics

Indicates emphasis and JD Edwards EnterpriseOne or other book-length publication titles.

Monospace

Indicates a JD Edwards EnterpriseOne program, other code example, or URL.

1 Introduction to JD Edwards EnterpriseOne Tools: Event Rules

This chapter contains the following topics:

- Section 1.1, "JD Edwards EnterpriseOne Tools: Event Rules Overview"

- Section 1.2, "JD Edwards EnterpriseOne Tools: Event Rules Implementation"

1.1 JD Edwards EnterpriseOne Tools: Event Rules Overview

Oracle's JD Edwards EnterpriseOne Tools for event rules are used to create or modify event rules (ER) in JD Edwards EnterpriseOne applications. Event rules are connected to certain runtime events and instruct runtime how to respond to the conditions you choose to define.

1.2 JD Edwards EnterpriseOne Tools: Event Rules Implementation

This section provides an overview of the steps that are required to implement JD Edwards EnterpriseOne Tools for event rules.

In the planning phase of your implementation, take advantage of all JD Edwards EnterpriseOne sources of information, including the installation guides and troubleshooting information.

1.2.1 JD Edwards EnterpriseOne Tools Development Tools: Event Rules Implementation Steps

The following steps need to be performed before working with JD Edwards EnterpriseOne event rules:

1. Configure Oracle's JD Edwards EnterpriseOne Tools Object Management Workbench (OMW).
See "Configuring JD Edwards EnterpriseOne OMW" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide.

2. Configure OMW user roles and allowed actions.
See "Configuring User Roles and Allowed Actions" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide.

3. Configure OMW functions.
See "Configuring JD Edwards EnterpriseOne OMW Functions" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide.

4. Configure OMW activity rules.
See "Configuring Activity Rules" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide.

5. Configure OMW save locations.
See "Configuring Object Save Locations" in the JD Edwards EnterpriseOne Tools Object Management Workbench Guide.

6. Set up default location and printers.
See "Understanding Report Printing Administration Technologies" in the JD Edwards EnterpriseOne Tools Development Tools: Report Printing Administration Technologies Guide.

2 Understanding Events, Event Rules, and Runtime Processing

This chapter contains the following topics:

- Section 2.1, "Events"

- Section 2.2, "Event Rules"

- Section 2.3, "Runtime Processing of Event Rules"

2.1 Events

Events are activities that occur on a form, such as entering a form or exiting a field by using Tab. Events can be initiated by the user or the application. A single control might initiate multiple events. The system also initiates some events, such as Last Grid Record Has Been Read, when certain actions occur.

2.2 Event Rules

This section discusses:

- Event rules

- Named event rules

- Embedded event rules

2.2.1 Event Rules Fundamentals

Event rules(ER) are logic statements that you can create and attach to events. ER is initiated when events occur at runtime. Oracle's JD Edwards EnterpriseOne software supports two kinds of event rules: named event rules and embedded event rules.

You can attach multiple event rules to one event. The various kinds of event rules include:

- Conditional statements, such as If/Else/End If.

- While loops.

- Assignments.

- Calls to business functions.

- Form or report interconnections.

- Calls to system functions.

- Table I/O operations.

2.2.2 Named Event Rules

A named event rule (NER) is a series of regular ER statements (such as assignments, business functions, system function calls, and so forth). A NER encapsulates the series of statements into one reusable component. You can call a NER the same way as calling a business function. Business functions implement customized business logic using C language; NERs implement customized business logic using event rule statements.

2.2.3 Embedded Event Rules

In addition to NERs, the other kind of ER is called embedded event rules, or simply event rules. Embedded ER is specific to a particular table, interactive application, or batch application. Embedded ER for a table is called table event rules or table triggers. Embedded ER for an interactive application or batch application is called application event rules.

2.2.3.1 Application Event Rules

You can add business logic that is specific to a particular application. Interactive applications connect ER using Oracle's JD Edwards EnterpriseOne Form Design Aid (FDA), while batch event rules use Oracle's JD Edwards EnterpriseOne Report Design Aid (RDA).

2.2.3.2 Table Event Rules

You can create table-specific event rules, which are ER that you attach to a table using Table Design Event Rules. This logic runs whenever any JD Edwards EnterpriseOne application accesses that table and uses that ER. For example, to maintain referential integrity, you might attach ER to a master table that deletes all children when a parent is deleted. Any JD Edwards EnterpriseOne application that deletes information from that table does not need to have embedded parent/child logic, because that logic exists in the table.

Note:
Be aware that this functionality applies only to JD Edwards EnterpriseOne applications. Other applications that access the same database table cannot and do not use these ERs.

2.3 Runtime Processing of Event Rules

This section discusses:

- Runtime processing of event rules.

- Runtime data structures.

- Form flow.

2.3.1 Fundamentals of Runtime Processing of Event Rules

Runtime processing refers to how, at runtime, the system evaluates various events (such as initializing a form, clicking a button, and using Tab to move between fields) and their attached ER. ER is attached to events, which in turn are attached to controls or forms.

FDA provides several different form types, each of which includes predefined fields and features that are specific to the form type. For example, a find/browse form automatically includes a Find menu option or tool bar button with appropriate functions attached to it. When users enter search text in a filter or query-by-example (QBE) field, and then click the Find button on the tool bar, the runtime engine processes logic to fetch a record.

To avoid generating unnecessary ER, you should understand the different field types and associated capabilities that characterize each form type.

2.3.2 Runtime Data Structures

Runtime data structures are structures or blocks of memory that hold data when user is working with an application. You should know what is happening to each form at runtime. You should know what is in a runtime structure at a given event point in the runtime process.

The runtime system dynamically creates runtime data structures. For example, if a form contains hidden controls, the system allocates memory for those controls even though they are not visible on the form. When you pass processing option (PO) values in a form, the system allocates memory to store the PO value.

2.3.2.1 Available Objects and Runtime Data Structures

A runtime data structure is made of a variety of objects on a form. An available object is represented by a two-character, alphabetical code that characterizes the source of data and determines how the object data is used in an interactive application at runtime. Available objects make up the runtime data structure for a form.

During runtime processing, the system stores data in memory in an internal data structure. Certain fields of the data structure temporarily store data during runtime. When no longer needed, the data is deleted so that the system can process another record.

In ER, you can access and modify available objects in order to implement business logic. For example, you can assign a value to a QBE field to set query criteria for the form.

This table lists the available objects:

Available Object Code

Description

BC

A column in the business view (BV). BCs for both the form view and the grid view appear in this list. The system fills these columns with values from the database when it performs a fetch. The system writes these values to the database during an add or update.

GC

A column in the grid. The row that the value references depends on which event is accessing the GC. During the fetch cycle, it is usually the selected row. In some circumstances, CG objects also denote a particular physical column in the grid instead of a value. An example is the Set Grid Font system function.

GB

The grid buffer. This buffer is one row of data that is independent of the lines that the system reads from the database and writes to the grid. The GB enables you to manipulate column data for a line that you want to insert or update without affecting the present state of the grid. You access the GB through an available GB object, which appears after the GC objects in the list of available objects in Event Rules Design. Each grid contains only one instance of each GB column.

FC

A control on the form. If the control is a database item, this field corresponds to a BC object. Furthermore, if the control is not a filter, the FC object represents the same value as the BC object, and changing one of these results in changing both.

FI

A value passed through a form interconnection. You access this object either to read values that are passed into the form or to set values to be passed back. These objects correspond to the elements of the form data structure.

PO

A value passed from a PO. These values are passed into the application when a user launches it. Any form in that application can access them. POs can either be entered by the user, or they can be set up in a particular version of an application.

QC

A cell from the QBE line in the grid. These objects represent the values in any QBE cell on the grid. They include wild cards, but do not include any comparison operators. Likewise, assignments to these objects can include wild cards, but not comparison operators. To set comparisons, you must use a system function.

HC

A hypercontrol item. A hypercontrol item is a menu item or a tool bar item.

VA

ER variables. These objects represent any variables that you set up in ER.

SV

System variables. These objects represent some environment variables that are accessible to ER.

SL

System literals. These objects represent some constant system values that are accessible to ER.

TP

Tab page object.

TK

A column in the table that contains the table ER.

CO

A constant, such as the return code for an error.

TV

Text variables.

RC

Report constants for a batch application.

RV

Report variables (batch application).

IC

An input column (table conversion).

OC

An output column (table conversion).

BC and FC share the same internal structure if an FC is associated with a database item; filter fields are an exception.

2.3.2.2 Processing Available Objects

When an available object is changed through ER, these actions occur:

- The object in the internal runtime structure is changed.

- If the object is a form control or grid cell, row, or column, the screen is updated with the new value.

A BV form control shares the same value as the corresponding business view item. (Filter fields are an exception to this rule.) This means that:

- FC data and BC data are always identical.

- Whenever FC data is changed, BC items are changed to the same value.

- Whenever BC values are changed, the FC runtime values also changes to the same values. This change may not immediately reflected to the screen.

- On Control is Exited processing, the value entered into the form control is captured in both the BC and FC item for that control.

2.3.2.3 Control is Exited Processing

Control is Exited processing includes these actions:

- The value in the control is saved to internal runtime structures.

- The Control is Exitedevent is processed.

If the value has changed since the previous time that the control was exited, these steps occur:

- The system processes the Control Exited/Changed–Inline event.

- The system processes the Control Exited/Changed–Async event.

- The system validates the value using edit rules defined for the DD item.

- The form control data is formatted using format rules defined for the DD item and displayed on the screen.

2.3.3 Form Flow

Each form type has different properties and event flow. The system provides events for the forms so that you can insert custom logic. These events occur regardless of whether you add event rule logic for that event.

This example represents how values in the runtime structures are stored in memory compared to how they appear on the form. This example uses the find/browse form when it is called directly from a menu. The runtime engine processes events in a certain order. The next sections describe the typical events for the find/browse form and the order in which they are processed. This process flow can vary depending on specific user interaction and the event rule logic that you use.

2.3.3.1 Pre-Dialog Is Initialized

These steps occur before the Dialog is Initialized event is processed and the form appears:

- Initialize runtime structures (or clear memory) as shown:

- BC = null.

- FC = null.

- GC = null.

- FI = Values passed from a calling form (if any).

- PO = Values passed from processing options.

- Initialize form controls.

- Initialize error handling.

- Initialize static text.

- Initialize helps.

- Create tool bar.

- Load form interconnect data into corresponding BC columns and filter fields (if any exist).

- Initialize thread handling.

2.3.3.2 Dialog Is Initialized

The system processes all event rule logic that is attached to the Dialog is Initialized event. When this event starts, the runtime structures contain these values:

- BC = Any FI values passed.

- FC = Any FI values passed.

- GC = null.

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

This diagram illustrates the information in the runtime structures just before the system fires Dialog is Initialized:

Figure 2-1 Content of runtime structures before Dialog Is Initialized fires

The Dialog is Initialized event can be used to initialize the form. After the Dialog is Initialized event is finished, runtime starts the Post Dialog Is Initialized process.

2.3.3.3 Post Dialog Is Initialized

Before the system fires the Post Dialog is Initialized event, the runtime structures contain these values:

- BC = null (or values already passed in).

- FC = null (or values already passed in).

- GC = null (or values already passed in).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

This diagram illustrates the information in the runtime structures just before the system fires the Post Dialog Is Initialized event:

Figure 2-2 Content of runtime structures before Post Dialog Is Initialized fires

The Post Dialog is Initialized event is commonly used to perform these tasks:

- Load filter fields that will be used for the WHERE clause in the SQL SELECT statement.

- Load PO values into filter fields.

- Perform any one-time logic for the form, such as fetching a system date.

2.3.3.4 Building SQL SELECT

After the user clicks Find, the system builds a SELECT statement with a WHERE clause. The SQL SELECT statement includes all columns in the BV. The WHERE clause includes any values in the QBE or filter fields. It can also contain values passed through Set Selection and Set Lower Limit system functions. The WHERE clause is then used to get all records that meet the criteria.

This diagram illustrates the information that appears in the runtime structures just before the system builds the SQL statement:

Figure 2-3 Content of runtime structures before SQL Select statement builds

2.3.3.5 Fetching Records

Records are fetched one page at a time (unless page-at-a-time is disabled). The system processes each record fetched one by one and display it in the grid row.

2.3.3.6 Page-at-a-Time Processing

Page-at-a-time processing means that the system fetches only a single page worth of records to display. To see the next page of records, the user clicks the Next button. You can customize the page size for each grid in FDA. A system administrator can also set a global page size for all grids.

Typically, page-at-a-time processing improves performance and scalability. Although it can be disabled, the JD Edwards EnterpriseOne standards state that you should not disable it unless you have a valid business reason to do so.

2.3.3.7 BC Assigned Database Values

After the system fetches each record from the database, it copies the database values to the BC items. Values from each marked column in the table appear in the BC runtime structure elements.

This diagram illustrates the information in the runtime structures when the system reads the first record:

Figure 2-4 Content of runtime structures when first record read

2.3.3.8 Grid Record Is Fetched

The engine then fires the Grid Record is Fetched event. At this point, the runtime structures have these values:

- BC = Values from the database (for the first record read).

- FC = Values from the database (if the fields are database fields).

- GC = null.

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

This diagram illustrates the information in the runtime structures just before the system fires Grid Record is Fetched:

Figure 2-5 Content of runtime structures before Grid Record is Fetched fires

The Grid Record is Fetched event is commonly used to perform these actions:

- Calculate a value for a work field in the grid.

- Suppress a row from being written to the grid.

After the Grid Rec Is Fetched event fires, the BC values are copied into the GC runtime structure.

This diagram illustrates the information in the runtime structures when the system reads the first record:

Figure 2-6 Content of runtime structures when first record is read

2.3.3.9 Write Grid Line-Before

The engine then fires the Write Grid Line-Before event. A this point, the runtime structures have these values:

- BC = Values from the database (from the record just read).

- FC = Values from the database (if the fields are database fields).

- GC = Values from the database (from the previous read).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

This diagram illustrates the information in the runtime structures just before the system fires Write Grid Line-Before:

Figure 2-7 Content of runtime structures before Write Grid Line–Before fires

The Write Grid Line–Before event is commonly used to perform these tasks:

- Suppress a grid row from being written.

- Add logic before the user sees a row on the form.

- Change formatting of a grid column.

- Convert any grid value, such as unit of measure.

- Retrieve additional information for the grid row, such as a description, from tables that are not in the BV.

After the system processes Write Grid Line–Before, the GC elements, which now include the database values for the first record, are copied to the grid cells on the form.

This diagram illustrates the information that appears in the runtime structures now:

Figure 2-8 Content of runtime structures after Write Grid Line–Before fires

2.3.3.10 Write Grid Line–After

The engine then fires the Write Grid Line-After event. At this point, the runtime structures have these values:

- BC = Values from the database (from the first record read).

- FC = Values from database (if the field is a database field).

- GC = Values from the database (from the first record read).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

The system displays the current record in the grid cells.

This diagram illustrates the information in the runtime structures just before the system fires Write Grid Line–After:

Figure 2-9 Content of runtime structures before Write Grid Line–After fires

You typically use the Write Grid Line–After event to add logic after the user sees a row on the form.

This diagram illustrates the information in the runtime structures after the system processes Write Grid Line–After:

Figure 2-10 Content of runtime structures after Write Grid Line After runs

The system continues to read records from the database and performs the same processing steps. When the system reads the next record, it performs these processing steps:

- Assign BC values from the database.

- Process Grid Rec is Fetched ER.

- Assign BC values to GC.

- Process Write Grid Line–Before ER.

- Display values in the grid row on the form.

- Process Write Grid Line–After ER.

This process is repeated until there are no more records fetched.

2.3.3.11 Last Grid Record Has Been Read

When there are no more records fetched from the database, the engine fires Last Grid Record Has Been Read event. At this point, the runtime structures contain these values:

- BC = Values from the database (from the last record read).

- FC = Values from the database (if the field is a database field).

- GC = Values from the database (from the last record read).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

The GC values appear on the last grid row.

This diagram illustrates the information in the runtime structures just before the system runs Last Grid Record Has Been Read:

Figure 2-11 Content of runtime structures before Last Grid Record Has Been Read fires

The Last Grid Record Has Been Read event is commonly used to write total lines to the grid and to display totals that are based on grid values.

2.3.3.12 Select Button Processing

When a user selects a grid row and clicks the Select button, the BC structure stays the same, however the GC structure reflects values on the row that is being selected.

This diagram illustrates the information in the runtime structures when the user selects a grid row that is other than the last fetched row. Note that the BC and GC structures do not contain the same values:

Figure 2-12 Content of runtime structures when user selects grid row that is other than the last fetched row

2.3.3.13 Button Clicked

The engine then fires the Button Clicked event for the Select button. At this point, the runtime structures have these values:

- BC = Values from the database (from the last record read).

- FC = Values from the database (if the field is a database field).

- GC = Values from the selected grid row.

- FI = Values passed from a calling form (if any).

- PO = Values passed from processing options.

This diagram illustrates the information in the runtime structures just before the system fires Button Clicked:

Figure 2-13 Content of runtime structures before Button Clicked fires

The Button Clicked event is commonly used to connect to another form.

Use Repeat Business Rules for Grid to repeat ER when multiple rows are selected.

2.3.3.14 Add Button Processing

Normally, the user does not select a row before an add action, but if a row is highlighted, the system updates the GC values to reflect the selected row values. The system does not update the database just because the user clicks the row.

The engine pauses for the Button Clicked event to be processed. At this point, the runtime structures have these values:

- BC = Values from the database (from the last record read).

- FC = Values from the database (if the field is a database field).

- GC = Values from the database (from the selected row).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

Because this is an add action, the content of GC is irrelevant at this point. BC and GC do not contain the same values.

This diagram illustrates the information that is in the runtime structures just before the system fires Button Clicked:

Figure 2-14 Content of runtime structures before Button Clicked for Add Button fires

You typically use the Button Clicked event for the Add button to interconnect to another form, such as a fix/inspect or headerless detail form on which the system actually performs the add action.

2.3.3.15 Delete Button Processing

When the user selects a grid row and clicks the Delete button, the system does not update the database immediately. The engine first fires the Button Clicked event for the Delete button. At this point, the runtime structures have these values:

- BC = Values from the database (from the last record read).

- FC = Values from the database (if the field is a database field).

- GC = Values from the database (from the selected row).

- FI = Values passed from a calling form (if any).

- PO = Values passed from POs.

This diagram illustrates the information in the runtime structures just before the system fires Button Clicked for the Delete button:

Figure 2-15 Content of runtime structures before delete Button Clicked fires

Next, the Delete Grid Rec Verify–Before event fires.

2.3.3.16 Delete Grid Rec Verify–Before

This diagram illustrates how the engine fires the Delete Grid Rec Verify–Before event:

Figure 2-16 Content of runtime structure when Delete Grid Rec Verify–Before fires

Next, the system displays a pop up window for user to confirm the delete. If the delete is confirmed, the Delete Grid Rec Verify–After event fires.

2.3.3.17 Delete Grid Rec Verify–After

In the Delete Grid Rec Verify-After event, you might want to perform custom logic to verify that the delete is valid. For example, other tables might contain dependant records that prevent this record from being deleted as long as they exist.

The system processes the logic that is attached to this event after the user clicks the OK button in the Verify confirmation form. If the user clicks the Cancel button in the Verify confirmation form, the logic attached to this event does not occur.

Next, the Delete Grid Rec From DB–Before event occurs.

2.3.3.18 Delete Grid Rec From DB–Before

At this point, the runtime structure FC is blank. The system has not yet deleted the record from the database. You can use the Suppress Delete system function in this event to prevent the system from deleting the record :

After the system processes the Delete Grid Rec From DB–Before event, it builds a SQL DELETE statement. Then the system deletes the current record. When user selects multiple records, all selected records are deleted.

2.3.3.19 Delete Grid Rec From DB–After

After the records are deleted from the database, the system fires the Delete Grid Rec From DB After event You might use this event to call a business function to delete information from related tables that are not in the current BV.

2.3.3.20 All Grid Recs Deleted From DB

After all selected records are deleted, the engine fires the All Grid Recs Deleted from DB event. At this point, FC is blank.

3 Using Event Rules Design

This chapter contains the following topics:

- Section 3.1, "Understanding Event Rules Design"

- Section 3.2, "Understanding Event Rule Validation"

- Section 3.3, "Understanding If and While Statements"

- Section 3.4, "Understanding ER Consistency"

- Section 3.5, "Understanding ER Variables"

- Section 3.6, "Prerequisites"

- Section 3.7, "Working with Event Rules Design"

3.1 Understanding Event Rules Design

You can use JD Edwards EnterpriseOne Event Rules Design to create event rule (ER) logic for forms and controls on a form. For example, you want to pass data for a selected record on a find/browse form to a fix/inspect form to revise that record. You need to create a form interconnection ER and attach it to the Select button option for the Button Clicked event.

You can create event rules that perform a large variety of tasks, including:

- Perform a mathematical calculation.

- Pass data from a field on a form to a field on another form.

- Count grid rows that are populated with data.

- Interconnect two forms.

- Hide or display a control using a system function.

- Evaluate If/While and Else conditions.

- Assign a value or an expression to a field.

- Create variables or programmer-defined fields at runtime.

- Perform a batch process upon completion of an interactive application.

- Process table input and output, validate data, and retrieve records.

Before you create an ER, consider which control (form, button, field, grid and so on) you want to add the logic in and what event you want to add the logic for. Answer these questions to determine which event should be used:

- Is the user initializing the form?

- Is the user clicking a button?

- Is the user exiting from a field?

- Is the user changing or exiting from a row?

After you place controls on a form, you can add ERs to any of the event that the control support. Remember that a form is also a control, and you can create logic that the system automatically processes whenever a form event is fired.

You create ERs by clicking the buttons on the tool bar in JD Edwards EnterpriseOne Event Rules Design. Depending on the button that you click, a different work areas appear for creating and manipulating the ER line-by-line. Specific buttons enable you to perform these tasks:

- Attach a business function or system function.

- Create an If/While statement.

- Insert an Else clause in an If statement.

- Assign a value or expression.

- Create a variable.

- Create a form or report interconnection.

- Perform table I/O.

- Find a string in a given ER.

- Add comments in the ER code.

- Print the ER code.

You can cut or copy an ER and paste it in the same event, form, or application or in a different event, form, or application. You can also paste ERs into other applications, such as word processing documents. This feature is useful for documenting the project.

When you paste an ER, the system resolves objects from the source as you paste them. If an object is partially resolved, the system pastes the closest matching object from the destination ER. A comment line appears above the partially-resolved line of event rules and in the status bar to indicate that the object is partially resolved. You can set paste options to display comments before and after a block of pasted ERs. Some objects cannot be resolved in the destination ER. The system disables these lines of ER and displays a comment. For example, an EndIf statement is commented out if its associated If statement is missing.

For criteria statements, the paste operation adds whatever is necessary to maintain a clean, logical structure. For example, if you paste an If statement and no EndIf statement exists, the paste operation adds a matching EndIf statement to make the logic complete.

Use the System Function button to attach predefined system functions to events. For example, you can attach system functions to an event that perform these tasks:

- Hide or display a control.

- Display media objects.

You can attach an existing business function to an event. Business functions include these types of code:

- C code that you generate manually (source language C).

- Named Event Rules (NERs) (source language Event Rules).

You typically use business functions for these purposes:

- Referential integrity, such as deleting secondary records when a master record is deleted, and for editing routines.

- Large and complex calculations that might otherwise overload the runtime engine.

3.2 Understanding Event Rule Validation

When you save an application, the system automatically validates all ERs in the application. If errors occur, details on the ER event, and the control and line number being executed at the time of the error are displayed in a popup window. You can also start the validation in FDA by selectingFile, Validate Event Rules.

The error log that the system creates is stored in a file, such as b9\prod\log\p1234.log (where prod is the environment). If no errors exist, the system does not generate a log.

3.3 Understanding If and While Statements

If and While statements are conditional instructions for an ER. They evaluate conditions and dictate the flow of logic when the ER is activated.

Use the If/While button to build conditional logic into an event. When you create an If statement, the system inserts an Else clause. However, you can use the Delete button to delete the Else clause and then reinsert it using the Insert Else button. When you delete an If or While statement, the system also deletes the associated Else and Endif or Endwhile clauses, but not the lines inside of those statements.

You can drag and drop statements line-by-line to change their sequence. Resequencing ER can result in improper syntax. When you click the Save or OK button, the system verifies the syntax. If it detects syntax errors, you can either disable the ER and continue or edit the ER to eliminate the errors.

To change a statement, double click the line.

To delete a statement, choose the line of the statement, and then click the Delete button.

3.4 Understanding ER Consistency

You can check the consistency of events in JD Edwards EnterpriseOne Event Rule Designer. Events can be either relevant or not relevant. A relevant event is one that is valid and that can be executed by the associated control. A not relevant event is one that is not executed by the associated control because the properties of that control do not create the conditions that cause the events to execute. You can change a not relevant event to a relevant event by updating the properties of the control.

3.5 Understanding ER Variables

An ER variable is a variable that you can use within the ER. You must assign a DD item to an ER variable. The DD item defines the type and default behavior of the variable.

Use ER variables instead of hidden fields. ER variables use fewer system resources at runtime.

After you add an ER variable, you cannot modify it. Instead, you must delete it and create another one.

Each ER variable is available within a scope. The scope of an ER variable determines how you can use it. Different scope options are available for interactive and batch applications. For example, you can:

- Reference a report variable anywhere in the report.

- Reference an ER variable only within the event in which it was created.

After you create an ER variable, it appears in the available objects list in JD Edwards EnterpriseOne Event Rules Designer where you added it. Use the ER variable in ERs just as you would use any available object in the list. If you create an event level variable and do not use it in ERs, FDA automatically deletes it.

The system automatically assigns to each variable one of these prefixes, based on the specified scope:

- frm_ (Form)

- evt_ (Event)

- grd_ (Grid)

- rpt_ (Report)

- sec_ (Section)

3.6 Prerequisites

Before you complete the tasks in this section:

- Create an application with one or more forms.

- Understand the difference between database items and data dictionary (DD) items.

- Understand the relationship between controls, events, and ER.

- Determine the purpose of each form used in the application.

- Answer these questions:

- What logic is required?

- For which control are you creating logic?

- For which event will the logic occur?

- Which runtime structures are affected?

3.7 Working with Event Rules Design

This section provides overviews of assignments and event rules design tool bar buttons, and discusses how to:

- Display event information.

- Assign a value.

- Create an If or a While statement.

- Create an ER variable.

- Attach a system function to an event.

- Attach a business function to an event.

3.7.1 Understanding Assignments

Use an assignment to assign a field with a fixed value or a mathematical expression. For example, you can create an assignment that inserts a default value when the user leaves the field. You can also use an assignment to calculate a value

When you create an expression, calculate only the data items that are of the exact same numerical scale or data type. For example, do not calculate different currencies or decimal figures that represent different decimal values because the result of these calculations might compromise data integrity.

3.7.2 Understanding Event Rules Design Tool Bar Buttons

The Event Rules Design form displays these tool bar buttons for generating different types of statements:

- Event Information
Displays information about event relevance.

- Assignment
Creates an assignment or a complex expression.

- Business Function
Attaches an existing business function.

- System Function
Attaches an existing JD Edwards EnterpriseOne system function.

- If/While
Creates an If/While conditional statement.

- Report Interconnect
Establishes a connection to a batch application or report.

- Form Interconnect
Establishes a form interconnection.

- Else
Inserts an Else clause, which is valid only within the bounds of If and End If.

- Variable
Creates a programmer-defined field.

- Table I/O
Enables ER support for database access. Performs table input and output, data validations, and record retrieval.

3.7.3 Displaying Event Information

To display information about the relevance of an event:

1. On Event Rules Design, select an event.

2. Click the Event Information button.

A not relevant event is displayed in dimmed italic text in the Event combo box. A message box appears that displays any information known to the system about why a not relevant event is not relevant.

3.7.4 Assigning a Value

To assign a value:

1. On Event Rules Design, select an event.

2. Click the Assignment/Expression button.

3. On Assignment, select the To Object that you want to receive the assigned value.

4. Use one of these methods to determine the From/Object Literal value:

- Select a From Object in the right-hand column to create a simple statement: [left-hand column] = [right-hand column].

- Type a literal expression (number, text, and so on) in the text entry box to assign a literal statement: [left-hand column] = [literal].

- Press the ⌊(X) button to create a complex expression or advanced mathematical function using Expression Manager.

3.7.5 Creating an If or a While Statement

To create an If or a While statement:

1. On Event Rules Design, select an event in the Event Rules Design window and click the If/While button.
Each cell in the Criteria Design grid represents a component of the criteria. When you select a cell, a list of valid options appears.

2. Select either the If or While operators.

3. Select a left operand from the list of available data items.
Right-click to sort the available data items by name or object type. If only one type exists, the sort options are unavailable. The system groups the available data items by a variety of object types.

4. Select a logical operator comparison (is equal to, is less than, and so forth).

5. Select a right operand from the object list.

6. To assign a literal, select <Literal>.

7. To create complex If statements, you can select the And option or the Or option, and continue the logic.

3.7.6 Creating an ER Variable

To create an ER variable:

1. On Event Rules Design, click the Variables button.
The Variables form displays different scope options, depending on whether you are working with an interactive application, batch application, or NER.

2. Complete the variable naming field located under the Add button.

3. Click one of the Scope options (Form or Event) depending on the purpose for which you created the variable.

4. If you selected Form Scope and you want to use a grid variable, click the Grid option.

5. Click the DD visual assist to browse for DD items.

6. Select the DD item to which the variable is associated and click the Add button.
The system automatically assigns a prefix to the variable, based on the type of scope that you choose.

3.7.6.1 Using Event Rule Variables for Automatic Line Numbering

You can use event rules to create automatic line numbering in form grids. Automatic line numbering means that each line in the grid will have a unique number and the lines will increment automatically as grid lines are added.

To create automatic line numbering event rules:

1. Create a variable to hold the value of the line number. Use the data dictionary item LNID.

VA frm_LineNumber_LNID

2. Initialize the variable on the Post Dialog is Initialized event.

VA frm_LineNumber_LNID = 0

3. On the Grid Record is Fetched event, number the lines as each line is pulled from the database.

If BC LineNumber > VA frm_LineNumber_LNID

VA frm_LineNumber_LNID = BC LineNumber

End If

4. On the Add Last Entry Row to Grid event, increment the line number and assign the new value to the next available line.

VA frm_LineNumber_LNID = VA frm_LineNumber_LNID + 1

GC LineNumber = VA frm_LineNumber_LNID

3.7.7 Attaching a System Function to an Event

To attach a system function to an event:

1. On Event Rules Design, select an event.

2. Click the ⌊(S) button.

3. Select a category in the System Functions box.

4. Select the system function that you want to attach.

5. In the Available Objects list, select objects to pass to the system function.

3.7.8 Attaching a Business Function to an Event

To attach a business function to an event:

1. On Event Rules Design, select an event.

2. Click the ⌊(B) button.
You can view a description (if one exists) for a business function by choosing Attachments from the Row menu.

3. Select a business function and click the Select button.

4. In the Available Objects list, select objects to pass to the business function.

5. To assign a literal to a business function parameter, select <Literal> in the Available Objects list.

6. Enter a single value and click the OK button.
Range and List are not valid literals to use with business function parameters.

7. Indicate the direction of data flow between Value and Data Items, and click the OK button.
As you click the direction arrow, it toggles through these four options:

- Data flows from the source to the target (right-pointing arrow).

- Data flows from the target to the source (left-pointing arrow).

- Data flows from the source to the target, and upon exiting the target, data flows back to the source (bi-directional arrow).

- No data flow (slashed circle).
If the direction of the items is hard-coded in the data structure for a business function (such as when the parameters are predetermined to be input, output, or bidirectional), then this predetermined direction appears here. You must complete the required items that appear in red. The status bar indicates the state of the flow to the target.

8. Select the Include in Transaction option to include this business function for transaction processing.
This option appears on transaction forms only.

9. Select the Asynchronously option to enable asynchronous processing.

10. Click one of these buttons to add notes:

- Business Function Notes

- Structure Notes

- Parameter Notes

4 Using BrowsER

This chapter contains the following topics:

- Section 4.1, "Understanding BrowsER"

- Section 4.2, "Working with BrowsER"

4.1 Understanding BrowsER

You can use JD Edwards EnterpriseOne BrowsER to view event rules (ER) for interactive and batch applications.

JD Edwards EnterpriseOne BrowsER displays the structure of forms within an interactive application, or sections within a batch application. The forms or sections appear in a hierarchical structure, with events and ER for each event. You can use JD Edwards EnterpriseOne BrowsER to search and filter ER, and disable or enable ER.

You can select one of these JD Edwards EnterpriseOne BrowsER options to easily view or search for ER code:

- Expand Tree

- Expand Node

- Show Object IDs

- Hide Objects with no ER

- Filter ER Records
Filter ER Records enables you to show or hide specific ER statements, including:

- Assignments

- Business functions

- Criterion

- Comments

- Form interconnections

- Options

- System functions

- Search ER Records enables you to search for specific ER statements or text within those statements.

4.2 Working with BrowsER

To work with JD Edwards EnterpriseOne BrowsER:

1. On Oracle's JD Edwards EnterpriseOne Object Management Workbench (OMW), select an object with ER and then click the Design button.

2. On Interactive Design, click the Design Tools tab, and then click the Browse Event Rules button.
Alternatively, you can access JD Edwards EnterpriseOne BrowsER directly from within Oracle's JD Edwards EnterpriseOne Form Design Aid (FDA) or Oracle's JD Edwards EnterpriseOne Report Design Aid (RDA) by choosing BrowsER from the View menu.

3. On Browsing, click the plus (+) and minus (–) buttons to expand or collapse the hierarchical view of events for interactive forms or batch report sections.
Each ER appears beneath the event with which it is associated and beside a control that contains event rule logic. If it does not appear beside a control, then no event rule logic exists on that control.

4. To disable an ER line, select the line and then click Disable button.

5. To enable a disabled line, select the line and then click Enable button.
You cannot print or modify ER from any BrowsER form.

6. To hide objects with no ER, right-click anywhere on the BrowsER window and select Hide objects with no ER from the popup menu.

7. To start a search or filter, right-click anywhere on the Browsing form and select Search or Filter ER Records from the popup menu.

5 Debugging Event Rules

This chapter contains the following topics:

- Section 5.1, "Understanding Debugging"

- Section 5.2, "The Debugging Process"

- Section 5.3, "Debugging Strategies"

- Section 5.4, "Debug Logs"

- Section 5.5, "Debugging Event Rules"

5.1 Understanding Debugging

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.

5.2 The Debugging Process

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:

1. Exit the application.

2. Rebuild debug information.

3. Reset breakpoints.

4. 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.

5.3 Debugging Strategies

You can use several strategies to make debugging faster and easier. Begin by observing the nature of the problem.

5.3.1 Is the Program Ending Unexpectedly?

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.

5.3.2 Is the Output of the Program Incorrect?

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.

5.3.3 Where Else Could the Problem Be Coming From?

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.

5.4 Debug Logs

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.

5.5 Debugging Event Rules

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.

5.5.1 Understanding the Event Rules Debugger

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:

1. Launch the ER Debugger.

2. Load into the Debugger the applications to debug.

3. Set any desired breakpoints.

4. 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.

5.5.1.1 Object Browse 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.

5.5.1.2 Object Tree

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.

5.5.1.3 Event Rules Window

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.

5.5.1.4 Variable Tree and Watch Window

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.

5.5.1.5 Breakpoint Manager

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.

5.5.1.6 Breakpoint State Indicators

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.

5.5.1.7 Breakpoint with Condition

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:

1. In the Breakpoint Properties dialog click the Condition button.

2. 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'.

3. 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.

5.5.1.8 Avoiding Problems with Breakpoint Conditions

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.

5.5.1.9 Breakpoint with Hit Count Condition

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.

5.5.1.10 Disabled Breakpoint

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.

5.5.1.11 Invalid Breakpoints

Invalid breakpoint conditions are logged to jdedebug.log each time the breakpoint having the invalid condition is reached.

5.5.1.12 Search Combo Box

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.

5.5.2 Debugging an Application with the Event Rules Debugger

To debug an application with the JD Edwards EnterpriseOne Event Rules Debugger:

1. From the Cross Application Development Tools menu (GH902), select Debug Application.

2. Select the object that you want to debug.

3. Select a form (for interactive applications) or section (for batch applications) and an event to view.

4. Select the ER line on which you want to set a breakpoint.

5. 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.

6. 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.

7. From the Debug menu, select one of these options:

- Go

- Disconnect

- Step Over

- Step Into

Glossary

Accessor Methods/Assessors

Java methods to “get” and “set” the elements of a value object or other source file.

activity rule

The criteria by which an object progresses from one given point to the next in a flow.

add mode

A condition of a form that enables users to input data.

Advanced Planning Agent (APAg)

A JD Edwards EnterpriseOne tool that can be used to extract, transform, and load enterprise data. APAg supports access to data sources in the form of rational databases, flat file format, and other data or message encoding, such as XML.

application server

Software that provides the business logic for an application program in a distributed environment. The servers can be Oracle Application Server (OAS) or WebSphere Application Server (WAS).

Auto Commit Transaction

A database connection through which all database operations are immediately written to the database.

batch processing

A process of transferring records from a third-party system to JD Edwards EnterpriseOne.

In JD Edwards EnterpriseOne Financial Management, batch processing enables you to transfer invoices and vouchers that are entered in a system other than JD Edwards EnterpriseOne to JD Edwards EnterpriseOne Accounts Receivable and JD Edwards EnterpriseOne Accounts Payable, respectively. In addition, you can transfer address book information, including customer and supplier records, to JD Edwards EnterpriseOne.

batch server

A server that is designated for running batch processing requests. A batch server typically does not contain a database nor does it run interactive applications.

batch-of-one

A transaction method that enables a client application to perform work on a client workstation, then submit the work all at once to a server application for further processing. As a batch process is running on the server, the client application can continue performing other tasks.

best practices

Non-mandatory guidelines that help the developer make better design decisions.

BPEL

Abbreviation for Business Process Execution Language, a standard web services orchestration language, which enables you to assemble discrete services into an end-to-end process flow.

BPEL PM

Abbreviation for Business Process Execution Language Process Manager, a comprehensive infrastructure for creating, deploying, and managing BPEL business processes.

Build Configuration File

Configurable settings in a text file that are used by a build program to generate ANT scripts. ANT is a software tool used for automating build processes. These scripts build published business services.

build engineer

An actor that is responsible for building, mastering, and packaging artifacts. Some build engineers are responsible for building application artifacts, and some are responsible for building foundation artifacts.

Build Program

A WIN32 executable that reads build configuration files and generates an ANT script for building published business services.

business analyst

An actor that determines if and why an EnterpriseOne business service needs to be developed.

business function

A named set of user-created, reusable business rules and logs that can be called through event rules. Business functions can run a transaction or a subset of a transaction (check inventory, issue work orders, and so on). Business functions also contain the application programming interfaces (APIs) that enable them to be called from a form, a database trigger, or a non-JD Edwards EnterpriseOne application. Business functions can be combined with other business functions, forms, event rules, and other components to make up an application. Business functions can be created through event rules or third-generation languages, such as C. Examples of business functions include Credit Check and Item Availability.

business function event rule

See named event rule (NER).

business service

EnterpriseOne business logic written in Java. A business service is a collection of one or more artifacts. Unless specified otherwise, a business service implies both a published business service and business service.

business service artifacts

Source files, descriptors, and so on that are managed for business service development and are needed for the business service build process.

business service class method

A method that accesses resources provided by the business service framework.

business service configuration files

Configuration files include, but are not limited to, interop.ini, JDBj.ini, and jdelog.properties.

business service cross reference

A key and value data pair used during orchestration. Collectively refers to both the code and the key cross reference in the WSG/XPI based system.

business service cross-reference utilities

Utility services installed in a BPEL/ESB environment that are used to access JD Edwards EnterpriseOne orchestration cross-reference data.

business service development environment

A framework needed by an integration developer to develop and manage business services.

business services development tool

Otherwise known as JDeveloper.

business service EnterpriseOne object

A collection of artifacts managed by EnterpriseOne LCM tools. Named and represented within EnterpriseOne LCM similarly to other EnterpriseOne objects like tables, views, forms, and so on.

business service framework

Parts of the business service foundation that are specifically for supporting business service development.

business service payload

An object that is passed between an enterprise server and a business services server. The business service payload contains the input to the business service when passed to the business services server. The business service payload contains the results from the business service when passed to the Enterprise Server. In the case of notifications, the return business service payload contains the acknowledgement.

business service property

Key value data pairs used to control the behavior or functionality of business services.

Business Service Property Admin Tool

An EnterpriseOne application for developers and administrators to manage business service property records.

business service property business service group

A classification for business service property at the business service level. This is generally a business service name. A business service level contains one or more business service property groups. Each business service property group may contain zero or more business service property records.

business service property key

A unique name that identifies the business service property globally in the system.

business service property utilities

A utility API used in business service development to access EnterpriseOne business service property data.

business service property value

A value for a business service property.

business service repository

A source management system, for example ClearCase, where business service artifacts and build files are stored. Or, a physical directory in network.

business services server

The physical machine where the business services are located. Business services are run on an application server instance.

business services source file or business service class

One type of business service artifact. A text file with the .java file type written to be compiled by a Java compiler.

business service value object template

The structural representation of a business service value object used in a C-business function.

Business Service Value Object Template Utility

A utility used to create a business service value object template from a business service value object.

business services server artifact

The object to be deployed to the business services server.

business view

A means for selecting specific columns from one or more JD Edwards EnterpriseOne application tables whose data is used in an application or report. A business view does not select specific rows, nor does it contain any actual data. It is strictly a view through which you can manipulate data.

central objects merge

A process that blends a customer's modifications to the objects in a current release with objects in a new release.

central server

A server that has been designated to contain the originally installed version of the software (central objects) for deployment to client computers. In a typical JD Edwards EnterpriseOne installation, the software is loaded on to one machine—the central server. Then, copies of the software are pushed out or downloaded to various workstations attached to it. That way, if the software is altered or corrupted through its use on workstations, an original set of objects (central objects) is always available on the central server.

charts

Tables of information in JD Edwards EnterpriseOne that appear on forms in the software.

check-in repository

A repository for developers to check in and check out business service artifacts. There are multiple check-in repositories. Each can be used for a different purpose (for example, development, production, testing, and so on).

checksum

A fixed-size datum computed from an arbitrary block of digital data for the purpose of detecting accidental errors that may have been introduced during its transmission or storage. JD Edwards EnterpriseOne uses the checksum to verify the integrity of packages that have been downloaded by recomputing the checksum of the downloaded package and comparing it with the checksum of the original package. The procedure that yields the checksum from the data is called a checksum function or checksum algorithm. JD Edwards EnterpriseOne uses the MD5 and STA-1 checksum algorithms.

connector

Component-based interoperability model that enables third-party applications and JD Edwards EnterpriseOne to share logic and data. The JD Edwards EnterpriseOne connector architecture includes Java and COM connectors.

Control Table Workbench

An application that, during the Installation Workbench processing, runs the batch applications for the planned merges that update the data dictionary, user-defined codes, menus, and user override tables.

control tables merge

A process that blends a customer's modifications to the control tables with the data that accompanies a new release.

correlation data

The data used to tie HTTP responses with requests that consist of business service name and method.

credentials

A valid set of JD Edwards EnterpriseOne username/password/environment/role, EnterpriseOne session, or EnterpriseOne token.

cross-reference utility services

Utility services installed in a BPEL/ESB environment that access EnterpriseOne cross-reference data.

database credentials

A valid database username/password.

database server

A server in a local area network that maintains a database and performs searches for client computers.

Data Source Workbench

An application that, during the Installation Workbench process, copies all data sources that are defined in the installation plan from the Data Source Master and Table and Data Source Sizing tables in the Planner data source to the system-release number data source. It also updates the Data Source Plan detail record to reflect completion.

deployment artifacts

Artifacts that are needed for the deployment process, such as servers, ports, and such.

deployment server

A server that is used to install, maintain, and distribute software to one or more enterprise servers and client workstations.

direct connect

A transaction method in which a client application communicates interactively and directly with a server application.

See also batch-of-one and store-and-forward.

Do Not Translate (DNT)

A type of data source that must exist on the iSeries because of BLOB restrictions.

embedded application server instance

An OC4J instance started by and running wholly within JDeveloper.

edit code

A code that indicates how a specific value for a report or a form should appear or be formatted. The default edit codes that pertain to reporting require particular attention because they account for a substantial amount of information.

edit mode

A condition of a form that enables users to change data.

edit rule

A method used for formatting and validating user entries against a predefined rule or set of rules.

Electronic Data Interchange (EDI)

An interoperability model that enables paperless computer-to-computer exchange of business transactions between JD Edwards EnterpriseOne and third-party systems. Companies that use EDI must have translator software to convert data from the EDI standard format to the formats of their computer systems.

embedded event rule

An event rule that is specific to a particular table or application. Examples include form-to-form calls, hiding a field based on a processing option value, and calling a business function. Contrast with the business function event rule.

Employee Work Center

A central location for sending and receiving all JD Edwards EnterpriseOne messages (system and user generated), regardless of the originating application or user. Each user has a mailbox that contains workflow and other messages, including Active Messages.

enterprise server

A server that contains the database and the logic for JD Edwards EnterpriseOne.

Enterprise Service Bus (ESB)

Middleware infrastructure products or technologies based on web services standards that enable a service-oriented architecture using an event-driven and XML-based messaging framework (the bus).

EnterpriseOne administrator

An actor responsible for the EnterpriseOne administration system.

EnterpriseOne credentials

A user ID, password, environment, and role used to validate a user of EnterpriseOne.

EnterpriseOne development client

Historically called “fat client,” a collection of installed EnterpriseOne components required to develop EnterpriseOne artifacts, including the Microsoft Windows client and design tools.

EnterpriseOne extension

A JDeveloper component (plug-in) specific to EnterpriseOne. A JDeveloper wizard

is a specific example of an extension.

EnterpriseOne object

A reusable piece of code that is used to build applications. Object types include tables, forms, business functions, data dictionary items, batch processes, business views, event rules, versions, data structures, and media objects.

EnterpriseOne process

A software process that enables JD Edwards EnterpriseOne clients and servers to handle processing requests and run transactions. A client runs one process, and servers can have multiple instances of a process. JD Edwards EnterpriseOne processes can also be dedicated to specific tasks (for example, workflow messages and data replication) to ensure that critical processes don't have to wait if the server is particularly busy.

EnterpriseOne resource

Any EnterpriseOne table, metadata, business function, dictionary information, or other information restricted to authorized users.

Environment Workbench

An application that, during the Installation Workbench process, copies the environment information and Object Configuration Manager tables for each environment from the Planner data source to the system-release number data source. It also updates the Environment Plan detail record to reflect completion.

escalation monitor

A batch process that monitors pending requests or activities and restarts or forwards them to the next step or user after they have been inactive for a specified amount of time.

event rule

A logic statement that instructs the system to perform one or more operations based on an activity that can occur in a specific application, such as entering a form or exiting a field.

explicit transaction

Transaction used by a business service developer to explicitly control the type (auto or manual) and the scope of transaction boundaries within a business service.

exposed method or value object

Published business service source files or parts of published business service source files that are part of the published interface. These are part of the contract with the customer.

fast path

A command prompt that enables the user to move quickly among menus and applications by using specific commands.

file server

A server that stores files to be accessed by other computers on the network. Unlike a disk server, which appears to the user as a remote disk drive, a file server is a sophisticated device that not only stores files, but also manages them and maintains order as network users request files and make changes to these files.

final mode

The report processing mode of a processing mode of a program that updates or creates data records.

foundation

A framework that must be accessible for execution of business services at runtime. This includes, but is not limited to, the Java Connector and JDBj.

FTP server

A server that responds to requests for files via file transfer protocol.

HTTP Adapter

A generic set of services that are used to do the basic HTTP operations, such as GET, POST, PUT, DELETE, TRACE, HEAD, and OPTIONS with the provided URL.

instantiate

A Java term meaning “to create.” When a class is instantiated, a new instance

is created.

integration developer

The user of the system who develops, runs, and debugs the EnterpriseOne business services. The integration developer uses the EnterpriseOne business services to develop these components.

integration point (IP)

The business logic in previous implementations of EnterpriseOne that exposes a document level interface. This type of logic used to be called XBPs. In EnterpriseOne 8.11, IPs are implemented in Web Services Gateway powered by webMethods.

integration server

A server that facilitates interaction between diverse operating systems and applications across internal and external networked computer systems.

integrity test

A process used to supplement a company's internal balancing procedures by locating and reporting balancing problems and data inconsistencies.

interface table

See Z table.

internal method or value object

Business service source files or parts of business service source files that are not part of the published interface. These could be private or protected methods. These could be value objects not used in published methods.

interoperability model

A method for third-party systems to connect to or access JD Edwards EnterpriseOne.

in-your-face error

In JD Edwards EnterpriseOne, a form-level property which, when enabled, causes the text of application errors to appear on the form.

jargon

An alternative data dictionary item description that JD Edwards EnterpriseOne appears based on the product code of the current object.

Java application server

A component-based server that resides in the middle-tier of a server-centric architecture. This server provides middleware services for security and state maintenance, along with data access and persistence.

JDBNET

A database driver that enables heterogeneous servers to access each other's data.

JDEBASE Database Middleware

A JD Edwards EnterpriseOne proprietary database middleware package that provides platform-independent APIs, along with client-to-server access.

JDECallObject

An API used by business functions to invoke other business functions.

jde.ini

A JD Edwards EnterpriseOne file (or member for iSeries) that provides the runtime settings required for JD Edwards EnterpriseOne initialization. Specific versions of the file or member must reside on every machine running JD Edwards EnterpriseOne. This includes workstations and servers.

JDEIPC

Communications programming tools used by server code to regulate access to the same data in multiprocess environments, communicate and coordinate between processes, and create new processes.

jde.log

The main diagnostic log file of JD Edwards EnterpriseOne. This file is always located in the root directory on the primary drive and contains status and error messages from the startup and operation of JD Edwards EnterpriseOne.

JDENET

A JD Edwards EnterpriseOne proprietary communications middleware package. This package is a peer-to-peer, message-based, socket-based, multiprocess communications middleware solution. It handles client-to-server and server-to-server communications for all JD Edwards EnterpriseOne supported platforms.

JDeveloper Project

An artifact that JDeveloper uses to categorize and compile source files.

JDeveloper Workspace

An artifact that JDeveloper uses to organize project files. It contains one or more project files.

JMS Queue

A Java Messaging service queue used for point-to-point messaging.

listener service

A listener that listens for XML messages over HTTP.

local repository

A developer's local development environment that is used to store business service artifacts.

Location Workbench

An application that, during the Installation Workbench process, copies all locations that are defined in the installation plan from the Location Master table in the Planner data source to the system data source.

logic server

A server in a distributed network that provides the business logic for an application program. In a typical configuration, pristine objects are replicated on to the logic server from the central server. The logic server, in conjunction with workstations, actually performs the processing required when JD Edwards EnterpriseOne software runs.

MailMerge Workbench

An application that merges Microsoft Word 6.0 (or higher) word-processing documents with JD Edwards EnterpriseOne records to automatically print business documents. You can use MailMerge Workbench to print documents, such as form letters about verification of employment.

Manual Commit transaction

A database connection where all database operations delay writing to the database until a call to commit is made.

master business function (MBF)

An interactive master file that serves as a central location for adding, changing, and updating information in a database. Master business functions pass information between data entry forms and the appropriate tables. These master functions provide a common set of functions that contain all of the necessary default and editing rules for related programs. MBFs contain logic that ensures the integrity of adding, updating, and deleting information from databases.

master table

See published table.

media storage object

Files that use one of the following naming conventions that are not organized into table format: Gxxx, xxxGT, or GTxxx.

message center

A central location for sending and receiving all JD Edwards EnterpriseOne messages (system and user generated), regardless of the originating application or user.

messaging adapter

An interoperability model that enables third-party systems to connect to JD Edwards EnterpriseOne to exchange information through the use of messaging queues.

messaging server

A server that handles messages that are sent for use by other programs using a messaging API. Messaging servers typically employ a middleware program to perform their functions.

Monitoring Application

An EnterpriseOne tool provided for an administrator to get statistical information for various EnterpriseOne servers, reset statistics, and set notifications.

named event rule (NER)

Encapsulated, reusable business logic created using event rules, rather that C programming. NERs are also called business function event rules. NERs can be reused in multiple places by multiple programs. This modularity lends itself to streamlining, reusability of code, and less work.

Object Configuration Manager (OCM)

In JD Edwards EnterpriseOne, the object request broker and control center for the runtime environment. OCM keeps track of the runtime locations for business functions, data, and batch applications. When one of these objects is called, OCM directs access to it using defaults and overrides for a given environment and user.

Object Librarian

A repository of all versions, applications, and business functions reusable in building applications. Object Librarian provides check-out and check-incapabilities for developers, and it controls the creation, modification, and use of JD Edwards EnterpriseOne objects. Object Librarian supports multiple environments (such as production and development) and enables objects to be easily moved from one environment to another.

Object Librarian merge

A process that blends any modifications to the Object Librarian in a previous release into the Object Librarian in a new release.

Open Data Access (ODA)

An interoperability model that enables you to use SQL statements to extract JD Edwards EnterpriseOne data for summarization and report generation.

Output Stream Access (OSA)

An interoperability model that enables you to set up an interface for JD Edwards EnterpriseOne to pass data to another software package, such as Microsoft Excel, for processing.

package

JD Edwards EnterpriseOne objects are installed to workstations in packages from the deployment server. A package can be compared to a bill of material or kit that indicates the necessary objects for that workstation and where on the deployment server the installation program can find them. It is point-in-time snapshot of the central objects on the deployment server.

package build

A software application that facilitates the deployment of software changes and new applications to existing users. Additionally, in JD Edwards EnterpriseOne, a package build can be a compiled version of the software. When you upgrade your version of the ERP software, for example, you are said to take a package build.

Consider the following context: “Also, do not transfer business functions into the production path code until you are ready to deploy, because a global build of business functions done during a package build will automatically include the new functions.” The process of creating a package build is often referred to, as it is in this example, simply as “a package build.”

package location

The directory structure location for the package and its set of replicated objects. This is usually \\deployment server\release\path_code\package\package name. The subdirectories under this path are where the replicated objects for the package are placed. This is also referred to as where the package is built or stored.

Package Workbench

An application that, during the Installation Workbench process, transfers the package information tables from the Planner data source to the system-release number data source. It also updates the Package Plan detail record to reflect completion.

Pathcode Directory

The specific portion of the file system on the EnterpriseOne development client where EnterpriseOne development artifacts are stored.

patterns

General repeatable solutions to a commonly occurring problem in software design. For business service development, the focus is on the object relationships and interactions. For orchestrations, the focus is on the integration patterns (for example, synchronous and asynchronous request/response, publish, notify, and receive/reply).

print server

The interface between a printer and a network that enables network clients to connect to the printer and send their print jobs to it. A print server can be a computer, separate hardware device, or even hardware that resides inside of the printer itself.

pristine environment

A JD Edwards EnterpriseOne environment used to test unaltered objects with JD Edwards EnterpriseOne demonstration data or for training classes. You must have this environment so that you can compare pristine objects that you modify.

processing option

A data structure that enables users to supply parameters that regulate the running of a batch program or report. For example, you can use processing options to specify default values for certain fields, to determine how information appears or is printed, to specify date ranges, to supply runtime values that regulate program execution, and so on.

production environment

A JD Edwards EnterpriseOne environment in which users operate EnterpriseOne software.

Production Published Business Services Web Service

Published business services web service deployed to a production application server.

program temporary fix (PTF)

A representation of changes to JD Edwards EnterpriseOne software that your organization receives on magnetic tapes or disks.

project

In JD Edwards EnterpriseOne, a virtual container for objects being developed in Object Management Workbench.

promotion path

The designated path for advancing objects or projects in a workflow. The following is the normal promotion cycle (path):

11>21>26>28>38>01

In this path, 11 equals new project pending review, 21 equals programming, 26 equals QA test/review, 28 equals QA test/review complete, 38 equals in production, 01 equals complete. During the normal project promotion cycle, developers check objects out of and into the development path code and then promote them to the prototype path code. The objects are then moved to the productions path code before declaring them complete.

proxy server

A server that acts as a barrier between a workstation and the internet so that the enterprise can ensure security, administrative control, and caching service.

published business service

EnterpriseOne service level logic and interface. A classification of a published business service indicating the intention to be exposed to external (non-EnterpriseOne) systems.

published business service identification information

Information about a published business service used to determine relevant authorization records. Published business services + method name, published business services, or *ALL.

published business service web service

Published business services components packaged as J2EE Web Service (namely, a J2EE EAR file that contains business service classes, business service foundation, configuration files, and web service artifacts).

published table

Also called a master table, this is the central copy to be replicated to other machines. Residing on the publisher machine, the F98DRPUB table identifies all of the published tables and their associated publishers in the enterprise.

publisher

The server that is responsible for the published table. The F98DRPUB table identifies all of the published tables and their associated publishers in the enterprise.

QBE

An abbreviation for query by example. In JD Edwards EnterpriseOne, the QBE line is the top line on a detail area that is used for filtering data.

real-time event

A message triggered from EnterpriseOne application logic that is intended for external systems to consume.

refresh

A function used to modify JD Edwards EnterpriseOne software, or subset of it, such as a table or business data, so that it functions at a new release or cumulative update level.

replication server

A server that is responsible for replicating central objects to client machines.

rules

Mandatory guidelines that are not enforced by tooling, but must be followed in order to accomplish the desired results and to meet specified standards.

secure by default

A security model that assumes that a user does not have permission to execute an object unless there is a specific record indicating such permissions.

Secure Socket Layer (SSL)

A security protocol that provides communication privacy. SSL enables client and server applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.

selection

Found on JD Edwards EnterpriseOne menus, a selection represents functions that you can access from a menu. To make a selection, type the associated number in the Selection field and press Enter.

serialize

The process of converting an object or data into a format for storage or transmission across a network connection link with the ability to reconstruct the original data or objects when needed.

Server Workbench

An application that, during the Installation Workbench process, copies the server configuration files from the Planner data source to the system-release number data source. The application also updates the Server Plan detail record to reflect completion.

SOA

Abbreviation for Service Oriented Architecture.

softcoding

A coding technique that enables an administrator to manipulate site-specific variables that affect the execution of a given process.

source repository

A repository for HTTP adapter and listener service development environment artifacts.

Specification merge

A merge that comprises three merges: Object Librarian merge, Versions List merge, and Central Objects merge. The merges blend customer modifications with data that accompanies a new release.

specification

A complete description of a JD Edwards EnterpriseOne object. Each object has its own specification, or name, which is used to build applications.

Specification Table Merge Workbench

An application that, during the Installation Workbench process, runs the batch applications that update the specification tables.

SSL Certificate

A special message signed by a certificate authority that contains the name of a user and that user's public key in such a way that anyone can "verify" that the message was signed by no one other than the certification authority and thereby develop trust in the user's public key.

store-and-forward

The mode of processing that enables users who are disconnected from a server to enter transactions and then later connect to the server to upload those transactions.

subscriber table

Table F98DRSUB, which is stored on the publisher server with the F98DRPUB table and identifies all of the subscriber machines for each published table.

super class

An inheritance concept of the Java language where a class is an instance of something, but is also more specific. “Tree” might be the super class of “Oak” and “Elm,” for example.

table access management (TAM)

The JD Edwards EnterpriseOne component that handles the storage and retrieval of use-defined data. TAM stores information, such as data dictionary definitions; application and report specifications; event rules; table definitions; business function input parameters and library information; and data structure definitions for running applications, reports, and business functions.

Table Conversion Workbench

An interoperability model that enables the exchange of information between JD Edwards EnterpriseOne and third-party systems using non-JD Edwards EnterpriseOne tables.

table conversion

An interoperability model that enables the exchange of information between JD Edwards EnterpriseOne and third-party systems using non-JD Edwards EnterpriseOne tables.

table event rules

Logic that is attached to database triggers that runs whenever the action specified by the trigger occurs against the table. Although JD Edwards EnterpriseOne enables event rules to be attached to application events, this functionality is application specific. Table event rules provide embedded logic at the table level.

terminal server

A server that enables terminals, microcomputers, and other devices to connect to a network or host computer or to devices attached to that particular computer.

transaction processing (TP) monitor

A monitor that controls data transfer between local and remote terminals and the applications that originated them. TP monitors also protect data integrity in the distributed environment and may include programs that validate data and format terminal screens.

transaction processing method

A method related to the management of a manual commit transaction boundary (for example, start, commit, rollback, and cancel).

transaction set

An electronic business transaction (electronic data interchange standard document) made up of segments.

trigger

One of several events specific to data dictionary items. You can attach logic to a data dictionary item that the system processes automatically when the event occurs.

triggering event

A specific workflow event that requires special action or has defined consequences or resulting actions.

user identification information

User ID, role, or *public.

User Overrides merge

Adds new user override records into a customer's user override table.

value object

A specific type of source file that holds input or output data, much like a data structure passes data. Value objects can be exposed (used in a published business service) or internal, and input or output. They are comprised of simple and complex elements and accessories to those elements.

versioning a published business service

Adding additional functionality/interfaces to the published business services without modifying the existing functionality/interfaces.

Versions List merge

The Versions List merge preserves any non-XJDE and non-ZJDE version specifications for objects that are valid in the new release, as well as their processing options data.

visual assist

Forms that can be invoked from a control via a trigger to assist the user in determining what data belongs in the control.

vocabulary override

An alternate description for a data dictionary item that appears on a specific JD Edwards EnterpriseOne form or report.

web application server

A web server that enables web applications to exchange data with the back-end systems and databases used in eBusiness transactions.

web server

A server that sends information as requested by a browser, using the TCP/IP set of protocols. A web server can do more than just coordination of requests from browsers; it can do anything a normal server can do, such as house applications or data. Any computer can be turned into a web server by installing server software and connecting the machine to the internet.

Web Service Description Language (WSDL)

An XML format for describing network services.

Web Service Inspection Language (WSIL)

An XML format for assisting in the inspection of a site for available services and a set of rules for how inspection-related information should be made.

web service softcoding record

An XML document that contains values that are used to configure a web service proxy. This document identifies the endpoint and conditionally includes security information.

web service softcoding template

An XML document that provides the structure for a soft coded record.

Where clause

The portion of a database operation that specifies which records the database operation will affect.

Windows terminal server

A multiuser server that enables terminals and minimally configured computers to display Windows applications even if they are not capable of running Windows software themselves. All client processing is performed centrally at the Windows terminal server and only display, keystroke, and mouse commands are transmitted over the network to the client terminal device.

wizard

A type of JDeveloper extension used to walk the user through a series of steps.

workbench

A program that enables users to access a group of related programs from a single entry point. Typically, the programs that you access from a workbench are used to complete a large business process. For example, you use the JD Edwards EnterpriseOne Payroll Cycle Workbench (P07210) to access all of the programs that the system uses to process payroll, print payments, create payroll reports, create journal entries, and update payroll history. Examples of JD Edwards EnterpriseOne workbenches include Service Management Workbench (P90CD020), Line Scheduling Workbench (P3153), Planning Workbench (P13700), Auditor's Workbench (P09E115), and Payroll Cycle Workbench.

workflow

The automation of a business process, in whole or in part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.

workgroup server

A server that usually contains subsets of data replicated from a master network server. A workgroup server does not perform application or batch processing.

XAPI events

A service that uses system calls to capture JD Edwards EnterpriseOne transactions as they occur and then calls third-party software, end users, and other JD Edwards EnterpriseOne systems that have requested notification when the specified transactions occur to return a response.

XML CallObject

An interoperability capability that enables you to call business functions.

XML Dispatch

An interoperability capability that provides a single point of entry for all XML documents coming into JD Edwards EnterpriseOne for responses.

XML List

An interoperability capability that enables you to request and receive JD Edwards EnterpriseOne database information in chunks.

XML Service

An interoperability capability that enables you to request events from one JD Edwards EnterpriseOne system and receive a response from another JD Edwards EnterpriseOne system.

XML Transaction

An interoperability capability that enables you to use a predefined transaction type to send information to or request information from JD Edwards EnterpriseOne. XML transaction uses interface table functionality.

XML Transaction Service (XTS)

Transforms an XML document that is not in the JD Edwards EnterpriseOne format into an XML document that can be processed by JD Edwards EnterpriseOne. XTS then transforms the response back to the request originator XML format.

Z event

A service that uses interface table functionality to capture JD Edwards EnterpriseOne transactions and provide notification to third-party software, end users, and other JD Edwards EnterpriseOne systems that have requested to be notified when certain transactions occur.

Z table

A working table where non-JD Edwards EnterpriseOne information can be stored and then processed into JD Edwards EnterpriseOne. Z tables also can be used to retrieve JD Edwards EnterpriseOne data. Z tables are also known as interface tables.

Z transaction

Third-party data that is properly formatted in interface tables for updating to the JD Edwards EnterpriseOne database.

Index
A  B  C  D  E  F  G  I  L  N  O  P  R  S  T  U  V  W

A

Add button, 2.3.3.14

All Grid Recs Deleted from DB event, 2.3.3.20

application event rules, 2.2.3.1

assignment, 3.7.1, 3.7.4

automatic line numbering

creating event rules for, 3.7.6.1

B

business function

attaching to an event, 3.7.8

Button Clicked event for Add Button, 2.3.3.14 Button Clicked event for Delete Button, 2.3.3.15 Button Clicked event for Select Button, 2.3.3.13 buttons

tool bar, 3.7.2

C

Control is Exited event, 2.3.2.3

controls

disabling/enabling, 2.3.3.2

hiding/showing, 2.3.3.2, 3.5

D

data structure, 2.3.2

data structure object codes, 2.3.2.1

data structure processing, 2.3.2.2

database triggers, 2.2.3.2

debugger, 5.5.1

breakpoint manager, 5.5.1.5

event rules window, 5.5.1.3

object browse window, 5.5.1.1

search combo box, 5.5.1.12

step by step instructions, 5.5.2

variable tree and watch window, 5.5.1.4

debugger features, 5.2 debugging strategies, 5.3 Delete button, 2.3.3.15 Delete Grid Rec From DB–After event, 2.3.3.19 Delete Grid Rec From DB–Before event, 2.3.3.18 Delete Grid Rec Verify–After event, 2.3.3.17 Delete Grid Rec Verify–Before event, 2.3.3.16 Dialog is Initialized event, 2.3.3.2

E

embedded event rules, 2.2.3

event, 2.1

All Grid Recs Deleted from DB, 2.3.3.20

Button Clicked for Add Button, 2.3.3.14

Button Clicked for Delete Button, 2.3.3.15

Button Clicked for Select Button, 2.3.3.13

Control is Exited, 2.3.2.3

Delete Grid Rec From DB–After, 2.3.3.19

Delete Grid Rec From DB–Before, 2.3.3.18

Delete Grid Rec Verify–After, 2.3.3.17

Delete Grid Rec Verify–Before, 2.3.3.16

Dialog is Initialized, 2.3.3.2

Grid Record is Fetched, 2.3.3.8

Last Grid Record Has Been Read, 2.3.3.11

Post Dialog is Initialized, 2.3.3.3

Write Grid Line–After, 2.3.3.10

Write Grid Line–Before, 2.3.3.9

event information, 3.7.3 event rules, 2.2.1

application, 2.2.3.1

design, 3.7

embedded, 2.2, 2.2.3

logic, 3.1

named, 2.2, 2.2.2

table, 2.2.3.2

validation, 3.2

event rules runtime data structure, 2.3.2 event rules runtime processing, 2.3.1

F

filter fields

loading for SQL SELECT, 2.3.3.3

loading PO values, 2.3.3.3

form initialization, 2.3.3.1 form interconnections, 2.3.3.13

G

grid controls

calculating work field values, 2.3.3.8

converting values, 2.3.3.9

formatting, 2.3.3.9

retrieving non-BV data, 2.3.3.9

suppressing a grid row, 2.3.3.8, 2.3.3.9

totalling values, 2.3.3.11

Grid Record is Fetched event, 2.3.3.8

I

if and while statement, 3.7.5

L

Last Grid Record Has Been Read event, 2.3.3.11

N

named event rules, 2.2.2

null pointer errors, 5.3.3

O

output errors, 5.3.2

P

page-at-a-time processing, 2.3.3.6

Post Dialog is Initialized event, 2.3.3.3

R

runtime data structure

event rules, 2.3.2

runtime processing

event rules, 2.3.1

S

Select button, 2.3.3.13

SQL fetches, building, 2.3.3.4

system function

attaching to an event, 3.7.7

T

table event rules, 2.2.3.2, 2.2.3.2

tool bar buttons, 3.7.2

U

unhandled exception, 5.3.1

V

variable, 3.7.6

using variables for automatic line numbering, 3.7.6.1

W

Write Grid Line–After event, 2.3.3.10

Write Grid Line–Before event, 2.3.3.9, 2.3.3.9

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.