Monitoring the Power Platform: Model Driven Apps – Monitor Tool Part 1: Messages and Scenarios
Summary
Monitoring Dynamics 365 or Model Driven Applications is not a new concept. Understanding where services are failing, users are running into errors, where form and business processes could be tuned for performance are key drivers for most if not all businesses, from small companies to enterprises. Luckily, the Dynamics 365 platform provides many tools to help audit and monitor business and operational events.
This article will cover user events and where they are sourced from. From there, we will dive into the Monitor tool and look at individual messages within. We will work with a few sample scenarios and see what we can gain from markers and messages within the Monitor tool.
Collecting User Events
Before we discuss techniques on how to capture events in Dynamics 365 let’s examine some meaningful events. From the client perspective this may include performance counters and metrics, user click events and navigation. Other data points include geolocations and preferences of users. Luckily, client events are easier to capture and we have many tools including browser based (Developer Tools) to applications (Fiddler) that are readily available. Some features of the platform allow for collecting markers while other events of interest we will have to supplement with custom delivery mechanisms.
For server side, external integrations and execution context contain identifiers for response codes that may require additional validation. For sandboxed plug-ins and custom workflow activities, we are limited somewhat to what tools we can leverage.
Upcoming articles will detail how to collect and push events of interest to a central area for analytics.
NOTE: The rest of this article will cover collecting and analyzing messages focused on the client. That said, server side events play a major role and can impact the client experience. I’ll address server side events in another article pertaining to Azure Application Insights and Model Driven Apps. In the meantime, .
AUTHOR NOTE: Click each image to enlarge for detail
The Monitor Tool
The Monitor tool can be launched from the Power Apps Maker Portal. Once launched, the Play Model Driven App button can be pressed to begin a session attached to the tool.
The Monitor tool can also be started by adding “&monitor=true” to the URL of your Model Driven Application.
After consenting or allowing to start a session, the Monitor tool will light up rapidly with various messages. Similar to the , each row can be further drilled into for investigation.
article on the Monitor Tool, titled provides a through deep dive including sample scenarios.
I highly suggest reviewing and keeping it close by for reference.
Key Performance Indicators
Key Performance Indicators represent major lifecycle events within a particular user action, such as loading a form. Consider the image below.
By sorting the records on the “KPI” category, these events begin to emerge. The image below shows the major lifecycle events or KPIs for a standard form load within Dynamics 365. Beginning with PageNavigationStart and ending with RenderedEditReady, these events represent the completion of a form load.
Scenario: Determining a Form’s Load Impact
Consider the scenario of a user logging into the system and opening a lead form for the first time. When performing this action, the form and data have not had a chance to be cached or stored locally which results in all items needed to be downloaded. This is sometimes referenced as a cold load. Reviewing the timeline event “FullLoad” we can determine what type of load the form rendered as.
Now, once captured, the user opens the fly out window to choose another lead record but using the same form. Again using the “FullLoad” KPI timeline event we can see the LoadType is now Two.
Finally, imagine the user needs to navigate back to the original lead record opened on the same form. We can see now the LoadType is now Three. Comparing this to the LoadType Zero image above, the entityId is the same.
Here is a sample scenario in full showing the differences in loading new and existing records and how changing a form can impact network requests to the server.
Attribution
On certain Key Performance Indicators a property is included called “Attribution” which represents specific events within a user action. This includes the commands or actions executed within a KPI. For example, during a form load lifecycle, controls are rendered, ribbon rule are evaluated, onload event handlers are executed, etc. The Attribution property will specify and group, in chronological order, which events happened. An added bonus is the duration is also shown for each event along with if any synchronous calls were made. Consider the image below.
Scenario: Locating dynamically added form changes and events
The image above shows for the FullLoad KPI. In this image we see three main groups of events: CustomControl (form controls), RuleEvaluation (ribbon rules) and onload (form event handlers). What’s interesting here is each of these is grouped, but also the solution they are part of and event solution layering is present. The RuleEvaluation and onload groups above both show an unmanaged or “Active” layer that contained customizations.
Compare that image with the one below.
A scenario came up during an investigation into the an increased duration of a form save. To begin, we went through the user events as normal with the Monitor tool running.
Upon review, you can see additional events occurred, tabstatechanged and onsave. The onsave was expected due to the registered event handler on the form. However the tabstatechange was not, this was found to be due to a recent code addition that triggered the setDisplayState of the tab.
if (control.getName() == tabName) {
control.setDisplayState("expanded");
}
By reviewing the Attribution property we were able to identify what caused the increase of 5 seconds.
Zone Activity and Other Data Points
Within Key Performance Indicators, are other data points that prove useful when debugging performance related issues. Latency and Throughput are shown as well as timings for network related calls and custom script executions. Within the ZoneActivity property we see events grouped by web service calls, and events. The CustomScriptTime shows the duration of all of the registered event handlers that fired during this particular Key Performance Indicator.
Performance Messages
Performance categorized messages detail potential performance issues that a user may run into. At the time of this writing, I’ve uncovered only synchronous XHR calls being sent but I anticipate growth here.
Scenario: Locating and Evaluating Synchronous Resource Timings
Requests from a Model Driven Application represent outgoing calls from the client to another source. These calls can occur either synchronously meaning the thread executing the call waits for the response, or asynchronously meaning the thread continues and listens for the response. Its preferred to eliminate all sync calls to reduce any potential disruption to a user’s experience within the application.
The Monitor tool helps by identifying these requests and calling them out. These call outs can be found in the “Performance” category as shown below.
Examining the performance entry, we can see the “dataSource” property shows the XHR URL. However, it doesn’t show the source of the call which is needed to better understand how and why the request was made.
Here is a gif showing how to use the Monitor tool, coupled with the Browser Developer Tools to locate the line of code that needs to be updated.
Using these messages, along with outputs from Power Apps Checker, we can begin to uncover gaps in code analysis. , I’ll cover in depth an approach to help identify and remediate these gaps.
Next Steps
This article describes where user and platform events may originate from and how they can be monitored. Gaining insights and understanding into the SaaS version of Dynamics 365 allows us to uncover the black box and find answers to some of our questions. Think about how the Monitor tool can be used to find out where API calls may have started and coupled with other articles in this series, how we can correlate to provide a true end to end monitoring solution. will cover how we can extract and analyze the sessions further.
If you are interested in learning more about , which includes a , please contact your Technical Account Manager or Microsoft representative for further details.
Your feedback is extremely valuable so please leave a comment below and I’ll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, .
Index