JD Edwards EnterpriseOne Technical Foundation
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.
There are three basic fundamental concepts that enable JDE's CNC architecture: Environments, Path Codes and Object
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?
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
Thin vs. Fat Clients:
- 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.
- A server that serves up web pages to thin clients. Users use a browser to connect to the web server
for EnterpriseOne access.
- 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.
- A server that handles the processing of the logic, contains the data and is a central storage place
for all objects.
- A server that handles processing of application logic. It is used to run business functions and/or
- 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:
- Assemble the package - The package is named and objects to be included are specified.
- 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
- Build the package - During this step the specifics of the previous two steps are used to
copy and convert central objects to the package.
- 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
- 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.
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.
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.
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.
Please Note: The Intro to JDE pages on this site are intended to be brief summaries for JD Edwards customers
who are encountering JD Edwards for the first time. For more advanced knowledge, please review the
articles in our JD Edwards Library,
and our JD Edwards Training offerings for JDE clients.
Another excellent resource to help you get started with JD Edwards is JDEtips eLearning.