Testing an EnterpriseOne Tools release tends to take a backseat to other day-to-day processes within a company. However, testing releases is of vital importance and can prevent unnecessary waste of time and resources when applied regularly.

Tools releases differ from full upgrades. They are the dot releases that you see, such as moving from 9.2.2.1 to 9.2.2.2. Each and every one of them is important because they allow you to stay current on delivered bug fixes, new functionality, support, and management of incremental changes. The more frequently you test releases, the fewer changes you have to test each time.

Common Testing Challenges

However, there are several identified barriers to running tests within releases. A common challenge among those who are in charge of configurable network computing is the challenge of calming management. In order for your business to continue moving forward, it may be your responsibility to convince management that this testing is necessary. In truth, small, temporary hindrances to daily operations may be necessary for major enhancements to the overall processes within your company. However, there are options that are less likely to influence daily ops that are worth exploring.

Another challenge is that many may be facing a very small window of time to complete testing. People often try to avoid high-traffic and time-sensitive seasons such as the end of a quarter, monthly-patching, or other company-specific scheduling. To tackle this barrier, you should use your time wisely by preparing for the release before your window of opportunity arrives.

Solutions to Testing Challenges

Preparation is key. There is a lot changing while you build up to a Tools release. When preparing for a Tools release, include the following steps in your plan:

1. Review certifications
2. Review the required components
3. Review the Tools release upgrade documentation
4. Review the net change documentation
5. Create a task plan
6. Create a test plan

It is extremely beneficial to create living documents for your task plan and test plan. Updating these documents during each experience will simplify future testing. After the review and creation of these items, choose which route of Multi-Foundation you would like to implement.

Multi-Foundation has been a part of Oracle for quite some time, and it is a widely accepted approach to testing. Multi-foundation allows you to apply a new Tools release and test the effects of applications on the side, without touching the main system of your business. You do not have to set up a second installation. In fact, you are able to use the configuration margin within JD Edwards to communicate to your actions to use the additional system created for testing purposes. If you are working with consultants, they will know how to set up and run Multi-Foundation because it is a known entity. If you are running the tests yourself, you can use Multi-Foundation in one of several ways. Two options for using Multi-Foundation include:

1. Take the non-production enterprise server to the new Tools release.
2. Run an additional enterprise server on the non-production enterprise server while keeping your other servers untouched.

Option 1

The first option is to take the non-production enterprise server to the new Tools release. This would be a Multi-Foundation system in one installation. The PD enterprise server remains on the “old” system during testing, but this is a temporary state. Your production is going to move to the new Tools release, at which point they will be back in sync, so you are out of the Multi-Foundation business at that point. The DV and PY port continue to run on the original port because they are talking to the same enterprise server and the same system.

The downside to this—especially if you expect your Tools upgrade to be a lengthy process— is the necessity to stop development and promotions during implementation to avoid unanticipated headaches. To be fair, it is possible to continue development, but it is not recommended. Running them simultaneously makes bug fixes in the moment near impossible. The production cutover for this process is to install the “new” Tools release to PD.

Option 2

The second option is to take a more complex route by running an additional enterprise server on the non-production enterprise server while keeping your other servers untouched.

Chantelle Cory of LSB Industries does this through her normal DV/PY and DV/PY Multi-Foundation. She adds a second set of all of these things on her non-production side. On the enterprise server, one runs on her normal 6017 port and the other runs on 6117. When the web services go different paths, each communicates to the correct enterprise to use the appropriate foundation.

A major benefit of this option is that the Multi-Foundation configuration can be left permanently. Two sets of DV and PY are available. Therefore, Chantelle has an enterprise server that will serve both Tools releases and a web server that runs the same functions on different ports. Development and promotions may continue, with testing occurring on both foundations. Once it’s set up, the second system can be disabled or enabled and refused for future Tools releases.

If you adopt this approach, make note to test in PY and PYMF (PY Multi-Foundation) by sending something to production in the testing process. Development occurs within the production Tools release. The production cutover is as follows:

• Install Tools release to the first set of DV/PY (port 6017 in the example above).
• Install Tools release to PD.
• The second set of DV/PY (the Multi-Foundation set) remains on the second port (6117 in the example above).

Now that you understand why and how to test Tools releases, the big question per business is exactly what to test.

Items to Test in A Tools Release

The number one priority for your company should be testing mission-critical applications. Although this will vary per customer, you should be able to identify the necessary functions by considering if they are urgently important to your operations. What are you dependent on to get through day one?

Common Mission-Critical Applications

• Sales Orders
• Purchase Orders
• Work Orders
• Configurators
• Payroll

Typical Screen and Form Behavior

• Moving grid columns (Internet Explore vs. Chrome)
• Multi-select
• Switching between tabs on power forms
• Import/export for Excel and Word
• Media object attachments
• Tools for sending emails and shortcuts
• Sending meeting invitations

Workflow (Within web-only maintenance)

• Requisitions
• PO approvals

New UDOs

• Grid formats
• Cafe One
• Watchlists
• Queries
• Personal forms
• Form extensions
• EnterpriseOne Search
• EnterpriseOne Pages

Existing UDOs

• Test broad, not deep

Batch Processes

• Work with submitted jobs
• Scheduler/3rd party schedulers
  • Review jobs that run in different queues
  • Renew timing sequences
  • Print immediate jobs
• Table conversions as part of integrations
• Subsystems for processing
• Processes that read/write to external custom folders
  • Media object attachments
  • Multi-tray printers
  • Custom processes
    • Import/export XML, CDSV, flat files
• UBEs/Embedded BI Publisher
  • Custom fonts/logos
  • Custom formats (checks/invoices)
• Financial row/tabular reports
  • Smart fields

One View Reporting

• Connectivity
• Soft coding
• Report graphics

Business Services

• Producer services
• Consumer services
• Package build/deploy (breaks frequently*)

Orchestrator & AIS

• Orchestrator
  • Service requests
  • Orchestrations
  • Process recorder
  • Notifications
  • Schedules
• AIS Functionality
  • UX One
  • One Search
  • Mobile applications

Third-Party Integrations

• Vertex/Avalara
• Packman/AutoDeploy
• DSI/RFSmart
• Other integration touch points

Tips & Tricks for Testing Tools Releases

Keep these tips and tricks in mind when deciding to test an EnterpriseOne Tools release:

• Choose your Tools release carefully. It can be beneficial to ignore first-level releases such as 9.2.3.0 and allow other companies to act as the guinea pig so Oracle can respond and fix unpredictable issues. Wait for releases such as 9.2.3.1 or later.
• Don’t adopt dot releases on the day they are released. Let them exist for a while before applying them to your business.
• Take a look at the known issues for testing releases. You can find these on the Oracle website, and they can help you get ahead of the problems several companies have faced.
• If you are running the complex Multi-Foundation approach, pay attention and make notes on each action performed to input correct ports, etc.
• Create living documents for your task plan and a test plan that are easily accessible and updatable. Attach screenshots to this document for further simplicity.
• Call Oracle or make comments on the documents in My Oracle Support for swift personal help and to enhance processes.

For more information on best practices for testing an EnterpriseOne Tools release, check out the presentation and additional Quest resources attached below.