? erpSourcing. All Rights Reserved October 2000

OneWorld Xe ESU Update Procedures

Technology Demographic Table

Product OneWorld

Version Xe

Platform/OS HP 9000

Industry All

Application All

Database Oracle

Keywords Update, Help, ESU, Oracle8,Xe

Date April 2001

@ WORK SERIESHands-on OneWorld Documentation

-

OneWorld Xe Page 2

OneWorld Xe Upgrade Procedure Plan

Disclaimer

All information contained in this document should be treated as a hypothetical project plan. It is often the case that with upgrades to production and development objects, that there are issues that will be raised. This will therefore dramatically increase project timelines.

None of the entries in this document are in any way a replacement for the JDEdwards OneWorld Xe Upgrade Guide – instead, this document should be treated as a complement.

Overview

OneWorld is a constantly changing product. It is a major reason for choosing JD Edwards above other solutions, since large samples of users worldwide constantly improve both the functionality and stability of the product.

However, it is not reasonable to expect users to undertake a full “upgrade procedure” each and every modification that occurs to OneWorld globally. Instead, individual “patches” should be applied if issues arise. This, of course, means that the JD Edwards customers are never identical. The OneWorld ERP System can be analogized as something akin to an Operating System that differs between users with Device Drivers and applications – as soon as the Operating System is Used it changes.

Because OneWorld is not specifically a Distribution System, Financial System or Manufacturing System but is a Toolset which has been used to create Distribution, Financial and Manufacturing applications – users need to be kept appraised of any fixes in code.

The central “foundation” of JD Edwards OneWorld – ie the toolset – is kept up to date using service packs. The foundation can not be changed by users – and is held in the “SYSTEM” directory of the workstations and servers that JD Edwards OneWorld is deployed to. Service Packs are relatively easy to deploy and ensure that functionality and issues are kept up to date.

The applications that JD Edwards provides with OneWorld are used in several different ways by JD Edwards Customers :

??Customers who run “out of the box”

??Customers who run any JDE application “out of the box” and only create custom applications

??Customers who customize JDE Applications as well as create custom applications

Neither of the above are “right” or “wrong” ways of running an enterprise system – but it is important to note that the flexibility of the toolset in OneWorld allows for the customer to choose the direction of their development.

Lastly, and most importantly, it is important to only apply ESU’s (Electronic Software Updates – programs that fix issues in JDE Products) only when an issue arises that is confirmed fixable by said ESU. Product updates and upgrades should certainly be applied eventually – but only if time and resources allow.

Out of the box customers

If a customer performs very little development – ie runs OneWorld “out of the box” – then this is the easiest upgrade path since the applications they use can be replaced without worry and tested prior to moving live. No retrofit is necessary – but unfortunately the customer is at the

-

OneWorld Xe Page 3

OneWorld Xe Upgrade Procedure Plan

whim of only using JD Edwards functionality – even though that functionality performs badly for the way that the user runs their business.

In the real world, most JD Edwards customers can run Financials with minimal application modifications – and a large number of JD Edwards customers can run Distribution the same way. It is estimated that 55-60% of OneWorld users run this way.

Custom Application Customers

This method of running OneWorld minimizes the application development that occurs on JD Edwards standard applications by creating copies of existing applications and then modifying those copies. This means that if a customer decides they wish to change the Sales Order Entry program – they would need to copy the SOE application to a custom system code (a “55” or “56” system code) and make changes to the copy.

If JD Edwards provides electronic updates or an upgrade – none of the custom code is touched by the update procedure. This will mean that if a user has copied, for example, Sales Order Entry to make changes – and a fix is provided to replace the original SOE application – then that fix will not appear in the custom application. Of course, the developer of the custom version may already have fixed any SOE issues that were there before.

It is important to note, however, that Custom Applications often are created based on existing application logic. Hence, the Sales Order Entry Application example is unlikely to have all of the lower logic copied to custom system codes. This would mean that any ESU on the Sales Order Entry Master Business Function (B4200310) or any subfunction would therefore drastically alter the logic and therefore the way that the application runs.

There are customers that create new applications from scratch – for example, one customer developed an insurance quotation application from the ground up – loosely basing some of the logic on existing JD Edwards applications – but realistically creating the application from the very ground up.

There are very few customers that have achieved complete autonomy from JD Edwards business applications – the application of ESU’s for these customers produce minimal impact.

Customized JDE Application Customers

One of the selling points of JD Edwards OneWorld above all other ERP Systems is the ability to change the software in line with the customers business. This methodology has been named “Activera” by JD Edwards – and certainly provides one of the strongest selling points of OneWorld.

Usually, “Activera” refers to the ability of users of the OneWorld product to change processing options and versions of software at runtime to provide functionality matching their business. However, often as not the requirement to completely change a specific module one way or another is required – by adding functionality to a Sales Order Entry screen or by changing a standard JD Edwards report to reflect custom data fields.

This type of modification comes relatively easy – a lot easier than having to develop an entire custom application suite – and often customers can create hundreds – if not thousands – of custom changes to applications. However, when the customer comes to upgrade or update these applications – it is often evident that the upgrade process will be slow and painful since most of the custom development will require retrofitting and extreme testing.

-

OneWorld Xe Page 4

OneWorld Xe Upgrade Procedure Plan

Typicially, customers will customize JD Edwards OneWorld applications initially – until the time that an upgrade is required. Often, the pain of the retrofit process will force customers into eliminating certain types of modifications – or will make copies of the custom applications under custom system codes.

How the code is stored

Contrary to popular opinion, most of the JD Edwards OneWorld “code” is not stored at the Deployment Server. Instead, we must re-evaluate how a pathcode is set up and is used.

OneWorld uses a “Pathcode” as a pointer to where the code is stored and run from. Objects (ie programs, tables, rules) are held two different formats – Runtime objects and Centrally stored objects. A pathcode “name” reflects the use of the code – for example, Pristine, Development, Prototype or Production (JD7333, DV7333, PY7333 and PD7333). This name points to the various places that OneWorld requires to access the code.

Source code (or Central Objects) is NEVER run at runtime. The objects are held at the database level (in a Datasource called “Central Objects”) and on the Deployment Server in a directory named after the pathcode name. It is important to note that only Business Function ‘C’ code is stored on the Deployment Server – along with several resource files. The majority of OneWorld’s code is held at the database level in several tables. Most of the code is held as a “BLOB” (Binary Large Object).

The Runtime code is converted from the source code. For the Business Functions – these are obviously .DLL’s (Dynamic Link Libraries). Almost all of the database “sourcecode” is converted to JD Edwards proprietary “TAM” files (Table Access Management) a much faster, indexed flat file format. These are converted from the Relational Database files to the respective TAM files.

The process of moving Source code to Runtime code is termed as a package build. As such, packages are “snapshots” in time of code. A developer changes the Central Objects – and these are not accessible by end users until the CNC Administrator first Builds the code into a Package – then Deploys the package.

As such, because of the nature of how the code is stored, JD Edwards does not have a method of version control. That is there is no way to take an object – say P4210 – and hold various versions of that object whilst in development. In the Development pathcode, there is only one “P4210” object – with many, many different Event Rules and Form objects stored at the database level. It is assumed that in the future, JD Edwards will provide an ability to store various versions whilst the object is being developed – such like Sourcesafe provides to Microsoft toolsets – and the “Save” button that has appeared in the JD Edwards Object Management Workbench is a step in this direction. However, it is imperative to stress both to CNC Administrators, Developers and Project Managers that JD Edwards OneWorld does not have version control.

What is Pristine Code

Traditionally, JD Edwards World RPG code would have a “Pristine” and a “Custom” codeset. Pristine was untouched by customers – and the code would usually look to see if a custom object existed – and if not, then the pristine object would be run. However, being a completely different architecture – OneWorld code is stored completely differently as discussed previously. As such, a “Pristine” pathcode is laid down but is rarely run at all – JD Edwards requires a “Pristine” Environment so that they can test whether or not an issue is due to bad coding or bad data. However, because it is so difficult to test whether or not an issue is reproducible because it works in “Pristine” – it often means that the Pristine codeset is all but

-

OneWorld Xe Page 5

OneWorld Xe Upgrade Procedure Plan

useless. An issue may exist in a modified object, bad data, bad data selection, bad version or even bad processing options. It is often argued that JD Edwards uses pristine only to confirm that an issue does not affect a majority of users – which can also be incorrect.

Therefore, Pristine is rarely used. However, it is used in an upgrade – and we also take advantage of this pathcode in the application of ESU’s

What is an ESU ?

The “Electronic Software Update” (ESU) is a replacement for a paper based process that was important for most JD Edwards customers. The “Paper Fix” process was available to customers to be able to immediately solve issues with certain applications behaving differently from expected parameters. Often bugs and issues would arise in JD Edwards code – and the paper-fix process was an immediate ability for most trained OneWorld implementers to apply changes to the code. However, because the code was written on paper – and therefore had to be TYPED into JD Edwards OneWorld – spelling mistakes and issues would arise from the paper-fixes themselves. To reduce the chance that the code was improperly entered – JD Edwards decided to provide electronic versions of these paper fixes that would merge into the OneWorld code.

A Paper Fix was indexed using a JD Edwards SAR (Software Action Request) number. This SAR number was linked to any JD Edwards support calls at the Response Line level.

Although there are a number of positive reasons for ESU’s - there are several drawbacks to the ESU methodology that JD Edwards have not addressed :

1. Even though JD Edwards have created a new process that provides for them less chance that the code would be inadvertently entered incorrectly – to minimize the number of ESU’s, JD Edwards combine many hundreds of SAR’s into one ESU – thereby creating a situation where SAR’s that are not required are forced onto a user.

2. There is no documented methodology for implementing an ESU in a development environment. Although ESU’s do not affect custom code – they can overwrite or modify customized JD Edwards objects – or even affect objects that Custom code requires, thereby dramatically changing how the code works. JD Edwards methodology expects the customer – if requiring an ESU – to lay down the entire code and replace the JD Edwards objects contained in the ESU. As can be imagined, this causes considerable damage to customized Applications.

These two points are enough to force customers to wonder whether either they are correctly developing by customizing JD Edwards components – or whether the paper-fix system should be re-evaluated.

However, there is a method that by using the new Object Management Workbench can emulate the older paper-fix method and will reduce the impact of ESU’s.

-

OneWorld Xe Page 6

OneWorld Xe Upgrade Procedure Plan

The Object Management Workbench

JD Edwards introduced a new gateway to their toolset in OneWorld Xe called the Object Management Workbench (or OMW). Using process flows – it is now possible to limit how objects are manipulated in OneWorld and security can now be applied to certain roles.

The OMW, however, is really only a front to the old Object Librarian. The Object Librarian – before Xe – was the original gateway to the OneWorld toolset – and the interactive application allowed users to move objects freely between pathcodes.

As can be imagined – allowing developers access to transfer objects between pathcodes is relatively dangerous. By not having any specific audit available – objects were easily overwritten – and multiple developers were able to make changes to the same object.

It was apparent, therefore, that OneWorld required some tool to be able to completely control how development occurred on objects. It was decided that the OMW was to be Project based (rather than purely object based) - which suits most development based customers. Specific Process codes would therefore be associated with these projects, and users were then able to control who and when object transfers would occur.

The standard JD Edwards OneWorld Object Configuration Management ruleset gives an insight to a correct methodology – but no documentation exists that correctly shows how the tool should be used.

-

OneWorld Xe Page 7

OneWorld Xe Upgrade Procedure Plan

An example OMW Activity Ruleset

Activity rules define how a project moves objects between pathcodes – it is the replacement methodology for Object Transfer and provides administrators with in-depth logging and auditing as well as the possibility of securing the environment.

The activity rules are held in the User Defined Code table – H92/PS.

As can be seen with the table to the right – the standard set of activity rule UDC’s provide for a concise workflow.

The above diagram demonstrates the process flow for taking a project from creation through to completion. Note that the dotted lines are object transfers occurring with the pathcodes.

Note that we can create activity rules that allow for gets and check-in/check-out processes against differing pathcodes.

Code Description *ALL All01 Complete02 Returned for Clarification06 Returned -Already Reported08 Returned -Could not Duplicate09 Closed-No Further Action10 Refer to Parent SAR11 New Project Pending Review12 Reviewed by Customer Support13 Reserved by Software Devel.14 Reserved by Software Devel.15 Reserved by Software Devel.16 Reserved by Software Devel.17 Plan or Research18 Design19 Design Review20 Awaiting Staff21 Programming22 Programmer Test23 Manager Review24 Transfer to Production25 Rework-Same Issue26 QA Test/Review27 Rework-New Issue28 QA Test/Review Complete29 Demo Data2A Approved by CRB2C Waiting Programmer Check In2M Waiting Manager Approval2Q Waiting QA Manager Approval2W Waiting CRB Approval30 Ready for Transfer to Cum31 Returned -Not Planned35 Manager Review ESU36 ESU transfer to PRD37 Ready for ESU Build38 In Production39 To be reviewed with Users grou3P Pristine Updates-OMW40 Production Development41 Xfer Production to Prototype42 Xfer Prototype to Development45 Pristine Get90 Completed -Not Tested91 Cancelled Entered in Error99 CompletedMM Beta Testing-MASTERSMP Alpha Testing-MASTERS

New Project

11

New Project

11

Project Review

12

Project Review

12

Plan Project

17

Plan Project

17

Design Project

18

Design Project

18

Design Review

19

Design Review

19

Assign resource

20

Assign resource

20

In Development

21

In Development

21

Pristine Get

45

Pristine Get

45

Completed

22

Completed

22

Review

23

Review

23

Transfer to PY

24

Transfer to PY

24

Rework

25

Rework

25

Testing & QA

26

Testing & QA

26

New Issue

27

New Issue

27

QA Complete

28

QA Complete

28

Ready for PD

30

Ready for PD

30

In PROD

38

In PROD

38

COMPLETED

99

COMPLETED

99

LOCAL

JD7333JD7333

DV7333DV7333

DV7333DV7333 PY7333PY7333

DV7333DV7333

PY7333PY7333

PD7333PD7333

-

OneWorld Xe Page 8

OneWorld Xe Upgrade Procedure Plan

Setting up the Activity Rulesets

Even though the power of the Activity rulesets seems to be straightforward to set up – there is an issue that arises. A certain “checkpoint” in the OneWorld transfer process checks the date and time for objects prior to a transfer.

This means that even though the user is certain they wish to have an object transferred out of Pristine into Development to overwrite an object – the checkpoint will always thwart the user. Unfortunately, the only way to actually find the error – and thus to know that the object failed to transfer correctly – is through the OMW Audit Logs.

However – if an object is checked out to a development workstation (ie – merged into the local TAM file) then checked back in – it will always reflect the latest date.

Note, therefore, that to transfer an object from Pristine into Development – we have set up a ruleset that requires the user to check out an object from pristine locally – then check the object back into Development. These rules are actually relatively easy to set up and are extremely powerful indeed.

Example Activity Ruleset

For one customer – the ruleset is pretty similar as above with the exclusion of some of the project management activities prior to Development. The process allows for only Development Management to add projects and to assign resources to the project. It is possible to use the Pristine Get for both ESU’s and to restore objects back to Pristine status (Activity 45)

Once the development has been completed, the Developer marks the project as having been completed – which then passes back to the Development Management for review. Rule 23 is a simple marker that shows that the project has been completed, reviewed and is ready for Testing.

However, to ensure that not ALL projects are placed into Test immediately after development – a “24” status code is used to notify the CNC administration that the project is ready to be transferred. The object transfer then occurs at this point between Development and Prototype.

The project is then in test – and only two outcomes are possible – rework (any issue) and Pass. Once the project is marked as “28” then the CNC administration is notified that the objects are ready for Production (38). Finally, once objects are built and deployed – the CNC administration moves the Project 99.

Note that some security is used here to control where a project is allowed to move between departments – and that there is no “Deployment” activity rule since it is assumed that the

-

OneWorld Xe Page 9

OneWorld Xe Upgrade Procedure Plan

transfer will also follow up with a package build and deployment in the respective environments.

Activity ruleset 21 to 21

Here the Development occurs – the ruleset allows for any user to check in or check out objects between the development pathcode and the Local machine.

Activity Ruleset 24 to 26

The transfer between Development and Prototype (CRP) occurs at this activity rule. Note that to transfer objects between pathcodes like this, it is imperative to ensure that the objects being transferred have newer dates in the source location (DV7333) than the destination (PY7333) – so it might be necessary to check out all objects in the project in status 21 and check them back in again. Note also that with a transfer between pathcodes, it is possible to mark rules as mandatory and also to distinguish whether or not to drop tokens on the objects.

User Object Type From Location To LocationFrom

ReleaseTo

Release

Allowed

Action Description*PUBLIC APPL LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC APPLVER LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC BSFN LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC BSVW LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC DSTR LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC GT LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC TBLE LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC UBE LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC UBEVER LOCAL DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC UO LOCAL Central Objects - DV7333 B7333 B7333 03 Transfer or Delete*PUBLIC APPL LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC APPLVER LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC BL LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC BSFN LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC BSVW LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC DSTR LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC GT LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC TBLE LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC UBE LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC UBEVER LOCAL DV7333 B7333 B7333 04 Check-In*PUBLIC UO LOCAL Central Objects - DV7333 B7333 B7333 04 Check-In*PUBLIC APPL DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC APPLVER DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BL DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSFN DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSVW DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC DSTR DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC GT DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC TBLE DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBE DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBEVER DV7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UO Central Objects - DV7333 LOCAL B7333 B7333 05 Check-Out / Get

UserObject Type From Location To Location

From Release

To Release

Release Token

Allowed Action Description

Mandatory Flag

*PUBLIC APPL DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC APPLVER DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC BSFN DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC BSVW DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC DSTR DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC GT DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC MENU Control Tables - DEV Control Tables - CRP B7333 B7333 0 03 Transfer or Delete 1*PUBLIC TBLE DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC UBE DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC UBEVER DV7333 PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC UDC Control Tables - DEV Control Tables - CRP B7333 B7333 0 03 Transfer or Delete 1*PUBLIC UO Central Objects - DV7333 Central Objects - PY7333 B7333 B7333 0 03 Transfer or Delete 1*PUBLIC WF Central Objects - DV7333 Central Objects - PY7333 B7333 B7333 0 03 Transfer or Delete 1

-

OneWorld Xe Page 10

OneWorld Xe Upgrade Procedure Plan

Activity Ruleset 26 to 26

This is an interesting set of rules – here the customer is allowing users to check out objects in the Prototype environment but not allow them to check them in. This is an unusual but extremely safe activity rule set, since it would allow the testing team install applications into PY7333 without necessarily going through a package build – but will not allow them to make changes in Prototype and thereby bypass the Development environment. By allowing them to check out objects in PY7333 – it is also possible to view the objects individually to ensure that changes correctly came across from DV7333 to PY7333 without the danger of uploading changes.

Activity Ruleset 28 to 38

The final ruleset prior to completion allows the users to move the objects from CRP over to PD7333 (Production). This process releases all tokens if successful.

User Object Type From Location To LocationFrom

ReleaseTo

ReleaseAllowed Action Description

*PUBLIC APPL PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC APPLVER PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSFN PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSVW PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC DSTR PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC GT PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC TBLE PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBE PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBEVER PY7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UO Central Objects - PY7333 LOCAL B7333 B7333 05 Check-Out / Get

UserObject Type From Location To Location

From Release

To Release

Release Token

Allowed Action Description

Mandatory Flag

*PUBLIC APPL PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC APPLVER PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC BSFN PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC BSVW PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC DSTR PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC GT PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC MENU Control Tables - CRP Control Tables - Prod B7333 B7333 1 03 Transfer or Delete 1*PUBLIC TBLE PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC UBE PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC UBEVER PY7333 PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC UDC Control Tables - CRP Control Tables - Prod B7333 B7333 1 03 Transfer or Delete 1*PUBLIC UO Central Objects - PY7333 Central Objects - PD7333 B7333 B7333 1 03 Transfer or Delete 1*PUBLIC WF Control Tables - CRP Control Tables - Prod B7333 B7333 1 03 Transfer or Delete 1

-

OneWorld Xe Page 11

OneWorld Xe Upgrade Procedure Plan

Activity Ruleset 45 to 45

This final set of rules is the key to the retrofit of ESU’s process. Here we can see that the rules are set up for users to be able to check OUT objects from Pristine to their local workstation – and check IN the object to Development. Note that only SUPERUSER is able to perform this check-in operation (whereas Developers can check out) since by transferring the objects in this manner, it can be confusing for those who do not realize that Check IN will actually overwrite development code. By forcing the only method of transfer via the users workstation (LOCAL) – this will force the updated time and date to the current date and time.

Easy ESU retrofitting

As has been mentioned before, the fact that OneWorld ESU’s overwrite objects expecting them not to have been altered will certainly ruin a project. JD Edwards have also decided not to provide Paper versions of the ESU’s.

Therefore, an easier method to deliver an ESU into a Development Environment is to only install the ESU to Pristine. It is imperative that Pristine is the only pathcode to affect.

Once the standard ESU installation has occurred – and the Pristine pathcode has been correctly updated with the objects – an ESU project will be available with status 11 (New Project).

Normally the best way to minimize the impact is to create a new Project with a similar name (for example with JD8401_JD7333 having been installed – create a project named JD8401_JD7333_RETRO). Then, drag the objects that you do NOT want to overwrite into this new project.

The remaining objects in the ESU project will be objects that you wish to overwrite in Development, Prototype and eventually Production. Using the activity rules in the previous chapter – move the project to status 45 – perform a check out to ensure that the objects are brought down locally to the development workstation – then perform a check-in to ensure that the Development pathcode is correctly updated.

Move the project to status 21 and eventually through to 38 as per a straightforward object promotion path. Ensure that testing occurs on major functionality thoughout the project life.

UserObject Type From Location To Location

From Release

To Release

Allowed Action Description

*PUBLIC APPL JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC APPLVER JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSFN JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC BSVW JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC DSTR JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC GT JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC MENU Control Tables - JDE LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC TBLE JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBE JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UBEVER JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UDC Control Tables - JDE LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC UO Central Objects - JD7333 LOCAL B7333 B7333 05 Check-Out / Get*PUBLIC WF Control Tables - JDE LOCAL B7333 B7333 05 Check-Out / GetSUPERUSER APPL LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER APPLVER LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER BSFN LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER BSVW LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER DSTR LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER GT LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER MENU LOCAL Control Tables - DEV B7333 B7333 04 Check-InSUPERUSER TBLE LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER UBE LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER UBEVER LOCAL DV7333 B7333 B7333 04 Check-InSUPERUSER UDC LOCAL Control Tables - DEV B7333 B7333 04 Check-InSUPERUSER UO LOCAL Central Objects - DV7333 B7333 B7333 04 Check-In

-

OneWorld Xe Page 12

OneWorld Xe Upgrade Procedure Plan

With the new RETRO project – move the project from status 11 to status 21 – assign a developer and use Visual ER Compare to compare the objects between JD7333 (the pathcode with the ESU applied) and DV7333. Any updated code that can be moved across can be done so at the developers’ discretion.

Unfortunately, this method does not work well on very large objects that have many, many SAR changes associated with the ESU. It may be better to print the entire object out to the clipboard and use a Search program to find the necessary SAR rules that exist – or even perform a compare between the Pristine Environment and a true pristine (prior to the ESU) pathcode to find the ESU changes – then mark these changes down ready for comparison between Development and the ESU.

As said before, this methodology is not perfect – but it certainly allows those customers with large amounts of custom development against JD Edwards objects to control how ESU fixes are applied – and gives the developer discretion to accept or deny the SAR fixes. It has been known for JD Edwards SAR fixes to accidentally introduce coding errors into applications.

Contact

For additional information contact :

Jon Steel Xe Upgrade Specialist Chief Technology Officer erpSOURCING LLC 10694 East Powers Drive Englewood Colorado 80111 Work phone : (303) 224 9468 Cell phone : (303) 883 9168 Fax Phone : (303) 224 9467 Email (main) : cto@spla.sh ICQ Number : 111747507