Understanding the Data Dictionary

This chapter discusses Oracle's JD Edwards EnterpriseOne Data Dictionary (DD) concepts, where data dictionary items are stored, and the different types of DD triggers.

Click to jump to parent topicData Dictionary Concepts

A data dictionary item identifies a unit of information. The DD item definition defines how the item can be used and includes information such as the type of item and its length. Most of the fields in JD Edwards EnterpriseOne applications are actually DD items. At runtime, JD Edwards EnterpriseOne applications (such as those in Accounts Payable or Sales Order Management) access the DD and reflect the assigned attributes in any of these fields:

Just as a dictionary contains word definitions, the JD Edwards EnterpriseOne DD is a central repository that contains all of the database data items that are used in all of the JD Edwards EnterpriseOne applications. Each data item in the dictionary is defined by a number of attributes that describe parameters such as the data type, data length, and so forth. The system performs automatic error checking against these parameters when users enter values during runtime.

Additionally, DD item attributes define how the DD item should appear when placed on a form or report, including its title and whether to display default values. Also, all DD items have an associated glossary in which you can enter text. If the DD item is included on a form, this text appears when the user presses F1, and so is sometimes referred to as F1 Help. The system also displays the glossary text under certain circumstances, such as for the content of an error message.

DD items are the foundation of JD Edwards EnterpriseOne objects. You create DD items for use as fields on a form, columns in a table, fields in a business view (BV), members of a data structure, and fields on a report. When you access applications from a fat client, the applications access the DD at runtime and immediately reflect modifications to DD item attributes such as field descriptions, column headings, decimals, and edit rules. Once accessed the DD items are stored on the workstation in a permanent cache. This is done for performance, to decrease the traffic to the server for the DD information. On the HTML client the DD is stored as serialized objects with the rest of the application specification information. DD items must be regenerated if changed for the applications to know about the modification.

This is a list of the parameters that define DD items:

The application retrieves field information from the DD. Fields marked with an asterisk (*) can be overridden in Form Design Aid (FDA) and Report Design Aid (RDA). In these instances, the application retrieves the overrides, if any exist.

Create new DD items and view existing ones with the Object Management Workbench (OMW) or the Data Dictionary Application program (P92001). After you create a DD item, use the Data Dictionary Application program to define jargon and language translations for it.

Use the Data Dictionary Application to create, view, and update attributes for DD items. You can copy a DD item with similar attributes and modify it for your specific needs. This method can be quicker and easier than creating a new DD item, but if you use this method you must distinguish between the original and the copy. You distinguish between them by modifying the alias.

Changing the type and attributes of a DD item might affect how the data is stored and cause discrepancies among records.

Note. The DD does not verify whether a DD item is used by an application when you delete it. If you delete a DD item that an application uses, that application will fail.

Glossary items are items that cannot be attributes in tables. Glossary items are typically used as information messages.

Error messages used in JD Edwards EnterpriseOne are stored as DD items. Error messages do not use all the fields that are required for regular DD items, so you need to use the DD glossary item application to display error messages.

Click to jump to parent topicData Dictionary and Data Dictionary Item Storage

This section discusses data dictionary and data dictionary item storage.

DD items reside on enterprise (logic) servers in relational database tables. Workstations retrieve from the publisher DD (the relational database tables) only those DD items that are necessary for the applications being used. This occurs when you use an application for the first time after installing JD Edwards EnterpriseOne. The DD information is stored on each workstation in a permanent cache under the same local path code and spec directory as these global tables:

See Also

Administering the Data Dictionary

Click to jump to parent topicData Dictionary Triggers

This section discusses:

Click to jump to top of pageClick to jump to parent topicData Dictionary Triggers Overview

A trigger is an editing or display routine that is attached at the dictionary level and initiated at runtime. Triggers are reusable objects and, therefore, automatically associated with each application that uses the DD item. Triggers save time and increase the usefulness of the code because you can create the business logic only once and then use it within multiple applications. Triggers ensure accuracy and integrity of data across all applications.

Use triggers to perform these tasks:

Although you can override any of these triggers in Form Design Aid (FDA), you should anticipate how the DD item will most often be used to reduce the need for overrides.

Click to jump to top of pageClick to jump to parent topicDefault Value Triggers

A default value trigger is the value assigned to the object based on that DD item when the object is blank.

Click to jump to top of pageClick to jump to parent topicVisual Assist Triggers

A DD item with an associated visual assist trigger displays the visual assist button at runtime. These types of visual assist triggers are available:

Click to jump to top of pageClick to jump to parent topicEdit Rule Triggers

Use edit rule triggers to validate field values that are based on business functions or rules (logic that you write yourself). For example, you can define an edit rule trigger that performs these functions:

To base the trigger on a business function, then the business function must already exist. To base the trigger on a rule, build the validation logic at the time that you define the trigger. These rules can include UDCs such as:

Click to jump to top of pageClick to jump to parent topicDisplay Rule Triggers

Use a display rule trigger to format data. You attach a display rule trigger based on either a business function or a UDC. To base the trigger on a business function, the business function must already exist. To base the trigger on a rule, indicate the formatting at the time that you define the trigger with one of these codes:

Click to jump to top of pageClick to jump to parent topicNext Number Triggers

The next number trigger controls the automatic numbering for such items as new general ledger account numbers, voucher numbers, and address numbers. It enables you to specify the numbering system code to use and automatically increments numbers to reduce transpositions and keying errors.

Use the next number trigger to enter a default value in a numeric DD item if the user does not enter a number. Next numbers are assigned from an array. The combination of system code and index defines how the next number will be assigned.

F0002 has this logic:

IBM Modulus 11 Self-Check Algorithm

Each position in the base number has a weight factor. Modulus 11 counts positions from the right-most digit (not including the check digit).

The Modulus 11 weight factors are 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 2, 3, 4, 5, 6, 7, 2 for positions 1 to 31, respectively.

After you set next numbers, do not change them. If you change next numbers, these issues might occur:

Next numbers connect to the DD. A DD item in the DD points to the next numbers system which you can manipulate with the Next Numbers application (P0002).

Click to jump to top of pageClick to jump to parent topicSmart Field Triggers

Smart fields are DD items with attached business functions. The business functions include named mappings, which simplify the process of choosing a DD item with particular functionality. End-users do not need to know which business function to use and what parameters to pass; instead, the user simply selects a DD item that has this information. Smart fields can be used in all section types in Report Design Aid (RDA). For example, you can use smart fields to derive a column heading or an object value in a tabular section. Smart fields are always in glossary group K.