10 tips for successfully executing a JD Edwards upgrade

There are generally a lot of choices for an upgrade, and they are only getting tougher. Do I change database, do I change platforms? Should I move to the cloud, do I need a managed service? Yes — lots of questions, but they really should not get in the way of the mechanics of what is being done. You’ll still need to do the same amount of testing, and let’s be honest, this is generally the critical path on any upgrade project.

Form a clear idea of what you want to achieve for the project. Scope the technical decisions early. Don’t be afraid of a couple of architectural changes in addition to the upgrade itself — refer back to my observation on testing [critical path].

Use the testing and the project to achieve some strategic goals. Nearly every upgrade that I’m involved in has more than a single dimension. More often than not, we are performing upgrades at the same time as cloud migrations. As I alluded to, this is a good combination and a tight scope. If I was to take on an upgrade and cloud migration, I’d try and not change much else in that step.

Changing too much can introduce too much risk. For instance, changing your output management software Create!form can be very onerous and take a lot of time. If you think of all the time that you have spent on making your invoice print perfectly, every time… Any change in this area is going to take a lot of time! You can do that iteratively when you get an opportunity. Output management solutions can be run in parallel and give you a perfect fallback position.

Be tight on scope and agree early — what is in and what is out.

It’s critical to understand the scope of testing. Whether you are doing test automation, test outsourcing or manual testing, you need to know the programs and versions that your users are currently using. This is going to allow for accurate test scenarios. Knowing your programs (both interactive and batch) will allow you to also choose candidates for automation (if that is what you are going to do).

A high level idea of your processes (whether documented or reverse engineered by clever E1pages) will enable you to group your test cases and test resources. Quite often a logical grouping of your testing can ensure that end to end processes are tested and that the test data is going through a full cycle too.

It is critical that you have a clear list of all your programs and how often they are used plus a full list of users from production and what programs they are running. Use these two project assets to then choose a test team and also ensure test case saturation in your test environments.

At Fusion5 we advocate the use of ERP Insights to give you “easy to use” reporting on all user activity in JD Edwards. This software subscription can plug into your current production environment and your upgraded environment and provide constant feedback about test volumes and test case saturation — for both batch and interactive.

Going from SQL Server to Oracle means that you will have case sensitive queries, when the users previously did not need to worry about cAsE. This is unavoidable and you’ll need to educate the user community on this, so you’ll need to follow change management processes and include lots of comms.

Going from Windows to Linux might mean changes to processing options for the location of files or interoperability. There are options for bulk Processing Option (PO) changes using the database. This is very important for finding a “\” for example and turning that into a “/” or vice-versa. This simple trick of interrogating the BLOB in the F983051 can change a very manual and error prone process to an exact science.

Media Object changes are critical and need to be understood as you upgrade JD Edwards. There are more storage options that you need to be aware of, some for good and some for your own peril. I say peril, the storage costs alone are similar (see below), but the database IOPS is something that you need to focus on VERY carefully for a cloud implementation – as this is what generally governs your service limits.

For example, let’s look at this from a pure cloud cost perspective. In AWS 100GB of s3 is going to cost you 0.023 dollars per GB ($2.50 a month). EFS (Elastic File System), a highly available storage format perfect for media objects, is going to cost you about 0.3 dollars per GB per Month ($36 a month). Let’s put that into your highly available database instance (multiple availability zone) and that is going to be 27.60 per month. Remember that you don’t really backup or restore the EFS, so you are only paying for a single copy (you might snap it to S3).

Look at your end game infrastructure and make sure that you understand both the change management impacts and the cost impacts of the new architecture.

Your browser is basically equivalent to your operating system in terms of compliance and importance to JD Edwards. You need to get it right. There are a number of important compatibility settings, security settings, proxy exceptions (and more) that you need to ensure are pushed out to the business as part of an implementation.

In general, URLs no longer change with an upgrade or migration of JD Edwards. A production URL (jde.fusion5.com.au) for example, is probably well known and has all sorts of favourites saved on all sorts of machines. Don’t change it — it’s painful. You’ll have more calls into your helpdesk saying “JDE is broken” that you can poke a stick at. Please keep the URL the same and you’ll have a better chance of everyone being able to login.

Ensure that you push out cache refreshes for any tools release change or any JDE change for that matter. It’s critical to manage all of your browsers too, not just the ones that you think are being used. How do you know what browsers you need to cater for? Use ERP Insights of course. This gives you detailed mapping of users and programs to browsers. It’ll also allow you to ensure that you are using activeX (please don’t keep relying on this) and what settings your CNC team need to put into the JAS.INI to ensure that all browsers are treated equally (well, as equally as possible). Supporting a broad base of browsers and technologies is always going to be best.

Browser performance constantly surprises me, as the two screen grabs below will attest to. We have two different clients that use JDE heavily, you’ll see opposite results in terms of the performance. It really does make a HUGE difference though — 80% difference in site one and 30% difference in site two – purely based on browser choice.

Batch activity is really a pure performance comparison which takes away a potential tier in your traditional 3 tier architecture using JD Edwards (Web, App & DB). The nice thing about this also is that you are really only testing your batch server and your database server.

JD Edwards (in my mind) submits two types of jobs

1. Type 1 runs a series of large SQL statements. These are generally not complex, as the batch engine’s capacity to run complex statements (even simple aggregates) is not good. Therefore you are going to get large open selects, which will generally then perform subsequent actions based upon each row that is returned in the main loop. (eg. R09705 — Compare Account Balances
   to Transactions).
2. Punchy UBE that gets in with some tight data selection, generally runs a pile of BSFNs and then jumps out again. (R42565 — Invoice Print).

It’s easy to categorise these jobs because of the amazing job Oracle did with “Execution Detail”, specifically rows processed.

You can actually databrowse this (V986114A) and see column Alias: PWPRCD, defined as “The number of rows processed by main driver section of the batch job”. I use this in a lot of SQL around performance, as I can get rows per second for my UBEs – which is a great comparison device. If you see consistent low numbers here, probably a punchy UBE — lots of rows, probably category one.

Make sure that you test UBEs in both of the categories that I have listed above. Some are going to test the database more, some are going to test the CPU on the batch server and some are going to test network I/O. Make sure that you “tweak” your TCP/IP too, as I have seen this make some impressive differences in batch performance. (search Doc ID 1633930.1 and tweak).

The Fusion5 UBE Analytics suite allows you to do this comparison immediately and gives you some impressive power to compare periods, servers and more.

We can choose a date range for compare and let the system do the rest. You can see that we can tell for each UBE and version combination that has been run for this fictional client in the date range specified, if you compare it with the previous period — performance has slowed down in the top 12 rows. I’d be looking at what has changed!

The UBE Analytics data is not stored in JD Edwards, so you never lose your history.

You’ve got my full attention in this section, I really enjoy load testing. Whether this is using OATS or other software, it’s a bit of a passion of mine.

Here is my recipe for success for interactive load testing. You have your batch results above, so you are pretty confident with database size and hopefully application (logic layer). We are now going to test the interactive performance of JD Edwards and how the user is going to experience things.

The first question you need to be honest about, is the peak capacity of users that you are going to test. If Server Manager tells you 150 users are on, how many people would you load test with? I can tell you — A LOT LESS! I would test 40 in that scenario with a wait time of five to eight seconds.

Let me show you why:

My interactive report says there are 56 users logged into JDE and active in the last five minutes. This is an interactive dashboard that Fusion5 ERP Insights customers have access to. You can also see the pages per minute and pages per second. We are peaking at about 150 a minute in that snapshot, but I can find the peaks over the last two months if needed.

Yet Server Manager is trying to tell me that I have 288 users. Even with my classic double up the AIS users — we have 144 logged in, but only 58 active in the last minute.

What I’m trying to say here is don’t stress your system with too many users. Tuning for three times the worst scenario possible is actually going to slow you down.

The graph is unequivocal in showing that performance is better when pages are busy. Do not have too many idle web servers because you have catered for 3x the users — your users are actually going to experience worse performance. This is MORE dramatic at the users drop off. I see around 20% performance improvement when a JAS server is loaded and cached up nicely.

Now that you can determine the number of users you need for load testing, you can execute this with the software or services that you have access to. At Fusion5 we use OATS and can assist with any load testing you need. We also validate and continually measure interactive performance using ERP Insights, which can produce all of the graphs that you see above.

Anecdotally, good performance from JD Edwards is when pages load in about 1.1 seconds.

We measure and record exactly what the end user experiences. We can also report on the network traverse time and the server response time. These are all critical values when determining what you need to fix. We can run this reporting on different users or geographies too, so you can compare performance in a single city or around the world.

As I said, if I’m at a go-live, it’s not my first rodeo. Sure, I’ll always have a nervous demeanour (perhaps a bit of) and a sick feeling in my stomach, but I do love it. I like seeing all of the data and statistics around me that somewhat affirm the planning and efforts that have gone into the project. It’s simple, when things go to plan.

Of course when a user does an open find over the F4211 and F42119 using a single non-indexed field and then wants to go to the end of the grid… with probably 20 million rows to be displayed…  I might not have tested that (nor catered for it in the sizing). Oh, and when it doesn’t return and they do it another 10 times (to be sure), that also was not in our test plan. Nonetheless — there will always be challenges and things unexpected — your job is to reduce the number of them.

Security sometimes takes a back seat, but please, please — don’t let it. Without exaggeration it’s about 1,000,000 times easier to make security changes before a go-live than after.

Simple things need to be completed and tested before go-live:

• Complete production security model in place, including row security.
• All table auditing enabled (if you do this).
• Complex JDE password for database and for JDE.
• Do not use the JDE account for the system account for your users. Please do not do this, create “jdeuser” or something much better that will not get locked out.
• Check that the password expiry policy for Oracle is not default, or else your system accounts will start locking out.
• Change your default node configuration, do NOT leave this standard. This is one of the largest security holes in the suite.
• LDAP or SSO is critical. Controlling user access is easiest if someone else is doing it (I find). So if the desktop team is decommissioning users (oh and changing passwords) this is a big bonus and will save time and money. The Fusion5 SSO offering is really cool too, especially if you want to use Azure to MFA people under certain criteria — all done by someone else!
• Make sure that your data is encrypted at rest and in transit.
• Get your security groups tight and your firewalls enabled.
• Default access should be no access.
• Adopt the most stringent security posture your business can afford.

Here is an interesting tip, quite often row security can be good for performance.

Why? Because it ensures that there is a where clause that is generally an indexed field. If you are row securing MCU or CO, then the where clause is enforcing less IO and hopefully a quicker result!

Tip 9 and 10 are closely related, but this tip is all about feedback.  If you know things are going well it’s great.  If you know things are going poorly, that is great too — because you can fix it. The worst case scenario is that things are going pear-shaped in the background and you only hear about it when a user raises a case. You need to be KPI’d on finding errors before your users — period.

How can you find errors before your users? Here are a couple of tricks that Fusion5 implements for our clients:

ERP Insights

Sometimes referred to as the black box for your ERP, we use this to monitor performance and usage of JD Edwards. It records every page load, by every user — every minute of every day. This information is incredibly powerful for benchmarking and comparing ANY change in your entire enterprise.

UBE Analytics

Having access to the runtime, rows processed, user and server information for every batch job allows us to continually monitor the critical two tiers of JD Edwards. Reading this with ERP Insights gives more information on where performance problems might be and another point of data to compare with.

Log monitoring

Fusion5 has a very advanced cloud formation in AWS which utilises cloudwatch to monitor all log files, UBEs and JD Edwards connections. This enables us to graph and monitor user connections, concurrent UBEs and search ANY logfile for ANY error — ever. This is a single console for all logs across JD Edwards. This approach and consistency can be used with many different installation types, not just limited to AWS.

DB growth monitoring

Keeping an eye on table by table database growth is critical for understanding if a process has gone rogue. It’s also critical for maintaining consistent database performance. Regular rowcount reporting and size reporting will ensure that you can deliver a service level to your users that is acceptable. Maintenance of your data size is important for costs and restoration times.

It’s a theme that is not going to go away. If you have implemented all of the shiny new toys
from JD Edwards, then you need to show ROI. 

Even the way Oracle is releasing JD Edwards functionality follows the ideals of continuous
delivery by committing to release 9.2 until 2031. We are getting improvements continuously, not in major releases. 

I think there are three ways that you can make a difference to your business in relation to adopting continuous improvements with JD Edwards.

A: Finding and implementing RPA (Robotic Process Automation) opportunities

There is so much opportunity here, and all of the tools are at your fingertips. You can use ERP Insights to find processes (applications/sequences) that are run frequently.  Use this data to go back to the business and observe what the end users are doing.  For instance, if you see that P42101 is being run 2,000 times a day — look for opportunities to improve this process.  This could be EDI, this could be spreadsheet macros that call an orchestration. What’s an orchestration I hear you ask? 

Orchestration is the ability to turn any piece of JD Edwards functionality into an API.  An API that is easy to call and can be authenticated with the user’s username and password.  So, exposing functionality to an Excel Macro — would be very easy. You could write an orchestration to enter a sales order (in my example) and then a smart macro to call the orchestration with the data on the spreadsheet. It could prompt for a username and password. If your users are being sent orders in spreadsheets — you may have just increased their productivity and reduced a significant amount of human errors.

RPA implementation can be for simple or complex processes. Look for repetition and eliminate it, as an ex-programmer — if you see repetition in code — there are inefficiencies in that code.  ERP Insights will then allow you to measure the success of your RPA, as the usage of the applications should go down with good RPA implementation.

Orchestration is free to implement and can make a huge difference to mundane tasks.

B: Continually optimise your architecture

This may be more relevant for public cloud implementations, but let’s be honest — most are public cloud implementations. You must continually drive for reduced hosting costs for all of the
JD Edwards assets. Quite often this is difficult, unless you have architected your solution for the cloud, turned the monolithic JD Edwards into an elastic cloud tenant. This can be done.

Fusion5 has created what we think is a world first elastic JD Edwards cloud formation for AWS.
This architecture has the ability to expand and contract with load and demand. We are able to define the rules to create new web servers and new batch servers and then retire them when they are not needed. This allows our clients to have a very efficient architecture and if they feel that they are paying too much, we can reduce the size and number of machines accordingly.

A good illustration of the options you have available to you when you migrate is above, a lift and shift [re-host] is a simple project — but will not allow you to get true cloud benefits from native constructs (cheaper storage, elasticity or additional security). If you do a re-platform (as I recommend) you can reshape JD Edwards to be a much more flexible cloud tenant.

If you did a re-host, I’d guess you might implement about 8 cloud constructs (EC2, EBS, ALB, multiple AZ, EFS (if you are lucky), whereas if you were re-platforming, you might use (RDS, EC2, EFS, ALB, ASG, CloudWatch, step functions, route53, S3, Launch Templates, Target Groups and more!)

It is much easier to get savings out of a re-platformed architecture.

At a number of sites I’ve seen savings of more than 50% month on month when we work hard at cloud cost reduction.

C: Continue to update JD Edwards

Patches for JD Edwards are now continuous, so your adoption should also be continuous.
I recommend making a plan, with a schedule of when you are going to take patches, when you
are going to test patches and when you are going to put them into prod. Start simple, choose twice a year and then work backwards for how long you are going to test, how long for retrofit etc. 

If you’ve been lucky enough to re-platform (as above) then you are going to have some distinct advantages when it comes to deployment. That is that changes can be deployed and tested much more rapidly and actually, continuously. If you have a flexible cloud implementation you could build and deploy an alternate package for production and ease this out into the user community. Our AWS cloud formation allows us to deploy packages without outages, we can do this on a schedule and therefore allow environments to consume change at their own pace. If there is an issue, we can back it out immediately and fix it.

A flexible architecture allows you to be more aggressive with your consumption of change and keep more “up to date” with the latest code from Oracle.

By Shannon Moir

Director JDE & Innovation | Fusion5

Shannon is Director JDE & Innovation for Australia and New Zealand. He predominantly works across five main areas: Internet of Things (IoT), social media, cloud, enterprise mobility and big data.

Shannon is recognised as an industry leader in enterprise mobility, cloud and analytics for Enterprise Resource Planning (ERP). He’s also a JD Edwards expert, with over 20 years’ experience in building and designing JDE sites. He holds a certification in Amazon Web Services architecture, which underpins many of his modern design techniques, especially when it comes to integration and ERP.

Passionate about sharing knowledge, Shannon is an avid blogger. He enjoys troubleshooting problems and recording his findings on his blog. He strives towards standardised, cost-effective innovation to help businesses make IT work for them, not the other way around. Read his blog.