oneworld architectural theory and configurations

PART I

OneWorldExplained—

Inside and OutChapter 1 OneWorld Architectural

Theory and Configurations

Chapter 2 OneWorld Building Blocks

Chapter 3 OneWorld Explorer

Chapter 4 Flexibility and the Client

Chapter 5 OneWorld Servers

Chapter 6 Coexistence: The Best ofBoth Worlds

Chapter 7 OneWorld Tables

Chapter 8 Interactive and BatchApplications Defined

Chapter 9 OneWorld SpecialtyApplications

Chapter 10 Packages and Their Delivery

Chapter 11 Service Packs

Chapter 12 OneWorld Configuration

Case Studies

Edwards8 / J.D. Edwards OneWorld: The Complete Reference / Jacot, Miller & Stern / 2510-1 / Chapter 1Folio 1:1

P:\010Comp\Edwards\510-1\ch01.vpThursday, November 09, 2000 5:20:35 PM

Color profile: Generic CMYK printer profileComposite Default screen

CHAPTER 1

OneWorldArchitectural Theory

and ConfigurationsFrom Objects to Enterprise: Flexibility in

Meeting Your Business Needs

Configurations Defined

Determining Which Architecture Best FitsYour Business

Standard Out-of-the-Box Configurations




OneWorld architecture is about one thing, and one thing only. It is about a

software that is so flexible it becomes part of the solution instead of the

problem. How many other ERP software packages can say the same? The

OneWorld architecture allows you to pick and choose hardware and software

solutions that meet your immediate needs while still providing the flexibility and

forethought to allow you to change those decisions. If you outgrow your solution,

or when new architectures become available or desirable, you can bet that with the

OneWorld product it’s easy for your organization to exploit those changes while not

throwing away the investment you’ve already made.

This chapter covers the various architectures available to the OneWorld product in the

following sections:

● From Objects to enterprise: Flexibility in meeting business needs

● Configurations defined: two-tier, three-tier, and N-tier

● Determining which architecture fits your business needs

● Standard “out-of-the-box” configurations

From Objects to Enterprise: Flexibility inMeeting Your Business NeedsThe OneWorld product is a robust software package with unparalleled flexibility and

scalability. Although many people have questioned this statement, we think that this

chapter proves the flexibility of this product. Once you understand the options that are

available in OneWorld, we think you’ll agree that this product is easily one of the most

powerful on the market.

OneWorld is an object-based product. To understand its flexibility, it helps to

understand its base architecture. When you look at a OneWorld screen, just about

everything you see is an object—including the OneWorld Explorer, the application,

and the database tables.

A OneWorld object is any reusable entity based on the OneWorld toolset. We use a

rule of thumb when trying to decide what is and what isn’t an object: Everything other

than business data is an object.

All objects start on the deployment server. They may not stay there, but we initially

put them there. In most companies using OneWorld, the true “master” objects never

4 J.D. Edwards OneWorld: The Complete Reference




OneW

orldExplained—

Insideand

Out

leave this location. (For more information about the deployment server, refer to

Chapter 5.)

Logic objects are deployed throughout the enterprise using compiled software

packages. They show up as replicated objects on application servers and workstations.

Because of the OneWorld toolset, developers are insulated against platform-specific

programming. That means if you develop a piece of logic (maybe a business function

designed to verify customer data in a custom EDI cross-reference table), you can

transfer and compile this logic on the AS/400 and Windows NT Intel machines, a

UNIX box, or a workstation without having to modify the code, providing both power

and flexibility to meet your business needs.

In addition, OneWorld specifically uses an architecture designed to allow your

organization the ability to decide where data resides and where to process logic. You’ll

be pleased to encounter the Object Configuration Manager (OCM). This product

enables the OneWorld architecture to leap-frog ahead of its competition. Let’s take an

absolutely crazy scenario; suppose you wanted to dedicate an entire server to each

table within the production environment. By using the OCM, not only could you do

so, but the user really wouldn’t realize that you’d done this. As far as the user is

concerned, the product would continue to work as it normally did. (Refer to Chapter 2

for more information on the OCM.)

Though the phrase is no longer used by J.D. Edwards personnel, we refer to the

previously described process as masking complexity. Masking complexity means that the

user doesn’t know where the logic is processed or where the data is stored. You can even

mix and match hardware and database platforms without bothering the production user

with the details. This allows you to leverage existing hardware and software and still not

be tied to it. Consequently, you can continue to use the latest in technology advances.

You also can leverage existing IT experience as well as any experience you might acquire.

And the benefits of masking complexity don’t stop there.

Suppose your users are continually launching huge, resource sucking universal

batch engines (UBEs), which are OneWorld reports, on your production server. You

know the type we mean—those 500-page detailed reports that they claim they read.

What can you do architecturally to solve this problem?

Using ActivEra, you can add a departmental server for this particular group. Based

on their business reporting requirements, you can even set up a special reporting

environment using replicated data and a separate network segment to fully isolate the

network traffic, database requirements, and processing time. How is that for an

architectural solution?

Chapter 1: OneWorld Architectural Theory and Configurations 5






Flexibility to ScaleAs you can see from the preceding discussion, OneWorld quickly scales to meet

your company’s processing and data requirements. OneWorld is able to work with

most new technologies including network disk arrays, clustering technologies,

and Windows Terminal Server capabilities. Your organization can utilize fully

redundant systems, LANs, WANs, virtual private networks (VPNs), and so on for

communication purposes. It really is that simple. Let’s look again at the solution of

adding a departmental logic processing server (also referred to as an application server,

see Chapter 5) to offload some UBE processing. Can you believe that the process of

offloading some UBE processes can take less than a day? That’s about what it should

take to install and begin using a new application server.

N O T E

The preceding time estimate assumes the server’s hardware, OS, and anydatabase requirements are already installed and configured. It also assumesthat the Configurable Network Computing (CNC) personnel are experienced.

Configurations DefinedTo better understand the possible configurations, we need to define a number of terms:

● Server A machine that processes service requests. These requests can be for

data, logic processing, data replication, or even security.

● Workstation A machine within the OneWorld system that makes requests for

services. It acts as the primary interface between the end user and the application.

● Client/server architecture A system design that specifically uses both servers

and workstations to optimally spread workload requirements, utilizing each

machine type to perform specific functions they are most suited to accomplish.

● Two-tier architecture An enterprise design where a primary logic server

works directly with the client workstations.

● Three-tier architecture An enterprise design using two servers for data and

processing functionality in addition to workstations. Each machine provides

specific logic functionality.



OneW

orldExplained—

Insideand

Out

● N-tier architecture An enterprise solution using three or more logic

processing servers in conjunction with workstations to run a specific

application. In essence, the architecture allows you to continue adding

servers until the desired performance level is achieved.

● Virtual three-tier architecture A souped-up two-tier architecture with

selected application logic running on the server. Although the term has only

recently been coined, configurability for this solution has been around since

1997 and supported by J.D. Edwards since 1998.

Now that we have defined some basic terms, let’s go into detail on the actual

architectural designs. For information on how to set up these configurations, refer to

other chapters in this book or in the documentation provided by J.D. Edwards.

Two-Tier ArchitectureThe majority of small implementations utilize this basic configuration. It is shown in

Figure 1-1. Notice that a single, primary logic/data server directly works in conjunction

with workstations.



FIGURE 1-1. The two-tier architecture, a typical configuration



In a two-tier configuration, the workstation performs all interactive application

logic and provides database functionality for a total of six tables. These tables include

user-defined code (UDCs) and menus. Workstations also have the ability to run batch

application logic by overriding the submission location at the time of the UBE

submission. The server provides the primary database functionality (the B733.2 version

includes over 1,600 business data tables, over 100 system tables, over 20 central object

tables, and over 40 control tables). This server provides data replication, software

packaging, and security services. It is also the primary UBE batch logic process server

(refer to Table 1-1).

In the third quarter of 1998, J.D. Edwards announced support for Microsoft

Windows Terminal Server (as of B732.1 SP 9). This new technology allows multiple

users to run remote Windows sessions from local workstations on the same server. It

provides fast connections and centralized administration, but most people assume

adding one of these servers automatically provides a three-tier architecture. Actually,

unless specifically configured, just adding Terminal Servers is really no different from a

traditional two-tier configuration using new technologies. When you run the

OneWorld suite on a Terminal Server, that Terminal Server is actually the workstation,

and the server is still the primary data and logic server on the enterprise, as shown in

Figure 1-2.



Application Logic Batch Logic Database Services Other Services

Server None Primary location Primary location Security

Replication

Packages

Workstation Primary location Secondary location Secondary(replicated only)

None

TABLE 1-1. Logic Services



OneW

orldExplained—

Insideand

Out



Three-Tier ArchitectureThe use of the Windows Terminal Server popularized both three-tier and N-tier

architectures. In essence, a three-tier architectural design has more than one server

providing logic services, as shown in Figure 1-3. People implementing OneWorld with

a Windows Terminal Server quickly determined that offloading certain interactive

application logic enables cost-effective hardware, system, and user configurations.

Applications run faster, and the companies achieved a higher user-to-server ratio.

This same configuration is usable without Terminal Servers. However, unless you can

justify the purchase of an application server by increased user performance, it is rarely

FIGURE 1-2. Windows Terminal Server two-tier architecture





worthwhile. Instead, three-tier architectures are deployed more often to offload nightly

processing and specific departmental or location requirements when Terminal Servers

are not in use (see Figure 1-4 and Table 1-2).

Virtual Three-Tier SolutionsWe’ve recently seen virtual three-tier solutions advertised. They are actually two-tier

solutions with distributed interactive application processing (refer to Table 1-3). This

configuration can substantially increase the speed of workstations. If your enterprise

server is beefy enough to support the additional logic processing requirements, we

highly recommend it. Any of the supported server configurations can function in this

capacity. However, you need to carefully decide which business functions (BSFNs) to

run on the server. Data corruption problems can occur if you don’t include everything

you’re suppose to. Additionally, some logic is designed to work on workstations only.

FIGURE 1-3. Three-tier Terminal Server solution



OneW

orldExplained—

Insideand

Out



FIGURE 1-4. Three-tier departmental architecture

ApplicationLogic Batch Logic Database Services Other Services

Enterprise Server None Primary location Primary location Security

Replication

Packages

Workstation Default location Tertiary location Secondary(replicated only)

None

Application server Selected logic Secondary location

Database server None None Secondary (realor replicated)

None

TABLE 1-2. Three-Tier Software Configurations



You may be wondering why you would want (or need) to look at an architecture

similar to the virtual three-tier solution (see Figure 1-5). It is the fastest configuration

currently designed for use with OneWorld. The closer the logic is to the data, the faster

the logic can be performed, which is especially true when you can run at BUS speed

with minimal latency as opposed to LAN or WAN speed. OneWorld has message-based

communications. These are substantially faster when performed on the enterprise

server. The logic request is made locally, the data is provided locally, the logic is



Application Logic Batch Logic Database Services Other Services

Enterprise server Selected logic Primary location Primary location Security

Replication

Packages

Workstation Default location Secondary location Secondary(replicated only)

None

TABLE 1-3. Virtual three-tier software setup

FIGURE 1-5. Virtual three-tier architecture



OneW

orldExplained—

Insideand

Out

performed locally, and results are posted locally. The only external requirement is a

screen refresh with the results.

N-Tier SolutionBased on your business requirements, you can configure and distribute logic and data

processing throughout your enterprise solution. The OneWorld product masks the

complexity caused by differences between hardware platforms and database formats.

This allows full functionality and scalability in designing and implementing your

enterprise architecture.

N-tier solutions combine workstations, any number of logic servers, and any

number of database servers into a single solution (see Table 1-4). As your company’s

needs grow through merger, acquisition, and other changes, you will be able to move

data and logic processing at will, providing superior functionality and speed to the user.

Thin-Client ArchitectureThin clients are traditional file allocation table (FAT) client workstations or actual

WinTerm devices that run the Windows Terminal Server software. The Terminal

Server software enables multiple users to share the same application, running on the

same server. Zero clients, on the other hand, are clients workstations that have a Web

browser and access the OneWorld product through HTML and Java applications (refer

to Figure 1-6 for an example of multiple architectural configurations).



ApplicationLogic Batch Logic

DatabaseServices Other Services

Enterprise server None Primary location Primary location Security

Replication

Packages

Workstation Default location Tertiary location Secondary (replicatedonly)

None

Application server Selected logic Secondary location

Database server None None Secondary (realor replicated)

None

TABLE 1-4. N-Tier Software Setup





FIG

URE

1-6.

Wid

e-op

enar

chit

ectu

re



OneW

orldExplained—

Insideand

Out

Determining Which Architecture Best FitsYour BusinessEvery company is unique, and thus, it is almost impossible to determine in a book

exactly what your company’s architecture should be. In addition, because of the rapid

rate of technological growth, you may start with one architectural design and end up

with an entirely different one. This consideration is important, especially if you are in

either the sales cycle or the initial scoping and planning phase of an implementation.

The fact that you may not end up with the same architecture that you start with

indicates the power of the J.D. Edwards OneWorld enterprise resource planning (ERP)

suite. OneWorld supports many different architectures and is continually improving to

support more. As new technologies are introduced to the marketplace, OneWorld

adjusts to embrace them as well. OneWorld’s architectural diversity enables your

organization to grow without being bound by the technology supporting it. OneWorld

is specifically designed to allow rapid changes even after go-live, which is the premise

of ActivEra.

Many different questions must be answered prior to deciding exactly what

architecture best suits your organization.

Are You Running J.D. Edwards World Product?The use of the World product gives rise to questions about coexistence and

hardware/software platforms. If you are running World, your data conversion efforts

should be significantly decreased. If you decide to run coexistence, then there are no

conversions required. In addition, the fact that you are running the World product

means that either you have in-house AS/400 experience or you have an existing service

arrangement with someone who does. You have the option of using other platforms

either with or in lieu of the AS/400 platform. You can start with AS/400 running in

a coexistence strategy, then migrate to an AS/400 database server solution, and

eventually end up without AS/400 entirely.







D E F I N I T I O N

Coexistence: Coexistence is the ability of the J.D. Edwards OneWorld andWorld software products to share business data. If you make a change to datain the World software, you can see this change in the OneWorld software, andvice versa.

N O T E

World and OneWorld have several modules that are not coexistent, includingaccounts receivable, human resources, and the real estate module. Other itemsthat are not coexistent include security, users, data dictionary, and development.

Is Your Organization Global?If you work for a global organization, speed at remote sites is a significant

consideration. Using data replication can solve some WAN speed issues. However,

data replication cannot address this problem nearly as well as either thin clients with

Microsoft Terminal Server or an HTML/Java zero client. If you have remote sites that

do significant volumes of work (for example, sales order entry), you should consider

methods of either distributing the data or centralizing the processing.

Do You Support Double-Byte Languages?Although double-byte languages are supported by J.D. Edwards, they may ultimately

accommodate different architectural solutions over organizations supporting

single-byte languages. The greater the number of double-byte languages supported,

the greater the architectural diversity within the system. Using the B733.2 version

of OneWorld, you can support only a single double-byte language per database. In

addition, although single-byte data and double-byte data can be maintained in the

same database, data corruption could result if the records were updated by nonlike

systems. If this is the case, you might decide to separate the systems geographically as

well as separating the hardware. Centralized and decentralized configurations provide

different user support options.

What Is Your Current IT Staff’s Skill Set?The skill level of your IT staff is important not only for hardware selection but also

for diversification in location and support options. For example, an organization that



OneW

orldExplained—

Insideand

Out

implements a decentralized database solution has remote locations set up with data

replication and location servers. If the remote site has a SQL DBA, it encourages them

to use SQL Server as that location’s database. If the home office has an Oracle DBA,

however, it encourages them to use Oracle as the primary solution. You may be

wondering how an architecture like this could work. Data replication within OneWorld

uses a unique set of tables that are not platform specific, which means your IT staff’s

current skill set will be sufficient.

The level of your current IT skill set may also determine the platforms you choose.

An organization we’re acquainted with initially used Windows NT with Oracle even

though their DBA was an UNIX/Oracle DBA. The Windows NT/Oracle side of their

system was not set up well, and after a few unpleasant episodes, the organization

changed its hardware platform. If they had considered their staff’s skills in the first

place, they could have avoided both the problems and the change.

Are You Going to Buy the Skills or Grow the Skills?The level of complexity that you can achieve in your architectural design is based

on the skills of your IT staff. Organizations that are self-reliant (that is, they don’t

outsource their setup and maintenance to third-party implementers) should probably

look for relatively simple solutions. This is especially the case if your organization has

decided to grow its skill set rather than buy it on the open market.

Although not many highly skilled JDE Technology consultants are available, some

are in the marketplace. If they are talented, they will cost your company $120,000

to $175,000 per year, assuming you don’t have to relocate them. If you do relocate

them, you can expect to pay in excess of $200,000 the first year, which is definitely

not a cheap proposition. If your implementation is large, these individuals can be the

difference between being successful and failing.

What Are the Details of Your Development?First, not all implementations perform customization of the software for business

objectives. Second, if your organization chooses to engage in specific application

development, you won’t necessarily change your architectural design. Finally, depending

on your organizational layout, the requirement for remote development can change

your overall near- and far-term architecture. Managing this entire system is important

and can make a difference in overall performance, as well as time-to-completion.

If you are developing, testing, and finalizing application customizations and system

integration remotely, significant time can be wasted if the development path code is







located across a WAN. It is far better to define local path codes and environments in

decentralized development architectures. Over one and a half hours can be spent

checking a single application into remotely located path code within the continental

United States. If your development efforts extend beyond those boundaries, you can

encounter additional difficulties based on international considerations.

The versatility and ability of the OneWorld product to support multiple

architectural configurations doesn’t stop with the hardware and software design,

configuration, and deployment. Rather, the philosophy that the OneWorld product

is part of your solution—and not your problem—is embodied throughout its design.

Because many organizations have specific business requirements not addressed by the

application suite, J.D. Edwards incorporates a robust development toolset designed to

facilitate easy, quick modifications that can migrate with the multiple releases of the

product itself. This value-added ability allows organizations to receive a rapid return

on their investment.

What Is Your Organizational Requirement forTime Online, Redundancy, and Failover?Based on your company’s uptime requirements (24x7, 12x5, and so on), you may need

to change your architectural design. You might also have to design redundant systems

at remote locations, which, while it isn’t a difficult task, is something that should be

taken into consideration. In addition, uptime requirements and backup criteria may

add additional hardware and software needs. The only limitation to what you are able

to do in this arena is money.

Making Sense of It AllLet’s try to gain some answers out of the questions we’ve just reviewed. If you are

running J.D. Edwards World product, you should seriously consider coexistence.

Although this solution isn’t appropriate for all companies, you should consider both

the advantages and disadvantages of this particular strategy. This decision will push you

toward the AS/400 and will limit the amount of data you need to convert. Understanding

languages, globalization, and IT skill sets enables you to decide about centralized and

decentralized processing, data, and support. Understanding your current systems

and infrastructure help in making this decision. If you know the scope of your



OneW

orldExplained—

Insideand

Out



implementation and the system requirements up front, you can plan your systems

with much greater authority. If you have questions on the best methods of designing

your OneWorld architecture, we recommend that you research the product (and

the fact that you are reading this book is the first step) and contact a consulting

organization with proven experience in this area. It is better to spend the money

getting the experience on loan than trying to figure it out on your own.

Standard Out-of-the-Box ConfigurationsSome people laugh when they hear that there is such a thing as a standard configuration.

With a product as versatile and flexible as OneWorld, not many clients retain the

standard configuration; however, understanding a typical configuration is useful. The

more you document and understand the changes to your system, the greater the

opportunity you will have to determine the source when a problem arises. To help you

solve potential problems, the following sections describe what OneWorld looks like

straight out of the box. Our discussion will focus on the simplest of configurations with

absolutely no architectural oddities.

More Details and DefinitionsMany of the specific OneWorld topics covered in this and the following sections are

described in detail throughout various chapters in this book. We understand that the

information in the following sections may be overwhelming, so we recommend that

you come back to this chapter as often as you’d like. Here are some very brief

definitions that pertain to our discussion:

● Data source A pointer to specific data or specific machines that performs logic

processing in OneWorld.

● Path code A combination of central object specifications and a directory

structure containing application C code.

● OCM The Object Configuration Manager is a utility within the OneWorld

system that enables you to specify where data resides or where to process logic.

● Environment A combination of path code and OCM mappings indicating

where to find data and logic processing machines.



As explained earlier, the OneWorld product has a two-tier architecture under a

typical or standard installation. The installation itself contains elements including a

deployment server, an enterprise server, and client workstations. Refer to the grid in

Figure 1-7 for a graphic representation of data sources, environments, and path codes

associated with the typical configuration.



FIGURE 1-7. Typical OneWorld data sources



OneW

orldExplained—

Insideand

Out



Making Sense of a Typical ConfigurationThe information provided in the grid in Figure 1-7 includes interesting architectural

information in addition to showing you the actual setup and naming conventions.

There are some peculiarities to the naming conventions. Let’s take the PRD733

(production) environment as an example of a typical environment. Five data sources

are uniquely associated with this environment:

● Business Data – PROD

● Control Tables – Prod

● Central Objects – PRODB733

● Versions – PRODB733

● OneWorld Local – PRODB733

Notice the case used in the preceding list. While databases should be configured

in such a way as to make them case insensitive, the OneWorld data source names are

both case and space sensitive, and the typical naming convention is exact. In the

business data, data source, there are 1,616 environment-specific tables; the control

tables include 47, the central objects have 23, versions have 1, and OneWorld local

has 6. Most environment configurations follow this lead.

N O T E

A typical customer configuration is what would be installed straight out of theJ.D. Edwards package with no CNC modifications.

PristineThe greatest exception to the naming convention rules is the pristine environment.

PRT733 doesn’t have an associated control tables data source. This situation will

be rectified in OneWorld Xe (formerly B733.3), which has the data source Control

Tables – JDE. These tables are wrapped into the business data in earlier versions of

the software. Another abnormality is that the business data, data source doesn’t follow

the standard naming convention. One would normally anticipate that this data source

would have a name such as “Business Data – PRIST.” Instead, the name for this data



is “Business Data – JDE” to clearly indicate that PRT733 has JDE demonstration data

instead of being populated with customer-specific information. Having both business

data and control tables in the same data source also means you have the same number

of tables as production’s data sources combined—1,676.

What About CRP733, TST733, and DEV733?Take another quick look through the list of typical data sources shown in Figure 1-7.

You don’t see either a Business Data – DEV or a Central Objects – TESTB733. J.D.

Edwards intentionally put all of the elements necessary to work with their development

methodology in the typical customer configuration. The development environment

uses test’s business data. The test environment is associated with the CRPB733 path

code. This enables customers to develop objects in the development environment,

transfer them to the CRP path code, and then test them in the TST733 environment.

One of the most important pieces of this development methodology is that the

development and testing environments share the same business data and control

tables. This minimizes perceived errors in developed code based on data alone. If

errors exist, these errors must be based in the object’s path code promotion (that is,

you forgot to transfer necessary objects or you didn’t have sufficient rights to the target

directory), the package building processes (a method of deploying software throughout

the enterprise), or in the code itself (your developer just didn’t do it right).

Data Sources, Path Codes, and Environments—Oh My!Under a typical configuration, J.D. Edwards delivers four path codes: PRODB733,

CRPB733, DEVB733, and PRISTB733. These path codes deliver five environments:

PRD733, CRP733, DEV733, TST733, and PRT733.

N O T E

In a typical customer installation, J.D. Edwards actually delivers sevenenvironments. They include the previously listed five plus the DEPB733 andJDEPLAN environments. These other two environments, however, are usedonly when installing or configuring the OneWorld product. These environmentsare usable only on the deployment server and do not have deploymentpackages associated with them.





OneW

orldExplained—

Insideand

Out

What About the AS/400?The AS/400 in a typical customer configuration adds additional data sources,

but there isn’t any difference in the setup of the architecture, the path codes, or the

environments themselves. The additional data sources are based on the requirement

of the AS/400 for translation and not translating into and out of its native EBCDIC

format. These data sources usually have a “ – DNT” after the normal naming

convention (for example, “System – B733 – DNT”). This data source does not translate

from EBCDIC whereas its corresponding System - B733 data source does. Although the

names of the data sources differ, there isn’t a difference in how the OneWorld data

sources themselves are set up. What makes these data sources different is their

corresponding Open Database Connectivity (ODBC) setup. When setting up Client

Access ODBC, you have the option of translating the data.

N O T E

If you incorrectly configure an AS/400 data source for translation, OneWorldprovides a nice little error indicating that the data source was not properly set upthe first time that the data source was used to extract data from AS/400.

SummaryWe’ve described the various architectures available in OneWorld. We’ve provided

enough information so that, as your experience grows with the product, you can

creatively use it as you need to. We’ve even discussed some considerations that will

determine the architecture and configurations you should employ. Other chapters that

will increase your ability to understand and work with the overall architecture include

Chapters 2, 4, and 5. When you combine those chapters with what you’ve learned

here, you will begin to see not only the power of the OneWorld product but how it

can solve your business requirements.





oneworld architectural theory and configurations

Documents