Invoke a Co-located Integration from a Parent Integration

You can invoke a co-located (child), active integration from the parent integration that you are designing through use of the local integration adapter. Co-located means the integration is running on the same host instance or in the same domain. Upon activation and invocation of the parent integration, it invokes and consumes the co-located integration.

The local integration adapter is a system adapter that is not exposed on the Connections page when you create a connection. Instead, the local integration adapter is invoked by a preseeded connection. It is created when creating an integration, if the local integration connection does not exist. This adapter has no connection properties and no security policies.

The local integration adapter works as follows:

• You select an active integration from runtime (that is, co-located) to build a new integration. Note the following guidelines:

  • Active synchronous-synchronous, asynchronous with no callback, and scheduled integrations are available for selection.

  • Asynchronous with callback integrations do not appear.

  • De-activated and draft integrations do not appear.

  • Scheduled integrations are permitted as an invoke connection and automatically called by the Submit Now option.

• You can add multiple child integrations. You can also add an integration containing a child integration (embedding multiple levels).

• You can map return values downstream. This mapping functionality is the same as for any other invoke mappings in the integration.

• You can add header support to the payload of the SOAP adapter used in the co-located (child) integration. See Create a Co-located Integration with Header Support.

• You can create a parent integration using a REST Adapter invoke connection configured with the Open API URL connection type to pass a binary payload to a child integration.

  Use binary data with payloads that are unstructured and inline (for example, application/octet-stream). The file contents are preserved, but require the receiver to determine the file type (for example, from the file name extension). The internet media type for an arbitrary byte stream is application/octet-stream.

The local integration adapter and the existing SOAP Adapter and REST Adapter differ as follows:

• You do not need to create multiple connections (SOAP/REST) to invoke the local integration service.

• Runtime communication always uses HTTP (that is, non-SSL).

This adapter is invoked internally in Oracle Integration to perform the local service invocation.

Note the following local integration restrictions:

• You cannot create a child integration with a WSDL having a nested anonymous schema. As a workaround, manually edit the WSDL and make the schema non-anonymous.
• SOAP-based child integrations:
  • A parent integration cannot send an attachment to a configured child integration.
  • A parent integration cannot map any headers.
• REST-based child integrations:
  • A parent integration cannot send an attachment to a configured child integration.
  • A parent integration cannot map any headers.
  • A parent integration cannot process an XML payload that is expected by the child integration.

The following steps provide an overview of creating an orchestrated integration in which a parent integration invokes a co-located integration.

Note:

• If you need to move a parent integration to another instance, it is best to include that integration and all its child integrations in a package.
• If the following integrations are imported from one environment to another (having different host names), then editing the local (child) integration or editing the REST Adapter in the Adapter Endpoint Configuration Wizard leads to major changes in the mapper that may require remapping.
  • Integrations in which a co-located (child) integration is invoked from a parent integration.
  • Integrations with a REST adapter using a Swagger-based connection.

1. Create and design an orchestrated integration.
2. Add an integration action to an integration in either of the following ways:
   • On the right side of the canvas, click and drag the Integration action to the appropriate location.
   • Click at the location where you want to add the integration action, then select Integration.
   The Configure Local Integration Selection Wizard is displayed.
3. Specify the following details, and click Next.

   Element	Description
   What do you want to call your local integration invocation?	Specify a name.
   What does this local integration invocation do?	Specify a description.

4. Specify the following details, and click Next.

   Element	Description
   Integration	Select the co-located integration to invoke. Only active integrations are displayed.
   Identifier	Displays the identifier of the selected integration.
   Description	Displays the description of the selected integration.

5. Select the operation for the co-located integration to perform, and click Next. The operation depends on the child integration. If the child integration trigger connection is a REST Adapter, it can have Get, Post, Put, and Delete operations. If the child integration trigger connection is a SOAP Adapter, it can have the WSDL operation name. If the child integration trigger connection is a schedule, it executes a submit now configuration.
6. Review your selections, and click Done.
7. Complete design of the parent integration.
8. Specify appropriate business identifiers for tracking the integration at runtime.
9. Activate and invoke the integration.
10. Go to the Track Instances page to track integration status.
    If successful, the Track Instances page has two instances (one for the parent and one for the child). If unsuccessful, and the parent is unable to call the child, there is one entry (for the parent). If the parent can call the child, there are two entries. If the child fails or the child was successful, but the parent the did not process properly the response, the parent may fail.

Create a Co-located Integration with Header Support

Headers are optional elements that pass extra information about your application requirements. For example, you can use the header element to specify a digital signature for password-protected services. You can configure and select the headers to send with the payload. Headers selection is automatic based on the WSDL URL definition you provide on the Connections page.

Along with request and response SOAP headers, you can configure standard HTTP headers, custom HTTP headers, and custom SOAP headers. You can view and edit these headers in the request and response mapper under the header elements.

Note:

Assume you configure a child SOAP integration with only custom and standard HTTP headers configured. If you try to use the integration in a local invoke, the local invocation ignores the headers and provides an option in the mapper to pass only data, and not headers. If custom and standard HTTP headers are passed along with any SOAP headers, the custom and standard HTTP headers are visible in the mappings.

The following use case provides a high level overview of creating a co-located integration with header support.

1. Create a SOAP Adapter connection with a WSDL URL that includes the header definitions.
   
   
   
   
2. Complete the remaining fields on the Connections page.
3. Test and save the connection.
4. Create an orchestrated integration to act as the co-located (child) integration.
5. Add the SOAP Adapter as a trigger connection in the integration.
6. Complete the pages of the Adapter Endpoint Configuration Wizard. In particular:
   1. On the Headers page, specify request and response header details.
      
      
      Description of the illustration local_int_soap_adapter_hdr.png
      
      
   2. On the Request-Headers page, specify request header names.
      
      
      Description of the illustration local_int_soap_adapter_req.png
      
      .
   3. On the Response-Headers page, specify response header names.
      
      
      Description of the illustration local_int_soap_adapter_resp.png
      
      .
7. In the mapper, map the request and response headers.
   
   
   Description of the illustration mapper1.png
   
   
8. Save and activate the integration.
9. Create another orchestrated integration to act as the parent integration.
10. Add the REST Adapter as a trigger connection in the integration.
11. Configure the pages in the Adapter Endpoint Configuration Wizard.
12. On the Summary page, review your selections, then click Done.
    
    
    Description of the illustration rest_adapter_summary.png
    
    
13. Add an Integration action to the integration.
    This invokes the Configure Local Integration Selection Wizard.
14. Complete the pages of the wizard. In particular, select the child integration created in Step 4 on the Selection Integration page.
15. Click the map icon between the REST Adapter trigger connection and SOAP invoke (the Integration action you configured) to configure the map.
16. Map the source id element to the target SOAP, HTTP, and custom header elements.
    
    
    Description of the illustration mapper2.png
    
    
17. Save and activate the parent integration. The parent integration is now designed with a child integration as a SOAP invoke.

Backward Compatibility for Header Support

Note the following details when using header support in existing integrations created prior to the release of support for headers in co-located integrations.

Question	Answer
What happens if an existing integration created with a header is imported into an environment in which header support in co-located integrations is supported.	You can activate the integration without any issues. However, if you want to use header functionality, you must edit the adapter by clicking through the pages of the Adapter Endpoint Configuration Wizard, then clicking Done on the Summary page. In this scenario, mapping is not deleted; you must to correct it.
What happen if you perform the following steps. Create a child flow with headers in a trigger connection. Use this child endpoint as a SOAP connection. Use the above SOAP connection as a trigger and create an integration in which you set Do you want to configure headers for this endpoint? to No on the Headers page of the Adapter Endpoint Configuration Wizard. Activate the integration. Invoke this child integration in a parent integration that uses the Integration action. Check if the integration generates a wrapper in the local invoke.	Based on the selection of Yes or No, headers are visible or invisible in the mapping.