JDE versions and platforms 2

[Mukul1]

Hi!
My company wishes to go in for JDE. What i'm unsure about, and need to get informed on, is... what are the versions of JDE like oneworld... what all platforms and databases does JDE run on... and what all are the modules which the versions have. Could any forum member direct me to a useful link or provide me with all this information?
Thanks in advance
Mukul

 

[Guest_imported]

At our company we only use thin clients in combination with Citrix for the users. With the implementation of JDE is seems that we need to buy full clients (PC's) for the application workstations. My question: can the full clients run under Citrix and is it really necessary at all to have full clients ?

 

[crashbang]

You can distribute Oneworld to your users entirely through Citrix but any development work will require a fat clients. One thing to note though. I have 30 users on fat clients, each of which requires a licence for JDE, and a Citrix server distrubuting JDE Oneworld to 30 users which requires 1 licence for JDE.

 

[monkeylizard]

Fat CLients are also required for Report Design. Although technically it's not development, JDE treats it as such. Any users that need to customize reports need a fat client. A zero client (Citrix) can USE any reports, canned or custom, they just can't alter them.

For clarification, JDE refers to FULL installs as 'Fat Clients' and Citrix/Terminal clients as 'Zero Clients' since there's actually no JDE installed loaclly to the client. A 'Thin Client' is a partial install of JDE. It 's like a Fat Client install, but only has the foundation code. The other pieces are installed from the deployment server on an as needed basis.

If you go with Citrix, be sure to use multiple servers or you will create an additional single point of failure. Monkeylizard
-Isaiah 35-

 

[JDETechConsultant]

The flexibility of the J.D. Edwards architecture does confuse things a bit...
As with all applications, you need Database, Business Logic, and Presentation layers. Here are some sample configurations and comments:

1) Enterprise Server (DB, BL)
Windows Client (PRES, BL)

This is a basic configuration that is appropriate for use over a local area network. The memory and processor power of the Enterprise Server is primarily used for database functions but can also be used for business logic and running reports. J.D. Edwards calls this a 'Virtual 3-Tier' configuration since the middle application tier functionality is handled by the Enterprise Server or the client. The Windows client can either be installed with all of the J.D. Edwards applications (Fin, Dist, Mfg, etc.) or with just enough of the foundation for it to run. In the later case, when a user access an application for the first time and that application does not reside on the client, the application is automatically installed on the fly (Just In Time Install or JITI). Regardless of the full or partial nature of the client install, this is still a 'Fat Client'.

2) Enterprise Server (DB, BL)
Application Server (BL)
Citrix Server (Pres, BL)
Citrix Client (Pres)

This is a typical configuration for a wide area network configuration or for a company that believes in minimizing desktop software installation and administration. The Citrix Server actually has a J.D. Edwards Windows Client (Fat Client) installed on it for multiple users to access. Because having multiple 'virtual' Windows clients on a single server can be resource intensive, an application server might be used to offload some of the business logic processing that would normally be done by the Windows client, allowing the Citrix Server to support higher numbers of clients. This is a 'Thin Client' configuration.

3) Enterprise Server (DB, BL)
Application Server (BL)
Java Application Server (Pres, BL) -- this is the JAS
Web Client (Pres)

This is an alternate configuration to scenario 2. This is a 'Thin Client' configuration--or better yet, a 'Zero Client' configuration because there is nothing you install on the client at all and no business logic is processed on the client. The J.D. Edwards applications run entirely on the application server and are delivered via java servlets and java server pages to a web browser (Netscape or IE) as HTML and Javascript. This is a cheaper (acquisition and administration) and more scalable solution than using Citrix.

There was a Java applet client that was supported up through Service Pack 19, but it is now deprecated since the Java Client offered no benefit over a Windows or Web Clients.

The J.D. Edwards software can scale vertically as I have mentioned, by adding different functional tiers (DB, App, Pres). But it can also scale horizontally. You can have multiple partitioned database servers handling specific tables, multiple application servers to segment the business logic work load, and multiple Citrix or JAS Servers supporting many 'virtual' users. The proper configuration is always implemenation specific, but just like your business can change on the fly, so can your J.D. Edwards architecture.

You will alway have a Deployment Server. This is an Wintel box that is used for installation, upgrades, modifications, deployments, and licensing. It can have some other administrative duties, but it will NOT be part of the production database, business logic, or presentation tiers.

Because of the flexibility of the architecture, you can technically use the Enterprise, Application, and JAS servers in multiple roles. You can have an all-in-one-box configuration, combine Application and JAS servers, combine Enterprise and Application servers, etc. Some configurations do not make sense, however, and will result in poor performance. And of course, you can use any combination of clients as well (Windows, Web, Citrix), this is not at all unusual.

It is very important that you do NOT use a 'rule of thumb' method for determining the required hardware resources. You should always work with a KNOWLEDGEABLE business parter or a J.D. Edwards hardware partner to do a system sizing and design. If you do not plan your technical foundation well you can end up wasting significant resources or worse jeopardize your implementation. DO IT RIGHT and you will have a flexible, scalable infrastructure that is easy to administer, and more importantly, you will have happy users.