JD Edwards EnterpriseOne Technical Foundation

Introduction

Configurable Network Computing (CNC) is the name JD Edwards gave to its technical architecture. It represents the system and networking side of JD Edwards EnterpriseOne. CNC allows highly configurable, distributed applications to run on a variety of platforms without users needing to know which platforms or databases are involved in a given task.

It means that even a single company can run multiple instances of EnterpriseOne on different hardware and middleware (including different database software), and the users will all see the same screens and functionality, and not need to concern themselves with where the data and programs physically reside.

CNC Fundamentals

There are three basic fundamental concepts that enable JDE's CNC architecture: Environments, Path Codes and Object Configuration Manager.

Environments

An environment is a collection of pointers indicating the location of data and EnterpriseOne. Three simple questions are answered by an environment:

·         Where is my data?

·         What machine will process my logic?

·         What directory contains the object being processed?

Path Codes

A path code is a set of objects. A path code defines an environment. There are multiple path codes or sets of objects in a standard system. A typical install will have development, prototype, production and pristine environments, each defined with a unique path code. A JDE customer needs multiple environments for various reasons. For example development and production need to be separate environments so that you can develop new functionality or test fixes in one set of objects without impacting the live, production environment.

Here are examples of different path codes:

Object Configuration Manager (OCM)

The Object Configuration Manager is a tool that configures processing and data at run time without requiring programming. Mappings are set up using data sources which tell the system where to find the data and where to run objects.

Above is an example of an OCM mapping. It illustrates that by default the environment, JPD900, accesses tables from the data source Business Data - PROD. There would be many other OCM mappings for this environment telling the system where to go for tables that are an exception to this as well as where batch jobs and business functions will run.

Summary of Fundamentals

Putting these three concepts together, an environment consists of a path code and object configuration mappings. So going back to the three questions answered by an environment, the path code answers the question of where the objects are and the object configuration mappings answer what database stores the data you are looking for and where the logic should be executed.

Machine Types

Thin vs. Fat Clients:

Workstation - Just a normal PC that we all have and use. Most people will use the workstation to access EnterpriseOne through a Citrix connection or a web browser. If you have an installation of EnterpriseOne actually installed on your workstation it is referred to as a fat client. Just having the Citrix connection or web browser connection would be considered a thin client.

Web Server - A server that serves up web pages to thin clients. Users use a browser to connect to the web server for EnterpriseOne access.

Citrix Server - A server containing EnterpriseOne client objects that multiple users can access at the same time by sharing the same specification files and applications. It allows thin client access by the users.

Enterprise Server - A server that handles the processing of the logic, contains the data and is a central storage place for all objects.

Applicaton Server - A server that handles processing of application logic. It is used to run business functions and/or batch jobs.

Deployment Server - A server that contains the business functions and the packages that are used to install EnterpriseOne across the enterprise.

Packages and Package Management

A package is a group of EnterpriseOne objects, which can be deployed together to the various servers and fat clients.
There are two main types of packages: full and update. Full packages contain everything you need to run EnterpriseOne. A full package is a complete set of objects and system tools for a specific path code. An update package enables you to update, add to, or refresh your existing full package with changed objects. These are much smaller and easier to handle than full packages.

When you are preparing a package, prior to deployment, there are five steps:

1.      Assemble the package - The package is named and objects to be included are specified.

2.      Define the package build - Build options are specified, such as business function build options and compression options. The package build also specifies if the build is for a client or server or both.

3.      Build the package - During this step the specifics of the previous two steps are used to copy and convert central objects to the package.

4.      Schedule the package for deployment - At this step you choose which workstations will receive the package including date and time to be received, whether the package is mandatory or optional, etc.

5.      Deploy the package to the enterprise server - This step is necessary to keep the enterprise server synchronized with the workstations.

The package build process is the most important part of CNC. It is the only way that new custom objects and fixes to the existing software can be pushed out to the users. Even something as simple as a new version of a report is a new custom object which needs to be part of a package build before other users can see the report and run it.

Software Fixes
EnterpriseOne is dynamic and continues to change as problems arise or enhancements are needed. JDE's problem tracking system calls individual requests SARs. A SAR is a Software Action Request. Oracle now calls them Bug Requests. SARs are created based on calls received from customers that are having problems or need additional functionality. These SARs are then forwarded to Oracle's development group and turned into fixes that fall into two categories: Tools Releases and ESUs.

A tools release (previously called a service pack) is geared towards fixing problems and enhancing EnterpriseOne system objects that function behind the scenes. Tools releases are always cumulative.

An ESU (Electronic Software Update) affects a set of user objects (application programs) and may include many SARs. These SARs are bug fixes or enhancements to applications and reports. An individual SAR may affect one or multiple objects. Objects are grouped by dependencies. In this type of fix, the changes you get to a specific object are cumulative so that you always have the most recent version of the object when you download a fix in a certain area. They are also path code specific so they can be tested before being moved to the production set of objects.

Typically you download an ESU from the internet, apply it to the development path code, build it into an update package, deploy it to a test machine and then test it. You do all of this without impacting your production set of objects. These fixes never reach production until they have been fully tested and approved.

Security

Various types of security are used within EnterpriseOne to control which applications, data and actions users are allowed access to. The main types of security are application and action code security.
Application security controls what objects users can access. Action code security controls what buttons users can access within application, such as add, change, delete. EnterpriseOne also has row and column security that control table access at the record or field level.

Development

EnterpriseOne allows companies to develop custom objects as well as modify standard objects. All source code on the application level is available and can be analyzed or changed based on need. The following object types exist:

APPL - Interactive Application - used to interact with the system in a real time basis
BSFN - Business Function - used to run routines or sets of code
BSVW - Business View - view over a table or combination of tables
DSTR - Data Structure - parameter list
GT - Media Object Data Structure - block of text or embedded object or a link to a file
TBLE - Table Definition - data or file containing fields
UBE - Batch Application - processes that run on a server and either perform table updates and data processing or create reports

Development is done using the Object Management Workbench which is a project-based system that uses various statuses to allow development and promote objects throughout the system. The standard project statuses are:

11 - New Project Pending Review
21 - Programming
25 - Rework-Same Issue
26 - QA Test/Review
28 - QA Test/Review Complete
38 - In Production
01 - Complete

A project can move forward and backward through these statuses until it is complete.
There are two types of programming done by EnterpriseOne programmers. The first is using the event rule language which is a 4th generation language, developed by JD Edwards, that builds code from wizard-like interfaces. The second type of programming uses C++ language. C code is only done in business functions. You can create business functions called Named Event Rules (NER) using event rules but when they are compiled, they are converted into C code.