The Oracle Utilities Adapter lets you integrate the Oracle Utilities application suite with other Oracle applications such as Oracle Enterprise Resource Planning (ERP).
Integrate on-premise Oracle Utilities applications with Oracle Cloud applications.
Integrate Oracle Utilities Customer Care and Billing with Oracle ERP Cloud.
Integrate Oracle Service Order Management with Oracle TOA Field Service.
The Oracle Utilities Adapter provides trigger (inbound) and invoke (outbound) support. This enables Oracle Utilities Applications to trigger an integration in Oracle Integration or invoke an Oracle Utilities Application using web services from Oracle Integration.
Both inbound and outbound services are exposed using the Oracle Utilities service catalog. This catalog provides a simplified user experience to create data mappings at design time while constructing integrations with utilities applications using the Oracle Utilities Adapter.
Every inbound and outbound service structure is exposed using a SOAP-based WSDL. (No support for REST.) Only synchronous invocations of utilities web services are currently supported.
You can also manually upload a WSDL in the trigger (inbound) direction for a specific service instead of parsing the WSDL from the HTTP-based service catalog WSDL specified on the Connections page. This option enables you to upload a WSDL for a particular service in which element-to-element mappings can be performed to deal with
Integrating with on-premises Oracle Utilities applications can be done using the on-premises agent.
Secure WSDL Support
The Oracle Utilities Adapter provides secure WSDL support.
- The Oracle Utilities Adapter works with the new 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:
- The endpoint within the WSDLs also points to the SOAP proxy. For example:
Whenever you use the secured/protected WSDL from a cloud environment, ensure that the security policy for SOAP-based integrations is Basic Authentication.
The Oracle Utilities Adapter provides REST support.
- Users of the Oracle Utilities Adapter can either create the integration using a SOAP catalog URL or REST Swagger definition URL-based connection.
- The existing SOAP catalog works as is and only fetches SOAP-based inbound and outbound services that are available in the SOAP catalog.
- The Oracle Utilities Adapter consumes inbound and outbound REST-based services that are available as part of the Swagger definition URL provided by OUAF.
- For each REST interface (inbound or outbound), an OpenAPI/Swagger definition URL is provided to Oracle Integration as part of the catalog.
- The OpenAPI/Swagger specification describes the REST interface.
- The current version of Oracle Integration supports only the Swagger Version 2 specification for the REST Adapter. Therefore, the Oracle Utilities Adapter should receive Version 2 of the Swagger document.
- Using the Oracle Utilities Adapter as an invoke connection in an integration invokes the inbound OUAF REST web services.
- Using the Oracle Utilities Adapter as a trigger connection in an integration consumes an outbound message from OUAF.
OAuth 2.0 Support
The Oracle Utilities Adapter supports the Open Authorization (OAuth 2.0 ) security policy for REST-based connections.
This enables you to configure the Oracle Utilities Adapter to consume a Swagger 2.0 API protected with OAuth 2.0 Token-Based Authentication. Under Token-Based Authentication, OAuth Resource Owner Password Credentials are supported. This policy is useful when the Basic Authentication security policy is not sufficient.
Most HTTP or HTTPS services typically use the OAuth authorization framework to protect their resources. In accordance with the OAuth 2.0 specification, the OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service. This is either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service or by enabling the third-party application to obtain access on its own behalf.