Run a Workflow in Different Environments

When you create a workflow, you know in advance where the workflow will run—on the server or, if it is a client workflow, in a particular types of host applications, like VertiGIS Studio Web or ArcGIS Web AppBuilder. As part of the authoring process, you test the workflow in your chosen environment, without testing it in other environments.

Later, you might decide to use the workflow in a different environment. For example, you might want to support an additional type of host application.

If the workflow fails when you try to run it in its new environment, it could be for one of the following reasons:

• Activities: Different environments support different activities. A workflow will fail at run time if it contains an activity that is not supported by the environment it is running in.

• Objects: Applications in different environments can be built on different software development platforms or different versions of the same platform. For example:

  • The Geocortex Viewer for HTML5 uses the 3.x ArcGIS API for JavaScript.
  • VertiGIS Studio Web uses the 4.x ArcGIS API for JavaScript.
  • VertiGIS Studio Mobile uses the 100.x ArcGIS API for .NET, including the Android, iOS and Windows variants.

  The underlying objects for the different platforms can have different properties and functions, or properties and functions that behave differently.

  A workflow will fail at run time if it contains an expression that references a property or function that does not exist in the environment. Even if the property or function exists in both environments, it could behave differently.

  There are steps you can take to ensure that a workflow will run in different environments, described below in Create Workflows that Can Run in Different Environments. If you have an existing workflow that you are trying to run in a new environment without success, follow the guidelines in Adapt a Workflow to a New Environment.

Create Workflows that Can Run in Different Environments

Workflow Designer is designed to help you create workflows that can run in any of the supported environments—in different host applications or on the server.

Follow the guidelines below to create a workflow that is capable of running in different environments:

• Declare the Environments: When you create a workflow, you specify the type of workflow (client or server) and, if it is a client workflow, which types of client application will host the workflow. Workflow Designer uses this information to filter the Toolbox so it only shows activities that work in your chosen environments. This prevents you from adding activities that are not supported in your chosen environments. If you decide to run a workflow in a different environment, make sure you update the environments in Workflow Designer. For instructions, see Change a Client Workflow's Host Applications or Change the Type of a Workflow.

• Use Activities Instead of Expressions: Many activities compensate for the differences between APIs so objects behave the same in the different environments. When you have a choice between using an expression or an activity to perform a particular operation, use the activity. This protects you from the environmental differences between objects.

  For example, suppose you want to get the extent of a geometry. An expression with geometry.getExtent() would work in an ArcGIS API for JavaScript 3.x app, but not in a 4.x app. An expression with geometry.extent would work in a 4.x app but not in a 3.x app. Using the Get Geometry Extent activity instead of an expression will work in either environment because the activity contains code that compensates for the differences between the APIs.

  Similarly, if you want to get the JSON for a geometry, the toJson() method would work in 3.x but not 4.x, and the toJSON() method would work in 4.x but not 3.x. The Convert To JSON activity will work in either environment.

• Use Auto-Complete Suggestions in Expressions: When you configure an object in an expression, Workflow Designer shows auto-complete suggestions for properties and functions that work the same in all environments. An object might have additional properties and functions that Designer does not suggest. Designer never suggests a property or function that is only available in a subset of the supported environments or that behaves differently in different environments.

  To ensure that your workflow will not fail in other environments due to differences between an object's properties and functions, limit yourself to using the suggested properties and functions.

  VertiGIS Studio Workflow only supports properties and functions that are suggested by auto completion. If a property or function is not suggested by auto completion, it is not supported.

  The fact that a property or function is not supported by VertiGIS Studio Workflow doesn't mean that it won't work. You can access an unsupported property or function by locating its name in the console and then typing the name into the expression. Be aware that if you do this, the expression might be invalid in some environments, causing the workflow to fail.

Adapt a Workflow to a New Environment

If a workflow fails when you run it in a different environment, it could be for one of these reasons:

• The workflow uses an activity that is not supported in the new environment.

  If the new environment was selected when the workflow was created, you can eliminate this as the source of the problem.

• The workflow accesses an unsupported property or function in an expression. The property or function either doesn't exist or behaves differently in the new environment.

  If the workflow only accesses properties and functions that are suggested by auto completion, you can eliminate this as the source of the problem.

If you think that one of these reasons might be causing the problem, follow the guidelines below to debug the workflow:

• Make sure the workflow's host applications are configured correctly on the Deployment panel. This allows you to compare the activities in the workflow to the activities in the Toolbox to see if the workflow has used an activity that is not supported in the new environment. It also ensures that you don't inadvertently add an unsupported activity when you fix the workflow.

• Use error messages, the Log activity, and the verbose log to locate the activity or expression that is causing the problem.

• Redesign the workflow to accomplish what you want without using the activity, property, or function that is causing the problem.

• Use the Validation panel to see if you have used an activity that is not supported by the selected environment. If you have an unsupported activity, use the Navigator to find all instances of a particular activity.

  • The Info panel can be used to determine the environment your workflow runs in.

    • The Workflow Type section displays whether your workflow is a client workflow or server workflow.

      The Workflow Type is only visible in on-premises Workflow.

    • The Deployment panel displays a client workflow's host applications. The Toolbox only displays activities that work in the selected host applications.

• Remember to test the workflow in each type of host application, not just the new host application. This ensures that your modifications haven't introduced a problem in another environment.

Underlying Technologies

Host applications are built on different technologies—JavaScript for applications that run in a web browser and .NET for mobile apps. Workflow Server is built on .NET. This means that the underlying objects that a workflow operates on differ depending on the environment that the workflow runs in.

There are significant differences between these technologies. The differences exist at many levels:

• Host applications use different ArcGIS APIs, either JavaScript or .NET. There are significant differences between these APIs.

• Within the ArcGIS API for JavaScript there are two major versions—3.x and 4.x. There are significant differences between these API versions.

• Within a major version of each ArcGIS API (for example, between 4.10 and 4.11) there are subtle differences.

• With each incremental release of a host application, the ArcGIS API version that it references will typically change to use the latest minor version.

The table below lists the technologies and ArcGIS API versions for the different environments supported by VertiGIS Studio Workflow.

Technologies used by VertiGIS Studio Workflow run-time environments

Environment	Built On	ArcGIS API Version
VertiGIS Studio Web	JavaScript	4.x
VertiGIS Studio Mobile (both VertiGIS Studio Go and custom apps)	.NET	100.x
Geocortex Viewer for HTML5	JavaScript	3.x
ArcGIS Web AppBuilder (both Enterprise and Developer Edition)	JavaScript	3.x (2D apps) 4.x (3D apps)
Server workflows *	.NET	Not applicable. Workflow Server does not reference any ArcGIS APIs.

*  Some activities can be used in both client and server workflows. These activities are capable of running in both
    JavaScript- and .NET-based environments. The activities behave the same regardless of the environment.