Table of Contents

Search

  1. Preface
  2. Understanding Data Types and Field Properties
  3. Designing Processes
  4. Using and Displaying Data
  5. Designing Guides
  6. Designing Process Objects
  7. Designing Service Connectors
  8. Using Connectors
  9. System Services, Listeners and Connectors

2. Design

2. Design

Shared Service Actions

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:
  1. Define an Abstract type action that contains all of the common definitions:
  2. Create multiple Inherit type actions that use those common definitions and extend or add to certain parameters.
  3. 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.


Updated February 11, 2021