During deployment of Azure Data Factory (ADF) via Azure DevOps pipelines I want to make sure that a certain trigger is only executed on Production and not on the lower environments. How can we do this without writing code (low-code)?
 |
| ADF Trigger |
Solution
When you start developing in a new ADF, the ARM template parameters file (result) only contains the ADF name that can be overwritten. When you have created a Linked Service, for example Azure Blob Storage, the file should look something like below.
This is possible by changing the ARM template parameter definition which on its turn will switch certain properties into overridable parameters during deployment. However, the triggers are not included by default in the parameter file. There is also a limitation that you cannot override every property, for example runtimeState to activate and deactivate the trigger. The workaround for this is to use the endTime property.
More information about which properties are parameterized can be found here.
1) Understand parameters in ADF
Before we start overriding properties in the ARM template, it is good to understand the parameters in general. As you know, when start building your ADF, one of the first things you do is creating a Linked Service. By default, ADF knows that for example a connection string or using a Key Vault in a Linked Service should be parameterize, because the database server or the URL will be different per environment in a DTAP. The result is always two ARM template files: the content itself (ARMTemplateForFactory.json) and the parameters that can be overwritten (ARMTemplateParametersForFactory.json). Another file holds the definition of the parameters (arm-template-parameters-definition.json).
When you start developing in a new ADF, the ARM template parameters file (result) only contains the ADF name that can be overwritten. When you have created a Linked Service, for example Azure Blob Storage, the file should look something like below.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"factoryName": {
"value": "bitools-d-adf-dwh"
},
"LS_ABLB_bitools_connectionString": {
"value": ""
}
}
}You can check this via "Manage - ARM template - Export ARM template".
 |
| ADF Portal - Check the parameters |
2) Check Trigger code
Now back to our trigger. Based on the documentation, we know which properties we can parameterize for a trigger. Lets have a look at the code of the trigger itself.
- In the ADF portal go to Manage (toolbox icon in left menu) and then to Triggers
- Find your trigger and hover your mouse on it and click on the code icon {}
 |
| ADF portal - Check the code of your trigger |
See below the JSON code of the trigger. You can override everything that is related to typeProperties. Unfortunately the runtimeState property is not one of them.
{
"name": "Trigger_Master",
"properties": {
"description": "Test",
"annotations": [],
"runtimeState": "Started",
"pipelines": [
{
"pipelineReference": {
"referenceName": "PL_Master",
"type": "PipelineReference"
}
}
],
"type": "ScheduleTrigger",
"typeProperties": {
"recurrence": {
"frequency": "Day",
"interval": 1,
"startTime": "2021-01-01T00:00:00Z",
"endTime": "2021-01-02T00:00:00Z",
"timeZone": "UTC",
"schedule": {
"minutes": [
10
],
"hours": [
0
]
}
}
}
}
}Now that we have identified which properties can be parameterized, we need to know which property we want to override for our use case. As you know, we need to make sure the trigger should not be executed on every environment. One way to do this is to set the end date (and time) of a trigger. This property is called endTime. For example: a trigger with an end date on "01/02/2021 12:00 AM" will not be executed because this is in the past. When the end date is "12/31/9999 12:00 AM", the trigger will be executed because it is in the future.
Go to your trigger and set an end date and time in the future, for example 12/31/9999 12:00 AM.
 |
| ADF portal - Specify end date for trigger |
3) ARM template
Next step is to override the endTime property in the ARM template parameter definition. Unlike integration runtime or linked services properties, we need to add this property first.
- In the ADF portal go to Manage (same as step 2) and then to ARM template
- Click on Edit parameter configuration
- Search for "Microsoft.DataFactory/factories/triggers" and add the endTime property (that is part of recurrence) within typeProperties, set the value to "=:-endTime" and click the OK button. See below how your JSON should look like for the trigger part.
"Microsoft.DataFactory/factories/triggers": {
"properties": {
"pipelines": [
{
"parameters": {
"*": "="
}
},
"pipelineReference.referenceName"
],
"pipeline": {
"parameters": {
"*": "="
}
},
"typeProperties": {
"scope": "=",
"recurrence": {
"endTime": "=:-endTime"
}
}
}
},Now check the ARM template parameters via "Manage - ARM template - Export ARM template" (see step 1) and the result should look like this.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"factoryName": {
"value": "bitools-d-adf-dwh"
},
"LS_ABLB_bitools_connectionString": {
"value": ""
},
"Trigger_Master_endTime": {
"value": "9999-12-31T00:00:00Z"
}
}
}In this case, we have set the default by using "=" in front of the value. Adding a minus - in front of parameter name (endTime) will remove "_properties_typeProperties" from the parameter name. More information here.
Note:
The global parameters are also not set by default. Click here how to include them in the ARM template parameters file as well.
4) Adjust release pipeline
If you are using YAML to publish the changes then the only thing you have to change is the overrideParameters property by adding the new parameter Trigger_Master_endTime and adding either a variable or a hardcoded value. The > behind the property helps you to break the string over multiple lines and keep the YAML code more readable.
###################################
# Deploy ADF Artifact
###################################
- task: AzureResourceManagerTemplateDeployment@3
displayName: '4 Deploy ADF Artifact'
inputs:
deploymentScope: 'Resource Group'
azureResourceManagerConnection: 'sc_mcacc-adf-devopssp'
subscriptionId: $(DataFactorySubscriptionId)
action: 'Create Or Update Resource Group'
resourceGroupName: $(DataFactoryResourceGroupName)
location: 'West Europe'
templateLocation: 'Linked artifact'
csmFile: '$(Pipeline.Workspace)/ArmTemplatesArtifact/ARMTemplateForFactory.json'
csmParametersFile: '$(Pipeline.Workspace)/ArmTemplatesArtifact/ARMTemplateParametersForFactory.json'
overrideParameters: >
-factoryName $(DataFactoryName)
-LS_ABLB_bitools_connectionString $(AzureBlobConnectionString)
-Trigger_Master_endTime $(AzureDataFactoryTriggerEndTimeActive)
deploymentMode: 'Incremental'
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)And if you're using the Release pipelines with the ARM template deployment task then you can just go to the Override template parameters property, click on the edit button and replace the value with a new value or a variable from a variable group.
 |
| ARM template deployment - Override template parameters |
Conclusion
In this post you learned how to add and override properties of a trigger during deployment via Azure DevOps. This allows you to activate or deactivate a trigger for that environment during deployment using ARM templates without writing any code.
In a previous post we showed you how to accomplish this for a Linked Service in combination with Azure Key Vault.
In a previous post we showed you how to accomplish this for a Linked Service in combination with Azure Key Vault.
