Implement a Service Window with Logic Apps

Sometimes you will come across a requirement in an integration solution where you need to implement a Service Window. A service window is a period where you need to stop and start processing based on a time schedule. A couple of examples where you may come across this are:

• A down stream legacy application has a back up process where the application needs to be off line while the back ups are taken
• A business process has a time window where processing needs to be paused such as only load jobs into an application up to 5 am and then workers will look to clear the job list. I have seen this in housing and warehousing sectors before

Although these requirements are less common these days because many systems and business processes operate 24/7, however you still occasionally come across this.

Readers who are familiar with BizTalk will remember that a Send Port had a basic service window capability where you could configure a start and stop time where the port would stop processing messages and then start again. It was quite a limited feature which struggled to deal with multiple service windows but covered most basic use cases.

The question today is with iPaaS on Azure how can I implement a Service Window pattern. Well lets consider the following architecture example.

In this example messages are sent to an API from external parties. The API places messages on a queue. A Logic App then processes the queue and loads messages into a database.

The requirement is that we need to stop processing messages between 11pm and 1am each day.

In the Logic App we can use recurrence triggers and polling intervals but they do not fully cover the requirements. We could achieve the service window requirement however if we were to control disabling and enabling the Logic App so that it was only processing at desired times. For example at 11pm we will disable the Logic App. At 1am we will enable the Logic App.

How to implement the service window

To implement the pattern I will use an automation runbook which I will add some Powershell to enable and disable the Logic App which I want to control.

Below is an example of the Powershell script:

[CmdletBinding()]
Param (
[Parameter (Mandatory = $true)][string]$ResourceGroupName,
[Parameter (Mandatory = $true)][string]$LogicAppName,
[Parameter (Mandatory = $true)][string]$DesiredState
)


$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

$AzureContext = Select-AzureRmSubscription -SubscriptionId $Conn.SubscriptionID

Set-AzureRmLogicApp -ResourceGroupName $ResourceGroupName -Name $LogicAppName -State $DesiredState -Force

Note to make this work I also added the AzureRM.LogicApp module to the Automation Account and the modules it depends on.

Once I have my runbook I can schedule it from the automation account if I want but the scheduling in Azure Automation accounts is a bit limited and the Logic App recurrence trigger is a more powerful scheduling engine.

I will instead create 2 Logic Apps, one called StartServiceWindow and one called StopServiceWindow. The StartServiceWindow logic app will trigger at 11pm every day and it will call the Azure Automation Runbook and pass parameters which will make the runbook disable the main Logic App. The StopServiceWindow logic app will trigger at 1am and it will call the Azure Automation Runbook and pass parameters to make it enable the main logic app. This will allow me to pause and resume processing messages from the queue. The below picture shows what the Logic Apps look like.

One of the powerful things about this pattern is that the API and queue will not prevent external parties submitting new messages, it is only the background processing that we will pause.

Using these process controller logic apps (start and stop) I could implement advanced patterns to disable and enable processing by using the power of the recurrence trigger or having more controller logic apps depending on my requirements. Also the runbook being parameterised, allows me to use the same runbook to control any Logic App my runbook has permission to access.

The final architecture diagram for my solution looks like the below.

Monitoring the Service Window

When I have implemented my Service Window, I also want to monitor it to ensure that it is operating correctly and to alert to me if there are any problems. There are a couple of ways I can do this. I can implement alerts if the Logic App fails, or also I could use Serverless 360 to implement a data monitoring. In Serverless 360 I would configure my data monitor to check that the logic app has executed at certain times of the day. For example I could check that between 10:30pm and 11pm the Logic App has executed at least once to disable the business process logic app.

Below shows the calendar view to show if your data monitoring is processing at the correct times.

You can findout more on the link below
https://docs.serverless360.com/docs/data-monitoring