Replace IDs with system independent party keys for wf-target-changed event in asset automation for Git compatibility

Motivation

Following the rollout of our Git integration for the Admin Client, we received a feature request to ease the transition to Git-based development and deployment. The request is focused on a specific case: an asset automation that used workflow target change as an event trigger.

Problem and solution

IDs for defining workflow targets in asset automations

Previously, the workflow target had been set by the user or user group ID. IDs are created automatically upon creation of a user or user group. This fact made it difficult to re-use asset automations between environments, as both types of IDs are only unique within their original environment. They lose its meaning after the automation is deployed to the next environment through Git. I.e., the XML configurations are getting copied, but contain the IDs that do not exist in the new environment.

Keys as alternative to IDs

As a solution, we introduce an alternative parameter to be used in such automations instead of the user or group ID: the user or group key (also referred to as party key).

A party key is a unique identifier. For users, such key is their login. For groups, the key needs to be created manually, either upon group creation or later, but always before you want to use it in an asset automation. Group keys are part of the master data.

IDs can still be used, but we encourage you not to do so for any newly created automations. This option is only kept for backward compatibility of existing automations.

Where to enter party keys

Party keys can be edited using one of the two options.

• If you use XML for creating asset automations, then please enter param3_key in there. Example:

<event target="AssetEvent" param2="0" method="wf-target-changed" param3_key="john.smith"/>

• If you use the Admin Client, you will see two dropdown next to each other of you chose “Asset workflow target changed” as an event trigger. Example:

Using the dropdowns is completely safe: you won‘t be able to enter any contradictory values in there. In fact, as soon as you use one of the dropdowns, the value in the other will be reset.

Moving asset automations between environments

To wrap it up, please consider the following if you want to move a custom asset automation from one environment to another by deploying a Git branch.

Depending on where you are in your customization project – at the very beginning or in the middle of the progress – you still may or may not need to do manual changes.

• If an automation already relies on party keys, make sure that the master data changes are deployed to the target environment too. No additional work required.

• If any automations still rely on IDs:

  • In the source environment:

    • create group keys if necessary

    • replace all IDs with party keys

    • deploy to the target environment together with the changes in the master data

  • Alternatively, but not recommended: you can deploy everything as-is and make changes in the target environment. You will also need to backpropagate changes to the source environment for consistency.

For now, there is no out-of-the-box way to automatically replace IDs with the corresponding party keys. For this reason, migrating existing automations requires a special attention from you.

Optional reading