Creating event-based triggers
Often, it is convenient to run a data movement pipeline in response to an event. One of the most common scenarios is triggering a pipeline run in response to the addition or deletion of blobs in a monitored storage account. Azure Data Factory supports this functionality.
In this recipe, we shall create an event-based trigger that will invoke a pipeline whenever new backup files are added to a monitored folder. The pipeline will move backup files to another folder.
Getting ready
- To illustrate the trigger in action, we shall use the pipeline in the Using parameters and built-in functions recipe. If you did not follow the recipe, do so now.
- We shall be creating a pipeline that is similar to the pipeline in Using the ForEach and Filter activities recipe. If you did not follow that recipe, do so now.
- In the storage account (see the Technical requirements section), create another folder called
Backups
. - Following steps 1 to 3 from the Using the Copy activity with parameterized datasets recipe, create a new dataset and point it to the
Backups
folder. Call itBackups
. - Register
Event.Grid Provider
with your subscription:a. Go to the portal and look for Subscription. Click on your subscription name.
b. In the Subscription blade, look for Resource Provider.
c. Find Microsoft.EventGrid in the list and hit the Register button. Wait until the button turns green (an indication that the registration succeeded).
How to do it…
First, we create the pipeline that will be triggered when a new blob is created:
- Clone the pipeline from the Using the ForEach and Filter activities recipe. Rename the clone
pl_orchestration_recipe_7_trigger
. - Rename the FilterOnCSV activity
Filter for Backup
. In the Settings tab, change Condition to@endswith(item().name, '.backup')
: - In the ForEach Activity, change the Items value to
@activity('Filter For Backup').output.Value
in the Settings tab: - In the ForEach activity canvas, remove the Metadata and Stored Procedure activities. Add a Copy activity to the ForEach canvas and configure it the following way:
Name:
Copy from Data to Backup
Source Dataset:
CsvData
(the parameterized dataset created in the first recipe)Filename:
@item().name
Sink Dataset: The
Backup
dataset - In the same ForEach canvas, add a Delete activity. Leave the default name (
Delete1
). Configure it in the following way:In the Source tab, specify Source Dataset as
CsvData
. In the Filename field, enter@item().name
.In the Logging Settings tab, uncheck the Enable Logging checkbox.
Note:
In this tutorial, we do not need to keep track of the files we deleted. However, in a production environment, you will want to evaluate your requirements very carefully: it might be necessary to set up a logging store and enable logging for your Delete activity.
- Connect the Copy from Data to Backup activity to the Delete1 activity:
- Configure the event trigger. In the Manage tab, select Triggers and click on the New button to create a new trigger. In the New trigger blade, configure it as shown in Figure 2.39. Make sure to select the Yes radio button in the Activated section:
After you select Continue, you will see the Data Preview blade. Click OK to finish creating the trigger.
We have created a pipeline and a trigger, but we did not assign the trigger to the pipeline. Let's do so now.
- In the Author tab, select the pipeline we created in step 1 (
pl_orchestration_recipe_7
). Click the Add Trigger button, and select the New/Edit option.In the Add trigger blade, select the newly created trigger_blob_added trigger. Review the configurations in the Edit trigger and Data preview blades, and hit OK to assign the trigger to the pipeline:
- Publish all your changes.
- Run the
pl_orchestration_recipe_1
pipeline. That should create the backup files in the data folder. The trigger we designed will invoke thepl_orchestration_recipe_7
pipeline and move the files from thedata
folder to thebackups
folder.
How it works…
Under the hood, Azure Data Factory uses a service called Event Grid to detect changes in the blob (that is why we had to register the Microsoft.EventGrid
provider before starting with the recipe). Event Grid is a Microsoft service that allows you to send events from a source to a destination. Right now, only blob addition and deletion events are integrated.
The trigger configuration options offer us fine-grained control over what files we want to monitor. In the recipe, we specified that the pipeline should be triggered when a new file with the extension .backup
is created in the data container in our storage account. We can monitor the following, for example:
- Subfolders within a container: The trigger will be invoked whenever a file is created within a subfolder. To do this, specify a particular folder within the container by providing values for the container (that is, data) and the folder path(s) in the blob name begins with field (that is,
airlines/
). .backup
files within any container: To accomplish this, select all containers in the container field and leave.backup
in the blob name ends with field.
To find out other ways to configure the trigger to monitor files in a way that fulfills your business needs, please refer to the documentation listed in the See also section.
There's more…
In the recipe, we worked with event triggers. The types of events that ADF supports are currently limited blob creation and deletion; however, this selection may be expanded in the future. If you need to have your pipeline triggered by another type of event, the way to do it is by creating and configuring another Azure service (for example, a function app) to monitor your events and start a pipeline run when an event of interest happens. You will learn more about ADF integration with other services in Chapter 8, Working with Azure Services Integration.
ADF also offers two other kinds of triggers: a scheduled trigger and a tumbling window trigger.
A scheduled trigger invokes the pipeline at regular intervals. ADF offers rich configuration options: apart from recurrence (number of times a minute, a day, a week, and so on), you can configure start and end dates and more granular controls, for the hour and minute of the run for a daily trigger, the day of the week for weekly triggers, and the day(s) of the month for monthly triggers.
A tumbling window trigger bears many similarities to the scheduled trigger (it will invoke the pipeline at regular intervals), but it has several features that make it well suited to collecting and processing historical data:
- A tumbling window trigger can have a start date in the past.
- A tumbling window trigger allows pipelines to run concurrently (in parallel), which considerably speeds up historical data processing.
- A tumbling window trigger provides access to two variables:
trigger().outputs.WindowStartTime  trigger().outputs.WindowEndTime
- Those may be used to easily filter the range of the data it is processing, for both past and current data.
A tumbling window trigger also offers the ability to specify a dependency between pipelines. This feature allows users to design complex workflows reusing existing pipelines.
Both event-based and scheduled triggers have a many-to-many relationship with pipelines: one trigger may be assigned to many pipelines, and a pipeline may have more than one trigger. A tumbling window trigger is pipeline-specific: it may only be assigned to one pipeline, and a pipeline may only have one tumbling window trigger.
See also
To learn more about all three types of ADF triggers, start here:
- https://docs.microsoft.com/azure/data-factory/concepts-pipeline-execution-triggers#trigger-execution
- https://docs.microsoft.com/azure/data-factory/how-to-create-event-trigger
- https://docs.microsoft.com/azure/data-factory/how-to-create-schedule-trigger
- https://docs.microsoft.com/azure/data-factory/how-to-create-tumbling-window-trigger