Propagating Event Rule Artifacts

Administrators can propagate (copy) individual items in Custom Commands, Advanced Workflows, and Connection Profiles to another server (for example, when adding a server to a cluster).

  • Propagation is only available for EFT-managed administrator accounts

  • Multiselect is not supported

  • The target server must have remote administration and REST API/ web administration enabled on the Server > Administration tab

To propagate items

  1. In the administration interface, on the Server tab, right-click the item to propagate (such as the Advanced Workflows node), then click Propagate. The Propagate dialog box appears.

  2. In the Propagate dialog box, specify:

    1. Target EFT Server administrator REST endpoint in the form of http or htt://[host]:[port]

    2. Target EFT Server administrator username

    3. Target EFT Server administrator password

    4. Target EFT Server Site name to which you want to propagate the item

    1. Select the Save target EFT Server parameters for future use check box if you plan to propagate numerous items. All the parameters except for target server administrator password are preserved across administration interface restart.

  3. Click Propagate. A prompt is displayed to the EFT administrator that action was successful or failed.

The result of successful propagation is that the artifact on the target EFT server is identical to the one propagated. The identity is provided by internal artifact ID.

  • If target server’s Site had no artifact with matching ID, it is created

  • If target server’s Site had the artifact with matching ID, it is replaced

Exceptions (not propagated) are:

  • Custom Command’s user-group assignment:

    • New Command has no user-group assignment

    • Replaced Command preserves its user-group assignment unchanged

  • Advanced Workflow’s Folder assignment:

    • New Workflow is placed outside any Folder

    • Replaced Workflow remains in its original Folder

NOTE: In the Advanced Workflows module, variables cannot contain periods; therefore, in each variable that contains a period, the period is replaced with an underscore. For example, change %CONNECTION.LOCAL_IP% to
%CONNECTION_LOCAL_IP%

  • Admin ACL for all artifacts:

    • New artifact gets all admin permissions "inherited" from root container

    • Replaced artifacts preserves its permissions unchanged

When accepting the artifact, the target server performs all the standard activities, such as access control, name collision prevention, data validation, audit, logging, and so on.

  • For creating new artifact, the ones performed when creating artifact via REST

  • For replacing existing artifact, the ones performed when updating artifact via REST

  • For name collision, no new validation was introduced, this functionality is dependent on REST API, i.e., if REST API allows it (even with case sensitivity) then propagate functionality will allow it

For artifact customization, some fields accept Run-Time Variables, which are:

  • Custom Command:

    • Executable path

    • Log file path

  • Advanced Workflow

    • Log directory path

  • Connection Profile

    • All the fields that are Run-Time Variables-aware in Offload/Download/Cloud Actions

  • Run-Time Variables are allowed to be specified in all EFT administrative interfaces (GUI, COM, and REST)

    • EFT validates incoming change and fails to accept if the fields contain unknown Run-Time Variables. In particular, it means that if the source server’s artifact references the Run-Time Variable that is not defined in target server, propagation fails.

To support identity by artifact ID, EFT Administrative REST interface handles HTTP PUT requests on individual artifact endpoints.

  • The new PUT REST endpoints are:

    • Custom Command: /Admin/v2/sites/<site-id>/custom-commands/<command-id>

    • Advanced Workflow: /Admin/v2/sites/<site-id>/awe-tasks/<workflow-id>

    • Connection Profile: /Admin/v2/sites/<site-id>/connection-profiles/<profile-id>

  • The requests follow standard JSON:API model

  • The semantics of the request is “create or replace”:

    • If the endpoint corresponds to no existing artifact, EFT considers the request “create resource” one and serves it similar to POST to collection with the only difference that the artifact created has the specified (rather than random) id.

    • If the endpoint corresponds to existing artifact, EFT considers the request “replace resource” one and serves it similar to PATCH (“update resource”) with the difference that, the body of PUT is considered full representation of the resource and all the missing fields are considered to have default (not “current” as for PATCH) values.

Effectively, when an artifact is propagated for the first time, target server creates its identical copy; for any subsequent propagation, target server replaces the copy with up-to-date value.

The Source server records propagation progress to EFT.log via COMMON logger (this is because the destination is not exercising REST API, its receiving incoming data).

Target server records propagation progress to EFT.log via standard REST Admin logger.

Artifact propagation is available via COM API Site interface new methods:

  • ICISite::PropagateCommand

  • ICISite::PropagateAdvancedWorkflow

  • ICISite::PropagateConnectionProfile

Artifact propagation is available via REST Admin interface

POST REST API endpoints:

  • Custom Command: /Admin/v2/sites/<site-id>/custom-commands/<command-id>

  • Advanced Workflow: /Admin/v2/sites/<site-id>/awe-tasks/<workflow-id>

  • Connection Profile: /Admin/v2/sites/<site-id>/connection-profiles/<profile-id>

Method name is “propagate” for all requests.

Example success case:

POST /Admin/v2/sites/00000000-0000-0000-0000-000000000001/custom-commands/00000000-0000-0000-0000-000000000001 HTTP/1.1
{
   "jsonrpc": "2.0",
   "method": "propagate",
   "id": "1",
   "params": 
   {
   "targetEndpoint": "http://target:4450",
   "targetSiteName": "targetSite",
   "targetAdminUsername": "targetAdminLogin",
   "targetAdminPassword": "targetAdminPassword"
   }
}
HTTP/1.1 200 OK
{
"jsonrpc": "2.0",
"id": "1",
"result": "success"
}

Example failure case:

POST /Admin/v2/sites/00000000-0000-0000-0000-000000000001/custom-commands/00000000-0000-0000-0000-000000000001 HTTP/1.1
{
  "jsonrpc": "2.0",
  "method": "propagate",
  "id": "1",
  "params": 
  {
  "targetEndpoint": "http://target:4450",
  "targetSiteName": "targetSite",
  "targetAdminUsername": 
   "targetAdminLogin","targetAdminPassword": 
   "targetAdminPassword"
  }
}
  HTTP/1.1 404 Not Found
  {
  "jsonrpc": "2.0",
  "id": "1",
  "error": {
  "code": -32004,
  "message": "Not found: custom-command (00000000-0000-0000-0000-000000000001)"  
  }
}