Creating and Maintaining Applications

This chapter provides an overview of.

• Data Dictionary

• Table Design Aid

• Business View Design Aid

• Form Design Aid

• Report Design Aid

• Data Structure Design

• Event Rule Design

• System Functions

• Table I/O

• Business Function Design Aid

• Processing Options

Understanding Applications

An application is a collection of objects that performs a specific task. You use JD Edwards EnterpriseOne Tools to build standard groups of related applications, such as: Architecture, engineering, and construction; Distribution; Energy and chemical systems; Financial applications; Workforce management; Manufacturing; and Technical applications. These applications share a common user interface because they are all generated through JD Edwards EnterpriseOne Tools. Applications refer to both interactive and batch applications. For example, all of the following are applications:

• Address Book Revisions

• Sales Order Entry

• General Ledger Post

• Trial Balance Report

See Getting Started with JD Edwards EnterpriseOne Tools Development Guidelines for Application Design.

Creating Applications

You use JD Edwards EnterpriseOne Tools to build your applications. You always begin your application development from the JD Edwards EnterpriseOne Object Management Workbench. You might not use every tool to create an application. For example, if you don’t need to add or modify data items you would proceed to Table Design from the Object Management Workbench. If one or more existing database tables contain all of the data items that you want to include in your application, you can skip the step of designing a table and proceed to Business View Design.

This flowchart illustrates the Development Cycle:

See Interactive Application Fundamentals.

Development Cycle

Understanding Data Items and the Data Dictionary

A data item identifies a unit of information. The data item definition defines how the item can be used and includes information such as the type of item and its length.

Because the data dictionary is dynamic, any changes that you make to a data item are effective immediately for all applications that include the data item. 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.

You 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 and the copy. You distinguish between them by modifying the alias.

Because changes to a data item are immediately reflected throughout the JD Edwards EnterpriseOne tools at runtime, remember that changing the type and attributes of a data item might affect how your data is stored and cause discrepancies among records.

See Understanding the Data Dictionary.

Understanding Table Design

A relational database table stores the data that an application uses in columns and rows. Each column is a data item, and each row is a record. You can create one or more tables for use in an application. To create a table, you select data items (the data items must already exist in the data dictionary) to include in the table and assign key fields as indices for retrieving and updating data. You must define your table so that JD Edwards EnterpriseOne software recognizes that the table exists.

You must use Table Design to generate the table whenever you want to:

• Create a new table.

• Add or delete a data item.

• Add or modify an index.

An index identifies records in a table. A primary index identifies unique records in a table. An index is composed of one or more keys, or data items, within the table. An index enables a database management system (DBMS) to sort and locate records quickly.

See Understanding JD Edwards EnterpriseOne Table Design Aid.

Understanding Business View Design

A business view is a selection of data items from one or more tables. After you create a table, use Business View Design to choose only the data items that are required for your application. EnterpriseOne uses the business view that you define to generate the appropriate SQL statements necessary to retrieve data from any of the supported databases. After you define a business view, you can create a form that updates data in an interactive application or you can design a report that displays data. Because you choose only those data items that an application requires, less data moves over the network.

Business views are required for creating applications and generating reports; they have the following characteristics:

• Contain some or all of the data items from one or more tables.

• Link a JD Edwards EnterpriseOne application to one or more tables.

• Define the data items from multiple tables used by an application (such as table joins or table unions).

See Understanding Business Views.

Understanding Form Design Aid

Form Design Aid is part of the Interactive Application Design and is used to create or modify EnterpriseOne applications. Applications are composed of forms, and a form is the interface between a user and a table. This interface should present the data logically and contain the functions that are necessary to enter and manipulate data.

Interactive Application Design is the entry point to several tools for creating, generating, running, maintaining, and securing applications. Interactive Application Design includes Form Design Aid for creating forms and Event Rules Design for attaching business logic through event rules. Use Interactive Application Design to do the following:

• Access Form Design for creating forms.

• Run an application

• • Create text overrides

• Browse ER

• Browse forms in an application

• Use Visual ER Compare to compare event rules between two versions of an application

• Use FDA Compare to compare one version of an application with another

To start Interactive Application Design, choose an application in Object Management Workbench and click the Design button. In Interactive Application Design, you can change the metadata for the application. To access application metadata, click the Summary, Category Codes, and Install/Merge Codes tabs. You can also attach text and files to an application by clicking the Attachments tab. You can access all other functions from the Design Tools tab.

See Getting Started with JD Edwards EnterpriseOne Tools: Form Design Aid.

Understanding Report Design Aid

Report Design Aid is used to present business data stored in the EnterpriseOne database. EnterpriseOne data is stored in databases using relational tables. The data is typically presented using batch applications that access the data through business views.

You can use Report Design Aid to create a variety of simple and complex batch processes and reports. The interface is simple enough to use without programming expertise, yet powerful enough to create the most complex reports. You can also use Report Design Aid to create batch processes and reports.

Each report is comprised of sections, which are the building blocks of all reports. Within the template, you can add, hide, remove, and rearrange sections as needed.

You cannot process a report without a batch version. The batch version is submitted for processing, and once submitted, runs without user interaction. You do not interact with the report again until processing is complete.

A report exists as a set of specifications that are read by the EnterpriseOne batch engine for processing. You can create variations of a single report template using batch versions. The first step in creating a report is to create a report object within EnterpriseOne. This report is actually a template from which multiple versions can be created.

See Getting Started with JD Edwards EnterpriseOne Report Design Aid.

Understanding Data Structure Design

Data structures are a key element of any programming language or environment. A data structure is a list of parameters that passes data among applications and tables or forms. JD Edwards EnterpriseOne uses data structures in the following instances:

• The system generates a data structure.

• You create a data structure.

The two types of system-generated data structures are as follows:

• Form

  Each form with an attached business view has a default data structure. Data structures receive parameters from or send parameters to other forms during Form Interconnects. You maintain the data structure by using the Form/Data Structure menu option in Form Design.

• Report

  A batch application with an attached business view can receive parameters from or send parameters to a data structure. You can create and maintain the data structure from the Report/Data Structure menu option in Report Design. Unlike a form data structure, this type of data structure is not automatically populated with data items.

As a user, you can create three types of data structures, as follows:

• Media object data structures

  To enable an application for media objects, you must create a data structure to pass arguments from the application table to the media object table. To work with a data structure for media objects, create a new media object data structure or select an existing one to modify in Object Management Workbench.

• Processing options data structures

  You use processing options to create an input property sheet. You use a parameter list to pass processing options to an application. You can create a processing option data structure template or modify an existing template in Object Management Workbench.

• Business function data structures

  Any business function, whether it uses C or Business Function Event Rules as its source language, must have a defined data structure to send or receive parameters to or from applications. You can create a DSTR object type, or choose an existing object type to work with in Object Management Workbench. You can also create data structures for text substitution messages. Additionally, you can attach notes, such as an explanation of use, to any data structure or data item within the structure.

See Getting Started with JD Edwards EnterpriseOne Data Structure Design.

Understanding Event Rules Design

Use Event Rules Design to create business logic for an application. You can create event rules that do the following:

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

Areas where event rules can be added are:

• Controls

  A control is a reusable object that appears on a form. Examples include push buttons, edit fields, and grids. A form itself is also considered a control. Controls can be simple or complex. Simple controls have few event points to which logic can be attached. Complex controls can have many event points to which logic can be attached

• Events

  Events are activities that occur on a form, such as entering information a form or exiting a field by using the Tab key. 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 Read, when certain actions occur

• Form Processing

  Form processing refers to the business logic associated with each form. By default, each type of EnterpriseOne form automatically processes various events. You specify additional logic by using Event Rules Design. Form processing depends on the occurrence of specific events, such as initializing a form or changing the value of a field

• Event Rules

  Event rules are logic statements that you can create and attach to events. JD Edwards EnterpriseOne software uses two types of event rules: business function event rules and embedded event rules. Event rules are initiated when events occur at runtime. You can attach multiple event rules to one event. The various kinds of event rules include:

  • Business Function Event Rules

    Business function event rules are encapsulated, reusable, business logic that you create using Event Rules Design, rather than C programming. Business function event rules are stored as objects and are compiled. Business function event rules are sometimes called Named Event Rules (NERs).

  • Embedded Event Rules

    Embedded event rules are specific to a particular table, interactive application, or batch application. They are not reusable. Examples include using form-to-form calls, hiding a field that is based on a value in a processing option, and calling a business function. Embedded event rules can be in application event rules (interactive or batch) or in table event rules. They can be compiled or uncompiled.

  • Application Event Rules

    You can add business logic that is specific to a particular application. Interactive applications connect event rules via Form Design, while batch event rules use Report Design.

  • Table Event Rules

    You can create database triggers, or rules that you attach to a table by using Table Design Event Rules. The logic that is attached to a table is run whenever any application initiates that database event. For example, to maintain referential integrity, you might attach rules to a master table that delete all children when a parent is deleted. Any application that deletes information from that table does not need to have the parent/child logic embedded in it because that logic exists in the table.

See Getting Started with JD Edwards EnterpriseOne Tools: Event Rules.

Understanding System Functions

System Functions are procedures provided by the tool and are usually specific to the type of component being used. For example there are system functions to hide and show fields on an application, and there are system functions to execute different sections in a batch application. Parameters are passed into and out of the component for functionality. The available system functions are determined by the object type.

See System Functions in Form Design Aid.

Understanding Table I/O

Use the Table I/O button in Event Rules Design to create instructions that perform table input and output (I/O) so that you do not need to manually code a business function in C code. Table I/O allows you to access a table through event rules. You can use table I/O to do the following:

• Validate data

• Retrieve records

• Update or delete records across files

• Add records

For example, you can use table I/O to display information in a table that your application does not use. You can use Log Viewer to view your table I/O SQL statements in the jdedebug.log. To do so, your jde.ini file must have debugging set to File.

See Working with Table Input/Output.

Understanding Business Function Design

This topic discusses both C business functions and named event rules, and includes information about master business functions, Business Function Builder, and business function documentation.

You can use business functions to enhance EnterpriseOne applications by grouping related business logic. Journal Entry Transactions, Calculating Depreciation, and Sales Order Transactions are examples of business functions.

You can create business functions using one of the following methods:

• Event rules scripting language

  The business functions that you create using the event rules scripting language are referred to as Business Function Event Rules (also called Named Event Rules). If possible, use Business Function Event Rules for your business functions. In some instances, C business functions might better suit your needs.

  Note. NERs get generated into either C or Java.

• C programming code

  EnterpriseOne software creates a shell into which the user inserts logic using C. You use C business functions mainly for caching, but they can also be used for the following:

  • Batch error level messaging

  • Large functions

    C business functions work better for large functions (as determined by the group). If you have a large function, you can break the code up into smaller individual functions and call them from the larger function.

  • Functions for which performance is critical

  • Complex Select statements

After you create business functions, you can attach them to EnterpriseOne applications to provide additional power, flexibility, and control.

See Getting Started with JD Edwards EnterpriseOne Tools Development Standards for Business Function Programming.

Understanding Processing Options

Processing options control how an interactive or batch application processes data. You can use processing options to change the way in which an application or a report appears or behaves. You can attach unique processing options to different versions of the same application, which allows you to change the behavior of an application without creating a new application. In addition, you can use processing options to do the following:

• Control the path that a user can use to navigate through a system.

• Set up default values.

• Configure an application for different companies or different users.

• Control the format of forms and reports.

• Control page breaks and totaling for reports.

• Specify the default version of a related application or batch process.

You can define processing options for an application that automatically appear at runtime. In addition, you might need to create a processing option version. The procedures for creating a processing option version are similar to those for creating an interactive version.

See Using Processing Options.