Showing posts with label Functions. Show all posts
Showing posts with label Functions. Show all posts

Sunday 18 June 2023

App Insights for Power Platform - Part 6 - Power Automate Logging

Note: Announcement 23 Aug 2023 - integration of Power Automate telemetry data with Azure Application Insights.

Series

App Insights for Power Platform - Part 1 - Series Overview 

App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics 

App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

App Insights for Power Platform - Part 4 - Model App Logging

App Insights for Power Platform - Part 5 - Logging for APIM 

App Insights for Power Platform - Part 6 - Power Automate Logging (this post)

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards 

App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics

App Insights for Power Platform - Part 9 - Power Automate Licencing

App Insights for Power Platform - Part 10 - Custom Connector enable logging

App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern

Overview:
  • Power Automate holds it own set of logs and history.  While Power Automate's internal logging is good and useful, it does not push logs into App Insights or Log Analytics for central monitoring.
  • You can manually export Power Automate logs from Power Platform and import them into Log Analytics, using the "Data Export" option.

  • Or you can create an Azure Functions that you can use to write to App Insights, below is a simple recording of the function (this is recording aims to remove complexity so there is no VS Code or publishing.
Function to write into App Insights Logs

#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    dynamic data = JsonConvert.DeserializeObject(requestBody);
    int eventId = data?.eventId;
    string errType = data?.errType;
    string errMsg = data?.errMsg;
    string correlationId = data?.correlationId;
    string workflowId = data?.workflowId;
    string workflowUrl = data?.workflowUrl;    
    string flowDisplayName = data?.flowDisplayName;

var custProps = new Dictionary<stringobject>()
{
    { "CorrelationId", correlationId},
    { "WorkflowId", workflowId},
    { "WorkflowUrl", workflowUrl},
    { "WorkflowDisplayName", flowDisplayName}
};

using (log.BeginScope(custProps))
{
    if (errType=="Debug"
    {
        log.Log(LogLevel.Debug, eventId, $"{errMsg}");   
    }
    else if (errType=="Critical")
    {
        log.Log(LogLevel.Critical, eventId, $"{errMsg}");  
    }
    else if (errType=="Warning")
    {
        log.Log(LogLevel.Warning, eventId, $"{errMsg}");   
    }
    else if (errType=="Trace")
    {
        log.Log(LogLevel.Trace, eventId, $"{errMsg}");          
    }
    else if (errType=="Error")
    {
        log.Log(LogLevel.Error, eventId, $"{errMsg}");          
    }
    else
    {        
      log.LogInformation($"Event is {eventId}, type is {errType}, and msg is {errMsg}");
    }        
};
    string responseMessage = $"This HTTP triggered function executed successfully. {errType} - {errMsg}";
    return new OkObjectResult(responseMessage);
}

Power Platform Admin Centre:

There is nice analytics inside the Power platform Admin Centre as shown below to examine Flows/Power automate:

The flows can also be reviewed on a per environment basis:

Series

App Insights for Power Platform - Part 1 - Series Overview 

App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics 

App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

App Insights for Power Platform - Part 4 - Model App Logging

App Insights for Power Platform - Part 5 - Logging for APIM 

App Insights for Power Platform - Part 6 - Power Automate Logging (this post)

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards 

App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics

App Insights for Power Platform - Part 9 - Power Automate Licencing

App Insights for Power Platform - Part 10 - Custom Connector enable logging

App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern

Friday 9 June 2023

App Insights for Power Platform - Part 1 - Series Overview

Overview: Microsoft have great capabilities for logging and monitoring.  In this series of posts I will be examining the various parts of logging that may be useful in building solutions that are well monitored, provide alerting, easy tracing, and identifies issues or potential issues as soon as possible.

I am looking at App Insights for Power Platform monitoring.  So this includes: 

  • Power Apps (Canvas, and model apps),
  • Power Automate,
  • APIM, 
  • Azure Functions, 
  • Azure Service Bus, and
  • App Insights.

I shall be setting up a demo environment and these are the logical components being covered.


All the components making up the solution shall log into Log Analytics (left-hand side of the diagram).

For Continuous Integration, my clients will be Postman monitor (it's awesome and so easy to use all those postman collections), DevOps is great and I'll use it to run smoke tests after new releases.  I also use flows, to report on flows (sounds nuts but i love it).  These are at the bottom of the diagram. 

Lastly on the right of the diagram, I look at extracting logs for reporting (Power BI), and Monitoring using Azure DevOps (p.s. think about Grafana instead of DevOps Dashboards, it so nice).

Couple of extras are: Availability Logging, alerting, automating Canvas app testing, Playwright.  

From the diagram, you can see the data is now held in Log analytics and it can be queried via Log Analytics or App Insights using Kusto.  Note: the syntax is slightly different.

Series

App Insights for Power Platform - Part 1 - Series Overview (this post)

App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics 

App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)

App Insights for Power Platform - Part 4 - Model App Logging

App Insights for Power Platform - Part 5 - Logging for APIM (this post)

App Insights for Power Platform - Part 6 - Power Automate Logging

App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards 

App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics

App Insights for Power Platform - Part 9 - Power automate licencing

App Insights for Power Platform - Part 10 - Custom Connector enable logging

App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern

Tip: The Power Platform Admin Centre has a good overview of the Power Platform, but to make logging and monitoring better push data into Azure Log analytics and monitor and alert centrally.

Also seeView and download Dataverse analytics - Power Platform | Microsoft Learn

Thursday 6 April 2023

Runas on Flows

Overview: If I use a connection in a Canvas App, the signed in user uses their own permissions and the connector as as the signed in user.  

Problem: I wish to run a flow as a specific user and not the users calling the flow from the Canvas app.

Hypothesis: I wish to call logging connector into Log Analytics, so I have created a flow, If I use the Power Apps V2 connector, it offers and option to run in another users context.

Resolution: Open the Workflow, ensure you are using the Power Apps V2 trigger, then...


Here I use the Scopes to perform a Try Catch finally set of logic


Tip:  most people tend to use a custom connector to push the error message into a function from the Workflow, the function app uses the App Insights SDK and logs the workflow error.

Simple C# code to write to App Insights using the SDK. 

#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
int eventId = data?.eventId;
string errType = data?.errType;
string errMsg = data?.errMsg;
string correlationId = data?.correlationId;
string workflowId = data?.workflowId;
string workflowUrl = data?.workflowUrl;
string flowDisplayName = data?.flowDisplayName;
var custProps = new Dictionary<string, object>()
{
{ "CorrelationId", correlationId},
{ "WorkflowId", workflowId},
{ "WorkflowUrl", workflowUrl},
{ "WorkflowDisplayName", flowDisplayName}
};
using (log.BeginScope(custProps))
{
if (errType=="Debug") { log.Log(LogLevel.Debug, eventId, $"{errMsg}"); }
else if (errType=="Trace") { log.Log(LogLevel.Trace, eventId, $"{errMsg}"); }
else { log.LogInformation($"Event is {eventId}, type is {errType}, and msg is {errMsg}");}
};
string responseMessage = $"This HTTP triggered function executed successfully. {errType} - {errMsg}";
return new OkObjectResult(responseMessage);
}

More Info:

Reza Dorrani has a great recording showing running Power Automate flows using elevated/shared accounts.

Saturday 22 February 2020

Catch Error in Power Apps and App Insight Logging

Error Handling:
App Insights logging: https://sharepains.com/2019/01/24/powerapps-experimenting-with-error-handling/  Replaced as Microsoft have built in telemetry as of 3 Feb 2020.
https://powerapps.microsoft.com/en-us/blog/log-telemetry-for-your-apps-using-azure-application-insights/

Example Error capturing and tracing to Azure AppInsights:
IfError( // Perform API Call , // Fallback so log here! ,
    Trace("Pauls Unique PowerApp",TraceSeverity.Error, {UserName:User().Email,         Role:gblRole, ErrorMsg:ErrorInfo.Message, ErrorControl:ErrorInfo.Control,         ErrorProperty:ErrorInfo.Property});     Notify("Err message ..." & ErrorInfo.Message); // Display the error on the UI
More detail..

Possible Canvas Apps Error Handling Pattern:
  1. Ensure AppInsights key is added to each canvas app
  2. Use IfError() to check calls and logic
  3. Use the Trace method to write info to App Insights
  4. Do I want to enable the Experimental error handling features (great to trace by correlationId)
  5. Consider all Power Automate that use Power Apps (ensure you use the V2 Connector)
  6. Never use IfError to handle business logic
To Review your App Insights Logging:
Open you Azure Portal > Open your App Insights blade >
Click the "Search" navigation option > Free text entry e.g. "Loyalty PowerApp"
App Insights, finding Traces generated in Power Apps

Monitoring Tool within Power Apps

The Monitor tool in Power Apps is great for debugging and tracing.
Start a monitor on the open Power App.

Monitor Tool - Showing a GET via a custom Connector and the returned response

Function/Code Logging:
Server-side code should log to App Insights or you logging framework.
It is ideal with the Trace within Power Apps explained above to be used in conjunction with 3rd party API calls.

Overview: C# code needs to have logging. If an error occurs an appropriate response must be bubbled up for the next lay

Possible C# Error Handling Pattern:

  1. All catch write exception to Log analytics or App insights 
  2. Calls to data sources, Azure Services and third party API's and complex logic ideally should be wrapped in a try catch and log the error to App insights using the C# App Insights SDK 
  3. The catch blocks ideally return the failed information so the caller code can deal with the logic using the output.  If you don't deal with the returned message, simply log the exception and rethrowing the error (this needs to be a conscious decision on each catch) 
  4. Catch specific errors: log, if you don't pass info to caller rethrow the error if applicable (bubble), respond accordingly i.e. catch the specific error and lastly use a catch all. - Heavy, but only add to existing code where this happens often or we are having problems, i.e. be specific
  5. Don't use Try, Catch to deal with business logic

Thought: Bubble up means: Code must log exceptions and returns appropriate reply to the caller, if you don't send the appropriate reply rethrow the exception after logging it so the caller has to deal with it.


Sunday 11 August 2019

Send email using O365 in an Azure Function C#

Create an Azure Function and the basics for send an email are below:

MailMessage msg = new MailMessage();
msg.To.Add(new
 MailAddress("someone@somedomain.com", "SomeOne"));
msg.From
 = new MailAddress("you@radimaging.co.uk", "Paul Beck");
msg.Body
 = "This is a test message using <b>O365</b> Exchange online";
msg.Subject = "Test Mail";
msg.IsBodyHtml
 = true;
SmtpClient
 client = new SmtpClient();
client.UseDefaultCredentials
 = false;
client.Credentials
 = new System.Net.NetworkCredential("your user name", "your password");  // Generate a key so pswd does not change or if account uses MFA
client.Port
 = 587; 
client.Host
 = "smtp.office365.com";
client.DeliveryMethod
 = SmtpDeliveryMethod.Network;
client.EnableSsl
 = true;

Tip:  Azure SendGrid is a great service for sending out emails.  Amazon have SES (Simple Email Service).

Tuesday 3 July 2018

Visual Studio Code - Azure functions using local Node and JavaScript Problem Solving

Problem:  When I deploy my function locally, I get warnings.  The local server still works but fixing the Functions Worker Runtime issue.


The Visual Studio Terminal when debugging locally output the following warnings:

"your worker runtime is not set. As of 2.0.1-beta.26 a worker runtime setting is required.
Please run `func settings add FUNCTIONS_WORKER_RUNTIME <option>` or add FUNCTIONS_WORKER_RUNTIME to your local.settings.json
Available options: dotnet, node, java"

Later it show that Java is the default language:
"Could not configure language worker java."

Resolution:
Open the local.settings.json file and add the "FUNCTIONS_WORKER_RUNTIME" value as shown below.  "FUNCTIONS_WORKER_RUNTIME": "node",



Problem:  When debugging my Azure Function using Node, I get the following error: "Cannot connect to the runtime process, timeout after 10000 ms - (reason: Cannot connect to the target:)." and the debugger stops.  the local server still serves the application but I cannot debug.


Resolution: After reading many blogs, I was not having any joy.  Finally, I remembered that I have changed the port number the previous day.  In desperation, I changed the port number in the launch.json file back to it's original and the debugger started working.


Wednesday 6 June 2018

SharePoint Online Replacement Patterns in Diagrams

Overview: This Post highlights my default position for achieving Common SharePoint solutions using SharePoint Online, flow and Azure Functions.


Matt Wade has a great resource on the components making up O365.
https://app.jumpto365.com/