This chapter contains the following topics:
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.
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:
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 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.
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:
glbltbl.xdb (references for the data)
glbltbl.ddb (the DD items)
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.
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:
Establish field default values.
Link DD 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 DD item will most often be used to reduce the need for overrides.
A default value trigger is the value assigned to the object based on that DD item when the object is blank.
A DD 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.
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:
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, 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:
EQ: Equal
GE: Greater or Equal
GT: Greater
HNDL: Table Handle
LE: Less Than or Equal
LT: Less Than
NE: Not Equal
NRANGE: Not Between
RANGE: Between
UDC: User-Defined Code
VALUE: In a List
ZLNGTH: Allocated Length (VARLEN flds)
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. DD items that define business units use this rule.
*RABN
Right-adjusts the value and precedes it with blanks. DD items that do not define business units use this rule.
*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. The code should be entered into the parameter field.
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 DD item types.
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:
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.
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 DD. A DD item in the DD points to the next numbers system which you can manipulate with the Next Numbers application (P0002).
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.