Debug Azure Functions

Since July I’m doing an assignment where Azure functions are intensively used. The functions are developed in Visual Studio, which has many advantages over developing functions in the Azure Portal. In Visual Studio you have intellisense, functions can be brought under source control and you can easily debug function execution. When you develop a Http Trigger function, you can perform the following steps:

• Set Function project as the StartUp Project.
• Set breakpoints in your function code.
• Check if all application settings are contained in local.settings.json. When debugging the application settings from the Azure Portal are not used.

Example local.settings.json:
{
“IsEncrypted”: false,
“Values”: {
“APPINSIGHTS_INSTRUMENTATIONKEY”: “1ef50250-49f8-463d-849a-e264336c6797”,
“AzureWebJobsStorage”: “DefaultEndpointsProtocol=https;AccountName=…;AccountKey=…;EndpointSuffix=core.windows.net”,
“AzureWebJobsDashboard”: “DefaultEndpointsProtocol=https;AccountName=…;AccountKey=…;EndpointSuffix=core.windows.net”,
“AfasGetPos”: “https://99999.afasonlineconnector.nl/profitrestservices/connectors/ASB_Totara_Pos?take={0}”,
“AfasGetPosTake”: “1000”,
“AfasToken”: “PHRva2Vu…48L3Rva2VuPg==”
},
“ConnectionStrings”: {
“OutputDataConnectionString”: “Server=tcp:blo-asb-dev.database.windows.net,1433;Initial Catalog=db-blo-asb-dev-sql;Persist Security Info=False; …”
}
}

• Press <F5> to start debug mode.

• Copy the address from the debug Window that appears
• Open Postman. Select POST as the Http method. Copy the function address in the address box. Enter the correct body and click submit.
• The function will be called and the first breakpoint is hit in Visual Studio.

Following the above procedure, you can also debug a Queue trigger function. The only problem is, that you will not get an address after pressing <F5>.

That actually makes sense, because you are not calling a Http service. What you do after pressing <F5> is, drop a message in an Azure Storage queue via the Azure Storage Explorer. The function will be called again and the first breakpoint is hit in Visual Studio.

For remote debugging, see: TwoCents post.

Debug an API App

Just because this knowledge faded away as well over the past few months. It’s very easy to debug a custom API App if you keep a few gotchas in mind. Here is a simple stepping plan.

1. Publish your API App to Azure. See the previous post. Make sure you deploy the API App with the Debug configuration (see Settings tab).
2. Next create a new Console project and solution. For instance. The solution could be Client.DSP.DSPClient and the project DSPClient. As we’ll see later, it’s very important to create the testclient in a separate solution.
3. Right-click the console application and select Add\REST API Client. The dialog is self explaining. Client code to consume the API App will be generated.
4. Now move to file Program.cs to add code for calling the client. In this case I had to pass the contents of a XML file. As an example see the code below.
5. Now go to the solution with your custom API App. On the left hand side in Visual Studio, you will see the Server Explorer. Select the Azure node, select App Service. Select the resource group and your custom API App. Right-click the custom API App and select Attach Debugger. The API App will  be started now. You can add breakpoints.
6. Now go to the client project. Set a breakpoint and press <F5>. Now you can start debugging.

Example code test client:

class Program
{
static void Main(string[] args)
{

var client = new DSPConnector();

string path = @”C:\Test\AGAssetsAHak.xml”;
string AGA_xmlstring = File.ReadAllText(path);

string result = client.PostAGAssets(AGA_xmlstring);

}
}

Attaching the debugger

I wanted to test a pipeline component that is executed after a resubmit via de ESB Portal. My standard approach is to add the assembly with the pipeline component to the GAC, reset IIS and then attach the debugger to the process. For some reason the breakpoints in code are not always hit. What you can also do, is add the following code at the beginning of the method to be debugged.

#if DEBUG
Debugger.Launch();
#endif

BRE resolver for itinerary fails

Error:
Procedure or function ‘Itinerary_getitinerary’ expects parameter ‘@name’, which was not supplied.

This error generally means that no itinerary name was returned from the resolver, in this case the BRI resolver. Either the resolver connection string is wrong or the BRE policy rule has an error that is causing itinerary resolution to fail.

The best way to debug is via DebugView. To enable tracing for ESB Toolkit:

• Open C:\Windows\Microsoft.NET\Framework64\v4.0.30319\CONFIG\machine.config for 64-bit
• Paste the following information under System.Diagnostics:

<system.diagnostics>
<switches>
<add name=”BizTalkESBToolkit21″ value=”4″/>
</switches>
</system.diagnostics>

• Start the DebugView program (Download)
• In DebugView, on the Capture menu, click Capture Global Win32 to make sure that it is checked.
• In the BizTalk Server Administration console, restart the BizTalkServerApplication host instance.