Design

Back Next

Shared Service Actions

Using shared service actions, you can define common inputs, bindings, and outputs, then reuse these definitions in other actions that "inherit" from the parent "abstract" action.

For example, you might have multiple actions which all share the same:

Input parameter session-id

HTTP Header such as content-type

Binding method (GET/POST) and URL

Authentication Credentials

Output fields

In that case, you can:

Define an Abstract type action that contains all of the common definitions:

Create multiple Inherit type actions that use those common definitions and extend or add to certain parameters.

For example, an Inherit action can:

Define a new input parameter (for example, $messageId).

Extend the binding URL and append the new parameter to the base with "/{$messageId}".

For example:

Notes on Usage

Shared service actions:

Are not available at design time within IPDs and Guides.

Inherit inputs, bindings, and outputs from a single parent (Abstract) action.

Do not allow abstract actions to inherit from other abstract actions.

Allow each Service Connector to have multiple abstract actions.

After you specify the Inherit Action Type, many fields are disabled.

However, for specific Binding and other options, you can choose to:

Inherit
: Use all input parameters from the Abstract action, as is. This is the default.

Exclude
: Exclude the parameter so it is not available to the action at design time or runtime.

Overwrite
: Specify parameters to overwrite what was inherited.

Defining Actions

Download Guide

Watch

Comments

Cloud Application Integration Homepage

0 COMMENTS

We’d like to hear from you! Log in to comment.

Rename Saved Search

Table of Contents

Design

Design

Shared Service Actions

Shared Service Actions