Oracle Utilities Application Framework V4.5.0.1.2 Release Notes
This section describes enhancements, system data details and deprecation notices in Oracle Utilities Application Framework v4.5.0.1.2 including:
Note: The Steps To Enable, Tips and Considerations, Key Resources, and Role Information sections provide guidelines for enabling each feature, where applicable.
Product Usability
This section describes the new and enhanced product usability features in this release, including:
Additional Inbound Web Service Query Options
You can search for REST Inbound Web Services by operation information and help text details.
In addition, the Open API spec may also be launched from the Inbound Web Service Operation portal for your convenience.
This provides more flexible search options. There is no impact to existing extensions with this enhancement.
Steps To Enable
No steps are required to enable this feature.
Batch Job Submission Query Portal
The Batch Job Submission search page has been converted to a portal to provide you with a more flexible user experience. The portal includes additional filters to allow more granularity in the search. The search also supports pagination, providing the ability to navigate between sets of search results.
This provides you with more search criteria and additional information in the search results. There is no impact to existing extensions with this enhancement.
Steps To Enable
No steps are required to enable this feature.
Enter Menu Name in Search Without Slash
The search widget no longer requires a preceding slash to search for a menu item.
If the keyword for the menu name matches keywords in the unified search results, you will see results mixed in. In this example, the word "market" includes results with "market" in the menu name and "market" in a customer's name or address.
When you enter a slash before the menu item text, it is a signal to the search to only search for the text in menu entries.
When using the Search widget, no longer requiring the slash improves usability and consistency.
Steps To Enable
No steps are required to enable this feature.
Improvements to Batch Analytics Snapshot Update Processes
Based on volume testing, the queries used to select records for the batch run and batch thread analytics snapshot tables have been optimized. Additional indexes have been added to the tables to support the amended queries. The batch processes now also support selecting records within a range of days, instead of months, to provide more flexibility in the initial population of the snapshot tables.
The processes used to populate the batch analytics table have been amended to improve performance.
Steps To Enable
No steps are required to enable this feature.
New Batch Analytics Views
The batch analytics views no longer derive data directly from the various batch run related tables. Instead, the views now reference the snapshot tables, which have been designed to simplify the view SQL and to take advantage of specific indices that are not available in the source data.
Steps To Enable
No steps are required to enable this feature.
Zone SQL and UI Map HTML Editor Improvements
The CodeMirror library is now used to apply syntax highlighting logic to the SQL editor in data explorer Zones. Line sequence numbers were also added.
The same improvements are visible in the HTML Editor for a UI map.
When viewing or editing the SQL definition in zone maintenance and when viewing or editing the HTML for a UI map, readability is improved with syntax highlighting.
Steps To Enable
No steps are required to enable this feature.
To Do Management and Processing Enhancements
This section describes the new and enhanced To Do features in this release, including:
To Do Entry Lifecycle Improvements
Several improvements were made to the To Do Entry lifecycle to more accurately reflect the status of a To Do Entry:
• The status Being Worked On was renamed to Assigned to reflect what actually happens in that status. Previously, you could have one or more To Do Entries in the Being Worked On state, but it did not mean that work was being performed yet. Now this status reflects only that the work has been assigned to someone.
• A new status value of In Progress was added. This allows you to explicitly mark which To Do Entry you are actually working on. You can only have one To Do Entry in the In Progress state at a time.
• A new status value of On Hold was added. This allows you to pause the progress of a To Do Entry if you need to wait for some event to occur before continuing to work on a To Do. Putting a To Do in the On Hold status allows for a more accurate accounting of how long it takes to work on a To Do Entry.
The two new status values of In Progress and On Hold are captured in a new Substatus field (TD_SUB_STATUS_FLG) on the To Do Entry. This new field can only be populated if the To Do Entry is in the Assigned status (the status formerly known as Being Worked On). This was done so that any implementation with the existing status field (ENTRY_STATUS_FLG) will continue to work as before.
An implementation needs to opt into using the substatus functionality by giving users that work on To Do Entries access to the new access modes. See the release readiness detail below for directions. Once an implementation has opted into the functionality, you will see these additional capabilities related to To Do Entries:
• When you perform any action that previously automatically assigned a To Do to you, it now also moves the To Do entry to In Progress. This happens if you click the Work action on To Do Entry, To Do Management, or on the To Do Details tab of the To Do Dashboard. Additionally, if you use To Do List and click the hyperlink in the Message column, this functionality applies.
• When you log into the system and have a To Do Entry that is In Progress, it is shown in the Current To Do dashboard zone.
• If you have an In Progress To Do and perform an action that causes a different To Do Entry to become In Progress, the previous To Do Entry is moved to the On Hold status.
• When you view an Open To Do Entry on the To Do Entry Maintenance page or Current To Do zone and you are allowed to work on the To Do, you see a button for Start Progress. This allows you to assign it to yourself and start work on in.
• When you view an Assigned To Do Entry on the To Do Entry Maintenance page or in the Current To Do zone, you also see a button for Start Progress.
• When you view an In Progress To Do Entry on the To Do Entry Maintenance page, you see buttons for Hold Progress and Stop Work. If you click Stop Work, it resets the In Progress state and the To Do will just be Assigned. These buttons are also available in the Current To Do zone. You can also perform any action that you can do in the Assigned state, including reopen, unassign, forward, and Complete the To Do.
• When you view an On Hold To Do Entry on the To Do Entry Maintenance page, you see buttons for Start Progress and Stop Work. You can also perform any action that you can do in the Assigned state, including reopen, unassign, forward, and Complete the To Do.
The To Do log has been enhanced to capture the status of the To Do Entry at the time the log is created as follows:
• A new log type Status Updated has been added and is used for any changes related to the new states of In Progress and On Hold. The existing log types of Assigned, Forwarded and Sent Back will continue to be used for those states for backward compatibility purposes.
• Going forward, log entries created will capture the status of the To Do at the time the log was created. Existing log values that predate the upgrade are not updated.
• A single status field is used and be populated with the substatus value of In Progress or On Hold, if applicable. Otherwise, it is populated with the status value of Open, Assigned, or Completed.
All the places where a To Do status is shown for an existing record, the system will show the substatus of In Progress or On Hold, if populated, otherwise it will show the Status (Open, Assigned or Complete).
The To Do Dashboard > To Dos by Status graph has been enhanced to also break out counts by substatus.
Steps To Enable
Provide the required access before using this feature.
Tips and Considerations
Regardless of whether an implementation has opted into the functionality, you will see that the additional status values are now available in the filter criteria for Status on the To Do Management and To Do Dashboard > Details pages. The filters for other pages, including To Do Search, To Do List, and Supervisor To Do Assignment have not changed to include the substatus values in the filter criteria. In addition, any page that shows a bar with counts of Assigned or Open To Do Entries have not changed to include counts by the substatus values.
Key Resources
Access Requirements
System administrators should set/grant users/grant access to the access modes HDPR (Hold Progress), SPWK (Stop Work) and STPR (Start Progress) for the CILQTDEP application service. If you choose to use this functionality, the recommendation is that this security is granted to all users that use To Do Entry (or none).
To Do Entry Supports Both Creation Process and Routing Process
If a To Do Type is configured with a creation process and a routing process, a To Do Entry based on that type now supports both processes. The creation process is stamped for audit purposes and the routing process is stamped so that the To Do Entry is processed the next time the routing process is run. Previously, although the To Do Type supported configuration for both types of processes, the To Do Entry table could only support a relationship to the creation batch process. The routing process functionality was not possible. To Do Entries created by a batch process may also be marked to be routed to an external system, increasing usability.
Steps To Enable
No steps are required to enable this feature.
Batch Processing Enhancements
This section describes the new and enhanced batch processing features in this release, including:
File Integration Type Writing Multiple Files and Flexibility in File Names
Previously, the plugin-driven extract process was enhanced to allow for the Process Records algorithm to return one or more file names to write the data to. In this release, the capability is extended to File Integration Types. The Extract Process algorithm plug-in spot on the file integration record now also supports returning a file name, allowing for records to be written to a file that differs based on business data, such as CIS Division or service provider. The plug-in spot supports indicating a file name for each schema instance if the use case requires some components of a work unit's information to be written to a separate file.
The ability to indicate that one or more open files should be closed is also supported by the Extract Process plug-in spot. This ensures that batch processes do not cause more than 10 files to be open at a given time for a given thread, which saves on memory allocation.
Steps To Enable
No steps are required to enable this feature.
Log Files for Batch Threads Renamed
The batch log files generated for batch threads, which you can download while viewing the results of a batch run on the batch run tree, are produced using the following format:
• (Batch control).(run number).(re-run number).THD(n).(datetime).stdout|stderr
The values of the batch control, run number, re-run number, n for thread number, and datetime are substituted at runtime. The new format aligns with the format for the logs generated at the batch run level ((Batch control).(run number).(re-run number).(datetime).stdout|stderr).
Previously, the format of these file names was the following:
• (Batch control).(datetime).(pid).THD(n).stdout|stderr
Steps To Enable
No steps are required to enable this feature.
Support for Database Resource Management for Batch Processes
DB Resource Manager tools may be used to prioritize resource allocation between various groups of batch processes. For example, processes like GDE. CMA, ILM etc., may be associated with a lower resource allocation priority relative to more critical batch processes. To support this capability, certain batch controls can be explicitly associated with a Resource Group of three pre-defined priority levels: 10 - High, 20 - Medium, 30 - Low. This definition is made using a new Batch Resource Configuration extendable lookup. The base product does not release values in this extendable lookup, allowing you to set up your own priority references.
When configured, the resource group of a batch control is added as part of the MODULE database session variable as follows: <batch control>,R=<resource group> and can be used as a correlation to a consumer group mapping in Oracle Resource Manager.
With this configuration enabled, DBAs can set up rules that parse the MODULE variable to identify the resource group for a batch process and apply prioritization rules accordingly. Since not all batch controls would be associated with a resource groups, default allocation rules should be considered.
Note: This enhancement does not include nor enforce the DB resource management configuration. It only allows for such tool to be leveraged by DBAs as needed. Refer to the Oracle Database Resource Manager documentation.
In addition, the batch control query portal is enhanced to filter by and display resource group information.
Steps To Enable
To enable this feature, complete these steps:
1. DBA configures DB Resource Manager allocation priority rules by resource group, including a default rule for batch controls not associated with a resource group.
2. Enable this functionality using the new Expose Batch Resource Group option in the General System Configuration feature configuration type.
3. Flush all caches.
Implementation Tool Enhancements
This section describes the new and enhanced implementation tools in this release, including:
Business Object Portal
The Business Object page has been converted to a portal, leveraging a more flexible and extendable user interface metaphor. The portal organizes information in a way that makes it easier to review and understand the configuration that controls business object related functionality.
In addition, the following implementation tasks were simplified by updates in this release:
• When adding a new business object, the schema is automatically generated, along with key UI configuration scripts as needed.
• If the new business object is a subclass of an existing business object, the schema is generated accordingly.
• Introducing a new business object algorithm: This action was available as a context sensitive zone and is now incorporated into the appropriate sections of the portal.
• Deactivating and activating a base product algorithm: This is now a simple action on the algorithms sections of the portal.
• Filtering for algorithms by system event.
• Filtering for options by option type.
Steps To Enable
No steps are required to enable this feature.
Integration Enhancements
This section describes the new and enhanced integration tools in this release, including:
Support for Application Variables in Outbound Message Payload
Some products require that "Application ID" and "Tenant ID" values are included with certain API calls, typically as a way to identify the calling application for reporting purposes. These values are provided to the utility at onboarding time and need to be captured in the application in relation to these API configurations.
As of this release, the Message Sender context information was enhanced to also capture the following application details:
• Application ID
• Tenant ID
The new details are not involved in the process of orchestrating and routing the call. They need to be incorporated into the payload by the application logic that composes the message using the new "Get Application Variables (F1MsgVars)" service script.
Steps To Enable
No steps are required to enable this feature.
Content Migration Assistant (CMA)
This section describes the new and enhanced CMA features in this release, including:
Content Migration Assistant Export by Entity Tag
You can now use entity tags to identify entities to export using Content Migration Assistant (CMA). The criteria based migration request functionality is enhanced to support a tag based export instruction as a way of exporting all entities associated with an entity tag.
This allows developers to collate their extensions in a similar way to bundling, but it harnesses the power of the Content Migration Assistant engine.
Steps To Enable
No steps are required to enable this feature.
Improved Support for Large Numbers of SQLs in Migration Object
When importing an object into an environment using Content Migration Assistant (CMA), the product supports selecting one or more SQLs associated with the object and suppressing them. At the apply stage, these SQLs are not included. This is useful when your object has one or more child rows that you prefer not to include in the target environment. In this release, the steps for selecting and marking records to suppress or unsuppress have been enhanced to support objects that have a large number of child records, and therefore a large number of SQLs. Now, instead of clicking Edit in the Migration Object main display zone, the List of SQL Statements zone now has Suppress and Unsuppress actions. You can use the filters on this zone to narrow down the results, select the appropriate records, and click the desired action.
Additional changes were made to the List of SQL Statements zone to better support a large number of records:
• The zone is now configured for Pagination, showing 500 records for a page.
• Additional filter values have been added. You can now do a likable search on the SQL statement text. In addition, you can limit to the results to excluded suppressed rows or to only show the suppressed rows.
Steps To Enable
No steps are required to enable this feature.
Improved Base Product Content Migration Assistant Requests
Previously, some base product migration requests were inefficiently exporting all records of an entity, including many base owned records where the maintenance object did not include fields that could possibly contain customized content. Exporting so many of these entities placed a performance burden on the import step to load, compare, and eventually not apply them.
The following migration requests were enhanced to be more efficient and only export custom-owned entities for maintenance objects that do not contain custom fields:
• F1-SystemConfig
• F1-SecurityConfig
• F1-SecurityConfigWithoutUsers
• F1-Tags
• F1-MigrationAdmin
• F1-IntegrationConfig
Steps To Enable
No steps are required to enable this feature.
Web Services Enhancements
This section describes the new and enhanced web services features in this release, including:
Define Default Template User for User Provisioning
The F1-OIMUSR (Populate User Data from a "Template" User) algorithm was enhanced to allow a Template User to be provided as a parameter. The algorithm is used by the User business object F1-IDMUser, which is used to create users from an external source. For example, the LDAP batch process uses this business object to create a user. The algorithm to copy information from a template user allows application configuration, such as user groups, user preferences, To Do roles, and other information not supplied by the external system, to be populated on the new user. Previously, this algorithm relied on the value of the template user to be provided as part of the payload for adding the user, using a characteristic. In this release, the algorithm first checks for a template user provided as a characteristic. If it is not found, it uses the template user provided as a parameter to the algorithm, if populated.
Steps To Enable
To enable this feature, complete these steps:
1. Go to Admin > Security > User in add mode and define the template user whose application configuration should be copied onto any new user.
2. Go to Admin > System > Algorithm.
3. Search for and select the algorithm F1-OIMUSR.
4. Click Edit, and then click the + in the Algorithm Parameter collection.
5. Enter an appropriate effective date and the Template User created above.
Improved Handling of Null Values in REST APIs
Date and time elements in requests and response messages require special handling when they contain no value. Unlike a string value, no value for date, time, and date/time elements has to be represented as null and not an empty string. In the same way, a numeric or Boolean element with "no value" should be represented as a null, not an empty string. Previously, the application did not properly accept null values for date and time elements in a JSON request. The application incorrectly represented such values in a JSON response as empty strings. The application correctly handled null values for numeric and Boolean elements except for a few outlier situations that were also fixed as part of this enhancement.
In this release, the Inbound Web Service REST engine v2 is enhanced to properly accept and process null values for elements of all data types.
The following clarifies some differences around request and response processing:
• As part of a request document, any element of any data type can be sent in with a null value, whether via the nil attribute in XML or the null value in JSON.
• As part of a JSON response document, empty node elements would be removed from the response or assigned either a null or empty string based on their data type:
• A string element would always be assigned "" an empty string. This include all types of string data types like lookup, etc. This already works this way, no change in this release.
• A date, date/time, time element would have a null value.
• A number, money element is consistently removed from the response. Previously, this was not the same for some outlying scenarios.
• A Boolean element is consistently removed from the response. Previously, this was not the same for some outlying scenarios.
Steps To Enable
No steps are required to enable this feature.
Improved Message Sender Context Customization
For most integrations supported by the base product, the end point URL and other details may only be provided by the utility at provisioning time. Previously, the entire message sender definition for such integration point had to be defined by the utility along with the configuration of the external system record that references the message sender.
As of this release, partially defined message senders may be released with the base product, allowing utilities to complete the definition with the necessary context information. This also allows the base product to include a more comprehensive configuration that includes the external system record that references the message sender.
Steps To Enable
No steps are required to enable this feature.
Support Language in REST Request
The REST engine considers the information populated in the Accept-Language header attribute. If a single value is provided, the system checks if the application has that language as a supported language in the application. If so, it returns translatable text in that language. The system looks for an entry in the Language table where the Locale field matches the value passed in Accept-Language.
If multiple entries are provided in the Accept-Language, the system uses HTTP content negotiation to select one of the provided values. If no supported language is found for the Accept-Language content, the system returns information in the language of the system user used to make the REST call.
Steps To Enable
No steps are required to enable this feature.
User Provisioning Using the SCIM Open Standard
A new REST service, SCIM User Provisioning (F1-SCIMUser), is provided to support adding, changing, or viewing the details of a user where the API follows the SCIM standard.
The following highlights some of the mapping between the SCIM API and the application's user record:
• The user record in the application supports only first name and last name. The SCIM standard supports additional detail such as middle name, suffix, and prefix. These elements are ignored when adding or updating a user.
• The SCIM standard supports a collection of email addresses. The application only supports one email address. As such, only the first email address is used when adding or updating a user.
• A user in the application requires several application specific settings in order to be added properly. When adding a user record via the Create User operation in this new REST service, the integration supports supplying a Template User reference (in the user type element in the API). The system copies application settings from that user to the new user being provisioned.
Steps To Enable
Provide the required access before using the feature.
Tips and Considerations
The inbound REST web service provided is F1-SCIMUser. Refer to its description along with the help text on the various elements for more information on using the REST service.
You need to define a template user in order to successfully add a User record via this REST service. The template user can be provided in the userType element. Alternatively, you can define the Template User as a parameter to the algorithm F1-OIMUSR (Populate User Data from a "Template" User). Refer to the separate feature "Define Default Template User for User Provisioning" for more information.
Access Requirements
System administrators should set/grant users/grant access to the Execute access mode on the CILTUSEP application service for the web service user that calls the new REST web service.
Miscellaneous Enhancements
This section describes the new and enhanced miscellaneous features in this release, including:
Adjusted Locale for English Language
As more integrations use the Locale as the standard method to determine a language, the product is adjusting the value defined for the default language row (ENG - English) to use the generic locale "en", instead of the more specific "en-US".
The default record's configuration is now aligned with the typical browser configuration for English.
Steps To Enable
No steps are required to enable this feature.
Oracle Utilities Application Framework Deprecation Notices
This section provides information on functionality that has been removed, is no longer supported by Oracle Utilities Application Framework v4.5.0.1.2, or is planned for removal.
Deprecated Items
There are no deprecated functionality or system data for Oracle Utilities Application Framework v4.5.0.1.2.
Items Planned for Future Deprecation
This is a list of functionality / system data that Oracle plans to deprecate in a future release.
Support for Previous User Experience
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 Metadata and Database Tables
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.
Mobile Application Framework Metadata
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.
Key Ring Validation Scripts, Algorithm Types, and Algorithms
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.
• Algorithm
• K1-KRDCKFS
• K1-KRINCKFS
• Algorithm Type
• KRDCKFS
• K1-KRINCKFS
• Message
• 11009 / 1402
• Plugin Script
• K1-KRDCKFS
• K1-KRINCKFS
• Service Script
• K1-ChkCfgExL
UI Metadata Related to Converted Pages
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.
• To Do Entry Maintenance
• toDoEntryCharGrid
• toDoEntryDrillKeyValuesListGrd
• toDoEntrySortKeyValuesListGrid
• todoentrykeyvalue
• todoentrymain
• toDoEntryMaint
• toDoEntryPopupAdd
• toDoEntryPopupForward
• toDoEntryPopupSendBack
• Any help navigation keys
• Table Maintenance
• metaDataTableFieldsGrid
• metaDataTableMainPage
• metaDataTableCFldsGrid
• metaDataTableConstPage
• metaDataTableMaint
• metaDataTableRefByConstPage
• metaDataTableFieldPage
• Any help navigation keys
• Work Calendar Maintenance
• workCalendarMaint
• workCalendarMainPage
• workCalendarHolidayGrid
• Any help navigation keys
• Message Maintenance
• msgMaintDetailsPage
• msgMaintGrid
• msgMaintPage
• msgMaintTabMenu
• Any help navigation keys
• Time Zone Maintenance
• timeZoneMainPage
• timeZoneTabMenu
• Any help navigation keys
• Application Security Portal
• f1appsecTabMenu
• Display Icon Portal
• displayIconRefMaint
Miscellaneous System Data
The following metadata is no longer in use and will be removed in a future release:
XSLT Managed Content Type
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.
REST IWS - Original REST Servlet
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.
Append Setting from Pagination
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.
Support for Master/Subordinate Servers for Web Service Catalog
The Service Catalog Configuration (master configuration) enables you to define subordinate servers. Defining subordinate servers is no longer applicable for the Oracle Integration Cloud.
Batch Run Statistics Portal Functionality
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.
F1-MAINPROC Business Object Read When Pre-processing Exists
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.