Oracle Cloud Support

The Oracle Utilities products are progressively being implemented on Oracle Cloud in both Software as a Service (SaaS) and Platform as a Service (PaaS). This has resulted in new cloud-based configurations and features. These features are also available for customers with customers with on-premise and hybrid implementations. This section will outline the additional configuration facilities that can be used for on-premise implementations.

Support for host allow listing

The hosts and port numbers used by the feature sets in your application are typically restricted in scope for on-premise products but on the cloud, the ports and hosts can be restricted to ensure compliance. The product supports the configuration of the hosts and ports, that are accessible from the online system, can be specified in a allow list which is validated at configuration time and runtime.

Note: URL's within configuration files are subject to deployment restrictions within the deployment facility itself.

Oracle Utilities Application Framework applications now support allow listing of URIs with schemes such as t3, t3s, ldap, ldaps, jdbc, etc. URI allow listing can be enabled by setting the com.oracle.ouaf.uriValidation.enable parameter in the spl.properties file to true. Once enabled, it is possible to limit the values of URL's within the product for key objects with the configuration. This is implemented as an allow list that can filter on scheme (aka protocol), hosts and ports. These are checked at runtime and can generate an error if they do not adhere to the allow list.

The feature allows for the following:

• Individual scheme hosts and port combinations can be configured to limit runtime access for specific features.

• Specification of the (*) wildcard is supported for scheme, hosts and ports.

Note: Custom allowlists are not supported on Oracle Utilities SaaS Cloud Services.

There are several configuration settings (ENVIRON.INI) that control the allow list:

• CLOUD_RESTRICTION_URLS_ENABLE - Whether the allow listing feature is used or not (default is false). See com.oracle.ouaf.web.allowCORS - Enable Cross Origin Resource Sharing for details.

• CLOUD_WHITE_LIST_PATH - The full path to the allow list file for Oracle Cloud. This variable should not be populated for on-premise implementations. This is only used if CLOUD_RESTRICTION_URLS_ENABLE is set to true. See com.oracle.ouaf.whitelist.file – Oracle URL Allow List Filename and Location for details.

• CLOUD_CUSTOM_WHITE_LIST_PATH - The full path to a custom allowlist for Oracle Cloud or on-premise implementations. This is only used if CLOUD_RESTRICTION_URLS_ENABLE_CLOUD_RESTRICTIONS_URLS_ENABLE_-_En is set to true. See com.oracle.ouaf.customer.whitelist.file – Customer’s URL Allow List File for details.

The format of the allow list is an XML format document:

Attribute	Comments
<uri>	URI tag
<path>	Specific path on the host.
<host>	Host name or IP Address for host. Wildcards are supported. IPV4 and IPV6 formats are supported.
<port>	Port Number. Wildcards are supported.
<scheme>	Protocol supported (HTTP or HTTPS support). Wildcards are supported.

For example:

<?xml version="1.0" encoding="UTF-8"?>

<uri>

<host>myhost.example.com</host>

<scheme>HTTPS</scheme>

</uri>

<uri>

<host>myhost2.example.com</host>

</uri>

</whitelist>

There must be a separate entry for each host, path, port and scheme combination. Oracle Utilities Application Framework applications now support allow listing of URIs with schemes such as t3, t3s, ldap, ldaps, jdbc, and so on.

The table below indicates when validation is performed for the following components:

Component	Design Time Validation	Run Time Validation
Message Sender Context	■
JNDI Server	■
Web Service Adapter	■	■
Feature Configuration	■
Reporting Options	■
External Navigation Keys	■	■
HTTP Sender		■
Real Time HTTP Sender		■
JSON Sender		■
Real Time Email Sender		■
JMS Sender		■
SMS BPEL Sender		■
Web Services (WSDL, OPA etc)

Support for URI Specification using Substitution Variables

Applications need to define URI links to the integrate components for seamless navigation to different application pages, for map viewer, etc. URI specifications can now include substitution variables to allow parameterization of URI components.

This new enhancement featuring substitution variables ensures support for secure, stable and uniformly configured environments. For configuration stability such URL values will be defined using substitution variables, aka aliases. E.g. "@CCB@/demoprop/cis.jsp" . This would help in migrating values between different environments, e.g. from CCB Test to CCB Prod environment, and in performing CMA extracts that would allow to pull URL values that are not environment specific.

A substitution list is provided to implement the physical path per environment. This file is maintained in $SPLEBASE/etc/substitutionVariableList.xml.

The substitution list file can be specified using then CLOUD_SUBSTITUTION_VARIABLE_LIST_FILE_LOCATION config parameter in the ENVIRON.INI file.

Following is the format of the substitution variables file:

<?xml version="1.0" encoding="UTF-8"?>

</uriVariable>

</substitutionVariables>

Attribute	Comments
<uriVariable>	URI Variable tag
<name>	The name of the substitution variable.
<value>	The URI(URL/Path) of the substitution variable.

uriVariable element has the attribute "allURIChildComponentsAreValid" with allowed values being true or false. If the attribute value is set to false, then the uriVariable value needs to be verified against the white list after the variable is replaced with the actual value. If the allURIChildComponentsAreValid is set to true, or is omitted, then this indicates that the variable value is already white listed and there is no further validation of the uri and all its child components (such as path, query and fragement) is needed.

Note: The default behavior is true.

The URI specification feature automatically includes the variable SPLOUTPUT. This is a system variable commonly defined with a valid file path that implementations may write files to. Automatically providing the configuration for this variable provides backward compatibility for any code that supported referencing "@SPLOUTPUT@" for a file location.

The SPLOUTPUT variable is automatically identified and substituted without having to explicitly define it in the substitution variable XML file.

For example:

<?xml version="1.0" encoding="UTF-8"?>

<name>F1_INTERNAL_FILES</name>

<value>/scratch/OUAF/sploutput/Files/Shared</value>

</uriVariable>

<value>/usr/OUAF/CustomerFiles</value>

</uriVariable>

<value>http://ccbenvurl.oracle.com:8001</value>

</uriVariable>

The following substitution variables are provided by default in OUAF:

• F1_CMA_FILES

• F1_BASE_REST_URL

• F1_BASE_IWS_URI

• F1_BASE_WEB_URI

• CSP_FRAME_ANS_HOST1

• CSP_FRAME_ANS_HOST2

Note: For CORS if more than 2 frame ancestors are needed, add additional substitution variables. Example: CSP_FRAME_ANS_HOST3.

• FA_DOMAIN

• ALM_DOMAIN

• F1_OPEN_API_BASE_URL

The below substitution variables are also provided by default, but no product functionality is using them. In a future release there, variables will no longer be delivered (to remove any ambiguity). Implementation are suggested not to use the any of the below names, but should rather use CM variable names.

• F1_BI_EXTRACTS

• F1_INTERNAL_FILES

• F1_CUST_APP_BASE

• F1_PROCESS_DIR

• F1_SVC_CATALOG_WSDL_DIR

• F1_PDB_EXTRACTS

Note: The list must not contain variables and file paths that contain internal product infrastructure. For example, configuration files, binaries, properties, security info and others.

Note: The list must not contain existing environment variables such as SPLEBASE, COBOL_RUNTIME_LIB, and their corresponding application directories.

Defining File Alias Using Extendable Lookup

In addition to the above-mentioned support for URI specification using substitution variables, an alternate option has been provided that allows for defining native file storage locations using an extendable lookup. The F1-FileStorage (File Storage Configuration) extendable lookup has been provided. Using this extendable lookup, a value may be defined referencing the Native File Storage file adapter option and then defining the file path that this value represents. The file path field follows the same rules as any other file path. For example, it can reference "@SPLOUTPUT@" or any other value defined in the Substitution Variables properties file. In addition, if the system has been configured to validate the value against an allow list, this is also enforced.

A new syntax has been defined for referencing file locations during configuration, for example in File Path parameters for a batch control:

file-storage://{ExtendableLookupValue}

Refer to the online help for more information about the supported syntax.

Support for Oracle Cloud Storage Access

The system has been enhanced to allow code that reads or writes files to reference an Oracle Cloud Storage location (container) rather than the native file system. The extendable lookup F1-FileStorage (File Storage Configuration) has been provided to support this. Using this extendable lookup, a value may be defined referencing the "Oracle Cloud Object Storage" file adapter option. With that configuration, your implementation may define the REST Endpoint URL, user name and password for accessing the storage location.Using this configuration, the same syntax described above may then be used when defining a File Path in the application, for example a parameter for a batch control.

file-storage://{ExtendableLookupValue}/{serviceName}

Refer to the online help for more information about the supported syntax.

Consolidated logging

Note: This feature only applies to clustered environments of your application.

Utilities products provisioned on the cloud would be hosted across multiple cluster nodes. The Application server or the Inbound Web Services could be spread across multiple nodes making their corresponding logs, distributed. Inorder to debug or to monitor the application components, users are provided with a consolidated view of these distributed logs.

Oracle Utilities Application Framework leverages RSysLog to accomplish the task to consolidate the distributed logs.

Note: The configuration and usage of RSysLog is not covered in this document.

Users can configure the location of the distributed logs using the ‘com.oracle.ouaf.consolidatedLog.fileName’ parameter in the spl.properties file. If configured, the consolidated logs would be picked up from the specified logs file and displayed to the user.

The RSysLog should be configured to retrieve the distributed logs and consolidate them into the log file specified against the com.oracle.ouaf.consolidatedLog.fileName property.

Diagnostics Support (WLDF)

Note: Refer to Configuring and Capturing Diagnostic Images for additional advice.

Oracle WebLogic includes a diagnostics capability in the form of Oracle WebLogic Diagnostics Framework (WLDF). Typically, most diagnostics tools only detect an issue after it has happened, which means important diagnostic information may not be captured. The WLDF captures information at the time of the issue and after to provide additional diagnostics in a standard format for inclusion in diagnostic tools built into Oracle products and for Service Requests within My Oracle Support.

The diagnostic engines work in the following way:

• The diagnostics facility is enabled to capture information. As part of that enablement the location of the diagnostics is configured.

• A set of rules are added to configure the diagnostics engine to recognize issues that are above and beyond the typical issues. WLDF detects common java issues automatically.

• When a rule or the diagnostic engine detects an error is occurring or has occurred, it gathers as much diagnostics information it can at the time of the error and creates a diagnostic image which assembles the diagnostics information into a structured format. This is placed in the configured location.

• Diagnostic images are available from the console as well as Oracle Enterprise Manager where they can be viewed, analyzed and attached to Service Requests as necessary.

Oracle Utilities Application Framework applications now support the WLDF using the following:

• A set of configuration settings that enable the support as well as set some basic settings. These settings are primarily used for embedded installations. For native installations, the WLDF definitions are included in the domain templates provided.

Note: For customers with preexisting native installations wanting to use this facility, it is recommended to enable the facility in an embedded installation and manually make the changes to your domain to match the settings using the Oracle WebLogic console or Oracle Fusion Middleware console.

• A set of base rules to instruct WLDF the conditions to track and detach issues. These are customizable rules for Oracle WebLogic to detect any issues outside of typical issues.

The following parameter controls the implementation of the Diagnostics Framework:

• WLS_DIAGNOSTIC_CONTEXT_ENABLED - This enables (true) or disables (false) the diagnostics generation support in the product. See WLS_DIAGNOSTIC_CONTEXT_ENABLED - ECID Support for details.

For native installations, the following process should be used from the Oracle WebLogic console to enable support:

• Navigate to the Environment, Servers menu item and click on the product server name to enable.

• In the Configuration tab, change the value of Diagnostic Volume to the desired level of diagnostics. It is recommended to use Low as a minimum. Save the changes and repeat for each product server (if multiple are implemented in the domain).

• Navigate to the Diagnostics, Built-in Diagnostics Modules menu item and select the product servers. Click on the Activate button to enable basic diagnostics. This should change the Status to Active.

• If a custom Diagnostic Module is to be used, then navigate to the Diagnostics, Diagnostic Modules menu item and select the desired diagnostic module to maintain. From the Targets tab, select the product servers to apply the desired diagnostics module. Save the changes.

ECID Support

Note: This feature only applies to Oracle WebLogic 12 and above implementations only.

Oracle WebLogic includes a set of facilities to add additional information to transactions known as the Execution Context Identifier (ECID). The single ECID is attached to each unique transaction within your application. This allows diagnostic tools to perform forensic analysis based on the identifier across the architecture.

There are a set of rules that apply to the ECID within the application:

• A unique ECID is generated at the start of a transaction within the product. This ECID is active for all calls within the product till a COMMIT or ROLLBACK is issued by the product. This constitutes a transaction boundary within the product.

• The ECID is only generated for online web based transactions in the present release.

• The ECID is used within the logs, diagnostic images and transaction tracking facilities within Oracle WebLogic and the related database connections.

• The use of ECID is optional and disabled, by default, for backward compatibility.

• The ECID is used by the various Oracle diagnostics tools such as Oracle Enterprise Manager, JVMD and Business Transaction Management.

Note: This is only supported when using Oracle WebLogic JDBC Data Sources. It is not supported for UCP at the present time.

The following parameters control the implementation of the Diagnostics Framework:

• WLS_DIAGNOSTIC_CONTEXT_ENABLED - This enables (true) or disables (false) the diagnostics generation support in the product. See WLS_DIAGNOSTIC_CONTEXT_ENABLED - ECID Support for details.

For native installations, the following process should be used from the Oracle WebLogic console to enable support:

• Navigate to the Diagnostics, Context menu item.

• Select the product servers and click on Enable to enable ECID support.

• The status of the selected servers should change to Enabled.

Global Cache Flush Support

One of the architectural features of Oracle Utilities Application Framework applications is the support for caching commonly used data. This cache is used to prevent the transactions to perform unnecessary calls for commonly used data. This cache is loaded and maintained by the product automatically.

In some cases, it may be necessary to force a refresh of the cache to reload the static data. Whilst a number of utilities are provided to flush the online/web services cache as well as the batch cache, if there were a number of servers or threadpools then the cache request may have to be performed on each threadpool or server.

In the current release any cache request can be configured to flush all caches, known as a global flush, across the architecture. Use of this facility is optional, but recommended in production environments to ensure consistent processing.

To use this facility the following must be configured:

• The ouaf.flush.jms.disabled property in the spl.properties file must be set to false. See ouaf.flush.jms.disabled - Global Flush Supported for details.

• The ouaf.flush.jms.connection, ouaf.flush.jms.requestTopic and ouaf.flush.jms.responseTopic properties must be populated in the spl.properties with the JMS resources used. These JMS resources must be created within the domain of the product. See ouaf.flush.jms.connection - Connection Factory for Global Flush, ouaf.flush.jms.requestTopic - Global Flush Request Topic and ouaf.flush.jms.responseTopic - Global Flush Response Topic.

Once enabled all flush requests now are global.

The global flush operates in the following way:

• When a flush is requested from the online using the JSP or JMX facility, Web Services through JMX, and batch ran through F1-FLUSH, an entry is placed in the JMS Topic dictated by ouaf.flush.jms.requestTopic - Global Flush Request Topic.

• Each of the components of the architecture has subscribed to the JMS resource specified by ouaf.flush.jms.requestTopic - Global Flush Request Topic at their startup time.

• When they receive a message in that topic, each component flushs their cache according to their local methods and sends an appropriate response in the JMS resource specified by ouaf.flush.jms.responseTopic - Global Flush Response Topic indicating success or failure. This JMS resource may be monitored using the Oracle WebLogic console, Oracle Enterprise Manager, a JMS Browser or the JMS Viewing facility within the product.

Note: It is possible to configure additional features of the JMS resources outlined above to decide on retention periods and other settings. Refer to the Understanding Oracle WebLogic JMS documentation for additional features.

Java Flight Recorder Support

Note: This feature only applies to Oracle JDK 7u60 and above implementations only.

Note: If Java Flight Recorder is enabled then these will also be included in Diagnostic Images if Diagnostics is enabled.

The Java Flight Recorder is a component of Java that collected diagnostic and profile data for a running Java Virtual Machine (JVM). Oracle Utilities Application Framework applications now support the enabling of the Java Flight Recorder for tracking online java performance.

To enable the support for Java Flight Recorder in a native installation the following process must be performed on the Oracle WebLogic console:

• Navigate to the Environment, Servers menu item. Click on the product server to enable configuration.

• Navigate to the Server Start tab on the Configuration tab and add the following java options to the Arguments field.

-XX:+UnlockCommercialFeatures -XX:+FlightRecorder

Note: If your site is using the setUserOverrides.sh facility, place these arguments in that script as an alternative.

• Navigate to the General tab on the on the Configuration tab and alter the Diagnostics Volume to the desired number of diagnostics to capture. At a minimum this value should be set to Low.

• Optionally, enable ECID tracking for advanced diagnostics for tracing individual transactions. See ECID Support for details.

Edit any Diagnostic Modules you are using, or create one if you are not using a module and configure a DyeInjection Monitor as outlined in Configuring the DyeInjection Monitor to Manage Diagnostic Contexts. Filters may be specific to focus the scope of the monitor if desired.

Work Manager Support

Note: This feature applies to native installation implementations only.

Oracle WebLogic supports WebLogic Server Work Managers, which allows implementations to set limits on the server to help optimize performance and prevent server overloading. Oracle Utilities Application Framework applications now allow specification of Work Managers to provide additional throttling capabilities.

To use this feature the following must be performed within the Oracle WebLogic console:

• Create a Work Manager with an appropriate name using the Environment, Work Managers menu item. Target the Work Manager to the product servers using the Targets tab. By default, the Work Manager will be unlimited and have no restrictions.

• The product supports the following constraints:

• Minimum Threads Constraint

• Maximum Threads Constraint

• Capacity Constraint

• It is also possible to override the action used for Stuck Threads.

• Request Class is currently not supported.

• Save the changes.

Work Managers can be monitored using Oracle WebLogic console or Oracle Enterprise Manager. Refer to the WebLogic Server Work Managers documentation for additional information.

Trust Store Support

Note: For more information about trust stores refer to the JSSE documentation and Keystore Configuration (Doc Id: 2014161.1).

Oracle Utilities Application Framework applications now support trust stores as well as key stores for two phase authentications for the online web channel. The format of a trust store is the same as the keystore, but the trust store is used to verify credentials whilst the keystore provides the credentials.

The truststore properties are defaulted in the following user exit file:templates/FW_spl.properties.keystore.truststore.include

If you need to customize any of the properties refer to the “Centralized Properties Customization” section in the OUAF installation document.