This chapter contains the following topics:
Oracle's JD Edwards Configurable Network Computing is the technical architecture for Oracle's JD Edwards EnterpriseOne software. Configurable Network Computing enables highly configurable, distributed applications to run on a variety of platforms without users or analysts needing to know which platforms or which databases are involved in any given task. Configurable Network Computing insulates the business solution from the underlying technology. Enterprises can grow and adopt new technologies without rewriting applications.
JD Edwards EnterpriseOne software comprises these software components:
Design Tools provides a unified set of tools to create all interactive applications, batch applications, and reports.
Applications provides the interactive and batch applications that perform your business needs. For example, Purchase Order Entry and General Ledger Post are applications.
Software Foundation Code provides underlying core processing that both interactive and batch applications depend on in order to run.
Software Middleware provides middleware that insulates the applications from the underlying database, operating system, hardware, messaging systems, and telecommunications protocols. Middleware insulates your business solution from the platform technology.
This section discusses the advantages that the JD Edwards EnterpriseOne Configurable Network Computing architecture provides:
Network-centric software
Flexible and leveraged technology
Worldwide business support
Custom solutions without consequences
Network-centric software enables you to create a uniform interface that supports a multiple-platform network. This compatibility across platforms provides:
Immediate availability of enhancements to all supported applications. Changes to these items are reflected in applications across the network:
Business objects
Business rules
Modes of processing
Hardware and database
Browser interface to support for internet technology
JD Edwards EnterpriseOne platform-neutral business specifications, or middleware, that comprise a common set of Application Program Interfaces (APIs) that integrate multiple-vendor, multiple-protocol differences. This integration insulates developers from the need to program to a specific platform.
You create the applications using tools that do not require a designer to master a programming language. JD Edwards EnterpriseOne tools conceal the code and enable the designer to concentrate on creating applications that are specific to current business needs and accommodate changes to business rules without reprogramming the application source code.
JD Edwards EnterpriseOne is object-based and event-driven to provide you with more efficient business processes. Developers can reuse objects between applications for different purposes. This reusability provides consistency throughout all JD Edwards EnterpriseOne applications.
JD Edwards EnterpriseOne does not rely on one command or keystroke to process information; rather, it processes information at strategic moments during the use of an application. For example, when a user moves among fields on a form, the system processes the information at the moment when the cursor leaves the field. JD Edwards EnterpriseOne immediately notes any errors and hides processing, such as an update of files that might also store information for the field, when the user moves to the next field on a form.
In addition, JD Edwards EnterpriseOne provides a common interface between applications. When you move from form to form, you see the same general setup.
JD Edwards EnterpriseOne provides support for mixed currency and languages. Also, you can run JD Edwards EnterpriseOne on platforms from servers to laptops. This scalability enables a traveling consultant to interface with the system and enter records. The consultant can then send these updated records over the internet to keep files as current as possible.
Note:
As of the ERP 8.0 release of JD Edwards EnterpriseOne software, JD Edwards EnterpriseOne no longer coexists with WorldSoftware. Contact Oracle for more information about migrating from WorldSoftware A73 to JD Edwards EnterpriseOne.You can make custom solutions to business applications with few or no consequences when you upgrade to a new release of JD Edwards EnterpriseOne. The JD Edwards EnterpriseOne toolset acts as an idea enabler by enabling you to transform a concept into a viable business solution. You maintain consistency across the enterprise, retain flexibility to adapt to changing business requirements, and minimize the time required to implement upgrades. This list provides examples of areas in JD Edwards EnterpriseOne that you can customize without consequences during an upgrade:
Vocabulary overrides
User overrides
Versions
Processing options
Code generator options
The section discusses the fundamentals of the Configurable Network Computing architecture, which consists of these items:
Environments
Path codes
Data Sources
Object Configuration Manager (OCM)
Object storage
Object deployment
A JD Edwards EnterpriseOne environment is a collection of pointers indicating the location of data and JD Edwards EnterpriseOne software objects. An environment answers these questions:
Where is my data?
What machine will process my logic?
What directory contains the object being processed?
JD Edwards EnterpriseOne provides an environment as a pointer to data and logic objects. For example, in the Purchase Order application the answers are as follows:
| Question | Response |
|---|---|
| Where is my data? | A user clicks the Find button to locate a Purchase Order. The environment determines in which database the table resides. |
| What machine will process my logic? | When finished entering an order, the user clicks OK. The environment determines where the logic (a master business function) necessary to record the transaction will process and where the transaction tables reside to enter the order. |
| What directory contains the object being processed? | After entering a user ID and password, a user must select the environment to log on to. If you have multiple sets of objects, selecting the environment determines which objects that JD Edwards EnterpriseOne executes (the directory in which they reside). This location is called a path code, and JD Edwards EnterpriseOne defines it in the Library List Master File (F0094) table. |
A path code can refer to the central development objects on the deployment server or to replicated objects on a workstation or logic server. A path code exists for each unique set of central objects. For example, you might have a set of objects reserved for software updates that you can deploy to users and a set of objects that you reserve for major enhancements.
A set of objects or the path code can reside in these locations:
Contains the central set of development objects specifications. All development occurs in this location. The path code connects the specifications and the C components on the deployment server.
Contains a replicated set of objects that JD Edwards EnterpriseOne uses at run time.
Contains a replicated set of objects that JD Edwards EnterpriseOne Enterprise andHTML servers use to process logic on these servers.
The Object Path table (F00942) contains path codes that track a set of objects and their location within JD Edwards EnterpriseOne.
A data source is the specific location of data or distributed processing. JD Edwards EnterpriseOne data sources can be:
An entire database in a specific location, regardless of the type of database, such as a MSDE located in a specific directory or a library in DB2 for IBM i
A specific machine in the enterprise that processes logic
The platform and data sources work together. You must define both the server that processes the logic and the databases that store the data. If multiple databases within one database management system (DBMS) reside on a machine, you must define each database to JD Edwards EnterpriseOne.
Do not confuse Microsoft open database connectivity (ODBC) data sources with JD Edwards EnterpriseOne data sources. The ODBC data source defines databases to various third-party communication products such as Client Access, Rumba, SQL Server, and MSDE. JD Edwards EnterpriseOne data sources define both databases and logic servers to JD Edwards EnterpriseOne.
This list describes JD Edwards EnterpriseOne data sources that you might use in the configuration:
A JD Edwards EnterpriseOne data source for an Oracle DBMS points to an Oracle Connect String and a Table Owner.
A JD Edwards EnterpriseOne data source for an Oracle DBMS points to an Oracle Connect String and a Table Owner.
A JD Edwards EnterpriseOne data source for a SQL Server DBMS points to a SQL Server Database (ODBC data source) and a Table Owner.
A JD Edwards EnterpriseOne data source for a DB2 for IBM i DBMS points to a RDB directory entry and a Library (ODBC data source).
A JD Edwards EnterpriseOne data source for a Microsoft Data Engine (MSDE) DBMS points to a MSDE database (OLBC data source).
The Object Configuration Manager (OCM) program (P986110) is a tool that configures distributed processing and distributed data at runtime without requiring programming. Using the Object Map table, the OCM points to the correct data, batch process, or business function for a given environment and user. The OCM is the control center for the runtime architecture. JD Edwards EnterpriseOne always uses the OCM to locate the data and platform needed to execute the distributed logic.
Every environment has an associated set of OCM mappings that indicate the distributed data and distributed processing locations for that environment.
This equation represents the relationship among the OCM, a path code, and an environment:
ENVIRONMENT = PATH CODE + OCM MAPPINGS
Where:
Path Code = what directory contains the object being processed
OCM mappings = (what database stores the data) + (where should the logic object execute)
JD Edwards EnterpriseOne provides three general storage formats; central objects, package objects, and serialized objects to accommodate several functions in JD Edwards EnterpriseOne.
You store objects in a central location to enable for these:
Deployment
Redeployment
Development
Central objects consist of object specifications for each JD Edwards EnterpriseOne object and C components for code-generated objects. Store the central object specifications in a relational database on either a deployment server or an enterprise server, depending on available resources. Store C components for code-generated objects in directories on the deployment server.
To deploy objects out to the enterprise, you define a package that JD Edwards EnterpriseOne creates from central objects. Each package contains a copy of the central objects. This copy consists of object specifications, and linked and compiled C components.
A package contains the necessary specifications and function libraries to run the business applications. Win32 clients have their own dedicated packages while servers share a single package. For example, to execute the Address Book application on a workstation, the workstation needs the object specifications and the compiled dynamic link library for the Address Book application and for any object that the application uses, such as data dictionary items, tables, and business views. The workstation and Enterprise server will store the compiled libraries on its file system. The object specifications will be stored in a Spec package.
A JD Edwards EnterpriseOne server shares a spec package contained in an enterprise RDMS with other JD Edwards EnterpriseOne servers and other web servers. A JD Edwards EnterpriseOne workstation now has a local database instead of TAM files.
The web server uses on-demand generation to create serialized objects from the shared object package when needed at runtime. The generator turns JD Edwards EnterpriseOne specifications into Java code, which enables you to access JD Edwards EnterpriseOne applications in HTML. The JD Edwards EnterpriseOne forms and applications that are generated are HTML objects. JD Edwards EnterpriseOne stores the objects in the local database and retrieves them at runtime. The serialized objects serve the function of a persistent cache.
Deploy JD Edwards EnterpriseOne to the workstations and servers using any of these methods:
Initial installation, for workstations and servers.
Workstation installation, for workstations.
Application installation, for workstations.
Just-in-time installation, for workstations.
The installation process is based on a centralized deployment server model. The Deployment Server Installation program (P986115) copies JD Edwards EnterpriseOne installation software from the CD-ROM to the deployment server. From the deployment server, you redistribute the software to the enterprise servers and workstations.
The Workstation Installation program (P986115) retrieves software from the package that you request. A package contains instructions that describe where to find the necessary components that the Workstation Installation program deploys to the local computer.
Each package represents a record of the central objects at a point in time. Once you build and test a package, you can safely modify central objects because users will not receive those objects until you build another package and make it available to them. Building a package involves copying the central objects to the package itself. The package then contains replicated objects, which JD Edwards EnterpriseOne can read at runtime.
Application installation can be used to quickly deploy changes to an individual application. The workstation initiates the application installation, and the deployment server responds by gathering and delivering all objects that are necessary to run the application.
Advantages of application installation are:
You do not need to build a new package and perform a global build before deploying the application change.
Developers and testers can use application installation to load changes that were recently checked into the central objects onto their machine.
Just-in-time installation installs applications to the workstation the first time you use them. For example, when you deploy a custom menu that contains a new application to a workstation, the object automatically installs on the workstation when a user clicks the menu option for the application.
Server deployment has been modified due to the migration from TAM specs to XML. A major change to server deployment are two new deployment models available for Java called the Discovery Process and the Spec.ini override. The Discovery Process is a web server auto-discovery model which places the system in control of the deployment.
JD Edwards EnterpriseOne is a multi-tier system that executes "Applications". The applications logic is contained in a "Package". These packages are built and deployed on "Nodes". Nodes are the participants in the system; such as a Windows client, Enterprise server, Java node (for example: HTML server, RTE server), and so forth.
The Spec.ini is a new file that is deployed to the \spec directory when a full package is installed. This file points to an XML package in a database.
The different deployments by releases are:
Deployment prior to 896:
Specs are in TAM binary format.
Specs are stored on the local file system.
A tool ("eGenerator") is used to convert TAM specs to serialized objects.
Generation is manual and needs to be done every time a package is deployed.
Generation only from a Windows client
Deployment in 896:
TAM Deployment (8.10, 8.11) is still supported. It uses the same deployment model as prior service packs.
H4A special cases.
XML Deployment (starting with 8.12) for Windows client, Enterprise server, Java nodes.
Deployment in 896 (H4A).
No change. Specs will be generated from the local package, in TAM or XML. No configuration changes required for Metadata.
Configuration flags in jdbj.ini will be ignored. specGenerateOnDemand is ignored and considered true.
Deployment in 896 (XML)
For all nodes the Specs are stored in XML in a RDBMS.
The Windows Client uses the local MSDE database with XML specs. The Spec.ini file is located in the \spec folder and points to the local database. It is deployed when a full package is installed on the fat client.
The Enterprise Server Spec.ini is deployed to the \spec directory when a full package is installed and points to an XML package in a database.
Java node (HTML server, RTE server, and so forth).
JD Edwards EnterpriseOne Java nodes utilizes a new deployment model called Discovery Process which enables the system to be in charge of controlling the deployment. Deployment of a package is fully automated. This process increases integrity and is best suited for production environments.
The web server Discovery Process will:
Locate the "default" enterprise server. The "default" server is defined as the default BSFN server for the signed-on user.
Find what package is deployed on that server.
Find the content of the package (including incremental package updates).
Delete any obsolete serialized objects.
Generate serialized objects on demand.
Some of the benefits to the Discovery Process deployment are:
Full and update packages are detected and applied automatically.
Serialized objects are cleared when invalid.
The web server executes application logic which is always up to date with the deployed package.
No manual process involved.
No need to bounce servers.
No need to deploy explicitly to a web server node.