This chapter contains the following topics:
Oracle's JD Edwards EnterpriseOne Architecture is an application architecture that enables interactive and batch applications, composed of a single code base, to run across a network of multiple server platforms and databases. The applications consist of reusable business functions and associated data that can be configured across the network dynamically. The overall objective for businesses to provide a future-proof environment that enables them to change organizational structures, business processes and technologies independently of each other.
EnterpriseOne standardizes and automates software installation, making many steps transparent to users. Technical setup is preconfigured to meet the requirements of many EnterpriseOne customers. In addition, EnterpriseOne products are pre-integrated and share a common database, which reduces the implementation process, minimizes ongoing administration, and provides customers the flexibility to add in new applications, modules, and tools as needed.
The EnterpriseOne implementation methodology defines specific roles that are involved in the design, installation, and configuration of an ERP solution. These roles are generally divided into four implementation teams:
Technology - installation and upgrades, system administration, security, change management.
Development - data conversions, interfaces, custom modifications.
Functional - business process, application configuration, integration and testing, end-user training.
Systems Integration - data center design, hardware support, network infrastructure, third-party software.
Each of these implementation teams is staffed by both consultant and customer roles. As an implementation progresses to completion, the consultant roles diminish, while the customer roles remain and often increase in level of responsibility. It is critical, therefore, that the customer ensures that each role to be assumed by its personnel is adequately trained.
Typically, the technology project team is led by a single consulting role, the technology specialist, and two customer roles, the system administrator and the change management administrator. The technology specialist and system administrator are involved with installing EnterpriseOne and setting up environments, users, security, distributed processing, data replication, and other system administration and operations support topics. The technology specialist and change management administrator are responsible for setting up version control, applying software updates and service packs, reviewing and promoting code and data across change management environments, and deploying code and data changes to the servers and workstations involved in the ERP solution.
The development project team is typically led by a custom solution consultant and staffed by one or more application developers. The custom solution consultant resolves business issues by developing applications. Primary responsibilities include developing a data migration strategy, designing interfaces to legacy and third-party systems, and designing custom modifications with upgrades in mind. The application developers migrate legacy data, code and test interfaces, code and test custom modifications, and integrate all code changes into the ERP solution.
While the change management administrator performs the version control functions that control the acceptance, promotion, and deployment of software changes, the custom solution consultant must help develop the internal procedures for realizing an application development life cycle within your business. In addition, development team members must be aware of change management tools and procedures, as well as how the technology components affect the design and operation of interfaces and custom modifications.
The functional project team is led by a consulting project manager and a customer project manager, and staffed by application specialists and customer process owners. These project members are responsible for the design, configuration, and deployment of EnterpriseOne applications, as well as the modeling of all business processes that will be realized through the application set. After EnterpriseOne is installed, configured, and rolled out, the application specialists continue in their role as product experts. Although application specialists do not implement technology-level solutions, they must understand how the software handles distributed processing, data replication, environments, and so on, because these application issues influence technology design and configuration. In addition, application specialists and process owners must become expert at troubleshooting potential problems and identifying the difference between a technology issue and an application issue.
The systems integration project team is responsible for many tasks that are outside the scope of services. Third-party consultants provide some of these services and supplement EnterpriseOne staff as EnterpriseOne Architect consultants, network architects, custom modification consultants, and so on. In addition, customers provide hardware and network infrastructure support.
Implementing the EnterpriseOne system includes many tasks that are outside the scope of EnterpriseOne software and services. Systems integration (that is, third-party) consultants provide these services to help you align the infrastructure to optimally support EnterpriseOne applications and runtime services, as well as expand the overall business solution with complementary third-party products. These consultants are able to assist with such services as data center design, IT process improvement, and network infrastructure. They are also able to assist with the installation, configuration, and integration of third-party hardware and software products that enhance and extend the EnterpriseOne software solution. These project members should be aware of the architecture and technical behavior of EnterpriseOne software and of how the various technology components interact with operating systems, database management systems, third-party middleware, and the network.
EnterpriseOne architecture is the technical architecture for EnterpriseOne software. EnterpriseOne 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. EnterpriseOne architecture insulates the business solution from the underlying technology. Enterprises can grow and adopt new technologies without rewriting applications.
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 EnterpriseOne architecture provides:
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:
Modes of processing
Hardware and database
Browser interface to support for internet technology
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. 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.
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 EnterpriseOne applications.
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. 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, EnterpriseOne provides a common interface between applications. When you move from form to form, you see the same general setup.
EnterpriseOne provides support for mixed currency and languages. Also, you can run 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 EnterpriseOne. The 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 EnterpriseOne that you can customize without consequences during an upgrade:
Code generator options
This section discusses the fundamentals of the EnterpriseOne architecture, which consists of these items:
Object Configuration Manager (OCM)
An EnterpriseOne environment is a collection of pointers indicating the location of data and 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?
EnterpriseOne provides an environment as a pointer to data and logic objects. For example, in the Purchase Order application the answers are as follows:
|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 EnterpriseOne executes (the directory in which they reside). This location is called a path code, and 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 EnterpriseOne uses at run time.
Contains a replicated set of objects that EnterpriseOne Enterprise and HTML 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 EnterpriseOne.
A data source is the specific location of data or distributed processing. 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 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 EnterpriseOne.
Do not confuse Microsoft open database connectivity (ODBC) data sources with EnterpriseOne data sources. The ODBC data source defines databases to various third-party communication products such as Client Access, Rumba, SQL Server, and MSDE. EnterpriseOne data sources define both databases and logic servers to EnterpriseOne.
This list describes EnterpriseOne data sources that you might use in the configuration:
An EnterpriseOne data source for an Oracle DBMS points to an Oracle Connect String and a Table Owner.
An EnterpriseOne data source for an Oracle DBMS points to an Oracle Connect String and a Table Owner.
An EnterpriseOne data source for a SQL Server DBMS points to a SQL Server Database (ODBC data source) and a Table Owner.
An EnterpriseOne data source for a DB2 for i DBMS points to a RDB directory entry and a Library (ODBC data source).
An 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. 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
Path Code = what directory contains the object being processed
OCM mappings = (what database stores the data) + (where should the logic object execute)
EnterpriseOne provides three general storage formats; central objects, package objects, and serialized objects to accommodate several functions in EnterpriseOne.
You store objects in a central location to enable for these:
Central objects consist of object specifications for each 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 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.
An EnterpriseOne server shares a spec package contained in an enterprise RDMS with other EnterpriseOne servers and other web servers. An 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 EnterpriseOne specifications into Java code, which enables you to access EnterpriseOne applications in HTML. The EnterpriseOne forms and applications that are generated are HTML objects. EnterpriseOne stores the objects in the local database and retrieves them at runtime. The serialized objects serve the function of a persistent cache.
User Defined Objects (UDOs) are personalized objects that you can view, create, and share for your own use, depending on the permissions you have been granted. The following list contains all UDOs:
EnterpriseOne Pages are the first screen end-users see when they log into EnterpriseOne. They are HTML files, and can contain any HTML-enabled functionality, such as interactive process flows, URL links and web pages, company logos, etc. You must be proficient in coding HTML to configure or create EnterpriseOne Pages.
CafeOne is an abbreviation for the Composite Application Framework, which is a user interface framework that enables EnterpriseOne applications to integrate with multiple third-party contents and applications, as well as other EnterpriseOne applications.
Queries enable you to select fields and QBE columns from a form and add conditions to make the search criteria more specific. The query feature is enabled on find browse, search/select, and power browse forms that have a Find button. Additionally, you can create queries in Data Browser for records in tables and business views.
Watchlist is a collection of items that match user-defined criteria and contain information to which users have selected to be alerted.
Grid Formats are a selection of the columns you choose to display, and the sequence in which they are displayed. Grid formats enable you to customize how information is displayed in your grid.
One View Reports (OVRs) consist of A One View Report consists of:
A Business Intelligence (BI) Publisher data model, which is a <report name>.xdmz file on the BI Publisher server.
A BI Publisher report, which is a <report name>.xdoz file on the BI Publisher server.
The report definition for the One View Report, which is the metadata for the report and resides in EnterpriseOne.
Deploy EnterpriseOne to the workstations and servers using any of these methods:
Initial installation, for workstations and servers.
Workstation installation, for workstations.
Update packages for individual objects.
The installation process is based on a centralized deployment server model. The Deployment Server Installation program copies EnterpriseOne installation software from the extracted downloaded file location to the deployment server. From the deployment server, you redistribute the software to the enterprise servers and workstations.
The Workstation Installation program 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 EnterpriseOne can read at runtime.
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.
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.