Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
In this article, we will explain how to set up one automation as a source and keep multiple target automations in other tenants synced with the changes made to the original. We will be using an intermediary tool for this process, in our case Github, to store the changes made to the source automation so you could also say this article doubles as a version control article for your future automations.
Setting up the source automation and syncing changes to Github
To get the initial automation data inside a Github repository, all we need to do is construct a quick automation that contains the "Get Automation" block and run it to receive the much-needed data in the block history. We can then copy that data and paste it all into a file inside our working repository. For example purposes, our working file is called 'automation.json' and is situated in the main directory of the demo repository.
Now that our initial setup is complete, we will list the steps needed to keep our repository up to date with all the changes to our automation. This is how the workflow will look:
You can see that our initial start block is replaced with a Qlik Cloud Services webhook that listens to all automations being updated in our tenant. We have also created a variable to keep the GitHub branch name in memory and keep it as a version number for the cases where it might be needed:
The formula used takes the date at which the automation was modified, transforming it to a UTC format, and attachs it to the branch name: version-{date: {$.AutomationUpdated.data.updatedAt}, 'U'}
We also need to attach a condition block to our flow to make sure only our source automation gets sent to our repository:
In this case, we are hardcoding the id of our automation in the condition input parameter. Next, on the 'yes' branch of the condition, comes the 'Get automation' block that will return the latest version of our source automation, followed by the flow that sends that data to a new branch in our Github repository. First, we create json object variable to store automation content from the 'Get automation' block:
Secondly, we create a new branch:
Thirdly, we update the automation.json file we had in our main repository with the new data we stored in the 'automationExport' json object variable block:
As you can see, GitHub platform only accepts BASE64 encoded file contents, so the JSON content received from 'automationExport' json object variable block will be transformed to that format. To create the commit and pull request, we have one more step, which is to find out the branch TREE SHA information:
With this information, we can go ahead and create the commit:
The final step in our flow is to create the pull request :
Keeping your target automation up to date with the latest version
To do this, we now move to our target tenant and create a separate automation there. The workflow involved is a simple one:
Again, the start block will get replaced by the Github webhook that is listening to all new pull requests done in our repository:
We also create an empty object variable that will be later used to save the incoming information from the repository. We need to create a condition block as well with the following two conditions:
This lets the automation flow continue only if the pull request has been closed and its contents have been merged into the main branch of our repository. It tells us that the pull request has been approved and we can sync all changes into our target automations. For that, we query the file contents of the repository and save that information in our object variable after we have transformed it from a BASE64 encoding format to a text-based format:
The formula used when assigning the value to the variable is {object: '{base64decode: {$.getFileContent}}'} which just removes the base64 formatting and turns the string into a JSON object to better handle it in the next block. Now all that is left is to use the 'Update Automation' block to bring the new changes to our target automation:
As you can see, we hardcoded the GUID of our target automation, but the do lookup functionality can be used as well to select one of the automations in our tenant. Finally, we need to send the correct parameters from our object to the input parameters of the block. This can easily be done by selecting the Name, Description, Workspace and Schedule parts of the object.
This should let you keep your automations synced over multiple tenants. Your target automation history should not be impacted by the syncs in any way.
Please be aware that if the target automation is open during the sync process, the changes to it will not be reflected in real-time and a reopening of the automation will be needed in order to see them.
Attached to this article you can also find the JSON files that contain the automation flows presented.
The information in this article is provided as-is and to be used at own discretion. Depending on tool(s) used, customization(s), and/or other factors ongoing support on the solution below may not be provided by Qlik Support.
