Using splitOn in a trigger to avoid zero length executions

Last week I was reviewing a logic app with one of the lead developers at Theta. It was a relatively simple logic app. It needed to call an oData endpoint on a regular basis, and process the value back. The developer original design was to:

• Poll the oData endpoint on the agreed interval.
• Test if the value array length was bigger then zero
• If the array was larger than zero, process each value in the array within a for each.
• Else, terminate the instance as cancelled, so he could distinguish between real executions and zero-length polls.

That would work, but if felt wrong for a couple of reason.

• The logic app was wasting an action to test if the actual logic would be executed or not.
• Another action was being wasted just to tag the logic apps that didn’t actually “fired”.

Then it dawn on me that we should be using splitOn instead. This would avoid the check, Setting up the splitOn is as simple as adding this on your trigger:

"splitOn": "#splitOn-expression#",

You should add the snippet above to your trigger definition replacing the #splitOn-expression# with the that corresponds to your parent array. In my case, since I was splitting on the oData value array, it looked like this:

"triggers": {
	"HTTP": {
		"inputs": {
			"method": "GET",
			"uri": "https://www.samplelocation.com"
		},
		"recurrence": {
			"frequency": "Minute",
			"interval": 10
		},
		"type": "Http",
		"splitOn": "@triggerBody()?['value']"
	}
}

Notice that splitOn can’t be configured from the designer yet, so you need to include it from the code view. But once it is added, it will show in the settings screen, which probably means that you will be able to set this in the designer in the near future.

One thing I was not sure was what would be the splitOn behavior when the array was empty. It was a pleasant surprise to find out that by adding a splitOn on the trigger, it will not fire if the array is empty! That meant that I wouldn’t need to worry identifying logic apps that didn’t execute. On the other hand, if the array have values, one logic app will be created for each child element. The added bonus to have each logic app running individually is that, if one of the instances fail, you can notify and resubmit only that instance.

Couple this with the trigger concurrency control that have been added a while ago and you have full control over the behavior of your trigger. You can define if your trigger will create a new logic app for each children element or have a cap on the number of logic apps that trigger in parallel. And this is now quite simple to configure, since the concurrency control can be accessed from the designer, but simply accessing the trigger settings by clicking on (…) then Settings on the drop down menu. The screen will look like this:

Enable the Concurrency control by turning on the setting (1), the sliding up or down the degree of Parallelism to define how many instances of the logic app will be instantiated at a single time.

One important thing to remember is that splitOn works quite similar to the debatching functionality in BizTalk. Once you split, the trigger’s body for each logic app instance generated  will be each child element of the array you selected. What that means is that any data on the “envelope” message – e.g. any other parent and/or sibiliting of the element selected to be debatched will be lost.

In Summary

Using splitOn allow you to debatch your logic app trigger. Its behavior allow you to:

• Trigger logic apps instances only when there is data to be processed.
• Have an individual instance of each logic app, which will simplify notification and retry of failed logic app instances.

You can couple splitOn and concurrency control to throttle your logic app volume, in cases where your destination system might not be able to cope with the number of instances being executed.

You must be aware that only the children of the array you splitting will be available on the triggered logic app instances.