1 Feature Summary

Overview

The following enhancements are included in this release.

Column Definitions

  • Feature: Provides a description of the feature being delivered.

  • Delivered: Identifies whether the feature is Enabled or Disabled upon initial delivery.

  • Scale: Identifies the size of the feature. Options are:

    • Small: These UI or Process-based features are typically comprised of minor field, validation, or program changes. there fore, the potential impact to users is minimal.

    • Large: These UI or process-based features have more complex designs. therefor, the potential impact to users is higher.

  • Customer Action Required: You must take action before these features can be used. these features are delivered disabled and you choose if and when to enable them.
Feature Module Impacted Delivered Scale Customer Action Required?
Removal of the Classic User Interface User Interface Enabled Large Yes
Replacement of the JOS Job Admin with a New POM Agent Batch Execution Enabled Large No
Implementation of OAuth Based Authorization Batch Invocation Enabled Medium Yes
Introduction of a New Service Based Batch Job Type Batch Setup configuration Enabled Medium No
Change in Environment Status Indicator on Batch Monitoring Screen Batch Monitoring Enabled Small No
Introduction of a New Kill Action for Running Jobs Batch Execution Enabled Medium No
Configuring New Batch Schedules Through the New User Interface Configuration Enabled Medium No
Move of Notifications and E-mail Setup to Retail Home Notifications Enabled Small No
Implementation of Application Properties in the New User Interface Configuration Enabled Small No
Introduction of New AMS Utilities for Overriding Batch Job Status Operations Enabled Small No

New Feature Descriptions

This section describes the new features.

Removal of the Classic User Interface

The classic User Interface, which was based on an older web application technology, was deprecated as of October of 2020. Customers have since been advised to move to the new User Interface. The classic User Interface has been removed in POM 21.0. The new User Interface is accessed through the following URL pattern: https://<hostname>/POMJetUI.

Replacement of the JOS Job Admin with a New POM Agent

The JOS Job Admin is a component of the Retail Applications designed to accept batch job requests from the POM application and to oversee their execution on a target server. In POM 21.0, this component is replaced with a much lighter one: Job Agent, which has the same function of managing the execution of jobs but with a much simpler engine.

This replacement is transparent to the user so there is no impact to customers.

Implementation of OAuth Based Authorization

OAuth is a mechanism for authorizing access to services without the need to share password data. It uses authorization tokens to prove an identity between consumers and service providers. It is a preferred authorization mechanism over the previously used Basic Auth mechanism where credentials are transmitted with an encrypted service call.

With POM 21.0, all POM service endpoints, including those exposed to customers, are protected by the OAuth authorization mechanisms. Customers must now switch the mechanism for invoking POM service endpoints to OAuth instead of Basic Auth. In order to invoke an endpoint using OAuth, a customer application must use an Access Token that was generated using the OAuth System Credentials Grant. Customers need to contact Oracle to obtain the OAuth client they need to call POM’s service endpoints. In the future, POM will provide a screen customers can use to obtain this client through self service.

Introduction of a New Service-Based Batch Job Type

In prior versions of POM 21.0, POM accommodated only one mechanism for executing a batch job. This was done through Unix Shell Scripts. In POM 21.0, POM added another mechanism to invoke a service endpoint for executing batch. This additional mechanism may be preferred by some applications. The mechanism used for executing batch is transparent and has no impact on customers.

Change in Environment Status Indicator on Batch Monitoring Screen

In version 21.0, POM has changed the way the Batch Monitoring screen visually indicates to the user what the status of the environment is. Prior to POM version 21.0, at the load of the screen, a green Environment link at the top right of the screen indicated that there were no application environment issues. A red Environment Error link Environment error image indicated there were issues with the environment.

The user would then click on that link or the icon next to it to open a right hand side panel showing details in the Status sidebar. In POM 21.0 the link and icon are replaced with a stateless environment (cloud) icon. Cloud Icon

Unlike the previous Environment status link, this new icon does not convey a status at the load of the Batch Monitoring screen. Instead, the user must click the icon to see the status of different components in the Status Sidebar. This change was necessary to improve the performance of the Batch Monitoring screen at load time and during a refresh.

Introduction of a New Kill Action for Running Jobs

Currently, if a running job needs to be terminated, there is no option in the POM UI to accomplish that. Customers need to file a Service Request to have a job killed. Oracle AMS then manually identifies where the job is actually executing and terminates it on the physical server it is executing on. In POM 21.0, a new Kill action or is available on the Batch Monitoring screen similar to the Hold, Skip and other actions.

Configuring New Batch Schedules Through the New User Interface

When POM is first installed for a specific customer, it does not include any application batch schedules out of the box, such as Merchandising or Retail Intelligence. Those schedules need to be configured in POM before the scheduling data can be loaded.

Prior to POM 21.0, Oracle Cloud Engineering owned the responsibility of configuring batch schedules in a newly provisioned environment. In POM 21.0 it is now possible for an Oracle administrator or a system integrator to initially configure those schedules.

Configuring a new schedule entails setting up schedule properties, such as the schedule name, description, and customer environment information for callbacks. It also entails setting up the location for different components and services in which different POM components need to interact to function properly.

Refer to the System Configuration chapter of the POM User Guide, Configure New Schedule section.

Move of Notifications and E-mail Setup to Retail Home

In prior versions of POM 21.0, the setup of Notifications for different POM events and of e-mail addresses or groups, where those notifications get sent, was completed through the Oracle Retail Application Administration Console (ORAAC) facility, accessible through the classic User Interface. With the removal of the classic User Interface in POM 21.0, the notifications and e-mail setup is now accomplished in the Oracle Retail Home application. Refer to the Retail Home Administration Guide, Notifications Administration chapter for details.

Implementation of Application Properties in the New User Interface

In prior versions of POM 21.0, configuration of POM application properties was completed through the Application Properties screen, accessible through the Settings menu of the classic User Interface. With the removal of the classic User Interface in POM 21.0, a Settings menu and Application Properties screen have been added to the new User Interface. To access the new screen, click the Settings cogwheel at the bottom of the POM right hand side bar. This opens the Settings menu containing the Application Properties menu task.

Introduction of New AMS Utilities for Overriding Batch Job Status

POM contains a menu option for AMS Utilities, available only to the AMS Administrator. Prior to POM 21.0, only one utility was available: Manual Job Run. In POM 21.0, two additional utilities were added: Override Job Status and Override Execution Request Status. These utilities are used to update their respective statuses if they were to get out of synch due to communication failures.

Note:

Administrators need to understand the impact of overriding these statuses as data corruption may result if the wrong override is performed.