2 Understanding the Data Dictionary

This chapter contains the following topics:

2.1 Data Dictionary Concepts

JD Edwards EnterpriseOne Data Dictionary is a central repository that contains the data items used in the JD Edwards EnterpriseOne system. Data items are either regular data items, which are database items that used in applications and reports, or glossary data items, which are used primarily as message text.

Each regular 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. Most of the fields in JD Edwards EnterpriseOne applications are regular data items. Data item attributes define how the item should appear when placed on a form or report, including the title and whether to display default values. The system performs automatic error checking against these attributes when users enter values into JD Edwards EnterpriseOne applications (such as those in Accounts Payable or Sales Order Management) at runtime.

All regular data items have an associated glossary in which you can enter text. If the data item is included on a form, this text displays when the user presses F1, which is usually referred to as F1 Help, Item Help, or field-level help.

Regular data items are the foundation of JD Edwards EnterpriseOne objects. You create data 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 Microsoft Windows client, the applications access the data dictionary at runtime and immediately reflect modifications to data item attributes such as field descriptions, column headings, decimals, and edit rules. Once accessed, the data items are stored on the workstation in a permanent cache. This is done for performance, to decrease the traffic to the server for the data dictionary information. On the HTML client, the data dictionary is stored as serialized objects with the rest of the application specification information. If data items are changed, they must be regenerated for the applications to recognize the modifications.

This is a list of the parameters that define regular data items:

  • Display Decimals

  • File Decimals

  • Alpha Description

  • Data Type

  • Size

  • Glossary

  • Allow Blank Entry *

  • Upper Case Only *

  • All Triggers *

  • Row and Column Headings *

The application retrieves field information from the data dictionary. The parameters shown above 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.

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

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

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

Note:

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

Glossary data items are items that cannot be attributes in tables. Glossary data items are typically used as messages in the JD Edwards EnterpriseOne system and do not use all of the fields that are required for regular data items. For this reason, glossary data items use the Data Dictionary - Glossary Items Application (P92002) to add or modify glossary item text, whereas regular data items use the Data Dictionary Application (P92001).

2.2 Glossary Text

This section discusses glossary text and text substitution.

Glossary text is used to describe regular data items or to define the text for messages and processing option help. There are two types of glossary text:

  • Data item glossary text.

  • Glossary item glossary text.

Both glossary text types have User Defined Code (UDC) values that further categorize them into glossary groups.

2.2.1 Data Item Glossary Groups

Regular data items use UDC H95/DG to designate the type of data item, which determines how the data item is used in JD Edwards EnterpriseOne. This table shows the codes for data item glossary groups.

Code Description
C Data Item Class
D Primary Data Elements
K Smart Fields
S Secondary-Dates, Arrays. Etc.

If a data dictionary data item is used on a form, the glossary text displays when you click the Item Help option.

Glossary groups D and S are the only types that have columns in database tables. Glossary group S is for data item arrays such as Address Line (ADD), which is the parent data item for Address Line data items AddressLine1 (ADD1) through AddressLine15 (ADD15).

2.2.2 Glossary Item Glossary Groups

Glossary data items are used for messages and processing option help text and do not use all the fields that are required for regular data items. Glossary items use UDC 98/GG to designate the type of glossary item, which determines how the item can be used. Glossary data items cannot be attributes in tables. Examples of glossary item types include:

  • Interactive error, warning, or information messages.

  • Processing option help.

  • Log messages.

  • Batch error messages.

  • Workflow messages.

Glossary items are usually designated as types E, H, X, or Y, although other types are available.

2.2.2.1 Glossary Group E

Glossary group E designates interactive error, warning, and information messages. Interactive messages display during runtime, based on actions taken by the user.

2.2.2.2 Glossary Group H

Glossary items assigned to glossary group H are used for Item Help in processing options. The glossary item is designated as the Help Override Data Item in the processing option template. For example, processing option template T01012 uses glossary item S0101205 for the Search Type processing option. The following glossary text displays for Search Type when you access the Address Book Revisions (P01012) processing options:

"Use this processing option to specify the default value that is used in the Search Type field on the Work with Addresses form. Use the visual assist for a list of valid search types. If you leave this processing option blank, the system uses * as the default value. The * instructs the system to locate all address book records."

See "Defining a Processing Options Data Structure (Template)" in the JD Edwards EnterpriseOne Tools Data Structure Design Guide.

2.2.2.3 Glossary Group X

JD Edwards EnterpriseOne has a variety of log files which provide information about the system operations. Depending on its purpose, a log file can contain a list of events that have occurred, along with problems, failures and warnings. Log messages are glossary items assigned to glossary group X.

2.2.2.4 Glossary Group Y

Glossary group Y is described as PPAT Level Messages. PPAT is an acronym for People, Places, and Things. Glossary group Y is used for batch level-break messages and workflow messages. These messages display in the Employee Work Center.

Batch error messages are sent to the Work Center after a batch job has completed. Batch error messages are level-break messages because most batch errors are created by edits that occur at level breaks in the entire batch process. Level-break messages can be action messages, which contain a shortcut to an application and require action on the part of the user, or non-action messages, which can be messages that instruct the user to review some information.

See "Defining Batch Error Messages" in the JD Edwards EnterpriseOne Tools Report Design Aid Guide.

Workflow messages are sent to the Work Center by Action or Information tasks in a workflow process. Action and Information tasks can be configured to use a message template. You create message templates as type Y glossary items.

See "Setting Up Message Templates" in the JD Edwards EnterpriseOne Tools Workflow Tools Guide.

2.2.3 Text Substitution

You can make the description and message text for glossary items more specific by using text substitution. Text-substitution messages enable variable text to be inserted into the glossary text at runtime. Text substitution provides a method to display the same basic message with some values that vary. For example, suppose a user enters an invalid search type in a field. The following error message appears: "Search type xx is not contained in the 00 ST table." The xx in the message will be replaced by the search type the user entered.

Text-substitution uses placeholders in the glossary text for values that will be substituted at runtime. The placeholders are indicated by an ampersand (&) and a number to mark the places where substitutions are to occur. For example, in the message "Batch &1 is out of balance by &2," the system replaces &1 with the actual batch number and replaces &2 with the amount that the batch is out of balance. The &1 and &2 placeholders indicate where the message text can vary each time that the message appears. Text-substituted values are defined by data dictionary items in a data structure. The data structure is associated with the glossary item using different methods, depending on the glossary type.

You can create text substitution glossary text for the following glossary types:

  • Interactive error, warning, and information messages.

  • PPAT Level messages (Batch messages and workflow messages).

2.2.3.1 Interactive Error, Warning, and Information Messages

For text-substituted error, warning, and information messages (glossary group E), you add a glossary data item to the data dictionary to define the glossary text and attach a pre-defined data structure to the message.

2.2.3.2 Workflow Messages

The data items in text-substituted workflow messages (glossary group Y) are limited to the data items in the JD Edwards EnterpriseOne workflow data structures. As with other glossary item types, you define the glossary text in the data dictionary, but you do not use the data dictionary to attach a data structure for the text-substituted values. You use the Workflow Tool to attach the glossary item to an Action or Information task in a workflow process and then map the text-substitution placeholders to values in the workflow data structures.

See "Configuring an Information or Action Task" in the JD Edwards EnterpriseOne Tools Workflow Tools Guide.

2.2.3.3 Batch Level-Break Messages

For batch level-break messages (glossary group Y), you add a glossary data item to the data dictionary to define the glossary text. If a data structure does not exist with all the data items that are required for the text substitution, you must create one and then create a type definition of the data structure to include in the associated business function. You must have a C business function for each level break message.

See "Defining Batch Error Messages" in the JD Edwards EnterpriseOne Tools Report Design Aid Guide.

2.3 Data Dictionary and Data Dictionary Item Storage

This section discusses data dictionary and data dictionary item storage.

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

  • glbltbl.xdb (references for the data)

  • glbltbl.ddb (the data items)

2.4 Data Dictionary Triggers

This section discusses:

  • Data Dictionary triggers overview.

  • Default value triggers.

  • Visual assist triggers.

  • Edit rule triggers.

  • Display rule triggers.

  • Next number triggers.

  • Smart field triggers.

2.4.1 Data 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 data 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:

  • Establish field default values.

  • Link data items to a user-defined code (UDC) table of values.

  • Activate a visual assist search program when a user positions the cursor in a field.

  • Establish rules and procedures that are embedded in the editing and formatting of the data for a field.

  • Determine a next number scheme that developers should use when assigning a number to data.

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

2.4.2 Default Value Triggers

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

2.4.3 Visual Assist Triggers

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

  • Search form

    This visual assist loads the selected search & select form to assist users in selecting values. The search & select form must exist before you attach a search form trigger. Also, the form must display table values only; it cannot display UDC values.

  • Calculator

    This visual assist provides an on-screen calculator to assist users in deriving mathematical values.

  • Calendar

    This visual assist provides an on-screen calendar to assist users in selecting dates.

  • Universal time

    This visual assist provides an on-screen clock and calendar to assist users in selecting times and dates.

2.4.4 Edit 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 tasks:

  • Validates and compares a field with a particular value.

  • Ensures that a field value is within a specified range of values.

  • Links a field to a specific UDC search & select form.

  • Checks for Y and N values.

To base the trigger on a business function, 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.

2.4.5 Display 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:

  • *RAB

    Right-adjusts the value and precedes it with blanks.

  • *RABN

    Right-adjusts the value and precedes it with blanks.

  • *RAZ

    Right-adjusts the value and precedes it with zeroes. For example, Company appears as 00001.

  • CODE

    Uses the specified edit codes to format numeric fields. See UDC 98/EC for a list of valid codes.

  • MASK

    No longer supported.

  • LMASK

    Embeds leading masks (*'s) within the data when it appears in the web client and UBE reports. For example, to display a credit card number with embedded asterisks, the mask parameter would appear as in this example:

    ********1234, where the number 4 in the parameter setting corresponds to the number of trailing digits that are unmasked. Make sure that this number is lower than the length of this data item.

    Mask can be used only with string data item types.

2.4.6 Next 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 data 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 by the system.

F0002 has this logic:

  • One record per system and 10-element array.

    The key to F0002 is system code. The table includes 10 columns for individual next number elements. The system uses each of these elements for a specific hard code within the applications for that system code.

    For example, if you specify system code 09 in the next numbers trigger, six rows are populated and four are blank. The system uses each of these coded, populated rows as hard code. The first row defines New Account ID. Within JD Edwards EnterpriseOne applications that create new accounts, the system retrieves the account number from system 09, row 1 of the F0002 table. Row 2 contains Journal Entries. In a master business function that creates journal entry documents, the system retrieves the document number from system 09, row 2 of the F0002 table.

    If you specify system 04 in the Next Numbers trigger, the system uses a separate set of rows that have hard codes for use within system 04.

  • Check digits.

    Check digits (sometimes called a Modulus 11 check) enable you to specify whether the system adds a number to the end of each next number that it assigns.

    For example, if you are using check digits and the next number is 2, the system adds a check digit such as 7, making the last two numbers 27. Check digits provide a method of randomly incrementing numbers to prevent the assignment of transposed numbers. In the algorithm in this topic, the system would never assign next number 72 while the check digits feature is activated.

2.4.6.1 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:

  • System performance will be affected.

  • Next numbers functionality will not duplicate numbers; when it reaches the maximum, it will start over.

  • You will not be able to change position or add a new entry without modifying the program.

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

2.4.7 Smart Field Triggers

Smart fields are data items with attached business functions. The business functions include named mappings, which simplify the process of choosing a data 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 data 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.