distributed and wan environments - erpsourcing network computing... · master business functions...

Configurable Network Computing Options for Distributed and Wide Area Network (WAN)

Environments

Revision 1

Document Number: ATG DISTWAN

Technical PreView

Technical PreView

OneWorld in Distributed and WAN Environments Revision History

ii Technical PreView – J.D. Edwards Confidential

Revision History

Revision and Date

Comment

1

4/23/98

First printing. Published electronically at:

http://corwwws1/advancedtechnologies/techcomm/techpreview.htm

Printed copies of this guide can be ordered from the J.D. Edwards Document Source using the Documentation Ordering Form at:

http://corwwws1/Documentation/Ordering/ordfrm.xls

The Item Number for this document is ATG DISTWAN and it can be ordered under the release tabs B73.1 and B73.2.

Please send email comments, corrections, and suggestions to [email protected]

Intended Audience The purpose of this document is to provide general background material for deploying OneWorld in distributed and Wide Area Network (WAN) environments. This document does not make recommendations, implied or actual. It provides test results and from those results certain limited conclusions can be drawn in terms of relative performance gains or losses. However, due to the wide variety of networking, hardware, and software configurations found in OneWorld installations, no guarantee can be made that specific results are achievable in any particular installation.

The intended audience for this document includes J.D. Edwards employees and OneWorld business consultants. This document is considered J.D. Edwards Confidential Information and distribution and use outside its intended audience is strictly prohibited.

Copyright (c) J.D. Edwards World Source Company, 1998. J.D. Edwards World Source Confidential. J.D. Edwards is a registered trademark of J.D. Edwards & Company.

Except as otherwise noted, the names of all other products of J.D. Edwards used herein are trademarks or registered trademarks of J.D. Edwards World Source Company.

All other product names used are trademarks or registered trademarks of their respective owners.

Technology Demographic Table

Product OneWorld

Version B73.1, B73.2, B73.2.1

Platform/OS All

Industry All

Application All

Database All

OneWorld in Distributed and WAN Environments Revision History

Technical PreView – J.D. Edwards Confidential iii

or telephone (303) 334-1789.

OneWorld in Distributed and WAN Environments Table of Contents

iv Technical PreView – J.D. Edwards Confidential

Table of Contents

INTRODUCTION ............................................................................................................................. 3

OVERVIEW..........................................................................................................................................3 CASE STUDIES....................................................................................................................................4 LAN AND WAN NETWORK ISSUES ...................................................................................................4 CONFIGURABLE ARCHITECTURE OF ONEWORLD APPLICATIONS..........................................................6

GUI Presentation Specifications.................................................................................................. 6 Business Function Components.................................................................................................... 6

Master Business Functions ............................................................................................................7 Major Business Functions ..............................................................................................................7 Minor Business Functions ..............................................................................................................7 Generated Java Applets and Servlets .............................................................................................7

Application Programming Interfaces (APIs)................................................................................ 7 Middleware................................................................................................................................... 9

JDENET Communication Middleware............................................................................................9 JDEBASE Database Middleware ..................................................................................................9

SECTION 1: DEPLOYMENT STRATEGIES .............................................................................. 13

STRATEGY 1: DATA REPLICATION.....................................................................................................13 Database-Only Workgroup Servers............................................................................................ 14

B73.1 and B73.2......................................................................................................................... 14 “Push” Replication Method: Enterprise Server is Both “Publisher” and “Subscriber” ....... 14

B73.2.1...................................................................................................................................... 15 “Push” Replication Method: Enterprise Server is Both “Publisher” and “Subscriber” ....... 15 Third-party Replication Combined with J.D. Edwards “NON” Mode ................................... 16

STRATEGY 2: PARTITIONING APPLICATION LOGIC..............................................................................18 Model: How a Master Business Function Operates ................................................................... 18

SOE Event ? – End of Sales Order Line.................................................................................... 19

SOE Event ? – MBF Receives Line Message ........................................................................... 19

SOE Event ? – MBF Extends and Edits the Line ....................................................................... 20

SOE Event ? – MBF Sends Return Message to Client Application.............................................. 20

SOE Event ? – End of Sales Order (OK Button) ....................................................................... 21

SOE Event ? – MBF Processes the Full Transaction.................................................................. 21

SOE Event ? – Transaction Commitment to the Database and MBF Clean-Up............................ 22 Server Behavior with Partitioned Application Logic ................................................................. 23

Processing Rule 1 – JDENET on Client ....................................................................................... 24 Processing Rule 2 – JDENET on the Server................................................................................. 24

Example: JDENET processes on a server ............................................................................. 25 Processing Rule 3 – Kernels on the Server................................................................................... 26

Example: Kernel processes on a server ................................................................................ 27 STRATEGY 3: HARDWARE TIERS........................................................................................................28

Workgroup Servers..................................................................................................................... 29 Application Servers .................................................................................................................... 30


Technical PreView – J.D. Edwards Confidential v

Mixed-Tier Configuration Model ............................................................................................... 30 STRATEGY 4: WINDOWS TERMINAL SERVER (WTS) ..........................................................................32

Bandwidth Considerations ......................................................................................................... 32 WTS Sizing Considerations......................................................................................................... 33

STRATEGY 5: ONEWORLD JAVA / HTML APPLICATION OFFERINGS ..................................................35

SECTION 2: PLANNING GUIDELINES ..................................................................................... 40

STRATEGY 1: DATA REPLICATION.....................................................................................................40 Join Considerations.................................................................................................................... 40

Releases B731.1, B731.2, and B732 Base .................................................................................... 40 Release B732.1 .......................................................................................................................... 41

Tables That Cannot Be Replicated Using OneWorld Replication .............................................. 41 Tables That Can Be Replicated .................................................................................................. 42

System Tables ............................................................................................................................ 42 Constants Tables ........................................................................................................................ 42 Master Tables ............................................................................................................................ 43 Language Support Tables ............................................................................................................ 44 Data Dictionary Tables ............................................................................................................... 45

Deciding how Data Dictionary Changes will be Propagated to Clients................................ 45 Replicating the Data Dictionary to Workgroup Servers........................................................ 45 Replicating the Data Dictionary to Application Servers........................................................ 46

User Defined Code (UDC) Tables............................................................................................... 47 Menus........................................................................................................................................ 48

STRATEGY 2: PARTITIONED APPLICATION LOGIC...............................................................................49 OCM Mappings for Partitioned Logic ....................................................................................... 49

Financials ................................................................................................................................... 49 Organization Structure (P0006A)..................................................................................................................................... 50 Invoice Entry (P03B11).................................................................................................................................................... 50 Receipt Entry (P03B102)................................................................................................................................................. 50 Voucher Entry (P0411)..................................................................................................................................................... 51 Journal Entries (P0911) .................................................................................................................................................... 51 Trial Balance by Business Unit (P09210A) ..................................................................................................................... 51

Distribution................................................................................................................................. 53 Inventory .............................................................................................................................. 53

Inventory Issues (P4112) ................................................................................................................................................. 53 Inventory Adjustments (P4114)....................................................................................................................................... 53 Inventory Transfers (P4113)............................................................................................................................................ 54 Inventory Reclassifications (P4116)................................................................................................................................. 54

Sales Order Processing ........................................................................................................ 54 Sales Order Entry (P4210)................................................................................................................................................ 55 Shipment Confirmation (P4205)....................................................................................................................................... 56 Backorder Release (P42117)............................................................................................................................................. 56

Procurement ......................................................................................................................... 56 Purchase Order Entry (P4310) ......................................................................................................................................... 57 Purchase Receipts (P4312)............................................................................................................................................... 58 Receipt Routing (P43250) ................................................................................................................................................ 59 Voucher Matching (P4314)............................................................................................................................................... 59

Manufacturing ............................................................................................................................ 60 Product Data Management................................................................................................... 60

Routing Master (P3003)................................................................................................................................................... 60


vi Technical PreView – J.D. Edwards Confidential

Bill of Material (P3002).................................................................................................................................................... 60 Work Center Master (P3006)........................................................................................................................................... 61 Work Center Rates (P3006).............................................................................................................................................. 61 Bill of Material Inquiry (P30200)..................................................................................................................................... 61

Shop Floor Control .............................................................................................................. 62 Work Order Parts Lists (P3111)....................................................................................................................................... 62 Work Order Routings (P3112).......................................................................................................................................... 62 Work Order Issues (P31113)............................................................................................................................................ 63 Work Order Completions (P31114) ................................................................................................................................. 63 Work Order Hours and Quantities (P311221).................................................................................................................. 63

Requirements Planning ......................................................................................................... 64 Planning Messages (P3411).............................................................................................................................................. 64

APPENDIX A: JDE.INI SETTINGS FOR SERVER PROCESSES........................................... 68

JDE.INI PARAMETERS FOR JDENET_N.................................................................................................68 VARIABLE VALUES FOR JDENET_N SETTINGS .....................................................................................68 ONEWORLD LOGIC PROCESSES (JDENET_K) ......................................................................................69 JDE.INI PARAMETERS FOR JDENET_K TYPE DEFINITIONS.....................................................................69 VARIABLE VALUES FOR JDENET_K TYPE DEFINITIONS ........................................................................70 JDE.INI PARAMETERS FOR NUMBERS OF JDENET_K PROCESSES ...........................................................71 VARIABLE VALUES FOR NUMBERS OF JDENET_K PROCESSES ..............................................................71

APPENDIX B: HP/UNIX KERNEL PARAMETER SETTINGS FOR ONEWORLD ............. 76

Message Queues ......................................................................................................................... 76 Semaphores ................................................................................................................................ 77 Shared Memory .......................................................................................................................... 78 File Descriptors .......................................................................................................................... 79 Processes .................................................................................................................................... 79

GLOSSARY..................................................................................................................................... 81

OneWorld in Distributed and WAN Environments Table of Figures

Technical PreView – J.D. Edwards Confidential vii

Table of Figures

Figure 1. Building Blocks to Generate OneWorld in Various Environments..............................................8

Figure 2. “Push” Replication Method for Database-Only Workgroup Servers (B73.1 and B73.2)..........15

Figure 3. “Push” Replication Method for Database-Only Workgroup Servers (Release B73.2.1)...........16

Figure 4. “Non” Mode for Database-Only Workgroup Servers (Release B73.2.1)................................17

Figure 5. End of Sales Order Line ........................................................................................................19

Figure 6. MBF Receives Line Message ................................................................................................19

Figure 7. MBF Extends and Edits the Line............................................................................................20

Figure 8. MBF Sends Return Message to Client Application.................................................................20

Figure 9. End of Sales Order (OK Button) ...........................................................................................21

Figure 10. MBF Processes the Full Transaction....................................................................................21

Figure 11. Transaction Commitment to the Database and MBF Clean-up..............................................22

Figure 12. Managing Partitioned Application Logic ...............................................................................23

Figure 13. Example: JDENET Processes on a Server............................................................................25

Figure 14. Kernel Processes on a Server ..............................................................................................27

Figure 15. Hardware Tiers (non-WTS or Java).....................................................................................28

Figure 16. Mixed-Tier Configuration Model..........................................................................................31

Figure 17. WTS (Hydra) – Typical Layout ...........................................................................................34

Figure 18. OneWorld Java / HTML – Single Repository, Optional Generation......................................35

Figure 19. OneWorld Java / HTML – Implementation Overview...........................................................36

Figure 20. Replicating the Data Dictionary to Workgroup Servers.........................................................46

Figure 21. jdenet_n and jdenet_k Process Flow....................................................................................73

OneWorld in Distributed and WAN Environments List of Tables

viii Technical PreView – J.D. Edwards Confidential

List of Tables

Table 1. Summary of Network Characteristics........................................................................................5

Table 2. Deployment Strategies – Availability........................................................................................13

Table 3. Tables That Cannot Be Replicated Using OneWorld Replication..............................................41

Table 4. Constants Tables – Data Replication Candidates .....................................................................42

Table 5. Language Tables – Data Replication Candidates......................................................................44

Table 6. Data Dictionary Tables – Data Replication Candidates ............................................................47

Table 7. User Defined Code (UDC) Tables – Data Replication Candidates...........................................47

Table 8. Menu Tables – Data Replication Candidates ...........................................................................48

Table 9. Organization Structure (P0006A) – Partitioned Logic Source Members...................................50

Table 10. Invoice Entry (P03B11) – Partitioned Logic Source Members...............................................50

Table 11. Receipt Entry (P03B102) – Partitioned Logic Source Members ............................................50

Table 12. Voucher Entry (P0411) – Partitioned Logic Source Members ...............................................51

Table 13. Journal Entries (P0911) – Partitioned Logic Source Members ...............................................51

Table 14. Trial Balance by Business Unit (P09210A) – Partitioned Logic Source Members...................51

Table 15. Inventory Issues (P4112) – Partitioned Logic Source Members.............................................53

Table 16. Inventory Adjustments (P4114) – Partitioned Logic Source Members ...................................53

Table 17. Inventory Transfers (P4113) – Partitioned Logic Source Members........................................54

Table 18. Inventory Reclassifications (P4116) – Partitioned Logic Source Members..............................54

Table 19. Sales Order Entry (P4210) – Partitioned Logic Source Members ..........................................55

Table 20. Shipment Confirmation (P4205) – Partitioned Logic Source Members...................................56

Table 21. Backorder Release (P42117) – Partitioned Logic Source Members ......................................56

Table 22. Purchase Order Entry (P4310) – Partitioned Logic Source Members ....................................57

Table 23. Purchase Receipts (P4312) – Partitioned Logic Source Members..........................................58

Table 24. Receipt Routing (P43250) – Partitioned Logic Source Members ...........................................59

Table 25. Voucher Matching (P4314) – Partitioned Logic Source Members .........................................59

OneWorld in Distributed and WAN Environments List of Tables

Technical PreView – J.D. Edwards Confidential ix

Table 26. Routing Master (P3003) – Partitioned Logic Source Members..............................................60

Table 27. Bill of Material (P3002) – Partitioned Logic Source Members...............................................60

Table 28. Work Center Master (P3006) – Partitioned Logic Source Members .....................................61

Table 29. Work Center Rates (P3006) – Partitioned Logic Source Members........................................61

Table 30. Bill of Material Inquiry (P30200) – Partitioned Logic Source Members..................................61

Table 31. Work Order Parts Lists (P3111) – Partitioned Logic Source Members .................................62

Table 32. Work Order Routings (P3112) – Partitioned Logic Source Members....................................62

Table 33. Work Order Issues (P31113) – Partitioned Logic Source Members......................................63

Table 34. Work Order Completions (P31114) – Partitioned Logic Source Members............................63

Table 35. Work Order Hours and Quantities (P311221) – Partitioned Logic Source Members .............63

Table 36. Planning Messages (P3411) – Partitioned Logic Source Members.........................................64

OneWorld in Distributed and WAN Environments

Technical PreView – J.D. Edwards Confidential 1

INTRODUCTION


2 Technical PreView – J.D. Edwards Confidential

OneWorld in Distributed and WAN Environments Introduction


Introduction

This document discusses numerous OneWorld configuration strategies and presents planning guidelines that will assist the field organization in deploying OneWorld for optimum performance in distributed and Wide Area Network (WAN) environments. There are five (5) deployment and configuration strategies that are all fully supported by OneWorld Configurable Network Computer (CNC) architecture, and which may be used singly or in combination to optimize OneWorld distributed and WAN performance are discussed in the Paper. These five (5) strategies and their availability are outlined in the table below.

Strategy Availability

1: Data Replication Available with B73.1

2: Partitioning Application Logic Available with B73.2.1

3: Hardware Tiers Available with B73.2.1

4: Future: Windows Terminal Server (WTS) – Hydra Beta – Projected availability with B73.2.2

5: Future: OneWorld Java / HTML Applications Beta – Projected availability with B73.3

Overview This document contains the following major sections:

Deployment Strategies This “educational” section contains background material on OneWorld distributed and WAN operations including the facilities and deployment strategies best suited for achieving optimal performance in distributed and WAN environments. An understanding of this material is critically important as it relates to the Planning Guidelines presented in this document. Understanding the Deployment Strategies will assist in the successful deployment of efficient distributed and WAN configurations in the field.

Planning Guidelines This “How To” section contains planning guidelines which are relevant to implementing two of the key deployment strategies for OneWorld distributed and WAN configurations: Data Replication and Partitioning Application Logic.

Appendices These appendices provide technical information:

?? Appendix A: jde.ini Settings for Server Processes



?? Appendix B: HP/UNIX Kernel Considerations

Case Studies

Additional supporting information related to configuring OneWorld for distributed and WAN operations along with additional test results will be published in the form of Case Studies. Published Case Studies will fall into two categories:

1. Customer Case Studies. These studies will document OneWorld operations in distributed and WAN environments. These studies will be published by the J.D. Edwards Advanced Technologies Group (ATG).

2. Performance Laboratory Case Studies. These studies will include data from laboratory tests aimed at analyzing and optimizing OneWorld operations in distributed and WAN environments. These studies will be published by J.D. Edwards Development organization’s Performance Laboratory.

LAN and WAN Network Issues

There are a number of technical factors that distinguish a Local Area Network (LAN) from a Wide Area Network (WAN). An in-depth discussion of these technical factors is contained in a document posted on the J.D. Edwards Knowledge Garden entitled J.D. Edwards Networking Primer and it is recommended reading. This document can be found at the following location:

http://corwwws1/it/servicemanagement/network_primer/network_primer.htm

As explained in the Network Primer, LANs are relatively fast and inexpensive whereas WANs are relatively slow and more expensive. Most Ethernet LANs operate at 10 megabits per second (Mbps) -- 10,000,000 bits of data transported per second. Ethernet hardware is now available that can operate at 100 Mbps (called Fast Ethernet) or 1,000 Mbps (called Gigabit Ethernet). Token ring LAN networks are typically configured to run at either 4 or 16 Mbps. In a WAN environment leased private line speeds range from 9.6 kilobits per second (Kbps) to 56 Kbps. More expensive and higher bandwidth T1 and T3 service can also be acquired in some worldwide locations to speed WAN operations.

The table below summarizes these relative speeds and rough comparative costs. It should be noted that the cost of WAN circuits is mileage sensitive and varies greatly from region to region, particularly internationally. Furthermore, not all types of service are available in all locations. The rough cut costs provided are typical United States rates for connections of 500 to 1000 miles.



Table 1. Summary of Network Characteristics

Network Type Speed Rough Cut Cost1 Comment

Token Ring 4 to 16 Mbps 0 LAN

Ethernet 10 to 1000 Mbps 0

T1 1.544 Mbps $10,500 per month

T3 45 Mbps $50,000 per month 28 aggregated T1 links

Leased 9.6 to 56 Kbps $1,000 to $4,000 per month

WAN

Frame Relay 56 Kbps to T1 $450 to $4000 per month Based on committed information rate(CIR)

Analog 9.6 to 33.6 Kbps $8.00 per hour Dial-Up

ISDN 56 to 128Kbps $8 to 20.00 per hour

Notes: 1 Costs are United States costs. These are operational costs and do not include the capital costs of building the network infrastructure.

In addition to raw bandwidth and speed another factor that favors LAN performance over WAN performance is latency. No matter how small the amount of data, for any particular network device, there is always a minimum hardware/software interaction time that cannot be eliminated. This is referred to as the latency of the device or service. For example, a typical Ethernet connection has latency of about 0.3 ms (milliseconds, thousandths of a second). By comparison, a typical WAN link with modem connections has latency of about 100 ms, or about 300 times greater than Ethernet.

The slower network speed and increased latency in a WAN environment does not generally favor the heavy-client configuration model. In this basic model the presentation and application logic is configured to run on the client while the server simply provides database services. This basic heavy-client configuration runs very well in a LAN but is subject to performance bottlenecks in a WAN. The source of the performance bottleneck is too much direct data traffic on the network combined with dozens of small and inefficient control messages traveling bidirectionally (chatter) multiplying the effect of network latency. Fortunately the configurable architecture of OneWorld applications offers a number of alternative strategies that reduce network traffic and the effect of network latency thereby facilitating efficient operations in a WAN environment.



Configurable Architecture of OneWorld Applications

In addition to the database itself, OneWorld interactive applications are made up of two (2) building blocks: GUI Presentation Specifications and Business Function Components. It is from these fundamental building blocks that all interactive OneWorld applications are constructed, generated and deployed. Important characteristics of these application building blocks and their associated Application Program Interfaces (APIs) are outlined below.

GUI Presentation Specifications Presentation specifications are bound in OneWorld into seven structured formats1. Because of this structured approach, the same specifications can be used to generate three technically diverse presentation interfaces (Windows, Java, and HTML).

?? Microsoft Windows. OneWorld specifications for Presentation and Event Rules (ER) are used to directly generate an interpretive Windows application and its presentation layer. The OneWorld Windows applications and their presentation layer are executable on Windows 95 or Windows NT clients under the control of the OneWorld Run Time Engine.

?? Java. The same OneWorld specifications for Presentation and ER are used to directly generate a compiled Java application and its presentation layer. In this case the specifications are in the form of Java applets. These applets are executable on any machine supporting the Java virtual machine.

?? HTML. Only the OneWorld specifications for Presentation are used to generate HTML applications. Since no logic processing is done by HTML, the ER specifications are generated into separate executable Java-based Business Function Components (see below) that are resident on a server machine. The HTML presentation is executable on any machine supporting browser-based technologies. The Java-based Business Function Components are executable by any machine supporting the Java virtual machine.

Business Function Components

Business Function Components are compiled objects that contain application logic that supports the execution of an application. Business Function Components are configurable under the CNC architecture and in most cases can be configured to run on a client with the presentation layer of an application or

1 There are seven structured form types: 1) Find/Browse, 2) Parent/Child, 3) Fix/Inspect, 4) Header Detail, 5) Headerless Detail, 6) Search/Select, and 7) Confirmation Message.



remotely on a server. All Business Functions have Application Programming Interfaces (APIs) which are well defined and documented. There are four types of Business Function Components, as follows:

Master Business Functions (MBF)

These are Business Functions that provide the logic and database calls necessary to extend, edit, and finally commit the full transaction to the database. The design of Master Business Functions allows them to be called asynchronously and to send coded error messages back to calling applications.

Major Business Functions

These components are used to encapsulate re-usable logic that is common to many applications, such as date editing routines and common multi-currency functions.

Minor Business Functions

These components are used to perform complex logic for a specific instance or single application. Minor Business Functions are used in OneWorld for processing that cannot be accomplished efficiently in ER or for logic that may be needed in multiple places but within a single application.

Generated Java Applets and Servlets

These components are generated when OneWorld applications are generated for HTML. The components are generated from the Event Rule specifications associated with a OneWorld interactive application and support the logic associated with an application’s HTML presentation layer. The components are compiled into Java applets and are designed to run under the control of the OneWorld Java Server.

Application Programming Interfaces (APIs)

OneWorld business function components use an Application Program Interface (API) to invoke other business function components. This API, called jdeCallObject, interfaces to the OneWorld JDENET – the message-oriented middleware component of OneWorld. This interface provides the communications between the application on the client and the business function component on the server. A OneWorld application on a client making a remote call to a business function component that is executing on the server is analogous to a Remote Procedure Call (RPC). In the OneWorld architecture, the “CallObject” technology is the process that OneWorld uses for instantiating an object either locally or remotely.



The following figure shows – from a conceptual level – the different generation and configuration options that are supported by the configurable architecture of OneWorld applications.

Data ServerOnly

1 2 Data

1

1 2WTS

Presentation

1 2

1 2HTML

Presentation

Windows:? Heavy Client? Light Server

Windows:? Light Client? Heavy Server

Windows WTS (Hydra)? "Ultra-Light" Client? Heavy Server

JAVA? Light Client? Heavy Server

HTML? "Zero" Client? Heavy Server

RDP / ICA

GUI ApplicationSpecifications

BusinessFunction

Components

1 2

2Call Object: JDENETData

Application SQL: ODBC / OCI

Data

Data

Call Object: JDENET / CORBA

DataHTTP

OneWorld

ApplicationBuilding Blocks

CLIENT COMMUNICATION SERVER

A

B

C

D

E

FUTURE

Figure 1. Building Blocks to Generate OneWorld in Various Environments



Middleware

In client/server environments, applications must communicate across different platforms. OneWorld uses a layer of software, called middleware, which resides between the platform operating system and the OneWorld business applications. J.D. Edwards provides the following type of middleware:

?? JDENET Communication Middleware ?? JDEBASE Database Middleware

JDENET Communication Middleware

JDENET is the message-oriented middleware that connects the generated presentation layer of OneWorld applications with Business Function Components through the standard OneWorld “jdeCallObject” API. Together the OneWorld facilities of JDENET and CNC support the configuration of Business Function Components for execution in a heterogeneous distributed environment.

JDEBASE Database Middleware

JDEBASE is the OneWorld software that provides platform-independent application program interfaces (APIs) for multi-vendor database access. These APIs are used in two ways:

?? By OneWorld applications that dynamically generate platform-specific Structured Query Language (SQL), depending on the data source request.

?? As open APIs for advanced C business function writing. OneWorld uses these APIs to dynamically generate platform-specific SQL statements.

This middleware provides workstation-to-server and server-to-server database access. To accomplish this, OneWorld is integrated with a variety of third-party database drivers such as ODBC, OCI, and Client Access 400.

OneWorld in Distributed and WAN Environments Section 1: Deployment Strategies


SECTION 1:

Deployment Strategies



SECTION 1: Deployment Strategies

As listed in the following table, this section describes the five key deployment strategies that may be used to improve OneWorld performance in distributed and WAN environments.

Table 2. Deployment Strategies – Availability

Strategy Availability

1: Data Replication Available with B73.1

2: Partitioning Application Logic Available with B73.2.1

3: Hardware Tiers Available with B73.2.1

4: Future: Windows Terminal Server (WTS) – Hydra Beta – Projected availability with B73.2.2

5: Future: OneWorld Java / HTML Applications Beta – Projected availability with B73.3

STRATEGY 1: Data Replication

Data replication is the process of replicating (copying) data to workstations or servers. One of the objectives of data replication is to place data closer to the processing logic that accesses the data in order to reduce network traffic and speed up response time – especially important in distributed and WAN environments. Data replication pays the greatest dividend where the Windows application configurations for heavy client / light server2 and light client / heavy server3 are utilized.

Before replication strategies are adopted, the supporting organization must make fundamental decisions:

?? Which “replication engine” to use ?? What level of support is required to administer the chosen replication facilities ?? What tables should be replicated and where should the replicas reside

The first decision usually involves deciding between using J.D. Edward’s built-in OneWorld replication facilities or other tools such as those provided by the database vendor, or a third-party such as Data Mirror. The advantage to using the database vendor’s facilities is that their replication tools are integrated within their respective database administration functions. The advantage to third-party replication tools is in meeting a cross-vendor replication need. The advantage to using the OneWorld replication tool is that it is integrated into the OneWorld product.

2 Reference Configuration “A” in Figure 1. 3 Reference Configuration “B” in Figure 1.



The support issue is important regardless of whose data replication facilities are utilized. Allocating adequate administrative resources to monitor and oversee data replication in any production environment is critical. The integrity of replicated data must be preserved and error recovery methodologies must be understood and mastered.

The Planning Guidelines section of this document presents information that can help in deciding what tables should be replicated and on which machine(s) the replicas should reside.

Architectural details of J.D. Edwards data replication methodology are presented in the standard J.D. Edwards technical documentation and is summarized in a document (future) on the Knowledge Garden. Actual OneWorld implementation procedures are documented in the OneWorld Configuration Planning and Setup Guide.

Database-Only Workgroup Servers

Workgroup Servers are database servers that are configured to run with replicated data in distributed environments or remote WAN locations. Field experience indicates that some customers prefer to configure Workgroup Servers using a low-maintenance concept. This concept calls for the deployment of simple database-only Workgroup servers rather than configuring them in the same class as full-scale Enterprise Servers. A Database-Only Workgroup Server does not run any OneWorld server code – it only supports a database.

This paper identifies strategies for using the Database-Only Workgroup Server configuration with OneWorld Releases B73.1 and with B73.2. Additional strategies are identified for Release B73.2.1. These release-level methods are outlined below.

B73.1 and B73.2

The following method may be used in OneWorld Releases B73.1 and B73.2 to configure Database-Only Workgroup Servers with replicated data.

“Push” Replication Method: Enterprise Server is Both “Publisher” and “Subscriber”

This method involves setting up the Enterprise Server as both the “Publisher” and “Subscriber” for the replicated table in the normal manner using the standard “Push” methodology. However, the Database-Only Workgroup Server is set up as the Subscriber data source for the replicated tables. This is possible without OneWorld code running on the Database-Only Workgroup Server. This method ensures that the “replicated” tables on the Database-Only Workgroup Server are fully synchronized with the Published tables on the Enterprise Server.

The advantage to using this method is that the Database-Only Workgroup Server remains a simple database server (no OneWorld installed).



The disadvantage to using this method is that, in releases prior to B73.2.1, to add or change static replicated data, a user must sign onto a second session and perform maintenance directly against the master copy of the table. Because changes made directly to the replicated copy of the table on the Workgroup Server are not propagated to the master copy it is sound policy to make the replicated tables on the Workgroup Server read-only.

The following figure provides a graphical depiction of the “Push” replication method.

WorkgroupServer

(OneWorld notrunning)

EnterpriseServer

"Publisher" and"Subscriber"

Client

LAN

Data Source Mapped toWorkgroup Server

FullSynchronization

WAN

Validation

Second Session for Table Maintenance

ReplicatedTable

PublishedTable

Figure 2. “Push” Replication Method for Database-Only Workgroup Servers (B73.1 and B73.2)

B73.2.1

With B73.2.1 improvements are made to the “Push” replication technology. In addition, a variation of the “Push” replication method is added that is designed to work with third-party replication facilities. This variation method is called “NON” and it performs as described and illustrated below.

“Push” Replication Method: Enterprise Server is Both “Publisher” and “Subscriber”

This method is the same as B73.1 / B73.2 “Push” replication except that the “Push” method is enhanced so that client changes made to replicated data on the Database-Only Workgroup Server are made simultaneously to the “Published” tables on the Enterprise Server. This removes the pre-



existing disadvantage of this method found under B73.1 / B73.2 where a separate session was required by clients to update the master tables.

The following figure provides a graphical depiction of the “Push” replication method.

WorkgroupServer


EnterpriseServer


Client

LAN


FullSynchronization

WAN

Full DataSupport

Maintenance changes automaticallyand synchronously made to the"Published" table.

PublishedTableReplicated

Table

Figure 3. “Push” Replication Method for Database-Only Workgroup Servers (Release B73.2.1)

Third-party Replication Combined with J.D. Edwards “NON” Mode

You can use this strategy with a Database-Only Workgroup Server by combining third-party replication and a new OneWorld replication setting called “NON”. With the “NON” mode, the Workgroup Server is identified as a “Subscriber” to the “Published” table and the Enterprise Server is set up as the “Publisher”. When setting up data replication “Subscribers”, the value “NON” is entered in the Subscription Type field (SUBTPE) where valid values are JTR, PSH, PUL, and NON.

This setup allows the client to be mapped against the replicated data on the Workgroup Server for all data selects (validations). At the same time, through the “NON” setup OneWorld knows where the “Published” resides. This allows OneWorld to perform actual inserts, updates, and deletes to the “Published” table even though the client, through OCM settings, is actually mapped to the replicated table on the Workgroup Server. Replication services are then implemented through third-party replication facilities.

This method has the following advantages:



1. Primarily, the advantage of this strategy is that a separate client session is not necessary to update master copies of replicated data on the “Publisher”.

2. The Database-Only Workgroup Server remains a simple database server (no OneWorld installed).

A disadvantage to this strategy is that there is a potential time delay between the time the table maintenance is performed on the master “Published” table and when the change is reflected on the Workgroup Server.

The following figure provides a graphical depiction of the “NON” mode.

WorkgroupServer


"Subscriber"

EnterpriseServer

"Publisher"

Client

LANOne-Way Replication byDatabase Vendor orThird Party

FullSynchronization

WAN

Full DataSupport

Maintenance changes automaticallymade to the "Published" table but notto the "Replicated" table. Thereplication facilities update the changeto the "Replicated" table.

ReplicatedTable

PublishedTable

Figure 4. “Non” Mode for Database-Only Workgroup Servers (Release B73.2.1)



STRATEGY 2: Partitioning Application Logic

The business logic for OneWorld applications can be partitioned to run remotely by mapping individual or specified groups of Business Function Components to be executed on an Application Server or Enterprise Server instead of a workstation. Examples of such configurations are illustrated by the Windows light client/heavy server4 and the Java light client/heavy server5 models. While OneWorld’s design allows all OneWorld Business Function Components to be partitioned in this manner, the biggest benefit is derived from partitioning Master Business Functions (MBFs).

OneWorld transaction-oriented applications are built around the concept of MBFs. The MBFs are typically responsible for transaction edits and for committing transactions to the database. Most of the I/O services for transaction-oriented applications are performed by MBFs. By localizing the majority of business logic for transactions in MBFs and by partitioning the MBFs to run on Application Servers, network traffic can be minimized thus dramatically improving the performance of the application in distributed and WAN environments.

The concepts of Business Function Components including Master Business Functions, Business Functions, and the OneWorld APIs that call them are described in the Configurable Architecture of OneWorld Applications section (on page 6) of this document.

Model: How a Master Business Function Operates

The following series of events and supporting figures demonstrate how a typical application utilizes an MBF. This example uses the Sales Order Entry (SOE) application.

4 Reference Configuration “B” in Figure 1. 5 Reference Configuration “D” in Figure 1.



SOE Event ? – End of Sales Order Line

The first event occurs when the end of a sales order line is reached causing the OneWorld client application to call the jdeCallObject API. This command sends a message to the MBF. Included with the message is data (in the form of a data structure) for the line. The application sends message with its associated data asynchronously. That is, once the message is sent, the client application proceeds to the next line.

Sales OrderProcessing

Client Server

MBFEdit1

EditFiles

TransFiles

MBFUpdate

MBFEdit

Figure 5. End of Sales Order Line

SOE Event ? – MBF Receives Line Message

This event occurs when the MBF receives the JDENET message that includes the data for the line. The line data is cached in the server’s shared memory.


Client Server

MBFEdit1

EditFiles

TransFiles

2

MBFUpdate

MBFEdit

Figure 6. MBF Receives Line Message



SOE Event ? – MBF Extends and Edits the Line

This event occurs when the MBF extends and edits the sales order line. The data necessary to extend and edit the line is typically accessed locally on a LAN. The data is requested by a database-dependent SQL call and is transported by the applicable Open Database Connectivity (ODBC) or Oracle Call Level Interface (OCI) mechanisms.


Client Server

MBFEdit1 3

EditFiles

TransFiles

2

MBFUpdate

MBFEdit

Figure 7. MBF Extends and Edits the Line

SOE Event ? – MBF Sends Return Message to Client Application

The fourth event occurs after the MBF extends and edits the sales order line and returns the extended line as well as any error codes to the client. The return message is sent using JDENET. Events 1 through 4 are then repeated asynchronously for all of the lines associated with the sales order.


Client Server

MBFEdit1

43

EditFiles

TransFiles

2

MBFUpdate

MBFEdit

Figure 8. MBF Sends Return Message to Client Application



SOE Event ? – End of Sales Order (OK Button)

This event indicates the user has completed all sales order lines. The user triggers this event by pressing the OK button after all edited lines have been returned to the client. When the OK button is pressed an “end of transaction” message is sent to the MBF. The client is then immediately released to enter the next transaction.


Client Server

MBFEdit1

43

EditFiles

5TransFiles

2

MBFUpdate

MBFEdit

Figure 9. End of Sales Order (OK Button)

SOE Event ? – MBF Processes the Full Transaction

The full transaction is processed when the MBF asynchronously reads the shared memory cache (where all transaction lines are stored) and begins the process of committing the entire transaction to the database.


Client Server

MBFEdit1

43

EditFiles

5TransFiles

2

6

MBFUpdate

MBFEdit

Figure 10. MBF Processes the Full Transaction



SOE Event ? – Transaction Commitment to the Database and MBF Clean-Up

The MBF commits the entire transaction to the database, typically locally through ODBC / OCI, and cleans up the shared memory cache for the completed transaction. Mapping the MBF to run on the server causes the bulk of the database and logic interaction to occur either totally within a single server machine (Enterprise Server) or between LAN-attached machines (Application Server and Database Server). This means that the entire transaction has been processed with a minimum of network traffic. This type of application transaction is ideally suited for performance gains in distributed and WAN environments.


Client Server

MBFEdit1

43

EditFiles

57 Trans

Files

2

6

MBFUpdate

MBFEdit

Figure 11. Transaction Commitment to the Database and MBF Clean-up



Server Behavior with Partitioned Application Logic

Compared to a typical heavy client scenario, partitioning application logic by configuring Business Function Components, such as Master Business Functions and other Business Functions, to run on the server requires the server to run more processes and to manage additional user sessions. There are important parameters (jde.ini parameters) that must be set to control the server’s behavior under this increased workload. The details on setting these jde.ini parameters are contained in Appendix A.

The following figure, along with the summary rules that accompany it, explains how OneWorld manages the workload of executing Business Function Components (MBFs) on an Application or Enterprise Server.

M

B

F

Kernel - n1: Internal Test / Echo

2: Call Object

3: Data Replication

4: Security Server

5: Transaction Monitor

6: Web APIs

WAN

JDENET

CLIENT

SERVER

JDENET - n

Application

Figure 12. Managing Partitioned Application Logic



Processing Rule 1 – JDENET on Client

On the client, the JDENET functions reside in a Dynamic Link Library (DLL) called jdenet.dll. These functions are called by the OneWorld Explorer program (Oexplore.exe – the client executable). That is, they are not run as a separate process (or service) – they are run from within the Oexplore.exe process.

When OneWorld clients first initiate a communication session with a specific OneWorld server (as defined by the Object Configuration Manager – OCM), they are assigned to communicate with a specific JDENET process on that server. This assignment is persistent for the entire OneWorld session. That is, the same logical connection is maintained for as long as the user is signed on.

Processing Rule 2 – JDENET on the Server

Multiple JDENET processes can be configured to run on a server. Parameters in the server’s jde.ini specify how many JDENET processes can be started on the server as well as the total number of network connections that can occur to and from that server.

If multiple JDENET processes are specified, OneWorld starts the processes as required on a one-for-one basis with incoming session requests until the maximum number of JDENET processes are started. Then OneWorld sequentially assigns subsequent sessions to specific JDENET processes in a round-robin (sequentially circular) fashion. Within each JDENET process messages are queued and processed one at a time.



Example: JDENET processes on a server

The figure used in this example is based on the characteristics listed in the table below:

Characteristic Value Jde.ini Parameter

Number of JDENET processes 3 [JDENET] maxNetProcesses=3

Number of connections per server nnn This is a site-specific variable number. Typically the setting should be a value high enough to accommodate the practical maximum for the installation.

A connection is defined as a process request by a client (such as a log-on) or a server (such as an application server connection to a database server). If this number is set too low, when the maximum number of connections is reached, no additional OneWorld processes can connect to this server.

For example:

[JDENET] maxNetConnections=800

Number of incoming sessions 6 N/A

Session1

Session4

Session2

Session5

Session3

Session6

JDENET_1 JDENET_2 JDENET_3

Figure 13. Example: JDENET Processes on a Server



Processing Rule 3 – Kernels on the Server

In order to handle different functions, the OneWorld architecture allows for different “types” of kernel processes to run on the server. The kernel “type” that processes distributed objects through the jdeCallObject API is a Type 2 kernel. A parameter in the server’s jde.ini specifies how many individual kernels of a specific kernel type can be started. The total number of active sessions that may connect to a kernel cannot be directly controlled. That is, OneWorld dynamically allocates sessions to applicable kernel types on an as-available basis. The number of users per kernel can be indirectly controlled. This is done by specifying a sufficient number of kernels in the desired relationship based on the number of connections (client-to-server and server-to-server). For example, you could specify enough kernels to have one user for each kernel, or two users for each kernel, and so on.

In determining the number of required kernels, remember that each kernel process consumes server memory resources. The exact amount of memory consumed is not as important a consideration as the performance aspect. That is, how many users (or MBFs) can simultaneously use a single a kernel before significant performance degradation begins to occur?

Kernel processes are started in a similar manner to the JDENET network communication sessions. For each kernel type, OneWorld starts a new kernel for each new session until the maximum number of kernels allowed are started. After the maximum is reached, OneWorld sequentially assigns sessions to a specific kernel process in a round-robin (sequentially circular) fashion (see the figure on page 25, Example: JDENET Processes on a Server).

Each Type 2 kernel queues and processes a single jdeCallObject API request at a time (See Application Programming Interfaces on page 7). If multiple sessions are assigned to a single kernel, when the jdeCallObject routine completes it takes the next request off the queue for that kernel type.

Clearly, care must be taken when configuring the jde.ini file for the server (see Appendix A). It should be noted that there is no way for the kernel balancing methodology to know the exact nature of the jobs being executed. In the following example (see the figure on page 27, Kernel Processes on a Server), this can result in Kernel_2 being loaded with heavy Sales Order Entry Processing while the other kernel, Kernel_1, is idling with less process intense functions. This insight into load balancing may be used to advantage when considering Hardware Tiers (discussed below).

Appendix A provides jde.ini settings applicable to all server platforms. Appendix B provides some requisite special setup considerations for starting multiple queues that are specific to a UNIX/HP server platform environment.



Example: Kernel processes on a server

The figure used in this example is based on the characteristics listed in the table below:

Characteristic Value Jde.ini Parameter

Number of JDENET processes 3 [JDENET] maxNetProcesses=3

Number of incoming sessions 6 N/A

Number of Type 2 kernels 2 [JDENET_KERNEL_DEF2] maxNumberOfProcesses=2

Number of sessions requesting Type 2 kernel

6 N/A

Session1

Session4

Session2

Session5

Session3

Session6

JDENET_1 JDENET_2 JDENET_3

Kernel_1 Kernel_2

561

2 34

Figure 14. Kernel Processes on a Server



STRATEGY 3: Hardware Tiers

OneWorld’s Configurable Network Computing (CNC) architecture also supports a multitude of hardware configuration options. However, outside of configurations involving the Windows Terminal Server (WTS) – code-named Hydra – and the OneWorld Java/HTML application offerings, all configuration options build off of three (3) basic configuration models. These basic hardware configuration models are illustrated below. The configuration options related to WTS and the OneWorld Java/HTML application offerings are discussed in their applicable sections in this document. The applicable sections are Strategy 4: Microsoft Windows Terminal Server (WTS) – Hydra (on page 32) and Strategy 5: OneWorld Java / HTML Application Offerings (on page 35).

Data

DatabaseServer

WAN LAN

All Data CallsConfiguration 1

? Heavy Client? Central Data

Data

DatabaseServer

WANLAN

Transaction Data

Data ReplicatedData

Local TableValidation

Data

DatabaseServer

WANLAN

TransactionData

ReplicatedData

ApplicationLogicServer

Workgroup Server

Configuration 2

? Heavy Client? Distributed Data

Configuration 3

? Light Client? Distributed Logic? Distributed Data

LAN

DataLocal TableValidation

Workgroup Server

LANTransaction Messaging

Standard 2 Tier

Modified 2 Tier

Mixed 3 Tier

Figure 15. Hardware Tiers (non-WTS or Java)



The following notes describe the three configurations shown in the preceding figure, Hardware Tiers:

?? Configuration 1. This configuration represents a “Heavy Client” configuration in distributed and WAN environments. This configuration, as mentioned previously, works well in a centralized LAN environment but not well for other than casual users in distributed and WAN environments. Some performance improvements can be realized with this configuration if a replicated data strategy is employed. Such a strategy however takes a great deal of administration and system resources if a large number of clients are involved.

?? Configuration 2. This configuration shows that a Workgroup Server has been added to service replicated data. The Workgroup Server is attached to locally supported clients on a LAN. Using this configuration minimizes the administration and system resources needed to support replication and makes it practical to replicate more volatile master files such as the Address Book.

?? Configuration 3. Referred to as a mixed-tier configuration model, this configuration shows that an Application Server has been added to execute distributed Business Function Components, such as Master Business Functions (MBFs). This configuration, which employs both Workgroup Servers and Application Servers, will deliver optimum OneWorld distributed and WAN environment performance outside of the WTS and Java / HTML domains.

Workgroup Servers

To improve network performance, it is a sound strategy to replicate data to Workgroup Servers in distributed environments or WAN environments. The Planning Guidelines section of this document contains a listing of tables, by type (for example, Constants, Data Dictionary, Master Tables, etc.) that are the best candidates for replication in such an environment.

There are three (3) main advantages to using a Workgroup Server for data replication:

1. End user response time can be improved by diverting the database traffic for table validation from a lower-speed network connection (WAN) to a high-speed connection (LAN). For distributed and WAN environments, overall network traffic and system resource requirements are also reduced when Workgroup Servers are used as opposed to replication to individual workstations.

2. Replication administration is significantly reduced when Workgroup Servers are used rather than individual workstations.

3. Workgroup Server configurations are ideal for supporting replication strategies where the database vendor’s replication facilities are utilized or third-party replication facilities are utilized. If J.D. Edwards’ replication facilities are used then the preferred method of “Push” replication should be utilized. The “Push” replication type is designed to keep replicated data synchronized at all times which is generally preferable (most reliable) in a production environment. In addition, with the B73.2.1 release of OneWorld the “Push” replication type will support automatic concurrent updates to Published Tables when Replicated Tables on Workgroup Servers are updated. This enhancement further simplifies overall operations in a remote location because separate sessions (using different OneWorld environments) are no longer required to update master tables on the Publisher. This enhancement also makes it more practical to replicate Master Tables such as the



Address Book on Workgroup Servers.

Specific strategies for configuring Database-Only Workgroup Servers (those without any OneWorld server code installed) are founding the Replication Strategy section of this document.

Application Servers

The significant benefit of distributing application logic, particularly Master Business Functions (MBFs), in distributed and WAN environments was discussed in Strategy 2: Partitioning Application Logic (on page 18). The actual implementation method involves the deployment of Application Servers. A number of creative CNC configurations may be used for Application Servers. At one extreme, distributed Business Function Components may be mapped directly to a single large enterprise server, which might occur frequently in an AS/400 installation. At the other extreme, a large number of Application Servers might be clustered around a relatively small NT-SQL Server Database Server.

There is clearly a great deal of flexibility in configuring Application Servers. They can be used in creative ways to scale the infrastructure as growth occurs or they can be used to eliminate performance hot spots. In considering Application Servers these additional points should be considered:

?? Since Application Servers are typically clustered around the main Enterprise Server and/or Database Server in a LAN environment, very high speed and reliable fiber LAN connections can be used between the Enterprise Server, Database Server, and peripheral Application Servers.

?? Application Servers may be used to group or isolate certain types of users from each other in order to balance performance.

?? Application Servers may be used to isolate the execution of UBEs.

?? Application Servers may be large multiple processor server-class machines or they may be small single processor workstation-class machines, depending on the number of concurrent users they serve.

Mixed-Tier Configuration Model

A mixed-tier configuration is a computing architecture that integrates a combination of Workgroup Servers and Application Servers to maximize application performance. For example, the following represent individual tiers:

?? Tier 1: The user interface including presentation and interactive logic. ?? Tier 2: The distributed Workgroup Servers with replicated data (relative to the LAN), ?? Tier 2 Distributed: The processing of distributed Business Function Components on Application

Servers (relative to the WAN). ?? Tier 3: The centralized database on the Enterprise Server

This combination of distributed 2-tier and 3-tier positions application data close to the application logic while minimizing network traffic. Such a configuration provides the foundation for optimum OneWorld



application performance in a WAN environment. The following figure illustrates a mixed-tier configuration supporting three remote sites on a WAN.

JDENet (Call Object)

OCI (Inquiries)


OCI (Inquiries)


OCI (Inquiries)

Ethernet

ApplicationServer

Tier - 2 Tier - 3Tier - 1Tier - 1 Tier - 2

LAN

Ethernet

WorkgroupDatabase ServerOneWorld Clients

LAN

Ethernet


LAN

Ethernet


WAN

ApplicationServer

ApplicationServer

DatabaseServer

Figure 16. Mixed-Tier Configuration Model



STRATEGY 4: Windows Terminal Server (WTS)

Windows Terminal Server (WTS) is a Microsoft product6. The designs of WTS and OneWorld are complementary because of CNC architecture. CNC enables the distribution of processing resources which enables WTS to be used as a low-cost, low-maintenance, and easy-to-implement front-end Application Server. The principles of WTS involve both a light-client and a server-centric architecture. This is enabled because all OneWorld application processing occurs centrally on servers, either the WTS server or other enterprise servers.

The role of the WTS client is to present only the Graphical User Interface (GUI) which is transmitted to the client from the WTS server. The client also transmits real time mouse movements and keyboard actions to the WTS server. The WTS server monitors these actions and processes them according to OneWorld’s design specifications, just as if the client were executing the OneWorld application on the local machine.

Bandwidth Considerations

In some ways, the WTS product is analogous to terminal-based, centralized host processing which is the architectural backbone of the J.D. Edward’s AS/400 World product. Under this central host architecture, “dumb” terminals provide a simple, character-oriented conduit between the users and the host. Users can log on, run application programs, read/write shared files, direct output to shared printers, and access shared databases. Furthermore, each user’s terminal session functions independently from the other terminal sessions because the arbitration between shared resources is performed deep inside the host operating system.

There are, however, important differences between WTS and traditional host-based processing such as AS/400 World products. One of the biggest differences is the graphical nature of the Windows environment. Host environments, including J.D. Edwards World Vision product, are traditionally character-oriented. In terms of bandwidth, such operations are highly efficient because they require only a small amount of traffic to travel the communication lines between the host and the terminal or terminal emulator.

The design of the WTS server dictates that for each WTS session, all of the graphical screen output and related input/output from a mouse or keyboard must flow between the desktop client and the WTS server. This means that for highly graphical event driven applications such as OneWorld, a significant amount of information travels over the network between the client device and the WTS server. It also means that a persistent connection (for WAN, a leased line or equivalent) must exist between the client and the WTS server. Fortunately, the display protocol that operates between the client and the WTS server compresses 6 Microsoft’s Windows Terminal Server (WTS) product is scheduled for release as an add-on to the Windows NT Server 4.0/5.0 operating system in mid 1998. J.D. Edwards is fully enabling OneWorld to operate in a WTS environment and will release WTS-compatible software in the B73.2.2 release of OneWorld. Hereafter, Hydra, which is the code name for the Microsoft product, will be referred to by its official product release name: Windows Terminal Server, or WTS.



and optimizes this transmission traffic. Further, the communication between client device and WTS is completely transparent and isolated from application developers.

WTS Sizing Considerations

For customers preferring “ultra-light” clients and centralized software administration, WTS will be an attractive option. There may be administrative advantages as well as some performance advantages of using WTS in distributed and WAN environments. There are however no definitive configuration guidelines to be made at this time because there is no publishable performance test data. However, this document can state the following facts that should be considered when contemplating the use of WTS in distributed and WAN environments.

1. Because an “ultra-light” client does not perform any processing, support environments require large high performance servers but do not require high performance clients.

2. On the WTS machine, there will be uniform allocation of server resources on a user-by-user basis. Resources include:

?? CPU time. Each user connected to a WTS has their own desktop environment and can run whatever applications are available to that desktop. However, all applications run by all users are contending for the central CPU resources available on the WTS machine.

?? Memory. Each user has their own independent session on the WTS which they use to run all the memory intensive applications at their disposal. Some users may try to open as many applications on their desktop as they can, which can degrade performance for all users on the WTS.

?? Global Windows NT objects and resources. When attached to a WTS, users do not run individual copies of Windows NT. Some of the core components are cloned, but the remaining components are shared among the users. Thus users are competing for access to the registry, the paging file, system services, and other global objects and resources.

Server sizing in a WTS environment is especially important. The server machine supporting the Windows NT operating system and WTS must be equipped with sufficient CPU, memory, and disk resources to handle the client requirements. Preliminary sizing information indicates that a WTS will need approximately 32 Mbytes of memory for base Windows NT operating system requirements. Additionally, each WTS client will require 4 to 8 Mbytes for each OneWorld application session.

3. WTS machines must be dedicated to running OneWorld Windows Terminal sessions only. WTS machines must not be used for:

?? Running OneWorld batch reports (UBEs)

?? As a local database (SQL Server) server

?? Running OneWorld partitioned application logic (acting as an Application Server)

?? Running any other application other than OneWorld



?? OneWorld application development

4. A single copy of the workstation “package” of OneWorld software is installed on the WTS. That package should be a “full package” so that no Just-In-Time-Installations (JITIs) are required that would impact performance. No server side OneWorld software is installed on the WTS.

5. Deployment guidelines for WTS system administrators will be available with the Microsoft WTS product release (scheduled for 3rd Quarter 1998).

The following figure shows a layout for a typical WTS environment.

Database

ClientPresentation

EnterpriseServer

WAN

SQL

Result

WTSServers

ClientPresentation

Dial Up andMobile Access*

OneWorldApplications

Batch ServerDatabase Server

* Requires additional technical considerations

Figure 17. WTS (Hydra) – Typical Layout



STRATEGY 5: OneWorld Java / HTML Application Offerings

J.D. Edwards is fully enabling OneWorld to operate in a Java? environment in the B73.3 release of OneWorld.

The goal of delivering OneWorld applications in Java and HTML (Hypertext Markup Language) has been realized by adding Java and HTML code generators to the OneWorld toolset. The code generators take direct advantage of the form type templates and the repository based business specifications that comprise the foundation for all OneWorld applications. The generated Java and HTML applications are essentially identical in form and function to the Windows based OneWorld applications. The one significant exception is that the browser-based applications characteristically do not offer the same level of integration with personal productivity applications on the desktop as their Object Linking and Embedding-compliant (OLE-compliant) client/server counterparts.

OneWorld DesignTools

OneWorld BusinessSpecifications and

Form Templates

Java / HTMLGenerator

WindowsRuntime

Generator

Deliverable

Windows Run-timeApplications

Deliverable

Java / HTMLApplications

Figure 18. OneWorld Java / HTML – Single Repository, Optional Generation



The Java and HTML versions of OneWorld offer an important option, with many architectural advantages, for operating OneWorld applications in distributed and WAN environments. The following figure illustrates the OneWorld Java application configuration and how it functions in such environments.

ClientHTTP Server

OneWorld Java Server(OneWorld Foundation Component)

Any commercially-available applicationthat serves the HTTP protocol (forexample, Microsoft IIS or Netscape)

Net Server

Directory

HTML Templates

Java Classes

Database

Client RuntimeComponents

Java SerializedObjects

"Call Object"SecurityJDBC Connect

Applications

HTML or JavaApplets

1 2

Database Server

ApplicationData

3

LANWAN

4

ApplicationServer

5

1 HTML or Java Runtime Classes are loaded to the client when the client first connects. If enabled by the clientdevice these components may be permanently stored on the client (Cache or database)..

2 Servlets : Java applications that execute on the Net Server - these are never downloaded to the client..

Business Views : These are generated and optimized based on actual application requirements.

Data Dictionary : Data Dictionary definitions are generated as objects for performance. They are boundto applications at runtime .

Applications : Application Java objects are generated from application specifications. Java Appletsare generated to run on the client and are loaded to the client when an application isinvoked. Java application servlets constitute the application nuclei that run on theNet Server to support the HTML implementation.

Servlets

Business Views

Data Dictionary

3 This is the HTTP communication layer between the client and the Net Server. It is important to note that the clientdoes not directly interface to the data base. Instead a single message is issued to the Net Server which processesthe data request. This architecture for data access offers significant advantages in a WAN environment ..

4 In the Web OneWorld configuration all Business Functions and Named ER execute on an Application LogicServer. It is recommended that the Net Server not be used for Business Function execution. Master Businessand other business functions may be partitioned to separate application logic servers in a normal CNC manner.Business functions are called through the standard "Call Object" methodology although in the Web environmentthe messaging transport mechanism may be CORBA or JDENET.

5 Database calls are executed via JDBC drivers. Data is packaged efficiently by the Net Server before beingtransported over the network to the client.

ApplicationServer - n

Figure 19. OneWorld Java / HTML – Implementation Overview



Once OneWorld Java operations are available, typical distributed and WAN environments will normally involve a mix of Windows client/server applications and Java/HTML enabled applications. One reason for this is that the OneWorld Development Tools will not be made available in Java or HTML. Only specification generated applications will be made available in the Java version of the product. Therefore, such functions as Report Design will be carried out through the Windows RDA facility. It may also be true that certain users will be configured to use client/server versions of applications because they need OLE desktop links. The flexibility of OneWorld CNC architecture fully supports such configuration options.



SECTION 2:

Planning Guidelines

OneWorld in Distributed and WAN Environments Section 2: Planning Guidelines


SECTION 2: Planning Guidelines

This section contains planning guidelines for:

?? Strategy 1: Data Replication ?? Strategy 2: Partitioning Application Logic

STRATEGY 1: Data Replication

When planning for deployment of OneWorld tables in a distributed data environment, administrators should keep in mind that different OneWorld applications may use one or more database tables during application processing. The applications may request information from one table that may require data from another table.

These application table dependencies mean that certain tables should be replicated together and not split across multiple locations. Failure to note such dependencies will result in decreased performance in distributed configurations.

Further, some table groupings should be replicated together. Such tables may not be separated for functional reasons or should not be logically separated for performance reasons. These groups are noted where applicable in this section.

This section of the document specifically identifies those tables that cannot be replicated using J.D. Edwards data replication tool. The actual implementation of data replication involves multiple decision points. J.D. Edwards suggests that CNC specialists of the Advanced Technology Group (ATG) are best suited to analyze specific business requirements and to make practical implementation decisions on which tables to replicate.

Join Considerations

Some limitations exist in OneWorld with distributed data and joined business views spanning multiple databases. Any application using such a business view will be impacted by this limitation. Join considerations are release dependent. Important: A OneWorld CNC Conference Room Pilot (CRP), utilizing CNC consultants, will determine the practicality of replicating specific joined tables.

Releases B731.1, B731.2, and B732 Base

For OneWorld Releases B731.1, B731.2, and B732 base, joins between Microsoft Access and a server database (DB2/400, Oracle, or SQL Server) will be performed entirely on the server. That is, Microsoft Access will not be used.

Joins between two different server databases are not supported.



Release B732.1

For OneWorld Release B732.1, joins are always performed based on the mappings of the individual tables – regardless of the location of the tables. A cross data source join operation is performed by the JDB database middleware (JDEBASE).

Tables That Cannot Be Replicated Using OneWorld Replication

The table below lists OneWorld tables that cannot be replicated using OneWorld replication tools.

Table 3. Tables That Cannot Be Replicated Using OneWorld Replication

Group Comment

BLOBs and Generic Text (GT)

As a general rule, tables containing Binary Large Objects (BLOBs) or Generic Text (GT) cannot be replicated using the OneWorld replication tool (although third-party tools could be considered). Examples of these tables include:

F00165 Media Object Text

GT92002 Data Dictionary – Glossary Information

System Application Tables

Only one copy of the next number tables (F0002 and F00021) can exist in any OneWorld environment. These tables must be located on a Database Server or an Enterprise Server. They cannot be replicated to a Workgroup Server or to an Application Server. The following are examples of tables that should not be replicated using OneWorld replication:

F0002 Next Numbers – Automatic

F00021 Next Numbers by Company/Fiscal Year – Auto

Note: An alternative to replicating the next number tables may be to distribute blocks of next numbers (for example, a billion numbers) to various servers in the enterprise. This theory will be proved by a future Case Study documented by the Advanced Technology Group.

System The System tables are those typically used by the OneWorld system programs, as opposed to OneWorld application programs. The system tables are those found in the System Data Source. The following are examples of tables that should never be replicated using OneWorld replication:

F98701 Next ID Master

F98950 User Overrides

F98DRLOG Data Replication Change Log

F98DRPCN Data Replication Pending Change Notification

F98OWSEC OneWorld Security

Transaction or Balance Tables

J.D. Edwards does not suggest using the OneWorld data replication tools to replicate transaction or balances tables. This is due to the administration overhead and exposure to data integrity issues. Examples of these tables include:

F0902 Account Balances File

F0911 Account Ledger



Group Comment

F4211 Sales Order Detail

F4311 Purchase Order Detail

Application Worktables

These are temporary tables unique to an application session. These worktables are sometimes used in place of temporary cached memory. Examples of worktables are:

F42UI11 Sales Order Detail Cache File (MBF)

F42UI01 Sales Order Header Cache File (MBF)

F40UI801 Generic Error Table

Tables That Can Be Replicated

The following sections list groupings of tables that can be replicated to improve performance in distributed and WAN environments. The specific strategy for replication of OneWorld tables should be formulated as part of the standard CNC Conference Room Pilot (CRP).

System Tables

System tables are those typically used by the OneWorld system programs, as opposed to OneWorld application programs. System tables are those found in the System Data Source. Typically System tables are cached in client memory, so they are accessed only at login time. However, it may still be beneficial to replicate certain system tables to improve login performance of clients in distributed and WAN environments.

Site-specific requirements must flow from the CNC CRP.

Constants Tables

Constants tables contain system and application constants that are specific to an application (for example, General Ledger) or generally applicable to all applications (for example, Automatic Account Instructions (AAIs) and Work Day Calendar). All replicated Constants tables must be mapped to the same location. The following table lists examples of Constants tables that can be replicated in distributed and WAN environments.

Table 4. Constants Tables – Data Replication Candidates

Table Description

F0007 Work Day Calendar

F0008 Date Fiscal Patterns



Table Description

F0009 General Constants Tables

F0010 Company Constants Tables

F0012 Automatic Accounting Instructions Master

F0013 Currency Codes

F0014 Payment Terms

F00141 Advanced Payment Terms

F0015 Currency Exchange Rates

F00151 Currency Exchange Rates (F0015 Header)

F0022 Tax Rules

F0025 Ledger Type Master File

F3009 Job Shop Manufacturing Constants

F40070 Preference Master

F40073 Preference Hierarchy

F4008 Tax Areas

F4009 Distribution/Manufacturing Constants

F40095 Default Locations/Printers

F40203 Order Activity Rules

F40205 Line Type Control Constants

F4095 Distribution/Manufacturing - AAI Values

F41001 Inventory Constants

F41003 Unit of Measure Standard

F98101 Imaging Constants

Master Tables

Master tables are those designated as “Master” by OneWorld application developers. All Master tables must be mapped to the same location. Because of the volume of data and changes these tables are considered “non-static” – not suitable for replication using OneWorld replication tools. However, distributed and WAN environment performance may be improved by the replication of these tables using native database or third-party replication tools.

In distributed and WAN environments, J.D. Edwards suggests that because of reduced administration and increased security, Master tables be replicated to Workgroup Servers – not replicated to individual workstations.



Site-specific requirements must flow from the CNC CRP.

Language Support Tables

OneWorld architecture includes features that accommodate base and additional languages. All users are assigned a language preference or key within their user profile. The language key is a two-character field that determines which language is presented on the applicable form or report. Only specific tables contain a language key. All such language-enabled tables are listed in the table below.

All Language tables must be mapped to the same location. In distributed and WAN environments, J.D. Edwards suggests that because of reduced administration and increased security, Language tables be replicated to Workgroup Servers – not replicated to individual workstations.

Table 5. Language Tables – Data Replication Candidates

Table Description Note

F0004D User Defined Code Types – Languages 1

F0005D User Defined Codes - Languages 1

F0006D Business Unit Alternate Description Master 2

F00090D Supplemental Database Language Preference 2

F0012D AAI Alternate Description Master

F00165 Media Object Storage 3

F0083 Menu Text Override File

F00921 Menu Path File

F0901D Account Master Alternate Description 2

F4101D Item Master – Alternative Description 2

F5192D Supplier Analysis Alternate Language Description 2

F9202 Data Field Display Text

F9203 Data Item Alpha Descriptions

F98306 Processing Option Text 6

F98750 Forms Design Aid Text Information

F98760 Report Design Aid Text Information

F98950 User Overrides 3, 4



Notes:

Note 1: This table is also considered a UDC table. This table must be replicated as a group with F0004 and F0005.

Note 2: This is a OneWorld “application” language table and it should be replicated as a group with the F98* tools language tables.

Note 3: This table is also considered a System table. As directed by CNC consultants, caution should be used when considering the replication of this table.

Note 4: A B73.2 performance enhancement precludes the need to replicate this table.

Data Dictionary Tables

The Data Dictionary has unique built-in OneWorld replication processing characteristics. The master copy of the Data Dictionary, in relational table format, will reside on an Enterprise Database Server. What makes the Data Dictionary unique is that, for client performance reasons, the OneWorld replication engine automatically builds a copy of the Data Dictionary on every OneWorld client machine in the enterprise.

Even though there are built-in facilities in OneWorld to replicate Data Dictionary items to client files there are three (3) important issues related to the overall strategy for Data Dictionary replication that must be considered. These three (3) issues are discussed in greater detail below.

Deciding how Data Dictionary Changes will be Propagated to Clients

Data Dictionary items are only loaded automatically to clients one time . That is, the built-in automatic replication facilities will only replicate an item to a client when the item is first referenced by a OneWorld application. This means that changes made to the master copy of the Data Dictionary will not automatically be propagated to clients.

There are two (2) methods that may be used to ensure that changes are propagated to clients:

a) Include the Data Dictionary in a package.

b) Turn on Replication for the Data Dictionary and set up every client in the enterprise as a “Pull” subscriber. The replication engine will process Replication Change Notification Log records in the normal manner.

Replicating the Data Dictionary to Workgroup Servers

Replicating the Data Dictionary to Workgroup Servers in distributed and WAN environments is a strategy that will help reduce overall network traffic. This reduction in network overhead will occur because local clients will retrieve needed Data Dictionary items from the Workgroup Server instead of from the home office “Publisher”.



The strategies for setting up the Workgroup Server as a Database-Only Workgroup Server (one without OneWorld as discussed in the Strategy Section of the document) are applicable to replication strategies for the Data Dictionary. The most straightforward method would be to use OneWorld replication with the following setup:

a) Setup Enterprise Server as both “Publisher” and “Subscriber” with “Subscriber” data source being the Workgroup Server. This will synchronize the Workgroup Server with relational Data Dictionary tables.

b) Setup the client as a “Subscriber” to the Enterprise Server “Publisher”.

c) Map the client OCM to the Workgroup Server. This will ensure that JITR updates to the client are done from the Workgroup Server across the LAN instead of across the WAN.

The following figure illustrates this configuration example.

WorkgroupServer


EnterpriseServer


Client

"Subscriber"

LAN

FullSynchronization

WAN

Full JITRSupport


Processing of Replicationrecords cause changed DataDictionary Item to be deletedfrom local non-relational table.

ReplicatedTables

PublishedTables

Figure 20. Replicating the Data Dictionary to Workgroup Servers

Replicating the Data Dictionary to Application Servers

Application Servers do not use Data Dictionaries that are built just-in-time. Instead, OneWorld supports a pre-built data dictionary for these machines in non-relational format. The pre-built data dictionary is typically delivered as part of the server package. As a result, changes to non-relational tables must be replicated to logic servers through a batch process and not through server “Push” replication.



All Data Dictionary tables must be mapped to the same location.

Table 6. Data Dictionary Tables – Data Replication Candidates

Table Description

F00165 Media Object Storage

F9200 Data Item Master

F9201 Data Field Specifications

F9202 Data Field Display Text

F9203 Data Item Alpha Descriptions

F9204 Data Item Aliases

F9205 Data Dictionary - Error Message Program ID

F9207 Data Dictionary - Error Message Information

F9210 Data Field Specifications (OneWorld)

F9211 Data Dictionary - Smart Fields

User Defined Code (UDC) Tables

Tables containing User Defined Codes (UDCs) are attached to data items are identified in the data dictionary and, in turn, the data dictionary links trigger the visual assist function. English-only versions of user defined codes are stored in the F0004 and F0005 tables. See Languages for a discussion of language-enabled UDC tables (F0004D and F0005D).

In distributed and WAN environments, all UDC tables can be replicated to a Workgroup Server. These tables cannot be separated – replicate all of the UDC tables together or replicate none of them.

Table 7. User Defined Code (UDC) Tables – Data Replication Candidates

Table Description

F0004 User Defined Code Types

F0005 User Defined Codes

F0004D User Defined Code Types – Languages

F0005D User Defined Codes – Languages



Menus

All menu tables are candidates for replication. All Menu tables must be mapped to the same location. These tables cannot be separated – replicate all of the Menu tables together or replicate none of them. In distributed and WAN environments, these tables can be replicated to a Workgroup Server.

Table 8. Menu Tables – Data Replication Candidates

Table Description

F0082 Menu Master File

F00821 Menu Selections File

F0083 Menu Text Override File

F0084 Menu Path File



STRATEGY 2: Partitioned Application Logic

J.D. Edwards has found that the redeployment of certain Business Function Components (including MBFs and BFs) can significantly increase the performance of a distributed OneWorld workstation while simultaneously decreasing network traffic. This redeployment involves remapping objects using OneWorld’s standard Object Configuration Manager (OCM) methodology. Future directions may provide automatic mechanisms to enable a customer to easily and reliably build site-specific packages that include customized variations of these mappings.

OneWorld is delivered with standard environments, data sources, and object mappings that are suitable to a typical centralized environment. This section presents configuration information that is based on performance analyses primarily concerned with improving performance in distributed and WAN environments. This analysis validates the integrity of OneWorld’s Remote Business Function architecture invoked by the jdeCallObject API.

OCM Mappings for Partitioned Logic

This section lists the OCM mappings required to partition applications on the various server platforms. These OCM mappings refer to mapping the objects to the same physical machine. The OneWorld applications are listed in logical order as follows:

?? Financials (below) ?? Distribution (on page 53) ?? Manufacturing (on page 60)

Financials

This section provides mappings for the following Financial systems:

?? Organization Structure (P0006A) ?? Invoice Entry (P03B11) ?? Receipt Entry (P03B102) ?? Voucher Entry (P0411) ?? Journal Entries (P0911) ?? Trial Balance by Business Unit (P09210A)



Organization Structure (P0006A)

The following table lists the Organization Structure application (P0006A) business function components that must be mapped to the same physical machine.

Table 9. Organization Structure (P0006A) – Partitioned Logic Source Members

Source Object Name Functionality

B0900097 F0006 – Add to Cache For Tree Structure Displays organization in tree structure

B0900098 F0006 Retrieve From Cache for Tree Structure

Invoice Entry (P03B11)

The following table lists the Invoice Entry application (P03B11) business function components that must be mapped to the same physical machine.

Table 10. Invoice Entry (P03B11) – Partitioned Logic Source Members


B03B0011 Invoice Entry MBF Create an invoice

B76C0013 Retrieve Colombian Taxes from Detail Tax File Localization (Colombia)

Receipt Entry (P03B102)

The following table lists the Receipt Entry application (P03B102) business function components that must be mapped to the same physical machine.

Table 11. Receipt Entry (P03B102) – Partitioned Logic Source Members


B03B0142 Receipts Entry Read Cache Process selected invoices

B03B0143 F03B11 Receipts Entry Load Invoices Invoice selection by customer

B03B0152 F03B11 Load By Statement Number Invoice selection by statement

B03B0158 Maintain Receipts Entry Cache Maintain processed invoices

B03B0169 F03B11 Invoice Match Process Invoice selection by document



B03B0172 Maintain Invoice Selection Cache Maintain selected invoices

Voucher Entry (P0411)

The following table lists the Voucher Entry application (P0411) business function components that must be mapped to the same physical machine.

Table 12. Voucher Entry (P0411) – Partitioned Logic Source Members


B0400047 Voucher Entry MBF Create a voucher

B76C0013 Retrieve Colombian Taxes from Detail Tax File Localization (Colombia)

Journal Entries (P0911)

The following table lists the Journal Entries application (P0911) business function components that must be mapped to the same physical machine.

Table 13. Journal Entries (P0911) – Partitioned Logic Source Members


B0900049 Journal Entry MBF Create a journal entry

B0900083 F0911 Update Detail Cache ALT9 Detailed currency restatement

Trial Balance by Business Unit (P09210A)

The following table lists the Trial Balance by Business Unit application (P09210) business function components that must be mapped to the same physical machine.

Important: The business functions used by this application can only run on a client.

Table 14. Trial Balance by Business Unit (P09210A) – Partitioned Logic Source Members

Source Object Name Note

B0900089 Trial Balance Static Array Totaling Must be mapped to Client

B0900068 Trial Balance Accumulate LOD Must be mapped to Client



Distribution

This section provides mappings for the following Distribution systems:

?? Inventory (System Code 41) ?? Sales Order Processing (System Code 42) ?? Procurement (System Code 43)

Inventory

This Inventory system (System Code 41) includes the following applications:

?? Inventory Issues (P4112) ?? Inventory Adjustments (P4114) ?? Inventory Transfers (P4113) ?? Inventory Reclassifications (P4116)

Inventory Issues (P4112)

The following table lists the Inventory Issues application (P4112) business function components that must be mapped to the same physical machine.

Table 15. Inventory Issues (P4112) – Partitioned Logic Source Members


XT4114Z1 Inventory Issues/Adjustments MBF Create an issue / Adjustment

B0900049 General Ledger MBF Get document number for display

Inventory Adjustments (P4114)

The following table lists the Inventory Adjustments application (P4114) business function components that must be mapped to the same physical machine.

Table 16. Inventory Adjustments (P4114) – Partitioned Logic Source Members


XT4114Z1 Inventory Adjustments MBF Create an issue / adjustment




Inventory Transfers (P4113)

The following table lists the Inventory Transfers application (P4113) business function components that must be mapped to the same physical machine.

Table 17. Inventory Transfers (P4113) – Partitioned Logic Source Members


XT4113Z1 Inventory Transfers MBF Create a transfer


Inventory Reclassifications (P4116)

The following table lists the Inventory Reclassifications application (P4116) business function components that must be mapped to the same physical machine.

Table 18. Inventory Reclassifications (P4116) – Partitioned Logic Source Members


XT4116Z1 Inventory Reclassifications MBF Create an inventory reclassification


Sales Order Processing

This Sales Order Processing system (System Code 42) includes the following applications:

?? Sales Order Entry (P4210) ?? Shipment Confirmation (P4205) ?? Backorder Release (P42117)



Sales Order Entry (P4210)

The following table lists the Sales Order Entry application (P4210) business function components that must be mapped to the same physical machine.

Table 19. Sales Order Entry (P4210) – Partitioned Logic Source Members


B4200310 Sales Order Entry MBF SOE entry

B4200690 Copy SO Info To Work Files Credit Memo Processing.

B4201070 F42UI11 Retrieve/Update Sales Order Detail (WF) Info

Display Before Accept Processing

B4201280 F42UI12 Get Sales Order Detail Info Add/Change on the Miscellaneous Information Fix/Inspect forms

B7600720 Retrieve Cache Information from Sales Header Localization (Brazil)

B7600730 Retrieve Cache Information from Sales Detail Localization (Brazil)

B76A0250 Enter Invoice Related to NC/ND Localization (Argentina)

B3200030 F32942 Load Qualified CSIDs To Cache Configurator

B3200200 F3292 CSE Rule Translate String Configurator

B3200230 Cache Process Verify CSID Configurator

B3200310 F3292 Get Cross Segment Editing Row Configurator

B3200360 Cache, Process Configured Component Configurator

B3200410 F32943 Configured String History File I/0 Configurator

B3200460 F3293 Evaluate AIR Configurator

B3200580 Config String, Format Segments Configurator

B3200590 Config String Get Upper Limit Configurator

B3200600 Config String Format Segments Cache Configurator

B3200790 Config, Load Edit Line From All Components Cache

Configurator

B3201150 F4801 Update WO Status During SO Change Mode

Configurator

N3200570 F3293 Get Configurator Constant Row Configurator

N3200700 Write Configurator Files at End Doc Configurator

N3200980 Configurator Indicate Price Extend Configurator

N3201130 Duplicate Configurator Information Configurator

N3201210 Verify UDC Value Configurator



Shipment Confirmation (P4205)

The following table lists the Shipment Confirmation application (P4205) business function components that must be mapped to the same physical machine.

Table 20. Shipment Confirmation (P4205) – Partitioned Logic Source Members


N4200790 Shipment Confirmation MBF Shipment Confirmation entry

B4200810 Load Or Unload Ship Confirm Cache Serial Number Processing

Backorder Release (P42117)

The following table lists the Backorder Release application (P42117) business function components that must be mapped to the same physical machine.

Table 21. Backorder Release (P42117) – Partitioned Logic Source Members


N4200860 Backorder Release MBF Backorder Release entry

B4200820 Backorder Release Process Cache Clean Up for Next Transaction

B4201260 Ship Confirm/Backorder Release Kit Cache Processing

Kits

B4200370 Commit Sales Order To Inventory Inventory Commitment

Procurement

This Procurement system (System Code 43) includes the following applications:

?? Purchase Order Entry (P4310) ?? Purchase Receipts (P4312) ?? Receipt Routing (P43250) ?? Voucher Matching (P4314)



Purchase Order Entry (P4310)

The following table lists the Purchase Order Entry application (P4310) business function components that must be mapped to the same physical machine.

Table 22. Purchase Order Entry (P4310) – Partitioned Logic Source Members


XT4311Z1 Purchase Order Entry MBF PO entry

B4300470 Check F4311Z Record PO Generator, Workbench, or Release

B4301370 Order Cache Record PO Generator, Workbench, or Release

B4301380 F4301Z Update Order # PO Generator, Workbench, or Release

B7600090 Retrieve PO Detail Cache Localization

B7600460 Retrieve PO Header Cache Info Localization



Purchase Receipts (P4312)

The following table lists the Purchase Receipts application (P4312) business function components that must be mapped to the same physical machine.

Table 23. Purchase Receipts (P4312) – Partitioned Logic Source Members


XT4312Z1 Purchase Receipts MBF Purchase Receipts entry

B0900049 Journal Entry MBF Clean Up for Next Transaction

B4301220 Tolerance Cache Clean Up for Next Transaction

B4301360 F4312Status Code Cache Clean Up for Next Transaction

XT4111Z1 Cardex Clean Up for Next Transaction

B4301340 Maintain Cache Parameters Clean Up for Next Transaction

B4301060 Read Receipt Cache Serial Number Processing

B4301350 Reverse Landed Cost Cache Landed Cost Processing

N4300970 Landed Cost MBF Landed Cost Processing

B4301050 Landed Cost Job Numbers (GL Job number) Landed Cost Processing

B4301040 Landed Cost Based On Landed Cost Processing

B4300990 F41291 Write Landed Cost Cache Landed Cost Processing

B4301060 Read Receipts Cache Landed Cost Processing

B7600270 Nota Fiscal Localization (Brazil)



Receipt Routing (P43250)

The following table lists the Receipt Routing application (P43250) business function components that must be mapped to the same physical machine.

Table 24. Receipt Routing (P43250) – Partitioned Logic Source Members


NXT43092 Receipt Routing MBF Receipt Routing entry

XT4312Z1 Receipts MBF Clean Up for Next Transaction


B4301220 Tolerance Cache Clean Up for Next Transaction

B4301360 F4312Status Code Cache Clean Up for Next Transaction

XT4111Z1 Inventory Transactions MBF Clean Up for Next Transaction

B4301050 Landed Cost Job Numbers (GL Job number)

Landed Cost Processing

B7600270 Nota Fiscal Localization (Brazil)

Voucher Matching (P4314)

The following table lists the Voucher Matching application (P4314) business function components that must be mapped to the same physical machine.

Table 25. Voucher Matching (P4314) – Partitioned Logic Source Members


XT4314ZN Voucher Matching MBF Voucher Matching entry

B0400047 Voucher Entry MBF Clean Up for Next Transaction


XT4311Z1 PO Entry MBF Clean Up for Next Transaction

B4301410 Maintain Distribution Parameters Cache Flexible Accounting (CMS)



Manufacturing

This section provides mappings for the following Manufacturing systems:

?? Product Data Management (System Code 30) ?? Shop Floor Control (System Code 31) ?? Requirements Planning (System Code 34)

Product Data Management

The Product Data Management system (System Code 30) includes the following applications:

?? Routing Master (P3003) ?? Bill of Material (P3002) ?? Work Center Master (P3006) ?? Work Center Rates (P3006) ?? Bill of Material Inquiry (P30200)

Routing Master (P3003)

The following table lists the Routing Master application (P3003) business function components that must be mapped to the same physical machine.

Table 26. Routing Master (P3003) – Partitioned Logic Source Members


N3001780 Routing Master MBF

B3001940 Routing Master Cache Clean Up for Next Transaction

Bill of Material (P3002)

The following table lists the Bill of Material application (P3002) business function components that must be mapped to the same physical machine.

Table 27. Bill of Material (P3002) – Partitioned Logic Source Members


N3002040 Bill of Material MBF

B3002040 Bill of Material MBF



B3002020 Bill of Material Cache Clean Up for Next Transaction

Work Center Master (P3006)

The following table lists the Work Center Master application (P3006) business function components that must be mapped to the same physical machine.

Table 28. Work Center Master (P3006) – Partitioned Logic Source Members


N3001840 Work Center MBF

B3001860 Work Center Cache Clean Up for Next Transaction

Work Center Rates (P3006)

The following table lists the Work Center Rates application (P3006) business function components that must be mapped to the same physical machine.

Table 29. Work Center Rates (P3006) – Partitioned Logic Source Members


N3001900 Work Center Rates MBF

B3001900 Work Center Rates Cache Clean Up for Next Transaction

Bill of Material Inquiry (P30200)

The following table lists the Bill of Material Inquiry application (P30200) business function components that must be mapped to the same physical machine.

Table 30. Bill of Material Inquiry (P30200) – Partitioned Logic Source Members


B3003090 Bill Explosion BSFN

B3003100 BOM Explosion Cache Clean Up for Next Transaction

B3003160 BOM Text Lines Cache Clean Up for Next Transaction



Shop Floor Control

The Shop Floor Control system (System Code 31) includes the following applications:

?? Work Order Parts Lists (P3111) ?? Work Order Routings (P3112) ?? Work Order Issues (P31113) ?? Work Order Completions (P31114) ?? Work Order Hours and Quantities (P311221)

Work Order Parts Lists (P3111)

The following table lists the Work Order Parts Lists application (P3111) business function components that must be mapped to the same physical machine.

Table 31. Work Order Parts Lists (P3111) – Partitioned Logic Source Members


B3101260 Work Order Parts Lists MBF

Work Order Routings (P3112)

The following table lists the Work Order Routings application (P3112) business function components that must be mapped to the same physical machine.

Table 32. Work Order Routings (P3112) – Partitioned Logic Source Members


B3101250 Work Order Routings MBF



Work Order Issues (P31113)

The following table lists the Work Order Issues application (P31113) business function components that must be mapped to the same physical machine.

Table 33. Work Order Issues (P31113) – Partitioned Logic Source Members


B3101790 Work Order Issues MBF

Work Order Completions (P31114)

The following table lists the Work Order Completions application (P31114) business function components that must be mapped to the same physical machine.

Table 34. Work Order Completions (P31114) – Partitioned Logic Source Members


B3100770 Work Order Completions MBF

B3100790 Work Order Issues MBF Co/By Product Completions

B3101570 Co/By Product Cache Co/By Product Completions

Work Order Hours and Quantities (P311221)

The following table lists the Work Order Hours and Quantities application (P311221) business function components that must be mapped to the same physical machine.

Table 35. Work Order Hours and Quantities (P311221) – Partitioned Logic Source Members


B3101040 Work Order Hours and Quantities MBF



Requirements Planning

The Requirements Planning system (System Code 34) includes the following application:

?? Planning Messages (P3411)

Planning Messages (P3411)

The following table lists the Planning Messages application (P3411) business function components that must be mapped to the same physical machine.

Table 36. Planning Messages (P3411) – Partitioned Logic Source Members


B3401360 Messages MBF

OneWorld in Distributed and WAN Environments Appendix A: jde.ini Settings for Server Processes


APPENDIX A:

Jde.ini Settings

for Server Processes



APPENDIX A: jde.ini Settings for Server Processes

Jde.ini parameters for jdenet_n

For servers only, the characteristics of the Jdenet_n jobs are controlled by the following jde.ini settings: [JDENET] netPgmName=network program name maxNetProcesses=number of jdenet_n processes maxNetConnections=number connections per jdenet_n process

Variable values for jdenet_n settings

The following describes the variable values for the jde.ini settings controlling jdenet_n.

network program name

Defines the name of the Jdenet_n job. The program name varies according to server platform. For certain platforms, the value can contain path information. For example:

AS/400: /QSYS.LIB/B731NET.LIB/JDENET_N.PGM UNIX: jdenet_n

number of jdenet_n processes

Defines the maximum number of jdenet_n jobs that can run on the OneWorld server. The number of jdenet_n network processes can be from 1 to n. If multiple jdenet_n jobs are specified, OneWorld starts the jobs as required allocating a job to each request. When the maximum number of jdenet_n processes is met as defined by this parameter, OneWorld automatically alternates between the currently running jdenet_n jobs until the maximum number of connections is reached. This provides a degree of load balancing between the OneWorld network processes. If, on a given server, the maximum number of connections for the jdenet_n job is met, a client or server cannot initiate an additional OneWorld session on that server.

number of connections per jdenet_n process

Defines the maximum number of connections that are allowed for each jdenet_n job. A specific and persistent connection is defined for the duration of a OneWorld session.

The number defined for this value is not the cumulative total of connections per server machine, but rather the maximum number of connections per individual jdenet_n job. The value applies equally to all jdenet_n jobs. That is, you cannot specify that one jdenet_n job can have 100 connections while another has 50. For example, if you specify maxNetProcesses=3 and maxNetConnections=100, the total number of concurrent sessions on that server is 300.



OneWorld Logic Processes (jdenet_k)

OneWorld logic processes are executed as directed by a jdenet_k process. This process is specifically identified by the program jdenet_k. This program is the OneWorld process that provides the link between the jdenet_n job and the appropriate platform-specific processing job. The jdenet_k process is only applicable to servers.

On the server, the jdenet_n job determines if the incoming message is a request for logic processing. If so, it routes the request to the jdenet_k job. Based on message identifiers, the jdenet_k job routes the processing request to the appropriate platform-specific processing program (defined by settings in the jde.ini). The jdenet_k program handles the two-way routing to and from the various logic processes and the jdenet_n job, which in turn handles the return delivery to the appropriate machine.

There are six kernel types, each responsible for specific types of OneWorld processes:

Type 1: OneWorld’s internal tests and echoes

Type 2: jdeCallObject API

Type 3: Data replication

Type 4: Security server

Type 5: Transaction monitor

Type 6: OneWorld web product APIs

Jde.ini parameters for jdenet_k type definitions

For servers only, kernel types are defined by the following jde.ini settings. Only variable values (identified by italic type) can be changed by the user.

[JDENET_KERNEL_DEF1] dispatchDLLName=kernel program name dispatchDLLFunction=JDENET_DistpatchMessage maxNumberOfProcesses=1 beginningMsgTypeRange=0 endingMsgTypeRange=255 newProcessThresholdRequests=0 [JDENET_KERNEL_DEF2] dispatchDLLName=kernel program name dispatchDLLFunction=JDEK_DispatchKernelMessage maxNumberOfProcesses=1 beginningMsgTypeRange=256



endingMsgTypeRange=511 newProcessThresholdRequests=0 [JDENET_KERNEL_DEF3] dispatchDLLName=kernel program name dispatchDLLFunction=DispatchRepMessage maxNumberOfProcesses=1 beginningMsgTypeRange=512 endingMsgTypeRange=550 newProcessThresholdRequests=0 [JDENET_KERNEL_DEF4] dispatchDLLName=kernel program name dispatchDLLFunction=JDEK_DispatchSecurity maxNumberOfProcesses=1 beginningMsgTypeRange=551 endingMsgTypeRange=580 newProcessThresholdRequests=0 [JDENET_KERNEL_DEF5] dispatchDLLName=kernel program name dispatchDLLFunction=TM_DispatchTransactionManager maxNumberOfProcesses=1 beginningMsgTypeRange=601 endingMsgTypeRange=650 newProcessThresholdRequests=0 [JDENET_KERNEL_DEF6] dispatchDLLName=kernel program name dispatchDLLFunction=JDEWK_DispatchWebMessage maxNumberOfProcesses=1 beginningMsgTypeRange=651 endingMsgTypeRange=700 newProcessThresholdRequests=0

Variable values for jdenet_k type definitions

The following describes the variable value for the jde.ini that defines the jdenet_k type definitions:

kernel program name

Defines the name of the jdenet_k job executing on a OneWorld server. The program name varies according to server platform and kernel function. For example:

AS/400 Types 1-5: JDEKRNL Type 6: JDEWAPI



UNIX (HP9000) Type 1: libjdenet.sl Types 2-4: libjdeknet.sl Type 5: libtransmon.sl Type 6: libjdewapi.sl UNIX (RS6000) Type 1: libjdenet.so Types 2-4: libjdekrnl.so Type 5: libjdekrnl.so Type 6: libjdewapi.so NT Type 1: jdenet.dll Types 2-6: jdekrnl.dll Type 6: jdewapi.dll

Therefore, as jdenet_k receives messages requiring processing from jdenet_n, it uses message type numbers to route the processing request to the appropriate kernel type. This routing determination is made based on numbers associated with message types. Message types are defined in specific ranges in the jde.ini and cannot be changed by the user.

Jde.ini parameters for numbers of jdenet_k processes

In addition to controlling the jdenet_n process, the [JDENET] section of the jde.ini also contains other parameters that control the maximum number of logic processes and the maximum number of kernel type ranges:

[JDENET] maxKernelProcess=number of kernel processes maxKernelRanges=number of kernel ranges

Variable values for numbers of jdenet_k processes

The following describes the variable values the jde.ini parameters that control the maximum number of logic processes and the maximum number of kernel type ranges:

number of kernel processes

Defines the maximum number of processes that the jdenet_k kernel job can call. This is the total of all definition types.



For example, if you define five ranges of kernels (see number of kernel ranges), each with a single process ([JDENET_KERNEL_DEFx] maxNumberOfProcesses=1), the value you specify here should be at least 5. Likewise, if you change the number of ranges or the number of individual processes, you must adjust this value accordingly. For example, if you increase the number of kernel ranges from 5 to 6, and increase the maximum number of processes for one of the definition types from 1 to 2, you must change the value for maxKernelProcesses from 5 to 7.

number of kernel ranges

Defines the maximum number of kernel ranges that the jdenet_k kernel job can call. A kernel range is defined by a specific definition labeled as [JDENET_KERNEL_DEFx], where x is a valid number associated with a range of message types. For example, [JDENET_KERNEL_DEF4] specifies the Security Server and includes ranges of messages from 551 to 580. For OneWorld Release B73.2, there are six pre-defined ranges of messages. Third-party vendors can write programs that interface with OneWorld APIs that define and use other messages ranges.

The following diagram shows the flow of incoming network messages through jdenet_n and jdenet_n. In this example, the incoming message is a Security Server request with a message type of 552. The following steps occur:

1. The jdenet_n process takes the message and determines that it is a logic request. It reads the jde.ini and determines the name of the kernel job. In this case, the name of the kernel job is jdenet_k.

2. The jdenet_n process reads the jde.ini and determines if the maximum number of kernel processes has been met.

3. The jdenet_n process reads the jde.ini and determines if the maximum number of kernel ranges has been met. If neither the maximum number of processes or maximum number of ranges has been exceeded, the request is passed the request to the jdenet_k job.

4. Based on the message type number, the jdenet_k job determines the kernel definition type. For this request, the kernel type is 4, which is the security server.

5. The kernel job reads the jde.ini to determine the maximum number of logic processes that are allowed for Type 4 kernels. In this example, two security server logic processes are allowed. If required and allowed, the jdenet_k job starts the platform-specific logic process.

6. The kernel job reads the jde.ini to determine which platform-specific logic process to call for the actual logic processing. In this example, an NT server is being used so the specified process is an NT platform-specific Dynamic Link Library named jdekrnl.dll. If the kernel job is not already started, the jdenet_k call starts it. If the job is already started, the request is queued to the next available logic process identified to run this message type request.



Incoming message (SS-552)

[JDENET]KrnlPgmName=jdenet_kmaxKernelProcesses=6maxKernelRanges=5

[JDENET_KERNEL_DEF1]maxNumberOfProcesses=1beginningMsgTypeRange=0endingMsgTypeRange=255



[JDENET_KERNEL_DEF4]MaxNumberOfProcesses=2beginningMsgTypeRange=551

=580

Jde.ini

Jdenet_k

12

jdekrnl.dll

DispatchDLLName=jdekrnl.dll

5

4

6

Jdenet_n

endingMsgTypeRange

[JDENET_KERNEL_DEF5]maxNumberOfProcesses=1beginningMsgTypeRange =601

=650endingMsgTypeRange

3

Figure 21. jdenet_n and jdenet_k Process Flow



APPENDIX B:

HP/UNIX Kernel Considerations

OneWorld in Distributed and WAN Environments Appendix B: HP/UNIX Kernel Considerations




Appendix B: HP/UNIX Kernel Considerations

The native proprietary HP/UX kernel is built using a long list of kernel parameters. These parameters control the quantity of various resources available within the HP/UX kernel. Several of them are pertinent to the operation of OneWorld server software, in particular the inter-process communication (IPC) facilities.

The HP/UX kernel parameters are normally set using the SAM (System Administration Management) tool. Within that tool, any given parameter may be set either to a simple numerical value, or to an expression based on other parameters' values. Setting HP/UX kernel parameters must be done by the what UNIX security refers to as the “SUPERUSER”.

OneWorld is not the only piece of software that uses the HP resources controlled by the HP parameters described herein. For each parameter, OneWorld's requirements are either a minimum or are in addition to the defaults provided with HP/UX, or the requirements of any other software installed on the system.

For this appendix, the following terms are defined:

jdenet_n The maximum number of jdenet_n ("net") processes that can be started on the server. This is controlled by the maxNetProcesses parameter in the JDENET section of each JDE.INI file.

jdenet_k The maximum number of jdenet_k ("kernel") processes that can be started on the server. This is controlled by the maxKernelProcesses parameter in the JDENET section of each JDE.INI file. Note that the maxNumberOfProcesses parameters in the JDENET_Kernel_Def… sections are not used by HP/UX.

jdequeue The maximum number of jdequeue processes that can be created, summed across all instances of OneWorld software running on the server. The number of invocations of runque.sh in the RunOneWorld.sh scripts controls this.

Message Queues

The values recommended here are intended for worst-case scenarios. Generally, queues are cleared quickly and typically do not back up unless there is some problem.

The relevant parameters are:

mesg System-V style message queues are supported. This must be 1.

msgmap The number of entries in the map of free message segments. The default value of msgtql + 2 should always suffice. If msgmap is made smaller than this, it's conceivable that attempts to create a message queue or send a message could fail. Unfortunately it's effectively impossible to quantify OneWorld's needs for msgmap.

msgmnb The maximum number of bytes that can be on any one message queue at any one time. This parameter is unique in that making it too large can hurt, because it would allow an errant program to gobble up too much of the system's message queue resources by writ ing many messages to one message queue. In particular, msgmnb should be only a fraction of (msgseg x msgssz). For OneWorld, a value of 8192 seems good. Larger values are OK, as long as (msgseg x msgssz) is large enough. This value is a minimum, not in addition to other requirements for this parameter.



msgmax The maximum size, in bytes, of a single message (contrary to what some people believe, it is not the maximum number of bytes that can be occupied by all messages on all queues in the system simultaneously). It makes no sense for msgmax to be any larger than msgmnb. I recommend setting msgmax = msgmnb. At a very minimum, msgmax should be 1024. This value is a minimum, not in addition to other requirements for this parameter.

msgmni The number of "message queue identifiers", i.e. the number of message queues that can exist system-wide. For OneWorld's use, allow (in addition to the system default value, and any other software's requirements) 1 + jdenet_n + (2 x jdenet_k) + (2 x jdequeue).

msgtql The number of message headers, i.e. the total number of messages that can be in all the message queues at once. For OneWorld's use, allow 10 x msgmni in addition to the system default value and any other software's requirements).

Inside the HP/UX kernel, messages in message queues are stored in message segments. The size and number of segments available system-wide can be configured:

msgssz The size of each message segments, in bytes. For OneWorld, a value of 64 seems appropriate.

msgseg The number of message segments system-wide. For OneWorld's use, allow 50 x (the OneWorld requirement for msgmni) in addition to the system's default value or any other software's requirements.

The total number of bytes that can be in all messages in all message queues in the system simultaneously is limited by msgseg x msgssz. As mentioned before, this should be significantly larger (like at least twice as large) as msgmnb.

However, as long as msgssz is increased from its default value of 8, both of these requirements are dwarfed by the values to which msgseg is commonly set anyway, which are in the thousands.

Semaphores

The following settings are required for OneWorld releases prior to B73.3. It is anticipated that the code dealing with semaphores on UNIX will be rewritten for release B73.3.

sema System-V type semaphores are enabled. This must be 1.

semaem The maximum "adjust on exit" value for any semaphore. OneWorld never needs this to be greater than 1, so the default value supplied with the HP/UX system should be fine.

semmap The number of entries in the map of free semaphores. The default value of semmni + 2 should always suffice. If semmap is made smaller than this, it's conceivable that attempts to create a semaphore set (done during JDEIPC initialization) could fail. Unfortunately it's effectively impossible to quantify OneWorld's needs for semmap.

semmni The maximum number of semaphore identifiers that can be used, system-wide. Before release B73.3 a separate identifier was used for each semaphore that was created, so allow about 50 for each instance of OneWorld on the system, in addition to the default and/or any other software's requirements. With release B73.3 and later a single identifier is used for each instance of OneWorld, so the default value supplied with the HP/UX system should be fine.

semmns The maximum number of semaphores that can be created, system-wide. Before release B73.3, allow about 50 for each instance of OneWorld on the system. With release B73.3 and later, by default each instance of OneWorld allocates 100 semaphores, but this value can be customized in the JDE.INI file, in the JDEIPC section, with the parameter maxNumberOfSemaphores. In all cases, the OneWorld requirement is in addition to the default and/or any other software's requirements.



semmnu The maximum number of processes that can have "undo's" pending against any one semaphore, which effectively is the maximum number of processes that can have any one semaphore locked at the same time. For OneWorld, allow one for each OneWorld process that that can exist (on the single largest installation of OneWorld on the system). This would be: 1 + jdenet_n + jdenet_k + 2 x jdequeue + max number of jdeprint processes + max number of runube processes The number of jdeprint processes is determined by how many print requests are outstanding (printing or waiting for a printer) at a given time. A good guess at an upper limit seems to be about 10, but this is application-dependent. For example, a large warehouse where pick slips are constantly being printed might have more. The number of runube processes is determined by how many UBE (batch) jobs are run directly on the server (not from a client) at any given time. Again, this depends on how the system is used, and there is no theoretical limit. The jdequeue parameter is doubled because each jdequeue process may create a runbatch process. This requirement is in addition to the default and/or any other software's requirements.

semume The maximum number of semaphore "undo" entries per process, which effectively is the maximum number of semaphores that any one process can have locked simultaneously. OneWorld needs this to be a minimum of about 4. This is not in addition to the default or the requirements of any other software; it is a simple minimum. The default value provided with the system should be fine.

semvmx The maximum value any semaphore is allowed to take. Currently, OneWorld never makes a semaphore have a value larger than 1, so the default value provided with the system should be fine.

Shared Memory shmem Shared memory is enabled. Must be 1.

shmmax The maximum size, in bytes, of any one shared memory segment. The default value provided with the system should be fine. Quite possibly other software (e.g. Oracle) will require an increase in this parameter.

shmmni The maximum number of shared memory segments system-wide. For OneWorld, allow 20 per instance of the OneWorld server software running on the system. This requirement is in addition to the default and/or any other software's requirements.

shmseg The maximum number of shared memory segments to which any one process can attach at a given time. The default value provided with the system should be fine.



File Descriptors nfile The maximum number of open files (or sockets) system-wide. Most of OneWorld's needs will be

easily handled by the default value supplied with the HP/UX system. However, explicit allowance must be made for the maximum number of sockets that can be created by jdenet_n processes to communicate with clients, summed across all instances of OneWorld server software running on the system. This is controlled by the maxNetConnections parameter in the JDENET section of each JDE.INI file. This requirement is in addition to the default and/or any other software's requirements.

maxfiles The default soft limit on the number of file descriptors any given process can have (a process can get its soft limit raised as high as maxfiles_lim by making a system call). For OneWorld, make sure maxfiles is at least the largest of all the maxNetConnections values in all the JDE.INI files in use, plus 10. This requirement is a minimum value, not in addition to the default and/or any other software's requirements. (We expect to remove this requirement in B73.3).

The symptoms of having this parameter too small are particularly subtle, because it can prevent OneWorld from opening the log file to generate an error message.

maxfiles_lim The hard limit on the number of file descriptors any given process can have. For OneWorld, make sure maxfiles is at least the largest of all the maxNetConnections values in all the JDE.INI files in use, plus 10. This requirement is a minimum value, not in addition to the default and/or any other software's requirements.

Processes maxuprc The maximum number of processes that can be running with any one user ID. This is of particular

concern on systems with either a very large OneWorld installation, or multiple instances the OneWorld software all running under the same user ID. For OneWorld, allow 2 x ( jdenet_n + jdenet_k + (2 x jdequeue)), summed across all instances of the OneWorld software running on the system. The doubling allows ample capacity for all the ancillary processes such as runube and runprint.

OneWorld in Distributed and WAN Environments Glossary


Glossary

This glossary defines terms in the context of J.D. Edwards system and the accompanying documentation.

ActiveX. A computing technology based on Microsoft’s OLE, that enables Java applet–style functionality for Web browsers as well as other applications. (Java is limited to Web browsers at this time.) The ActiveX equivalent of a Java applet is an ActiveX control. These controls bring computational, communications, and data manipulation power to programs that can “contain” them. For example, certain web browsers, Microsoft Office programs, and anything developed with Visual Basic or Visual C++.

API. See Application Programming Interface.

Applet. A small application, such as a utility program or a limited–function spreadsheet. It is generally associated with the programming language Java, and in this context refers to Internet–enabled applications that can be passed from a web server to a web browser residing on a client.

Application. In the computer industry, the same as an executable. In OneWorld, an interactive or batch application is a DLL containing programming for a set of related forms that can be run from the menu driver to perform a business task.

Application Developer. A programmer who develops OneWorld applications using the OneWorld toolset.

Application Programming Interface (API). A software function call that can be made from a program to access functionality provided by another program.

Application Server. A server on which OneWorld business function components interactive and/or batch applications are run instead of on a client or Enterprise Server. This server does not contain a database.

Batch Server. A server on which OneWorld batch processing requests (also called UBE) are run instead of on a client, Application Server, or Enterprise Server. This server does not contain a database or run interactive versions.

Browser. A client application that translates information sent by the World Wide Web. A client must use a browser to receive World Wide Web information on the desktop.

Business Function. An encapsulated set of business rules and logic that can normally be reused by multiple applications. Business functions can execute a transaction or a subset of a transaction (check inventory, issue work orders, and so on). Business functions also contain the APIs that allow them to be called from a form, a database trigger, or a non–OneWorld application. Business functions can be combined with other business functions, forms, event rules, and other components to make up an application. Business functions can be created through event rules or third–generation languages, such as C. Examples of business functions include Credit Check and Item Availability.

Business Function Components. Compiled objects that contain application logic supporting the execution of an application. These components are configurable under CNC and in most cases can run on a client or a server. There are four types of these components:

?? Master Business Functions ?? Major Business Functions



?? Minor Business Functions ?? Generated Java Applets and Servlets

Business Function Event Rule. Encapsulated, reusable business logic created through event rules rather than C programming.

Business View. Used by OneWorld applications to access data from database tables. A business view is a means for selecting specific columns from one or more tables whose data will be used in an application or report. It does not select specific rows and does not contain any physical data. It is strictly a view through which data can be handled.

CallObject. See jdeCallObject.

Central Objects. Objects that reside in a central location and consist of two parts: the central objects data source and central C components. The central objects data source contains OneWorld specifications, which are stored in a relational database. Central C components contain business function source, header, object, library and DLL files and are usually stored in directories on the deployment server. Together they make up central objects.

Child. See Parent/Child Form.

Client/Server. A relationship between processes running on separate machines. The server process is a provider of software services. The client is a consumer of those services. In essence, client/server provides a clean separation of function based on the idea of service. A server can service many clients at the same time and regulate their access to shared resources. There is a many–to–one relationship between clients and a server, respectively. Clients always initiate the dialog by requesting a service. Servers passively wait for requests from clients.

Configurable Network Computing. An application architecture that allows interactive and batch applications, composed of a single code base, to run across a TCP/IP network of multiple server platforms and SQL databases. The applications consist of reusable business functions and associated data that can be configured across the network dynamically. The overall objective for businesses is to provide a future–proof environment that enables them to change organizational structures, business processes, and technologies independently of each other.

Data Dictionary. The OneWorld data dictionary contains data item definitions and specifications. J.D. Edwards has an active data dictionary that is accessed at runtime.

Data Source. A specific instance of a database management system running on a computer. Data source management is accomplished through Object Configuration Manager (OCM) and Object Map (OM).

Data Structure. A group of data items that can be used for passing information between objects, for example, between two forms, between forms and business functions, or between reports and business functions.

Data Replication. In a replicated environment, multiple copies of data are maintained on multiple machines. There must be a single source that “owns” the data. This ensures that the latest copy of data can be applied to a primary place and then replicated as appropriate. (This is in contrast to a simple copying of data, where the copy is not maintained from a central location, but exists independently of the source.)

Database Driver. Software that connects an application to a specific database management system.



Database Server. A server that stores data. A database server does not have OneWorld logic.

Database-Only Workgroup Server. A Workgroup Server that contains only a database and runs no OneWorld server code.

Deployment Server. The central point of the OneWorld installation process. It is used for package deployment and to hold the central C components portion of central objects.

Detail Area. A control that is found in OneWorld applications and functions similarly to a spreadsheet grid for viewing, adding, or updating many rows of data at one time.

DLL. See Dynamic Link Library.

Duplicated Database. A decision support database that contains a straightforward copy of operational data. The advantages involve improved performance for both operational and reporting environments.

Dynamic Link Library (DLL). DLLs contain a set of program modules that are designed to be invoked from executables when the executables are run, without having to be linked to the executables. They typically contain commonly used functions.

Dynamic Partitioning. The ability to dynamically distribute logic or data to multiple tiers in a client/server architecture.

Enterprise Server. A database server and logic server. See Database Server, Logic Server. Also referred to as host.

ERP. Enterprise Resource Planning.

Event. Actions that might occur when a GUI application or OneWorld report is running. Example events are tabbing out of an edit control, clicking a push button, initializing a form, or

performing a page break on a report. The GUI operating system uses miniprograms to manage user activities within a form. Additional logic can be attached to these miniprograms and used to give greater functionality to any event within a OneWorld application or report using event rules.

Event Rule. Used to create complex business logic without the difficult syntax that comes with many programming languages. These logic statements can be attached to applications or database events and are executed when the defined event occurs, such as entering a form, selecting a menu bar option, page breaking on a report, or deleting a record. An event rule can validate data, send a message to a user, call a business function, as well as many other actions. There are two types of event rules:

1.) Embedded event rules

2.) Business function event rules

Executable. A computer program that can be run from the computer’s operating system. Equivalent terms are “application” and “program.”

Find/Browse. A type of form used to:

1) Search, view, and select multiple records in a detail area

2) Delete records

3) Exit to another form

4) Serve as an entry point for most applications

Firewall. A set of technologies that allows an enterprise to test, filter, and route all incoming messages. Firewalls are used to keep an enterprise secure.

Fix/Inspect. A type of form used to view, add, or modify existing records. A fix/inspect form has no detail area.



Form. In Microsoft Windows terminology a form is known as a dialog box. In OneWorld, a form is a GUI window that contains controls to display, accept input of, and process information. A OneWorld application might contain multiple forms.

Form Type. The following form types are available in OneWorld:

1) Find/browse

2) Fix/inspect

3) Header/detail

4) Headerless detail

5) Message

6) Parent/child

7) Search/select

Graphical User Interface. A computer interface that is graphically based as opposed to being character–based. An example of a character–based interface is that of the AS/400. An example of a GUI is Microsoft Windows. Graphically based interfaces allow pictures and other graphic images to be used in order to give people clues on how to operate the computer.

Grid. See Detail Area.

GUI. See Graphical User Interface.

Header/Detail. A type of form used to add, modify, or delete records from two different tables. The tables usually have a parent/child relationship.

Headerless Detail. A type of form used to work with multiple records in a detail area. The detail area is capable of receiving input.

Host. In the centralized computer model, a large timesharing computer system that terminals communicate with and rely on for processing. It contrasts with client/server in that those users work at computers that perform much of their own processing and access servers that provide services such as file management, security, and printer management.

HTML. See Hypertext Markup Language.

Hypertext Markup Language. A markup language used to specify the logical structure of a document rather than the physical layout. Specifying logical structure makes any HTML document platform independent. You can view an HTML document on any desktop capable of supporting a browser. HTML can include active links to other HTML documents anywhere on the Internet or on intranet sites.

Index. Represents both an ordering of values and a uniqueness of values that provide efficient access to data in rows of a table. An index is made up of one or more columns in the table.

Inheritance. The ability of a class to receive all or parts of the data and procedure definitions from a parent class. Inheritance enhances development through the reuse of classes and their related code.

Internet. The worldwide constellation of servers, applications, and information available to a desktop client through a phone line or other type of remote access.

IP. A connection–less communication protocol that by itself provides a datagram service. Datagrams are self–contained packets of information that are forwarded by routers based on their address and the routing table information contained in the routers. Every node on a TCP/IP network requires an address that identifies both a network and a local host or node on the network.



In most cases the network administrator sets up these addresses when installing new workstations. In some cases, however, it is possible for a workstation, when booting up, to query a server for a dynamically assigned address.

J.D. Edwards Database. See JDEBASE Database Middleware.

Java. An Internet executable language that, like C, is designed to be highly portable across platforms. This programming language was developed by Sun Microsystems. Applets, or Java applications, can be accessed from a web browser and executed at the client, provided that the operating system or browser is Java–enabled. (Java is often described as a scaled–down C++). Java applications are platform independent.

Java Database Connectivity (JDBC). The standard way to access Java databases, set by Sun Microsystems. This standard allows you to use any JDBC driver database.

JDEBASE Database Middleware. J.D. Edwards proprietary database middleware package that provides two primary benefits:

1) Platform-independent APIs for multidatabase access. These APIs are used in two ways:

a. By the interactive and batch engines to dynamically generate platform-specific SQL, depending on the data source request.

b. As open APIs for advanced C business function writing. These APIs are then used by the engines to dynamically generate platform–specific SQL.

2) Client–to–server and server–to–server database access. To accomplish this OneWorld is integrated with a variety of third–party database drivers, such as Client Access 400 and open database connectivity (ODBC).

jdeCallObject. An API used by business functions to invoke other business functions.

jde.ini. J.D. Edwards file (or member for AS/400) that provides the runtime settings required for OneWorld initialization. Specific versions of the file/member must reside on every machine running OneWorld. This includes workstations and servers.

JDENET. J.D. Edwards proprietary middleware software. JDENET is a messaging software package.

JDENET Communications Middleware. J.D. Edwards proprietary communications middleware package for OneWorld. It is a peer–to–peer, message–based, socket–based, multiprocess communications middleware solution. It handles client–to–server and server–to–server communications for all OneWorld supported platforms.

Just In Time Installation (JITI). OneWorld’s method of dynamically replicating objects from the central object location to a workstation.

Just In Time Replication (JITR). OneWorld’s method of replicating data to individual workstations. OneWorld replicates new records (inserts) only at the time the user needs the data. Changes, deletes, and updates must be replicated using Pull Replication.

Middleware. A general term that covers all the distributed software needed to support interactions between clients and servers. Think of it as the software that’s in the middle of the client/server system or the “glue” that lets the client obtain a service from a server.

Mixed Tier. A architectural computing configuration that integrates a combination of Workgroup Servers, Application Servers, or other servers to maximize application performance.



Multitier Architecture. A client/server architecture that allows multiple levels of processing. A tier defines the number of computers that can be used to complete some defined task.

Network Computer. As opposed to the personal computer, the network computer offers (in theory) lower cost of purchase and ownership and less complexity. Basically, it is a scaled–down PC (very little memory or disk space) that can be used to access network–based applications (Java applets, ActiveX controls) via a network browser.

Network Computing. Often referred to as the next phase of computing after client/server. While its exact definition remains obscure, it generally encompasses issues such as transparent access to computing resources, browser–style front–ends, platform independence, and other similar concepts.

Object. A self–sufficient entity that contains data as well as the structures and functions used to manipulate the data. For OneWorld purposes, an object is a reusable entity that is based on software specifications created by the OneWorld toolset. See also Object Librarian.

Object Configuration Manager (OCM). OneWorld’s Object Request Broker and the control center for the runtime environment. It keeps track of the runtime locations for business functions, data, and batch applications. When one of these objects is called, the Object Configuration Manager directs access to it using defaults and overrides for a given environment and user.

Object Librarian. A repository of all versions, applications, and business functions reusable in building applications. It provides check–out and check–in capabilities for developers, and it controls the creation, modification, and use of

OneWorld objects. The Object Librarian supports multiple environments (such as production and development) and allows objects to be easily moved from one environment to another.

Object Librarian. A repository of all versions, applications, and business functions reusable in building applications. It provides check–out and check–in capabilities for developers, and it controls the creation, modification, and use of OneWorld objects. The Object Librarian supports multiple environments (such as production and development) and allows objects to be easily moved from one environment to another.

ODBC. See Open Database Connectivity.

OCM. See Object Configuration Manager.

OLE. See Object Linking and Embedding.

OneWorld. A combined suite of comprehensive, mission–critical business applications and an embedded toolset for configuring those applications to unique business and technology requirements. OneWorld is built on the Configurable Network Computing technology — J.D. Edwards’ own application architecture, which extends client/server functionality to new levels of configurability, adaptability, and stability.

OneWorld Application. Interactive or batch processes that execute the business functionality of OneWorld. They consist of reusable business functions and associated data that are platform independent and can be dynamically configured across a TCP/IP network.

OneWorld Object. A reusable piece of code that is used to build applications. Object types include tables, forms, business functions, data dictionary items, batch processes, business views,



event rules, versions, data structures, and media objects. See also Object.

OneWorld Process. Allows OneWorld clients and servers to handle processing requests and execute transactions. A client runs one process, and servers can have multiple instances. OneWorld processes can also be dedicated to specific tasks (for example, workflow messages and data replication) to ensure that critical processes don’t have to wait if the server is particularly busy.

Open Database Connectivity (ODBC). Defines a standard interface for different technologies to process data between applications and different data sources. The ODBC interface is made up of a set of function calls, methods of connectivity, and representation of data types that define access to data sources.

Package. OneWorld objects are installed to workstations in packages from the deployment server. A package can be compared to a bill of material or kit that indicates the necessary objects for that workstation and where on the deployment server the install program can find them. It is a point–in–time “snap shot” of the central objects on the deployment server.

Parent/Child Form. A type of form that presents parent/child relationships in an application on one form. The left portion of the form presents a tree view that displays a visual representation of a parent/child relationship. The right portion of the form displays a detail area in browse mode. The detail area displays the records for the child item in the tree. The parent/child form supports drag and drop functionality.

Partitioning. A technique for distributing data to local and remote sites to place data closer to the users who access. Portions of data can be copied to different database management systems.

Path Code. A pointer to a specific set of objects. A path code is used to locate:

1.) Central Objects

2.) Replicated Objects

Platform Independence. A benefit of open systems and Configurable Network Computing. Applications that are composed of a single code base can be run across a TCP/IP network consisting of various server platforms and SQL databases.

Primary Key. A column or combination of columns that uniquely identifies each row in a table.

Processing Option. The choices available when you submit a version of a program for processing. Processing options set up default values, control formats, control breaks and totaling for reports, and control how an application or report processes data.

Published Table. Also called a “Master” table, this is the central copy to be replicated to other machines. Resides on the “Publisher” machine. The Data Replication Publisher Table (F98DRPUB) identifies all of the Published Tables and their associated Publishers in the enterprise.

Publisher. The server that is responsible for the Published Table. The Data Replication Publisher Table (F98DRPUB) identifies all of the Published Tables and their associated Publishers in the enterprise.

Pull Replication. One of the OneWorld methods for replicating data to individual workstations. Such machines are set up as Pull Subscribers using OneWorld’s data replication tools. The only time Pull Subscribers are notified of changes, updates, and deletions is when they request such information. The request is in the



form of a message that is sent, usually at startup, from the Pull Subscriber to the server machine that stores the Data Replication Pending Change Notification table (F98DRPCN).

Query by Example (QBE). Located at the top of a detail area, it is used to search for data to be displayed in the detail area.

Replicated Object. A copy or replicated set of the central objects must reside on each client and server that run OneWorld. The path code indicates the directory where these objects are located.

Scalability. Allows software, architecture, network, or hardware growth that will support software as it grows in size or resource requirements. The ability to reach higher levels of performance by adding microprocessors.

Search/Select. A type of form used to search for a value and return it to the calling field.

Server. Provides the essential functions for furnishing services to network users (or clients) and provides management functions for network administrators. Some of these functions are:

1) Storage of operating system program modules, utilities, and commands

2) Storage of user programs and data

3) Management functions for the file system

4) Management functions for security and user access

5) Network monitoring and management components

6) Data protection functions for fault tolerance

It may not be possible for one server to support all users with the required services. Dedicated

servers that handle specific tasks, such as those listed below, are also common:

1) Backup and archive servers

2) Application server

3) Database server

4) Electronic mail server

5) Fax server

6) Print server

7) Directory services server

Specifications. A complete description of a OneWorld object. Each object has its own specification, or name, which is used to build applications.

SQL. See Structured Query Language.

Store and Forward. A transaction method that allows a client application to perform work and, at a later time, complete that work by connecting to a server application. This often involves uploading data residing on a client to a server.

Structured Query Language (SQL). A fourth generation language used as an industry standard for relational database access. It can be used to create databases and to retrieve, add, modify, or delete data from databases. SQL is not a complete programming language because it does not contain control flow logic.

Subscriber. The server that is responsible for the replicated copy of a Published Table. Such servers are identified in the Subscriber Table.

Subscriber Table. The Subscriber Table (F98DRSUB), which is stored on the Publisher Server with the Data Replication Publisher Table (F98DRPUB) identifies all of the Subscriber machines for each Published Table.



Table. A two–dimensional entity made up of rows and columns. All physical data in a database are stored in tables. A row in a table contains a record of related information. An example would be a record in an Employee table containing the Name, Address, Phone Number, Age, and Salary of an employee. Name is an example of a column in the employee table.

TCP/IP. Transmission Control Protocol/Internet Protocol. The original TCP protocol was developed as a way to interconnect networks using many different types of transmission methods. TCP provides a way to establish a connection between end systems for the reliable delivery of messages and data.

Trigger. Allow you to attach default processing to a data item in the data dictionary. When that data item is used on an application or report, the

trigger is invoked by an event associated with the data item. OneWorld also has three visual assist triggers: calculator, calendar and search form.

UBE Server. See Batch Server.

Universal Resource Locator (URL). Names the address of a document on the Internet or an intranet. The following is an example of a URL:

http://www.jdedwards.com

This is J.D. Edwards Internet address.

Visual Assist. Forms that can be invoked from a control to assist the user in determining what data belongs in the control.

Workgroup Server. A remote database server usually containing subsets of data replicated from a master database server.

distributed and wan environments - erpsourcing network computing... · master business functions...

Documents