Skip to end of metadata
Go to start of metadata

Introduction

Operations must be valid in order to be deployed. This page covers how to identify invalid operations and view the validation errors associated with them, as well as how to resolve validation errors. Examples of common operation arrangements are also provided.

Validation Errors

This section covers how to identify invalid operations and view the validation errors associated with invalid operations.

For new projects, invalid items are highlighted by default on the design canvas, with the default selection of Highlight Invalid Items. To turn off this option, clear this selection:

This view can also be toggled on using the Invalid filter in the Components tab of the project pane to filter on invalid items.

When this display option is selected, the names of invalid operations appear in italics and the color red on the design canvas and in the project pane. In addition, on the design canvas, blocks representing invalid operation steps are outlined with a red border and the operation is outlined with a red border when selected:

In the project pane, invalid operations that have an implicit error are shown with an error icon :

The error icon  does not display if the reason the operation is invalid is because it contains other components with implicit errors. For example, an operation may be invalid because it contains other components that are invalid.

Click the error icon  next to the operation name to display a message listing the validation errors for the operation. For detailed information on what causes operations to be invalid and how to resolve validation errors, see Validation Rules, next.

Validation Rules

Certain validation rules must be followed for operations to be deployed to the Harmony cloud and executed on Harmony agents. These rules ensure that all parts of a project are supported and expected by the agent. The rules for operations are detailed as follows.

Names Must Be Unique

Names of operations must be unique. If an operation has the same name as another other operation in the project, this validation error message will be returned:

Operation names must be unique.

When creating a new operation from scratch or renaming an operation, the interface will not allow you to provide the same name for multiple project components. However, if you receive this error, check to make sure you have given a unique name to each operation and rename any duplicates where necessary. To rename an operation, click into the operation's title area on the design canvas and begin editing the text.

Operations Must Be Valid

In order for an operation to be valid, the operation steps it contains must be valid according to the rules described in this section. If this rule is not met, this validation error message will be returned:

Operation contains invalid steps.

Depending on what components are used as steps in the operation and how those components are arranged, different rules may apply, as detailed below.

In addition, if an operation is invalid for some other reason that cannot be readily determined, this error message will be returned:

Operation is invalid.

Valid Patterns

Operations must conform to certain patterns provided above. If this rule is not met, this validation error message will be returned:

Operation does not conform to any known pattern.

To resolve, make sure the components used in the operation are arranged in one of the sequences provided below. In these patterns, activities are considered to be used as a source if they provide data within an operation. Activities are considered to be used as a target if they receive data within an operation. For additional explanation about sources vs. targets and the parts of the operation, see Operation Creation and Configuration.

If a certain desired arrangement does not adhere to one of the valid patterns described below, you may be able to use a combination of operations that each follow a valid pattern. To do so, create each operation separately and then chain them together using operation actions.

For common examples using these patterns, see Common Operation Pattern Examples at the end of this page.

The same patterns that are visually presented above are described in text below, where optional components appear in gray and required components appear in red. Additional details about the types of endpoints that can be used are also provided.

Archive Pattern

Script(s) + Source Activity + Script(s) + Target Activity + Script(s)

In this pattern, the source and target activities can be associated with any of these endpoint types:

Transformation Pattern

Script(s) + (Group: Source Activity + Script[s]) + Transformation + (Group: Script(s) + Target Activity) + Script[s])

In this pattern, the source and/or target activities can be associated with any endpoint type, as long as at least one activity is included. A transformation cannot exist by itself in an operation without an activity.

Script Pattern

Script(s) + Target Activity

In this pattern, the target activity can be associated with any of these endpoint types:

Two-Target Archive Pattern

Script(s) + (Group: Source Activity + Script[s]) + Transformation + Script(s) + Target Activity 1 + Target Activity 2 + Script(s)

In this pattern, the optional second target activity is used to archive a response from the first target. The response from the first target passes through the raw response data to another target without transforming it. This can be thought of as an archive or as a passing through of data (sometimes referred to as a passthrough).

The source and target activities must be associated with certain endpoint types depending on where they are used in the pattern:

  • Source Activity: If used, the source activity can be associated with any endpoint type.
  • Target Activity 1: The first target activity can be associated with any of these endpoint types:
  • Target Activity 2: If used, the second target activity can be associated with any of these endpoint types:
Two-Target Transformation Pattern

Script(s) + (Group: Source Activity + Script[s]) + Transformation 1 + Script(s) + Target Activity 1 + (Group: Transformation 2 + Target Activity 2) + Script(s)

In this pattern, the optional second group is used to take the response from the first target, transform it, and then write it to a second target.

The source and target activities must be associated with certain endpoint types depending on where they are used in the pattern:

  • Source Activity: If used, the source activity can be associated with any endpoint type.
  • Target Activity 1: The first target activity can be associated with any of these endpoint types:
  • Target Activity 2: If used, the second target activity can be associated with any endpoint type.
Salesforce Bulk Source Pattern

Script(s) + Source Activity + Script(s) + Target Activity + Script(s)

In this pattern, the source activity must be a Salesforce bulk query activity. The target activity can be associated with any of these endpoint types:

Salesforce Bulk Target Pattern

Script(s) + Source Activity + Script(s) + Target Activity + Script(s)

In this pattern, the source activity can be associated with any of these endpoint types:

The target activity can be associated with any of these endpoint types:

API Activities

If an operation chain contains an API activity, it must be the only API or API SOAP request activity the operation chain and it must be the source of the first operation. That is, no other operation may be calling this operation from a script or an "on success" or "on failure" operation action.

If these rules are not met, this validation error message will be returned:

An API Request must be the source of the first operation (i.e., no other operation is calling this operation from a script or an onSuccess/onFailure outcome).

To resolve, check that the API or API SOAP request begins the operation chain.

Database Activities

If an operation contains a database activity, it must also contain a transformation. If this rule is not met, this validation error message will be returned:

A database activity requires a transformation to be used.

To resolve, make sure you are using one of the valid transformation patterns described earlier on this page.

NetSuite Activities

If the operation contains a NetSuite activity, it cannot include more than one NetSuite activity, and it cannot also contain a SOAP activity or other application activity such as Salesforce.

If these rules are not met, one of these validation error messages will be returned:

Operation cannot contain more than one application/SOAP activity [name].

Operation does not conform to rules for application activity [name].

To resolve, make sure you are using only one NetSuite activity in each operation and no SOAP or Salesforce activities, and check to make sure you are following a valid pattern. Refer to the example Application Call provided under Common Operation Pattern Examples later on this page.

Salesforce Activities

If the operation contains a Salesforce activity, it cannot include more than one Salesforce activity, and it cannot also contain a SOAP activity or other application activity such as NetSuite. If the operation contains a non-bulk Salesforce target activity, this activity must be preceded by both a source activity and a transformation. If the operation contains a bulk Salesforce activity, it must not also contain a transformation.

If these rules are not met, one of these validation error messages will be returned:

Operation cannot contain more than one application/SOAP activity [name].

Operation does not conform to rules for application activity [name].

To resolve, make sure you are using only one Salesforce activity in each operation and no SOAP or NetSuite activities, and check to make sure you are following a valid pattern. For non-bulk Salesforce activities, refer to the example Application Call provided under Common Operation Pattern Examples later on this page.

SOAP Activities

If the operation contains a SOAP activity, it cannot include more than one SOAP activity, and it cannot also contain an application activity such as Salesforce or NetSuite. If this rule is not met, this validation error message will be returned:

Operation cannot contain more than one application/SOAP activity [name].

To resolve, make sure you are using only one SOAP activity in each operation and no Salesforce or NetSuite activities, and check to make sure you are following a valid pattern. Refer to the example SOAP Call provided under Common Operation Pattern Examples later on this page.

NOTE: The API SOAP activities are not associated with a SOAP endpoint but are instead associated with an API endpoint and thus considered to be API activities.

Project Components Must Be Valid

Project components used as any part of an operation must be valid for the operation to be valid. This includes components used as steps of an operation, as well as other components used in support of an operation. For example:

  • A component used directly as a step in the operation, such as an activity, transformation, or script.
  • An endpoint that an activity used in the operation is dependent upon.
  • A component called by a script in the operation.

The validation rules depend on the type of component, and are covered collectively under Component Validity.

Common Operation Pattern Examples

This section provides examples of operation patterns that meet the validation rules described on this page. These examples are simplified to demonstrate the basic building blocks of some commonly built operations and are not intended to cover all possible combinations. Refer to Valid Patterns earlier on this page for all possible arrangements.

Script

An operation can simply contain a single script. In this case, all actions in the operation are performed by the script.

This pattern is typically used at the beginning of a workflow to create a "launch script" that runs one or more of several branch operations based on a system variable or other data value.

Scripts may also be used anywhere in an operation to perform complex calculations that require custom logic.

Archive

If all you need to do is to move files from a data source to a target, you can use an operation without a transformation. 

The first activity is used as the source, providing data within the operation. The second activity is used as the target, receiving data within the operation.

For archiving data, the source and target activities are limited to those that interact with files. Instead of a source activity, you could also use a script.

Transformation

Operations that make use of transformations serve a variety of use cases. For example, you can create operations that (1) transform data from a source to a target, (2) transform data, then write the response to another target, or (3) transform data from a web service call by converting the application call's response and writing to a target.

Operation Transforms Data from Source to Target

This example pulls data from a source activity that is then transformed and written to a target activity:

Operation Transforms Data, then Writes Response to Another Target

In this example, when an HTTP activity is used as the target of the transformation, such as HTTP PUT or HTTP POST, an additional target activity can be placed directly after it, or after another transformation, in order to write the HTTP response to another target. 

This operation arrangement, used for getting a REST token, shows the HTTP response being written to a global variable for use in the next operation:

Operation Calls a Web Service

This example is for updating an application such as Salesforce through the application’s API, or calling a SOAP web service method. The application call typically includes both a request and response data structure. 

In this arrangement, the operation has three parts:

  • A source activity and transformation to construct the request data structure.

  • The application call itself.
  • A second transformation and target to convert the application call's response and write the data or file to a target.

Application Call

SOAP Call

On This Page

Last updated:  Dec 04, 2019

  • No labels