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.
-
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.
-
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.
- 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.
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.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.
|
Based on the selection of Yes or No, headers are visible or invisible in the mapping. |