Oracle Utilities Adapter Capabilities

The Oracle Utilities Adapter lets you integrate the Oracle Utilities application suite with other Oracle applications such as Oracle Enterprise Resource Planning (ERP) and Oracle Field Service (OFS).

The Oracle Utilities Adapter provides the following capabilities:

Provides trigger (inbound) and invoke (outbound) support. This functionality enables other applications to trigger an integration in Oracle Integration or invoke an Oracle Utilities application using web services from Oracle Integration.
Exposes both inbound and outbound services using the Oracle Utilities service catalog. This catalog provides a simplified user experience to create data mappings at design time while exposing inbound and outbound web services of the utilities applications.
Exposes every inbound and outbound service structure using a SOAP-based WSDL or REST OpenAPI URL-based connection.
Integrates with on-premises Oracle Utilities applications using the on-premises connectivity agent.
Supports connecting to private resources that are in your virtual cloud network (VCN) with a private endpoint. See Connect to Private Resources in Provisioning and Administering Oracle Integration 3 and Configure the Endpoint Access Type.
Supports private endpoints for both SOAP and REST endpoints for invoke and trigger connections.
Enables you to implement the following message exchange patterns on inbound SOAP and inbound REST endpoints:
- Synchronous request/response
- One-way request
See Asynchronous Trigger Support in Orchestrated Integrations.

SOAP and Secure WSDL Support

The Oracle Utilities Adapter provides secure WSDL support. You can create SOAP-based integrations using the Oracle Utilities Adapter with a SOAP catalog of inbound/outbound services exposed by an OUAF application.

The Oracle Utilities Adapter works with a SOAP catalog exposed in the Oracle Utilities Application Framework (OUAF) in the cloud using a SOAP proxy.
SOAP proxy and OUAF changes for the cloud are made so that the behavior of the SOAP catalog is similar as in on-premises environments except for the following important changes:
- The WSDL to retrieve the catalog is secured by default. Therefore, the credentials must be passed to retrieve the WSDL.
- Individual WSDLs of all services exposed by the SOAP catalog are secured by default. Therefore, credentials must be passed to retrieve the WSDL.
- The WSDL link used to retrieve the catalog and individual WSDLs is different. It points to the SOAP proxy server. For example:
```
https://host:port/soap/api/iws/ServiceCatalog?WSDL
```
- The endpoint within the WSDLs also points to the SOAP proxy. For example:
```
https://host:port/soap/api/iws/ServiceCatalog
```
The Oracle Utilities Adapter supports use of the following security policies for SOAP:
- Username Password Token
- Basic Authentication
- OAuth Client Credentials (cloud and on-premises)
- OAuth using JWT User Assertion (only for nonagent connections)
- OAuth Client Credentials using JWT Client Assertion (only for nonagent connections

Whenever you use the secured/protected WSDL from a cloud environment, ensure that the security policy for SOAP-based integrations is either Basic Authentication or OAuth Client Credentials.

See Configure Connection Security.

REST Support

The Oracle Utilities Adapter provides REST support. You can create REST-based integrations using the Oracle Utilities Adapter with an OpenAPI URL-based catalog of inbound/outbound services exposed by an OUAF and non-OUAF (NMS) application.

Using the Oracle Utilities Adapter as an invoke connection in an integration invokes the inbound OUAF or non-OUAF (NMS) REST web services.
Using the Oracle Utilities Adapter as a trigger connection in an integration consumes an outbound message from an OUAF or non-OUAF (NMS) application.
The Oracle Utilities Adapter consumes inbound and outbound REST-based services that are available as part of an OpenAPI URL provided by OUAF and non-OUAF (NMS) applications.
The Oracle Utilities Adapter supports REST service versions 1.0 and 2.0 of inbound web services.
The Oracle Utilities Adapter supports use of the following security policies for REST:
- Basic Authentication
- OAuth Resource Owner (only for invoke and nonagent based connections)
- OAuth Client Credentials
Only a JSON payload is supported. An XML payload is not supported.
Support is provided for HTTP methods GET, PUT, POST and PATCH.

Note:

The Oracle Utilities Adapter supports REST services on Oracle Utilities Application Framework (OUAF) version 4.5 or greater.

Support for Swagger 2.0 is removed in Oracle Utilities Adapter version 24.04.0 or higher. Use OpenAPI 3.x catalogs for connections. See Using the Swagger 2.0 REST Catalog with Oracle Utilities Adapter Version 24.04.0 or Higher.

Catalog format for an OUAF application.

https://host:port/ouaf/rest/ouaf/openapi/iws/catalog

https://host:port/../../../rest/openapi/iws/catalog

Catalog format for a non-OUAF (NMS) application.

https://host:port/nms-application_code/rest/v1/catalog

Where:

###application_code is code for application. Please refer to non-OUAF application documentation for the application code.

OAuth 2.0 Support

The Oracle Utilities Adapter supports the Open Authorization (OAuth 2.0) security policy for REST- and SOAP-based connections.

This support enables you to configure the Oracle Utilities Adapter to consume an OpenAPI 3.x API for REST and secured and nonsecured WSDLs for SOAP protected with OAuth 2.0. This policy is useful when the Basic Authentication security policy does not meet your security needs.

Note:

The OAuth Resource Owner Password Credentials policy is supported only for REST nonagent-based connections.

See Configure Connection Security.

JWT Client and User Assertions Support

JWT client and user assertions with OAuth Client Credentials are supported with the following security policies:

OAuth Client Credentials using JWT Client Assertion security policy
OAuth using JWT User Assertion security policy

JWT assertions enable you to invoke a service provider that does not regard an OAuth client secret as secure. Trust is established with a key-pair exchange instead of a client secret.