{"id":9926,"date":"2020-07-16T10:36:12","date_gmt":"2020-07-16T17:36:12","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/monitor-now-supports-model-driven-apps\/"},"modified":"2020-07-16T10:36:12","modified_gmt":"2020-07-16T17:36:12","slug":"monitor-now-supports-model-driven-apps","status":"publish","type":"power-apps","link":"https:\/\/www.microsoft.com\/en-us\/power-platform\/blog\/power-apps\/monitor-now-supports-model-driven-apps\/","title":{"rendered":"Monitor now supports model-driven apps"},"content":{"rendered":"
“Why is my form performing so slowly?”\u00a0 “Where is this script error coming from?”\u00a0 “Why is my field control not showing up?”<\/em><\/p>\n Until now, users have had little transparency into the flow of model-driven apps unless they are comfortable wading through the complexity of browser developers tools or Fiddler.\u00a0 It was hard to find events and logs that could help diagnose performance and functional issues.<\/p>\n We’re excited to announce that the Monitor tool<\/strong>\u00a0is now available for model-driven apps!<\/strong>\u00a0 The Monitor tool (currently supported on canvas apps<\/a>) provides a way to view a stream of events from a user’s session in order to diagnose an issue.\u00a0 As of this blog post, we support the following events on the latest build:<\/p>\n Note<\/strong>: depending on your CDS\/Dynamics version, you may see a subset of these events as they roll out to your org.\u00a0 Monitor for model-driven apps is currently only supported for browser sessions on online organizations.<\/p>\n There are two ways to enter a Monitor session for model apps.<\/p>\n Once the app is launched from Monitor, you’ll see a Join dialog letting you know that any data from the app will be sent to the Monitor owner.<\/p>\n After hitting “Join”, events will start flowing to Monitor.\u00a0 Let’s take a look at what events are being sent.<\/p>\n Page navigations, command executions, form saves, and other major actions will send KPI and network events to Monitor.\u00a0 \u00a0Many events and fields are sent and supporting documentation will be published soon, but let’s take a look at some key ones below:<\/p>\n FullLoad<\/strong> signifies the complete load of a page navigation, such as an edit form load.\u00a0 This waits for certain network requests to complete and all rendering to finish, so the form may indeed be usable before FullLoad completes.<\/p>\n <\/p>\n \u00a0<\/p>\n <\/p>\n The\u00a0FullLoad<\/strong> event captures many statistics about the page load.\u00a0 You can see the task edit form loaded in 506 ms, and clicking on the row reveals a wealth of information in the property pane.\u00a0 As mentioned above, we will add more documentation on each field, but you can immediately see details on\u00a0customScriptTime<\/strong> (time spend execute custom JavaScript),\u00a0loadType<\/strong> (0 = first time loading page type, 1 = first time loading entity, 2\u00a0 = first time loading record, 3 = exact record has been visited),\u00a0and\u00a0FormId<\/strong> (form identifier for further diagnosis).\u00a0 Expanding\u00a0Attribution<\/strong> gives a breakdown of custom JS execution time by type, publisher, solution, version, web resource, and method.\u00a0 This can quickly help identify bottlenecks in form load time.<\/p>\n The\u00a0Network<\/strong> events reveal details about each request made from the app:<\/p>\n You can see well-known network statistics like\u00a0requestStart<\/strong>,\u00a0responseStart<\/strong>, and\u00a0decodedBodySize<\/strong> (see MDN documentation<\/a>), as well as custom properties like whether the request was\u00a0cached<\/strong> and sent as a\u00a0fetch<\/strong> or XMLHttpRequest.<\/p>\n Let’s look at a few scenarios where Monitor can shed light and solve script errors, unexpected behavior, and slowdowns.<\/p>\n Sometimes, a bug in the custom JS will cause a script error or functionality issue when loading a page.\u00a0 While this usually produces a call stack in the dialog, it’s hard to always know where it’s coming from or decode the error.\u00a0 Monitor will receive an event from the app with more details on the error so you can debug more quickly and easily.<\/p>\n Let’s say a user is experiencing a script error dialog on account form load.\u00a0 We can use Monitor to get more details on the event.\u00a0 Once the scenario is reproduced, you can see the script error produces an error event highlighted in red.\u00a0 Clicking on this row gives us not only the call stack<\/strong> but the publisher name<\/strong>, solution name\/version<\/strong>, web resource name<\/strong>, and type<\/strong> (onload, onchange, RuleEvaluation, CustomControl, etc.).\u00a0 Looks like a typo in the script, and we have a publisher to contact for a fix!<\/p>\n <\/p>\n Browser developer tools can help profile slow page loads, but there is a lot of data to filter though and it’s not clear what is important to look at.\u00a0 Monitor aims to solve that by showing relevant events that contribute to page load performance.<\/p>\n Let’s say a user is experiencing slow account form loads, and the browser is constantly freezing up.\u00a0 In this case, once we reproduce, we can immediately see a performance warning telling us that a synchronous XMLHttpRequest was sent during the load which degraded performance.<\/p>\n <\/p>\n See previous blog post<\/a> for how to alleviate synchronous XHR performance issues.<\/p>\n For every page load, we send all KPI for the loading sequence as well as network request details as mentioned earlier.<\/p>\n Look for a deeper blog post on this soon, but to give a sneak preview, Monitor will show events regarding tab and control visible\/enabled state on the edit form.<\/p>\n If a user is wondering why a field isn’t showing up on an edit form, Monitor can easily help demystify.\u00a0 In this scenario, the Last Campaign Date is not showing up on the account form.\u00a0 There are series of uci_formchecker_*<\/strong> events produced on an edit form load (use the Category column filter if needed).\u00a0 Once reproduced in a Monitor session, we can see the following event with Category\u00a0uci_formchecker_controlstate_events<\/span><\/strong>.<\/span> Drilling into the details, we can scroll to Last Campaign Date and clearly see that\u00a0The control is disabled in the form XML<\/strong>.\u00a0 The action item is to\u00a0Contact the form or entity owner to change it<\/strong>.<\/p>\n We’re adding more events to model-driven apps every week to help diagnose common issues.\u00a0 As always, please feel free to provide any feedback in the comments below or in our community post<\/a>.\u00a0 We’d like to know what’s useful to best support troubleshooting and transparency.<\/p>\n","protected":false},"excerpt":{"rendered":" We’re excited to announce that the Monitor tool\u00a0is now available for model-driven apps!\u00a0 The Monitor tool provides a way to view a stream of events from a user’s session in order to diagnose a performance or functionality issue.<\/p>\n","protected":false},"author":206,"featured_media":0,"comment_status":"open","ping_status":"open","template":"","power-apps-category":[1591,1664],"power-apps-tag":[1536,1600,1604],"coauthors":[2180],"class_list":["post-9926","power-apps","type-power-apps","status-publish","hentry","power-apps-category-dataverse","power-apps-category-uncategorized","power-apps-tag-alm","power-apps-tag-dynamics-365","power-apps-tag-events"],"yoast_head":"\n\n
Let’s take a look at Monitor in action!<\/h2>\n
\n
Events<\/h2>\n
\n<\/p>\nSolving issues and slow performance<\/h2>\n
Custom script errors<\/h3>\n
Slow performance<\/h3>\n
Form control and related menu display<\/h3>\n
\n<\/p>\nFeedback<\/h2>\n