Skip to Content

Valid operation patterns and validation errors

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 by using a valid operation pattern. 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:

highlight invalid items

When Highlight Invalid Items is selected, any invalid operations or components are outlined in the color red and have an invalid icon next to their name on design canvas:

operation invalid

In the project pane, the names of invalid workflows and components are listed in red italics and are shown with an error icon:

invalid operation

Click the error icon next to the operation name to display a message listing the validation errors for the operation. Operations with an implicit error can be invalid for any of the following reasons:

Error Additional Information
Operation is empty. The operation must have at least one operation step.
Operation does not conform to any valid pattern. Operation rules and patterns can be found here. The operation must meet established operation patterns that ensure the operation is supported and expected by the agent. These patterns are covered next under Validation patterns.
The transformation [source / target] schema does not match the schema structure provided by ["Activity Name"] activity. Open transformation ["Transformation Name"] in ["Operation Name"] operation and refresh the target schema. In an operation that contains a transformation with an activity-provided schema, the activity-provided schema must match the schema structure provided by an adjacent activity.
Transformation ["Transformation Name"] has a source schema but no source activity. Remove the source schema from the transformation or add a source activity before the transformation. If the operation contains a transformation with an activity-provided or transformation-provided source schema, there must be a source activity preceding the transformation.

HTTP target activities that send their response to a second target activity can only send responses to one target activity throughout the project. The HTTP activity ["Target 1 Activity Name"] in this operation is sending its response to multiple target activities throughout the project.

In this operation its target is ["Target 2A Activity Name"]. In operation ["Operation 2"] its target is ["Target 2B Activity Name"].

Replace the ["Target 1 Activity Name"] activity with a duplicate activity in one of the operations. You can do this by finding the ["Target 1 Activity Name"] activity in the Components Tab, open the menu, and duplicate. Drag the duplicated activity to the operation.

In an operation that uses the Two-target archive pattern and contains an HTTP target activity that writes a response to a second target activity, the HTTP target activity also being used in another Two-target Archive Pattern operation must write to the same target activity.

Note

This validation rule can be disabled, though doing so is not recommended. For more information see HTTP validation rule errors at the end of this page.
"Operation ["Operation Name"] cannot have more than one listener or event-based activity: ["Activity Names"]." An operation can contain only one listening activity per operation.
"Operation ["Operation Name"] has ["Activity Name"] as a listener or event-based activity -- such activities needs to be the first in the operation. The operation must meet established operation patterns for the listening activity. The operation patterns that each listening activity can be used with are listed in the documentation for each activity.
"Operation ["Operation Name"] cannot have ["On Success" / "On Fail" / "On SOAP Fault"] outcome to ["Operation Name 2"] target operation which is has a listener or event-based as first activity." An operation cannot use operation actions to invoke another operation that contains a listening activity.
"Operation ["Operation Name"] starts with a listener or event-based activity ["Activity Name"] and cannot have schedule attached to." An operation that contains a listening activity cannot be run on a schedule.
"["Script Name"] script in ["Operation Name"] operation cannot use RunOperation() to invoke ["Operation Name 2"] operation that has a listener or event-based activity. An operation cannot use the RunOperation function to invoke another operation that contains a listening activity.

The error icon does not display if the reason the operation is invalid is because it contains other components with implicit errors. 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 on.
  • 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.

Validation patterns

Certain validation patterns must be followed for operations to be deployed to the Harmony cloud and executed on Jitterbit agents. These patterns ensure that all parts of a project are supported and expected by the agent:

The following diagram summarizes all valid operation patterns. Each pattern is also presented individually and described in text below the diagram, where optional components appear in bold gray and required components appear in bold red.

operation patterns annotated pp

Footnotes for validation patterns

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

B If a Salesforce, Salesforce Service Cloud, or ServiceMax Query is used as the source activity, then a target activity is required.

C Operations cannot include more than one NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax, or SOAP activity.

D Operations that include a Salesforce, Salesforce Service Cloud, or ServiceMax activity cannot also contain any other activities except for those associated with the API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, or Variable connectors.

E Only non-bulk activities can be used in this location.

F The HTTP activity must receive a request body and produce a response body. An HTTP GET activity returns a message indicating success {"success": true} or failure {"success": false} instead of the actual response.

Frequently asked questions (FAQ)

As you design operations, it may be helpful to consider the answers to these frequently asked questions:

  • What's the difference between a source and a target?
    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 versus targets and the parts of the operation, see Operation creation and configuration.
  • What patterns are valid with my endpoint?
    The patterns that can be used with each specific type of activity are documented within the individual activity pages under Connectors. On each activity page, the specific patterns that can be used are included within the section "Next Steps," which is typically the last section on each activity page.
  • What if my use case doesn't fit a valid pattern?
    If a certain desired operation arrangement doesn't adhere to a valid pattern, you may be able to use a combination of operations that each follows a valid pattern. To do so, create each operation separately and then chain them together using operation actions.

  • How can I remember these patterns?
    Operations that do not follow a valid pattern are flagged as invalid and are unable to be deployed. As you become familiar with the patterns, generalizations such as these may become apparent:

    • File-based generic connectors, such as FTP, HTTP, and Temporary Storage, are able to be used without a transformation.
    • In most cases, application connectors for non-bulk activities, such as those for Epicor, ServiceNow, and Workday, require a transformation.
    • Scripts can be added almost anywhere.

  • Are there examples of how others have set up operations?
    For common examples using these patterns, see Common operation pattern examples at the end of this page, or refer to each individual activity page under Connectors.

Archive pattern

operation pattern archive annotated pp

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:

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

E Only non-bulk activities can be used in this location.

Script pattern

operation pattern script annotated pp

Script(s) + Target Activity

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

Transformation pattern

operation pattern transformation annotated pp

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.

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

B If a Salesforce, Salesforce Service Cloud, or ServiceMax Query is used as the source activity, then a target activity is required.

C Operations cannot include more than one NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax, or SOAP activity.

D Operations that include a Salesforce, Salesforce Service Cloud, or ServiceMax activity cannot also contain any other activities except for those associated with the API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, or Variable connectors.

E Only non-bulk activities can be used in this location.

Two-target archive pattern

operation pattern two target archive annotated pp

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

In this pattern, the second target activity is used to archive a response from the middle activity, which functions both as the first target and as the second source.

The response from the middle activity passes through the raw response data to a second 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:

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

C Operations cannot include more than one NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax, or SOAP activity.

D Operations that include a Salesforce, Salesforce Service Cloud, or ServiceMax activity cannot also contain any other activities except for those associated with the API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, or Variable connectors.

E Only non-bulk activities can be used in this location.

Two-target HTTP archive pattern

operation pattern two target HTTP archive annotated pp

Script(s) + Source Activity 1 + Script(s ) + Transformation + Script(s) + Target Activity 1 / Source Activity 2 + Target Activity 2 + Script(s)

In this pattern, the second target activity is used to archive a response from the middle activity, which functions both as the first target and as the second source. This pattern is different from the Two-target archive pattern in that the middle activity is an HTTP activity.

The response from the middle HTTP activity passes through the raw response data to a second 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 1 A: If used, the first source activity can be associated with any endpoint type.
  • Target Activity 1 / Source Activity 2: The first target activity (also referred to as the second source activity) can be associated with any of these endpoint types:
  • Target Activity 2: The second target activity can be associated with any of these endpoint types:

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

E Only non-bulk activities can be used in this location.

F The HTTP activity must receive a request body and produce a response body. An HTTP GET activity returns a message indicating success {"success": true} or failure {"success": false} instead of the actual response.

Two-transformation pattern

operation pattern two transformation annotated pp

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

In this pattern, the second transformation is used to take the response from the middle activity (which functions both as the first target and as the second source), transform it, and then optionally 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 1 A: If used, the first source activity can be associated with any endpoint type.
  • Target Activity 1 / Source Activity 2: The first target activity (also referred to as the second source activity) can be associated with any endpoint type except for API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, or Variable.
  • Target Activity 2 E: If used, the second target activity can be associated with any endpoint type.

A If an operation chain contains an API activity, it must be the only API or API SOAP Request activity in 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.

C Operations cannot include more than one NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax, or SOAP activity.

D Operations that include a Salesforce, Salesforce Service Cloud, or ServiceMax activity cannot also contain any other activities except for those associated with the API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, or Variable connectors.

E Only non-bulk activities can be used in this location.

Salesforce bulk source pattern

operation pattern Salesforce bulk source annotated pp

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

In this pattern, the source activity must be a Salesforce Bulk Query activity, Salesforce Service Cloud Bulk Query activity, or ServiceMax Bulk Query activity. The target activity can be associated with any of these endpoint types:

Salesforce bulk target pattern

operation pattern Salesforce bulk target annotated pp

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:

Common operation pattern examples

This section provides several common examples of operations configured using a valid operation pattern. These examples are simplified to demonstrate the basic building blocks of commonly built operations and are not intended to cover all possible combinations. Refer to Validition 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.

operation kickoff script

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.

operation simple file transfer

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 FTP read

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 chain get token

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:

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

  • The application call itself, which functions as the first target activity and second source activity.

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

Application call

operation Salesforce insert

SOAP call

operation check credit card info

HTTP validation rule errors

One of the HTTP validation rules applies to operations using the Two-target archive pattern where an HTTP activity in the Target 1 position writes a response to a second target activity (Target 2). In this scenario, the validation rule requires that an HTTP Target 1 activity must not be used in any other Two-target archive pattern operations where the HTTP Target 1 activity writes to a different second target activity.

Operations that violate this validation rule are reported as invalid with an error message similar to this:

validation errors HTTP target activities

Resolve HTTP validation errors

We recommend following the instructions provided in the error message to fix the operations so they are valid. Following those instructions, we recommend these steps:

  1. Duplicate the HTTP target activity in the Target 1 position of one of the operations using the Two-target archive pattern:

    operation duplicate activity

  2. Replace the HTTP target activity in the Target 1 position of the identified operation(s) with the duplicate copy:

    operation duplicate activity result

  3. Repeat for any additional invalid operations. Once the validation errors are resolved, redeploy the operations.

Disable the HTTP validation rule

In certain situations, it may be desirable to disable this HTTP validation rule as follows:

  1. Open the project settings:

    actions menu settings

  2. In the Deploy tab, disable HTTP Validation Rule:

    project existing deploy disable annotated

  3. Click Save.

Once disabling and saving the setting, the operation validation errors reported due to this error should be resolved. However, note that any HTTP Target 1 activities used in a Two-target archive pattern operation will write to the Target 2 activity of the last deployed operation. This may cause invalid data to be written.

Caution

Using this setting to disable the HTTP validation rule is not recommended and may result in unintentionally writing invalid data to target activities in operations using the Two-target archive pattern.

Re-enable the HTTP validation rule

If you have previously disabled the HTTP validation rule and are ready to re-enable it, follow these steps:

  1. Open the project settings.

  2. In the Deploy tab, enable HTTP Validation Rule.

  3. Click Save. Note that this is a design-time change and that this action does not deploy any changes to the Harmony cloud.

  4. Resolve any HTTP validation errors (see Resolve HTTP validation errors above).

  5. Redeploy the project (see Project deployment).

    Note

    Prior to redeployment, execution of any now-invalid operations is allowed, as Harmony executes the currently deployed operations. Redeployment of the affected operations is required for the changes to be propagated to Harmony.