JD Edwards Continues to Lead in ERP Technology Value Matrix 2016 - Nucleus Research

Here is the Link to read further

Overview of the JD Edwards EnterpriseOne Architecture

D Edwards EnterpriseOne is a complete suite of modular, preintegrated, industry-specific business applications designed for rapid deployment, ease of administration, and low total cost of ownership. It is ideally suited for organizations that manufacture, construct, distribute, service, or manage products or physical assets.

JD Edwards EnterpriseOne Tools is the runtime architecture and integrated development environment at the heart of the EnterpriseOne architecture. JD Edwards EnterpriseOne Tools is the technology layer that integrates with database systems, web application servers, reporting tools, and other third-party solutions. JD Edwards EnterpriseOne Tools provides an abstraction layer that allows the JD Edwards EnterpriseOne applications to function without a direct dependency on the platforms and middleware beneath them.

JD Edwards EnterpriseOne Tools supports the industry's leading hardware, operating systems, and database platforms. Moreover, JD Edwards EnterpriseOne applications look the same to application users, regardless of the database or hardware platform being used.

Figure 1-1 JD Edwards EnterpriseOne Application Suites

Description of "Figure 1-1 JD Edwards EnterpriseOne Application Suites"

The following illustration provides a high-level overview of the components that comprise the JD Edwards EnterpriseOne technology layer. These components enable functionality such as user interface, security, reporting, and so on, across all JD Edwards EnterpriseOne application modules. Although depicted and often named as servers, these are actually logical components, which often can be colocated on the same physical hardware or installed into virtual machines.

Figure 1-2 JD Edwards EnterpriseOne Technology Layer

Description of "Figure 1-2 JD Edwards EnterpriseOne Technology Layer"

This System Overview Guide provides a brief description of each of these technology components within the JD Edwards architecture. The information will help you plan the topology of your JD Edwards EnterpriseOne implementation by helping you understand the general function of each component, which components are mandatory, which are optional, and which components run on which platforms.

Modifying Table and Deployment Doubts

In JDE, for tables, you have :
- jde specs of the table that are stored in the database (but not used at runtime) and the local specs (on entreprise servers/fat clients) used at runtime. They describe which fields and indexes you used to define your table.

- the database tables, with their fields and indexes and data
- for web, the web specs of tables (stored in F98998 and F98999, at least in Xe …)

The process to deploy change of table is :
1 - update the jde specs of the table stored in the database (by doing the checkin in OMW)

2 - update the local specs on servers and fat clients (deploying a package, update or full. No 

need to delete any specs tables -dddict, ddtext and glbtbl must be deleted only for
data dictionnary changes-).
At this point, your jde specs are ok, but the table didn't change in your database.

3 - You have to make the «real» table in the database match the jde specs … Otherwise, you'll get error messages (when jde will try to access data in fields existing in jde specs but not defined in the database).
You can achieve that by either :
a - generate the table, using OMW, on a fat client.
To do that be sure the local specs of your fat client are up-to-date (either you installed the update/full package, or get the spec from OMW).
Beware that generate a table from there drop the table in your database and re-create it, according to the jde specs (fields, indexes, …).
So it means it'll delete any data in your table.
If you want to keep data, you'll have to save it first in some other table (in Oracle, with a simple create mysavetable as select * from mytable), then generate in OMW and insert the records back in your new table (chosing what you'll put in the new field for these previous records …).
b - You can make the change directly in your database to have it match with jde spec, either by adding the new columns (in Oracle, alter table mytable add …), which i don't like much (it leads to table fragmentation), or by sql drop/create the table.
The advantage of that 2nd option is that it can be done in a script to automate the deployment …
I use the first method only for totally new table, because you can generate the database table at any time before the deployment, because it won't be used before the deployment is finished. No error to be afraid of.
I use the second one for existing table with new columns that have to be changed only during the deployment and can't be before.

4 - on Xe at least, you have to use the egenerator to update the web specs of your table. It will use the local spec of your generator to update the F98999x tables.
Before doing it, i usually run R98CRTGL ube on the egenator, after i installed the update package. Because deploying an update package with a table delete the global tables, and makes the
client do JITI, which can sometimes disturb egeneration process.

5 - Bounce jas services, to be sure there's no old specs in jas cache.
Anyway, for our production environment, deployment is always done with restart. Hot deploy works fine on developpement platform, where not too much activity, but in production, too much problem.