Understanding Introspecting and Deploying Integrations

The Integration Network features a series of pages that enable you to introspect and deploy services on remote nodes.

The system can introspect and deploy integrations on any node defined in the integration network. However, to introspect integrations on the local node, a handler and a local routing must exist on any integration that you introspect.

Important:

To introspect a service operation on the local node, a handler and a local routing must be defined for the service operation.

Introspection Checks

During the introspection process, the system checks the following items for the selected service operations for the selected nodes:

  • Service operations are active.

  • Routings.

    • Routings exist.

      Note that routings are checked from the node where introspection was invoked.

      Physical routings, deployment configuration routings and default routings are all potential routings that can be auto-generated based on versions available. The prioritization for routing checks is 1.) physical routing, 2.) deployment configuration routing, and finally 3.) default routing.

    • Alias names match.

      The alias name match is verified on the physical routing, the deployment configuration, or the default routing.

      The system derives the alias from the name and version of the service operation.

    • Sending and receiving nodes match.

    • No multiple target aliases exist. (Synchronous service operations only.)

Introspection Checks (REST)

During the introspection process, the system checks the following items for the selected REST service operations for the selected nodes:

REST as consumer (source):

  • Service operation is active.

  • Routing exists.

    Check for an any-to-local routing on the target with an alias name that is the same as alias name on source (local-to-WADL) defined as the REST provider on the target. If no such routing exists, the system check that the service operation.version is defined as a REST provider on the target.

  • Handler exists.

    The system checks that an OnRequest handler exists on the target system for the any-to-local routing.

  • REST base URL update.

    The system updates the REST base URL on the source system to <REST target Location endpoint>/< External Alias from Any to Local routing> on the target system.

  • Service operation permissions exist.

REST as provider (target):

  • Service operation is active.

  • Routing exists.

    Check for a local-to-WADL routing on the target with an alias name the same as alias name on source (any-to-local) defined as REST consumer on target. If no such routing exists, the system checks that the service operation.version is defined as a REST consumer on the target.

  • Handler exists.

    The system checks that an OnRequest handler exists on the source system for the any-to-local routing

  • REST base URL update.

    The system updates the REST base URL on the target system to <REST target Location endpoint>/< External Alias from Any to Local routing> from the source system.

  • Service operation permissions exist.

Deployment Processing (Non-REST and REST)

In many cases during deployment processing, the system can activate service operations, handlers, and routings that are found to be inactive during the introspection process. The system can also frequently create routings if none are found to exist during introspection. However, there are some situations where manual intervention is required to resolve routing issues and handler issues. And in all cases where service operation permissions do not exist, manual intervention is required to assign permissions.

Related Topics