////
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements.  See the NOTICE file
distributed with this work for additional information
regarding copyright ownership.  The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License.  You may obtain a copy of the License at
  http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied.  See the License for the
specific language governing permissions and limitations
under the License.
////
[[RemoteWorkflowEngine]]
:imagesdir: ../assets/images
:openvar: ${
:closevar: }
:description: The remote run configuration runs workflows on a remote Hop Server. This run configuration requires little configuration, but requires a Hop Server and a Hop Server metadata definition.

= Remote Workflow Engine

== Hop Remote workflow engine

The remote run configuration runs workflows on a remote Hop Server.

This run configuration requires little configuration, but has two prerequisites:

. a running xref:hop-server/index.adoc[Hop Server]
. a xref:metadata-types/hop-server.adoc[Hop Server metadata definition] in your project, pointing to your running Hop Server.

This page describes the options that are specific to the remote workflow engine. These options extend the general  xref:workflow/workflow-run-configurations/workflow-run-configurations.adoc[workflow run configuration options].


=== Options

[options="header",cols="1,3"]
|===
|Option|Description

|Hop server
|The remote Hop server to run your workflow on.

|Run Configuration
|The configuration to use on the remote Hop Server.
In most configurations, this will be a local (locally on the server) runtime configuration.
In rare cases you might want to run on yet another server using another remote workflow configuration.

|Server poll delay (ms)
|The delay in milliseconds between periodic polls to the remote server.
If you don't specify a value this defaults to 1000ms (1 second)

|Server poll interval (ms)
|The interval in milliseconds between periodic polls to the remote server.
If you don't specify a value this defaults to 2000ms (2 seconds)

|Export linked resources to server?
|Enable this option if you want to not only send the current workflow to the server but also other referenced workflows and pipelines.
See below for detailed information

|Named resources reference source folder
|This is the reference source folder for the named resources that are being used (e.g. `{openvar}PROJECT_HOME{closevar}`).
See below for detailed information.

|Named resources reference target folder
|This is where you expect the source folder to map to on the server (e.g. `/path/on/server`).
See below for detailed information.

|===

=== Export linked resources to server

This option sends not just the parent workflow to the server but also all other referenced pipelines and workflows.
For example if you have pipelines or workflows referenced in actions they will be sent to the server as well.
All the used pipelines and workflows together with the XML presentation of the workflow execution configuration will be sent over to the server in the form of a ZIP archive.
The server receives this archive and without unzipping runs the workflow.
To make this function correctly, Hop changes the references as well as references to filenames.
For example `{openvar}PROJECT_HOME{closevar}/update-dimensions.hwf` will be changed to `{openvar}Internal.Entry.Current.Folder{closevar}/update-dimensions.hwf`.
As you can see Hop will try to use a relative path to the parent file.

If you have are using data files then those file names will be renamed as well.
For example, you might be reading a file called `{openvar}PROJECT_HOME{closevar}/files/bigfile.csv` in a `CSV File Input` transform.
During the export the referenced filename will be changed to `{openvar}DATA_PATH_1{closevar}/bigfile.csv`.
For every folder that is referenced a new variable will be defined and set in the execution configuration.
By default, the path set for this variable will be the same as on the executing (local) machine.
On the server this might not make a lot of sense.
For this reason you can specify a reference source folder like `{openvar}PROJECT_HOME{closevar}` in combination with a target folder like `/server/`.
In that example variable `DATA_PATH_1` will get value `/server/files/`.
This in turn allows you to transfer required files in advance or map a folder into a docker container and so on.
It gives you flexibility when executing remotely while having ease of development on your client.

