By Simeon Ghent

Historically, a Package Build and Deployment, could only be performed on a Development Client machine, or Deployment Server. Starting with Tools Release 9.2.5.x, additional functionality was introduced to allow packages to be built from the web.

Now that packages can be built from the web, this process can be taken one step further by adding automation, with the help of an Orchestration!

So why would you want to automate a package build? There might be various reasons depending on your environment and development processes, but a few reasons might be:

• Reduce manual processes; no need to use a Development Client or Deployment Server
• To save time and effort
• Schedule daily/weekly Update Packages for specific OMW projects, or OMW project statuses (streamline development processes)
• Schedule Full Packages
• Potentially give super-users, or developers access to run the orchestration as part of the development life-cycle

With anything like this, there is some setup and configuration that is required; a pre-requisite ESU to be installed (search the update centre for bug 32767915).

The high-level steps are:

• Download and install the Package Build Orchestration sample
• Deploy the Package Build Orchestration sample
• Create SM Health Check Connection
• Update Connector
• Subscribe the Notification
• Build an Update Package from the Orchestration
• Deploy the Package

For more details about the above, the Oracle tutorial for Automating Package Builds, is a good place to start.

The Package build orchestration will only build a package.  The Deployment of the package will need to be performed manually.  This is more of a safety measure, as we wouldn’t want potential issues to be automatically deployed into Production (or any other environment). You also need to check the Package Build reports and logs, before deploying.

The Orchestration

Oracle have kindly done all of the legwork with the Orchestration sample, and it contains all of the steps to build a package, as well a Server Manager instance health check. Obviously, this can be duplicated for your own needs (in case you wanted to create automated package builds for different objects, OMW projects, update or full packages etc).

The Health Check performs a test to ensure that the Enterprise Server is up and running. If this step fails, the package build process will not complete.

You can set up email addresses so that a notification is sent if this step fails, so the issue can be looked into. You can tailor the message to suit your needs.

When you run the Automated Package Build Orchestration in JD Edwards EnterpriseOne, you can input various values. If some values are not likely to change (like Path Code, Instance Name etc), you can set these to be defaults.

An explanation of each input field, can be found here.

Once it has been successfully run, you can see the jobs running within Submitted Job Search (WSJ).

Notification

Now, here is where subscribing to the Notification comes in… Once the package build jobs have completed, you’ll see a notification telling you that there are packages that are ready to deploy, so you can validate the packages and deploy.

This notification is defaulted to run every Monday at 07:00, but you can change this to suit your needs. (You may need to check the Scheduler to ensure the schedule is started.)

Subscribing to the notification is easy…

• Sign in to your web environment, go to Manage Notifications -> My Subscriptions

• Click Add Subscription and select “Packages Ready for deploy”

• Click the save button, and then close the form, and that’s it!

Checking the Update Package

As mentioned above, you can view the package build reports via the Submitted Job Search (WSJ) application.

Also verify the Package Build status via menu GH9083 -> Package and Deployment Tools -> Package Assembly. This will all be very familiar, as it’s just a web version of the Development Client/Deployment Server applications we are normally used to. You can check the Package Status, view objects within the package etc.

Obviously, you would also check the server logs etc. as necessary.

Scheduling the Automated Package Build

The Orchestration Sample, comes with a couple of Schedules. You can use these, or create your own.

Schedules created are not automatically invoked.  These contain the schedule details, but need to be started from within the Orchestrator Scheduler.

If you have a different schedule (from the default one) and want to assign this to the Automated Package Build Orchestration…

Select the Orchestration, click the Start Node, and then the Schedule icon.

Click the Select Schedules button.

Select the appropriate Schedule from the list.

Don’t forget to save the Orchestration!

Now the Schedule needs to be started… Go to the Orchestrator Scheduler and start the relevant schedule(s), and let the Automated Package build work its magic.

Something else to think about?

If you have Development resource, a custom front end JDE application could be created, that could trigger an Orchestration with a button. The form could include any fields that we would allow the user could change (ie OMW project), and these fields would be passed through to the Orchestration.

Some validation and checks could be incorporated into the form, to try and ensure correct data is entered.

Access to the application could be granted to specific user groups (developers, or superusers), or just a way of performing package builds all from within the JDE web instance, rather than having to sign in to Orchestrator to do it.

This may or may not be something to think about, depending on your situation, requirements, and needs.

Official Oracle JD Edwards documentation on automated package builds and deployments, can help you understand the process in detail, for further information, visit Oracle’s support page.