Create a Connection

Before you can build an integration, you must create the connections to the applications with which you want to share data.

To create a connection in Oracle Integration:

1. In the navigation pane, click Design, then Connections.

2. Click Create.

   Note:

   You can also create a connection in the integration canvas. See Define Inbound Triggers and Outbound Invokes.

3. In the Create connection panel, select the adapter to use for this connection. To find the adapter, scroll through the list, or enter a partial or full name in the Search field.

4. Enter the information that describes this connection.

   Element	Description
   Name	Enter a meaningful name to help others find your connection when they begin to create their own integrations.
   Identifier	Automatically displays the name in capital letters that you entered in the Name field. If you modify the identifier name, don't include blank spaces (for example, SALES OPPORTUNITY).
   Role	Select the role (direction) in which to use this connection (trigger, invoke, or both). Only the roles supported by the adapter are displayed for selection. When you select a role, only the connection properties and security policies appropriate to that role are displayed on the Connections page. If you select an adapter that supports both invoke and trigger, but select only one of those roles, you'll get an error when you try to drag the adapter into the section you didn't select. For example, assume you configure a connection for the Oracle Service Cloud (RightNow) Adapter as only an invoke. Dragging the adapter to a trigger section in the integration produces an error.
   Keywords	Enter optional keywords (tags). You can search on the connection keywords on the Connections page.
   Description	Enter an optional description of the connection.
   Share with other projects	Note: This field only appears if you are creating a connection in a project. Select to make this connection publicly available in other projects. Connection sharing eliminates the need to create and maintain separate connections in different projects. When you configure an adapter connection in a different project, the Use a shared connection field is displayed at the top of the Connections page. If the connection you are configuring matches the same type and role as the publicly available connection, you can select that connection to reference (inherit) its resources. See Add and Share a Connection Across a Project.

5. Click Create.

   Your connection is created. You're now ready to configure the connection properties, security policies, and (for some connections) access type.

Configure Connection Properties

Enter connection information so your application can process requests.

1. Go to the Properties section.
2. Specify the following details.

   Element	Description
   WSDL URL	Specify the URL in either of two ways: Click Upload , then click Browse to select the WSDL to upload. If you upload a ZIP file, the file is validated and the page is refreshed to display the Service WSDL list. The relative paths of all WSDLs in the ZIP are displayed. Select the WSDL to use in the connection. Manually specify the WSDL to use.
   Target Server's TLS Version (Optional) (Under Optional properties.)	If no value is selected, the default value used for outbound connections is Transport Layer Security (TLS) version 1.3. It's up to your discretion and the end application's requirements to select either TLS version 1.2 or 1.1 as the default. TLSv1.1 TLSv1.2 TLSv1 is no longer supported. If you previously configured a connection in a version prior to Oracle Integration 3 to use TLSv1.1, either update the connection by not selecting a value for this field or select TLSv1.2. The TLS protocol provides privacy and data integrity between two communicating computer applications. For trigger-only connections, you cannot select a TLS version. Oracle Integration accepts what it receives as long as it's TLSv1.1 or TLSv1.2.
   Suppress insertion of timestamp into the request (Optional) (Under Optional properties.)	Optionally suppress the timestamp in the WS-Security header. Suppression applies to the Username Password Token security policy in the invoke (outbound) direction. In secure Web Services transactions, a WS-Utility (WSU) timestamp can be inserted into a WS-Security header to define the lifetime of the message in which it is placed. Yes: No timestamp is added to the WS-Security header sent as part of the outbound request. For inbound requests with the basic authentication security policy, no timestamp is required to be sent by the client. No: Clients are expected to send a timestamp in the WS-Security header with the request.
   Ignore timestamp in the response message (Optional) (Under Optional properties.)	Specify if the timestamp is not required in the response message. Yes: The timestamp is not required in the response message. If the timestamp is present in the SOAP security header when the response is received from the service , it is ignored. No: The timestamp is received in the response from the service is not ignored.
   Enable two way SSL for outbound connections (Optional) (Under Optional properties.)	If you are configuring the SOAP Adapter for use with a two-way SSL-enabled server, select Yes. .
   Identity keystore alias name (Optional) (Under Optional properties.)	Enter the key alias name configured for two-way SSL communication. Both the client and server pass certificates to each other to establish an SSL link when two-way SSL is enabled. This value should match the alias that was provided to import identity to Oracle Integration. This is the name you entered in the Key Alias Name field when uploading the identity certificate in the Upload Certificate dialog. See Upload a Certificate to Connect with External Services. The alias name to provide must match the name provided for the private key entry in the JKS file.

Configure Connection Security

Configure security for your SOAP Adapter connection by selecting the security policy.

1. Go to the Security section.
2. Select the security policy.
   The page is refreshed to display the login credential fields.
3. Specify the login credentials. For trigger (inbound) connections, the security policy must be either username password token, basic authentication, SAML, or OAuth 2.0. This is because all Oracle Integration inbound endpoints are protected with any of these policies.

   When configuring the SOAP Adapter with the trigger-only role, you cannot select No Security Policy because all Oracle Integration endpoints are protected.

   • New connections do not show No Security Policy in the dropdown list.
   • Existing connections default to the Username Password Token security policy.
   • Connections updated with the REST APIs are automatically changed to use the Username Password Token security policy by default even though the request payload used No Security Policy.

   Security Policy	Fields
   Basic Authentication (In the trigger (inbound) direction, supports HTTP basic authentication over SSL: oracle/wss_http_token_over_ssl_service_policy). Note the following behavior: If the invoking client is secured with Oracle Web Services Manager (OWSM) using an oracle/wss* policy, the client receives a failure. In the inbound (trigger) direction, if the Suppress insertion of timestamp into the request (Optional) field is enabled, then oracle/http_basic_auth_over_ssl_service_policy is supported. In customer-managed environments, when configuring a trigger SOAP Adapter with Basic Authentication, the wss_http_token_service_policy policy is used regardless of whether the Suppress insertion of timestamp into the request option is set to Yes or No in the Connections page. Therefore, with or without the timestamp added in the SOAP header, as long as the username and password credentials are valid, the connection runs successfully at runtime. If Basic Authentication is required for both trigger and invoke connections, create one connection with the Trigger and Invoke role that uses the Basic Authentication security policy.	Username — Enter the name of a user who has access to the destination web service. Password — Enter the password. Confirm Password — Reenter the password.
   Username Password Token (In the trigger (inbound) direction, supports oracle/wss_username_token_over_ssl_service_policy.)	Username — Enter the name of a user Password — Enter the password. Confirm Password — Reenter the password.
   OAuth Client Credentials (In the invoke (outbound) direction.)	Access token URI — The URL from which to obtain the access token. Client Id — The client identifier issued to the client during the registration process. Client secret — The client secret. Scope — The scope of the access request. Scopes enable you to specify which type of access you need. Scopes limit access for the OAuth token. They do not grant any additional permission beyond that which the user already possesses. Auth request media type — The format of the data you want to receive. This is an optional parameter that can be kept blank. For example, if you are invoking Twitter APIs, you do not need to select any type. Client authentication — You can optionally configure OAuth flows with client authentication. This is similar to the Postman user interface feature for configuring client authentication. Send client credentials as basic auth header: Pass the client ID and client secret in the header as basic authentication. Send client credentials in body: Pass the client ID and client secret in the body as form fields. When you click Test, the access token is requested using the provided access token URL with client credentials. The access token is persisted in the credential store.
   OAuth Authorization Code Credentials (In the invoke (outbound) direction.)	Client Id — The client identifier issued to the client during the registration process. Client secret — The client secret. Authorization code URI — The URI from which to request the authorization code. Access token URI — URI to use for the access token. Scope — The scope of the access request. Scopes enable you to specify which type of access you need. Scopes limit access for the OAuth token. They do not grant any additional permission beyond that which the user already possesses. Client Authentication — You can optionally configure OAuth flows with client authentication. This is similar to the Postman user interface feature for configuring client authentication. Send client credentials as basic auth header: Pass the client ID and client secret in the header as basic authentication. Send client credentials in body: Pass the client ID and client secret in the body as form fields. When you click Provide Consent, the authorization code request is sent to the authorization URL along with the redirect URL. You are then redirected to the sign in page. After signing in with the authorized user name and password, the authorization code is sent back to the caller. The authorization code, client ID, and client secret are sent to the access token URL. To exchange the access token, expiry and refresh token are sent back to caller. When you test the connection, the refresh token flow is called to validate the refresh token.
   No Security Policy	No fields are displayed.
   Security Assertion Markup Language (SAML)	This policy is only available when configuring the SOAP Adapter as a trigger. If you attempt to add the SOAP Adapter with this security policy configuration as an invoke in an integration, you receive an error. Username — Optionally enter the name of the SAML user.
   OAuth 2.0	This policy is only available when configuring the SOAP Adapter as a trigger. If you attempt to add the SOAP Adapter with this security policy configuration as an invoke in an integration, you receive an error. No fields are displayed.

   If you select a security policy, the following behavior occurs.

   If the Inbound SOAP Connection is Configured with Security Policy...	Then...
   Username Password Token	The client should send the username/password and timestamp as part of the WSEE header. The response includes only the SOAP payload.
   Basic Authentication	The client should send the username/password in the HTTP headers and timestamp as part of the WSEE header. The response includes only the SOAP payload.
   Basic Authentication and the Suppress insertion of timestamp into the request (Optional) field is enabled	The client should send the username/password in the HTTP headers. The response includes only the SOAP payload.

   Note:

   If no timestamp is included as part of the header, configure the SOAP Adapter connection with the Basic Authentication security policy (oracle/http_basic_auth_over_ssl_client_policy) and set Suppress insertion of timestamp into the request (Optional) to Yes.

Configure the Endpoint Access Type

Configure access to your endpoint. Depending on the capabilities of the adapter you are configuring, options may appear to configure access to the public internet, to a private endpoint, or to an on-premises service hosted behind a fire wall.

• Select the Endpoint Access Type
• Ensure Private Endpoint Configuration is Successful

Select the Endpoint Access Type

Select the option for accessing your endpoint.

Option	This Option Appears If Your Adapter Supports ...
Public gateway	Connections to endpoints using the public internet.
Private endpoint	Connections to endpoints using a private virtual cloud network (VCN). Note: To connect to private endpoints, you must complete prerequisite tasks in the Oracle Cloud Infrastructure Console. Failure to do so results in errors when testing the connection. See Connect to Private Resources in Provisioning and Administering Oracle Integration 3 and Troubleshoot Private Endpoints in Using Integrations in Oracle Integration 3.
Connectivity agent	Connections to on-premises endpoints through the connectivity agent. Click Associate agent group. The Associate agent group panel appears. Select the agent group, and click Use. To configure an agent group, you must download and install the on-premises connectivity agent. See Download and Run the Connectivity Agent Installer and About Creating Hybrid Integrations Using Oracle Integration in Using Integrations in Oracle Integration 3.

Ensure Private Endpoint Configuration is Successful

• To connect to private endpoints, you must complete prerequisite tasks in the Oracle Cloud Infrastructure Console. Failure to do so results in errors when testing the connection. See Connect to Private Resources in Provisioning and Administering Oracle Integration 3.
• When configuring an adapter on the Connections page to connect to endpoints using a private network, specify the fully-qualified domain name (FQDN) and not the IP address. If you enter an IP address, validation fails when you click Test.
• IPSec tunneling and FastConnect are not supported for use with private endpoints.

Test the Connection

Test your connection to ensure that it's configured successfully.

1. In the page title bar, click Test. What happens next depends on whether your adapter connection uses a Web Services Description Language (WSDL) file. Only some adapter connections use WSDLs.

   If Your Connection...	Then...
   Doesn't use a WSDL	The test starts automatically and validates the inputs you provided for the connection.
   Uses a WSDL	A dialog prompts you to select the type of connection testing to perform: Validate and Test: Performs a full validation of the WSDL, including processing of the imported schemas and WSDLs. Complete validation can take several minutes depending on the number of imported schemas and WSDLs. No requests are sent to the operations exposed in the WSDL. Test: Connects to the WSDL URL and performs a syntax check on the WSDL. No requests are sent to the operations exposed in the WSDL.

2. Wait for a message about the results of the connection test.
   • If the test was successful, then the connection is configured properly.
   • If the test failed, then edit the configuration details you entered. Check for typos and verify URLs and credentials. Continue to test until the connection is successful.
3. When complete, click Save.