This section describes enhancements, system data details and deprecation notices in Oracle Utilities Application Framework v4.5.0.1.3 including:

This section describes the new and enhanced product usability features in this release, including:

The following language related to a business object status may now be overridden by your implementation:

For example, you could change the status "Canceled" for a given business object to use the term "Discarded". You could do this by navigating to the lifecycle definition for that business object and providing an override description for the "Canceled" state. In addition, you can find the states that transition to Canceled and override the Action Label from "Cancel" to "Discard".

The description of any product-delivered business object Status Reason can now also be overridden by your implementation.

This does not impact any existing extensions. The user interface may change if you choose to override descriptions.

No steps are required to enable this feature.

The product delivers two new views:

If you have any custom zones that retrieve the DESCR field from F1_BUS_OBJ_STATUS_L or from F1_BUS_OBJ_STATUS_RSN_L and you plan to override any business object status description or a status reason description, you should update your custom zone to use the corresponding view instead.

The vertical area that stays anchored in the application as a user moves through the system is now referred to as a "Sidebar" instead of a "Dashboard." This change is reflected in documentation, metadata descriptions, and configuration on the User page related to the area (including the Sidebar Width, the Sidebar Location and the Sidebar State). This does not impact any extensions.

This allows the "Sidebar" to be distinguished from other "Dashboards" used to describe portals that display high-level views of a specific subject area. For example, the Batch Day Dashboard and the To Do Dashboard.

No steps are required to enable this feature.

This section describes the new and enhanced To Do features in this release, including:

The system now includes the following calculated duration information on the To Do Entry page:

In addition, the base delivered Information string for a To Do Entry has been updated to include the age for a non-complete To Do and the duration for a completed To Do.

If your implementation uses a To Do information algorithm to override the base delivered information, you will not see any change to your To Do information. This change does not impact any extensions.

When you see the calculated duration information, it helps you understand at a glance how long a To Do entry took to work on and how long before it was completed.

No steps are required to enable this feature.

The zone that displays related To Do entries on the To Do Entry maintenance portal has been enhanced to support actions on the related To Do entries. In addition, the current To Do being maintained is included in the results so that you can perform actions on all To Do entries.

The Related To Do Entries zone supports all the actions available on the To Do Management portal. You can do mass assignment, mass updates to priority, mass addition of a log entry, and mass completion. In addition, you have access to the Work button to push all the related To Do entries into your Worklist. The actions are only available if a user is allowed to work all the related To Do entries.

On the To Do Management zone and the To Do Details zone on the To Do Dashboard portal, the link for the Related To Dos message now brings you to the To Do Entry maintenance portal. Previously, you were brought to the To Do Search page where you could do actions only on the To Do entries related to the one in the results.

This does not impact any extensions.

The ability to action one or more related To Dos on the To Do Entry maintenance portal provides improved support for managing multiple records.

No steps are required to enable this feature.

This section describes the new and enhanced batch processing features in this release, including:

The Batch Job Submission page has been converted to a portal, leveraging a more flexible user interface metaphor. The portal organizes information in a way that makes it easier to review and enter key details, such as batch job parameters.

In addition, the following user interactions were changed in the portal:

This does not impact any extensions.

No steps are required to enable this feature.

A new business object (BO) for Batch Job Submission and a new Determine BO algorithm linked to the Maintenance Object were introduced. The base BO includes all the user interface behavior designed for the new portal. If your implementation has introduced your own CM business object and CM Determine BO algorithm, you should review your business object's configuration and merge it into the base business object.

Upgrade scripts ensure that users with Read access to the existing application service will have access to the new application service associated with the new portal. The table below lists the existing and new application services.

 

Note that any existing bookmarks for this page will take you to the previous version of the page. You need to take the following actions to move the bookmark to the new page:

This section describes the new and enhanced implementation tools in this release, including:

The following terms were added to the SQL Allowlist:

Note that the terms were also added to the allowlist in previous releases via patches. This does not impact any extensions.

Additional terms included in SQL allowlist provides implementations with more capabilities when writing SQL statements in data explorers.

No steps are required to enable this feature.

Business object option types and algorithms system events are now documented in designated extendable lookups, Option Configuration for option types and Algorithm Entity Type for system events. It is noted whether they support single or multiple values. This configuration is for documentation purposes only. Previously, there was no indication as to whether a business object's option type or algorithm system event implemented a single value or supported multiple values.

Using this information, the Business Object portal uses an icon to highlight whether a single value option type or algorithm system event record has been overridden by a higher sequence record. The situation may occur when the business object's option or system event configuration is extended by other products or customers. In the same way, an icon is used to highlight that a business object algorithm has been inactivated. The use of these icons makes it easier to focus on configuration records that are in effect and active.

The detailed description of the option types are presented in a more user friendly and searchable way. Also, as of this release, you can maintain reasons for a specific status directly on the Lifecycle tab where you review and maintain all other status-related configurations.

This does not impact any extensions.

No steps are required to enable this feature.

If you have introduced custom business object-related option types, it is recommended that you also define them in the Option Configuration extendable lookup to indicate whether the option type assumes a single value or multiple values. By default, the Business Object portal displays an option type that is not defined in the extendable as if it supports a single value.

In the same way, if you have introduced custom business object related system events, it is recommended that you also define them in the Algorithm Entity Type extendable lookup to indicate whether the system event assumes a single algorithm or multiple algorithms. By default, the Business Object portal displays a system event that is not defined in the extendable as if it supports multiple algorithms.

The Populate Node and Override Information tree node algorithms can now optionally set the broadcast fields to use. When this information is not provided, the default primary key field names are used. Previously, when a user clicked on the broadcast icon on a tree node, the broadcasted field names were hardcoded to the node entity's primary key field names. While this was appropriate for most entities, there were use cases where the broadcasted field names should have differed from key names.

In addition, these tree node algorithms can now also determine that for a specific node the broadcast icon is not applicable and therefore should not be displayed. The tree node definition must explicitly allow broadcasting for the icon to appear and the algorithm can only set it to not appear as needed for a specific node.

This does not impact any extensions.

This allows for better support of complex tree node broadcasting requirements and provides more flexible interaction with trees.

No steps are required to enable this feature.

The Extensions Dashboard portal was enhanced to show all revisions made to an extension entity in descending order in a new Revision Control zone. A Configuration Migration zone was also added to also list all Content Migration Assistant migration objects that applied changes to an extension entity. These zones appear only when an extension entity is selected.

A new Review tab was added to the Extensions Dashboard portal to highlight rare duplicate configuration issues that may arise after an upgrade. Utilities can use this information to adjust their configuration.

This does not impact any extensions.

The new user experience allows utilities and partners to improve the way they track and manage their extensions, which helps to reduce implementation costs.

No steps are required to enable this feature.

Lookup values can be easily filtered by various criteria and a smaller set of records can be selected for update. This helps handle lookup fields, like algorithm entity, that have too many values to manage as a single list. This does not impact any extensions.

This improved user experience helps to reduce implementation costs.

No steps are required to enable this feature.

This section describes the new and enhanced integration tools in this release, including:

The definition of valid cloud object storage regions are now configured using an extendable lookup rather than a lookup. Defining the regions in an extendable lookup allows us to support defining both the region key and the region identifier. Previously, using a lookup to define the region supported only defining the region key. Product code was required to map the region identifier, requiring code change any time a new region was defined.

The product provides base delivered values for all the regions that are provisioned for cloud services. You can define a region for cloud object storage that is not provided by the base produce using the region value in the extendable lookup.

For backward compatibility for upgrading implementations, all regions previously provided in the lookup that are not in the list of those that the product is supplying are provided in the extendable lookup with a "CM" (customer modification) owner.

This does not impact any extensions.

As Oracle Cloud expands the regions it offers, this change allows the services to react to these new regions quickly without changes to the product code.

No steps are required to enable this feature.

This section describes the new and enhanced CMA features in this release, including:

The user record includes a user hash for security reasons. This hash value is calculated using a cryptography key in a given environment. When using Content Migration Assistant to import users from another environment, the process now includes a step to recalculate the user hash value using the target environment's cryptography key.

This update means implementations can import users from one environment to another without getting an error related to the user hash.

No steps are required to enable this feature.

This section provides information on functionality that has been removed, is no longer supported by Oracle Utilities Application Framework v4.5.0.1.3, or is planned for removal.

There are no deprecated functionality or system data for Oracle Utilities Application Framework v4.5.0.1.3.

This is a list of functionality / system data that Oracle plans to deprecate in a future release.

In the current release, the product provides an option to Switch UI View. This changes the current user experience for the user for that session. Assuming the user is in the latest user experience (referred to as Redwood), this action switches the user experience to the previous look-and-feel.

In the future, the product plans to remove support for the ability to switch that design that preceded Redwood.

Workflow and notification functionality was an early way to support exchanging messages with an external system (notification) and providing a configurable process for acting on incoming messages (workflow). In more recent years, the functionality for managing external messages is supported using Outbound Message and Inbound Web Service functionality. In addition, there are several features to support processing incoming messages. Service scripts can handle simple use cases. For more complicated processes, the service task or other business object driven objects are available.

The metadata and database tables related to this feature will be removed in a future release. Note that only a portion of the functionality for this feature is managed by Oracle Utilities Application Framework. Most of the functionality is supported in the Oracle Utilities Customer Care and Billing product.

Removal of support for the Mobile Application Framework has already been announced in a previous release. However, there is metadata still included in the application related to this functionality.

The metadata will be removed in a future release.

The product is removing all scripts, algorithm types, and algorithms that performed validation rules on the K1-SignatureKeyRing business object. The algorithms have been removed from the BO configuration. There are requirements to expand the use of a signature key ring beyond the current implementation for object file storage and the existing validations are not applicable to other planned use cases.

The following items will be removed in a future release.

The UI metadata related to fixed pages that have been converted to portals will be removed in a future release. The navigation keys listed are related to each maintenance page. The related UI program component data will also be removed. Note that the metadata related to the search pages will not be removed at this time in case they are used on other fixed pages.

The following metadata is no longer in use and will be removed in a future release:

 

Entries in the Managed Content table related to XSL should be using the XSLTC managed content type and not the XSLT managed content type. In a future release, the XSLT managed content type will no longer be supported.

The original URL supplied for invoking IWS based REST services included the IWS Service name in its makeup. Support for this will continue for backward compatibility purposes, but it will be deprecated in a future release. You should adjust your existing integrations to use the currently supported URL.

There are several known issues with the functionality of the "append" option in pagination. It is recommended that you do not use this pagination setting.

The Service Catalog Configuration (master configuration) enables you to define subordinate servers. Defining subordinate servers is no longer applicable for the Oracle Integration Cloud.

The Batch Run Statistics portal provides additional information about batch runs, but some functionality on the portal is related to capturing additional information from an external tool. This information is stored in a Fact record. Support for capturing additional information from an external tool will be discontinued in a future release.

In the original implementation of configuration tools, the main framework maintenance BPA (F1-MainProc) did not perform a Read of the BO when a pre-processing script was linked to the BO via options. The pre-processing script was responsible for the Read.

In a subsequent release, a BO Read was added in F1-MainProc (even if a pre-processing script existed) to resolve a UI Hint issue related to child business objects. This solution introduced a problem only visible for specific scenarios and a different fix has been introduced. The new fix made the BO Read unnecessary in F1-MainProc. Because there are many pre-processing scripts that are properly performing the Read of the BO, ideally the BO Read should be removed from F1-MainProc so that multiple reads are not performed. However, there may have been pre-processing scripts introduced after the BO Read was included in F1-MainProc that were coded to not perform a BO read in the pre-processing script. Due to this situation, the BO Read is still performed as part of the processing of F1-MainProc.

When a pre-processing script exists, we plan to remove the BO Read from F1-MainProc logic. You should review your custom pre-processing scripts that are linked to your BO options to ensure that they properly perform a Read of your BO.