Showing posts with label Turbo Forms vs Legacy Form in CRM 2016. Show all posts
Showing posts with label Turbo Forms vs Legacy Form in CRM 2016. Show all posts

Wednesday, December 21, 2016

Microsoft Dynamics CRM Turbo Forms with Faster Rendering

Forms will load significantly faster and more efficiently.
The new renderer is based on previous generations and has the same functionality and behavior. However, there are some things that admins and developers need to do to ensure full compatibility when upgrading.

Each CRM form is held in an IFRAME but previously these weren’t retained in the browser which meant the entire IFRAME needed to be reloaded each time a similar record is opened.

IFRAMES are now retained throughout the user session. For example, once you’ve opened the first contact record in a session CRM will cache the frame enabling subsequent contacts to be opened without reloading this component.

CRM now handles common and custom scripts separately to achieve further performance gains.

Common scripts will always be cached and never need to be reloaded during this session.
Because caching is only retained per user session it means that the initial form rendering for each entity will take slightly longer after logging in but all subsequently forms for the same entity will load significantly quicker.

Custom scripts are now loaded in a separate IFRAME and are discarded when the user closes the form but because CRM now retains common scripts users will immediately enjoy faster form loads once this upgrade is applied.

Microsoft has made further changes to CRM’s form rendering which now handles more processes concurrently to shave off additional time each time a record is loaded compared to earlier versions.

In order to help catch unsupported customization's, we added a dialog that displays the issue when script errors occur so that they do not fail silently. If these symptoms occur, then it is likely there are unsupported customization's in the system.


There are 2 main changes that have been made: loading process of the form, and handling of cache.
In terms of loading process, we have parallelized as many operations as possible to eliminate time wasted because the browser is idle. We increased the content that’s cached, moved rendering processes partially to server-side, and optimized the initialization of controls.
Form load used to be a very linear process. Since the new form renderer is more parallelized, the rendering engine now constructs the form and XRM model first and binds the data whenever the server responds. The diagram below is a rough approximation in order to illustrate the differences between the 2 rendering engines and may not reflect the exact changes.


Customers should all make sure to test their organization in sandbox mode to preview before upgrade. This way, should any symptoms show up around forms not loading/script errors, you will be able to catch and fix it
before upgrade.
  • Any attempt to access DOM in the content iframe using JS, jQuery or other 3rd party libraries (document.getElementById() or jQuery selectors)
  • Creating a new HTML content in the parent window for persistent content (and assumed that the parent window was the main CRM iframe.
  • Window.load, parsing iframe/form URL
  • Attempting to use unsupported (non-XRM) APIs, especially undocumented ones that may have been shipped with CRM for internal usage only
  • Accessing window.parent() from a web resource that may assume for example there’s a variable set in the current window context.    
Fallback options
  • No action is needed by users or administrator as this is turned on by default.
  • The loading process for record forms is significantly better and faster since more content is cached. For more information on performance, see Microsoft’s note on form rendering engine.
  • Common and custom scripts are handled separately.
  • The engine has the same functionality as it is based on previous generations. It uses Form XML Schema and has full support for client scripting.
  • Access window.parent from a web source that has to do with a variable set.
  • Unsupported APIs, i.e., non-XRM.
  • Window.load or iframe/form.
  • Access DOM in content iframe using JQuery or JavaScript.
Examples of things that will break:
·         In case there is difficulty identifying the issue or a backup plan is needed post-upgrade, we have introduced an organizational-level fallback to temporarily allow usage of the legacy rendering engine. This will ensure compatibility at the cost of performance. Do not rely on this solution long term as the plan is to remove this option in the following release.
·         This setting can be found under Settings -> Administration -> System Settings -> General. Select “Yes” under “Use legacy form rendering” to enable this mode for all users.
·         If script errors are showing up, or if forms are not behaving as intended, this setting can be used to diagnose if the problem is specific to the new form rendering or not. If it is due to the new form rendering engine, then most likely there are some unsupported customization's.
Here are a few of the benefits of the new Form Rendering Engine:
  • No action is needed by users or administrator as this is turned on by default.
  • The loading process for record forms is significantly better and faster since more content is cached. For more information on performance, see Microsoft’s note on form rendering engine.
  • Common and custom scripts are handled separately.
  • The engine has the same functionality as it is based on previous generations. It uses Form XML Schema and has full support for client scripting.
The tricky thing for users and administrators has to do with unsupported customization's or direct DOM manipulations which will possibly fail and need to be re-engineered. The following are examples of when this might occur:
  • Access window.parent from a web source that has to do with a variable set.
  • Unsupported APIs, i.e., non-XRM.
  • Window.load or iframe/form.
  • Access DOM in content iframe using JQuery or JavaScript.

When using JavaScript code in Microsoft Dynamics CRM, it is possible that some code will stop working or cause an error when you upgrade. The Microsoft Dynamics CRM Custom Code Validation Tool helps identify potential problems so that a developer can fix them.
Please run this tool on your CRM instance to help identify potential issues with custom JavaScript in JavaScript libraries and HTML web resources. It will detect issues in the custom web resources that will no longer work after the upgrade is completed.
The most common issues that this tool targets are:
  • Common DOM manipulations
  • CRM 2013 Deprecated APIs
Running this tool before upgrade will enable you to identify issues and fix them prior to your scheduled upgrade so that your upgrade process can run smoothly. Microsoft Dynamics CRM 2015 Custom Code Validation Tool