Page 29 - MSDN Magazine, November 2018

an appropriate HTML page (View) to each individual browser. The time taken for the Web App to return a view determines the responsiveness of your Web site and the number of simultaneous users it can support. For this reason there’s a pressing need to avoid long-run- ning process when obtaining the data needed by your Web site views. A Service Bus Queue is a good way to address this type of problem, as it allows your Web App to store messages containing the processing details, and then provides an immediate response to the user—even if it’s just a view that says come back later for the result. Another software component operates in the background to read the queue and perform the required processing for each message.
Browser
Result
1
Send Form
Azure
Web App
Polling
3
Create Read
4
Update
In the case of my application, Service Bus queue is ideal. It’s also cheap and very easy to use, particularly now that there’s good integration with Azure Functions, which are perfect for doing my background processing.
Provisioning Azure Resources
Azure Cloud Shell is built into the Azure Portal Web site and allows you to provision Azure Resources using a series of simple commands from the PowerShell Console. To create the Azure Service Bus queue and Func- tion App, you must issue commands from the Cloud Shell, with appropriate values for your subscription, resource group and location. These values will be the same ones you used to provi- msdnmagazine.com
Figure 2 The OvaryVis Class in the Models Folder
Form
01 02 03
Submit
5 F5 - Refresh
Return View
Figure 1 System Overview
Service Bus Queue
Message
2
Azure Function Trigger
Service Bus
Database OvaryVis Record
The advantage of Service Bus is that when lots of
users are submitting data for classification, the queue
simply gets longer. Yes, this means people may need to wait longer for their results, but it ensures that the Web site remains respon- sive. It also de-couples your system by separating foreground Web App processing from the component running your background processing. Azure services like Storage queues, EventHubs and EventGrid perform a similar function, but target other types of usage. You can find a useful comparison of Azure Storage queues and Service Bus queues at bit.ly/2QJVwNp, and a comparison of Azure messaging services at bit.ly/2DoY1T5.
The advantage of Service Bus is that when lots of users are submitting data for classification, the queue simply gets longer.
sion your Web app and database. You also need to give yourself a unique Service Bus namespace rather than MSDNOvaryVisSBQ. Here are the commands to use:
az account set --subscription MsdnOvaryVis
azservicebusnamespacecreate --nameMSDNOvaryVisSBQ--location"WestEurope"
--resource-group resMSDNOvaryVis --sku Basic
az servicebus queue create --name dimsubmission --namespace-name MSDNOvaryVisSBQ
--resource-group resMSDNOvaryVis --max-size 1024
You’ll notice that I opted for the lowest service tier (--sku Basic), which allows me to receive 1 million messages up to 256KB each in size for $0.05 with no monthly charge. In addition to creating a Service Bus queue you also need to create a Function app and a new storage account for it, as shown here:
az storage account create -name msdnovaryvisstorageac --resource-group resMSDNOvaryVis
--location "WestEurope" --sku Standard_LRS
az functionapp create --name MSDNOvaryVisFnApp --resource-group resMSDNOvaryVis --storage-account msdnovaryvisstorageac --consumption-plan-location westeurope
The name of the Function app service is publicly accessible, so you’ll need to enter your own name in place of MSDNOvary- VisFnApp. You should also note that creating your first Azure Function results in the creation of a consumption plan, which is
November 2018 23