The new form rendering engine

***[Referencing to Microsoft Dynamics CRM Team Blog]

In Microsoft Dynamics CRM Online 2015 Update 1 (v7.1), a new form renderer was built to provide better performance. 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.

What will users notice?

End users will not notice anything different, other than forms loading faster. The new form rendering engine has full support for client scripting (Write code for Microsoft Dynamics CRM forms), uses the same XML definition (Form XML schema), and has the same behaviors all around. There have been no fundamental changes made in terms of what the form does.

In order to help catch unsupported customizations, 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 customizations in the system.

What changed?

All the changes have been focused on how the form load process can be optimized. 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.

Forms also used to waste a lot of resources. Since they were hosted in iframes, the iframe would be discarded and reloaded on each form load. The new form renderer does not discard iframes and instead keeps the iframe around. All common scripts are already parsed and never need to be loaded again. This introduced the design to load custom scripts and ISV scripts in a separate iframe which is the one that’s discarded when the form closes.  Previously, these scripts would be loaded in the same iframe as the form.

In summary:

  • Iframes are now kept throughout the user session
  • Custom scripts are loaded in separate iframes
  • No changes in supported scripts or form
    capabilities

What do I need to do?

As an admin or developer there are some things to be aware of. Because the new form rendering engine makes changes to how iframes are organized, any attempt to access unsupported APIs or use direct DOM manipulations may fail and need to be fixed.

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.

Examples of things that will break:

  • 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.

In order to help identify potential issues, the CRM 2015 custom code validator can be used. It’s primary purpose is to identify usage of deprecated APIs but it will also attempt to flag usage of unsupported APIs. The tool can be found here: https://www.microsoft.com/en-us/download/details.aspx?id=45535.  Developers should also review their scripts to ensure only supported APIs are being used.

Customers that have 3rd party solutions should reach out to their partners for updated solutions that have been verified to work with the new form rendering engine. While most are expected to continue to work, those with unsupported customizations need to be updated.

Fallback options

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 customizations.

If you are the owner of the scripts, make sure that there are no unsupported customizations. Otherwise reach out to the provider of the solutions for an updated solution.

View article…

Advertisements

Only update things you need to

While it is important not to reduce the benefit of a Dynamics CRM system by excluding activities that would be beneficial, often requests are made to include customization that add little business value but drive real technical complexity.

Consider a simple business scenario:

If every time we create a task we also update the user record with the number of tasks they currently have allocated, that could introduce a secondary level of blocking as the user record would also now be heavily contended. It would add another resource that each request may need to block and wait for, despite not necessarily being critical to the action. In that example, consider carefully whether storing the count of tasks against the user is important or if the count can be calculated on demand or stored elsewhere such as using hierarchy and rollup field capabilities in Dynamics CRM natively. Limited update philosophy should also be adopted while extending CRM using Processes, Plugins or Scripts.

 

 

This is something that reminds me of normalization in DBMS J

***References : Scalable Dynamics CRM Customization documentation

Critical On Demand Fix: Modal dialogs not supported on Google Chrome 37

Few months back I had written a post on Google Chrome version 37 had stopped supporting model dialog (here). This affects if you open up the form customization and try and save and publish in Chrome (Version 37 and higher), you may notice it does not save or publish. This is because Dynamics CRM is using a modal dialogue, likewise you may see this behavior on editing dashboards or updating status reasons.

The current fix for this is a registry update which can be found here http://support.microsoft.com/kb/3000002, or using an alternative browser.

Microsoft has announced that in April they will be releasing updates that will fix the feature deprecation. In order for customers, who are using Chrome browser, to continue to function, they will need to upgrade to the upcoming CRM versions listed below:

  • CRM 2011 – A COD will be delivered on CRM 2011 UR18(On prem Only)
  • CRM 2013 – A COD will be delivered in CRM 2013 UR3(On prem Only)
  • CRM 2013 SP1 – Fix will be included in CRM 2013 SP1 UR3(Online & On Prem)
  • CRM 2015 – Fix will be included in CRM 2015 UR1(Online & On Prem)

*Note: COD = Critical On Demand Fix

Please be aware that these updates are coming and will need to be applied to your environments to ensure Chrome based users can fully function on the latest versions.

Missing column field names in Advanced Find’s Add Columns: IE 11 security update issue

***Microsoft released a patch that resolves this issue***

http://support.microsoft.com/kb/3025390

Issue:

You install MS14-080: Cumulative security update for Internet Explorer: December 9, 2014 on a computer that’s running Internet Explorer 11 or the Internet Explorer 11 Web Browser control. However, after you do this, you may experience unexpected behavior when you interact with sites that use one or more web application modal dialog boxes. Any data or information that’s provided in the modal dialog box may not be returned to the application window or to the dialog box that created the data or information. Therefore, the application that created the dialog box may exhibit errors or lack specific functionality that was dependent on that dialog box data.

Description:

This week Microsoft released a cumulative security update for Internet Explorer 11 (KB3008923) which had the unfortunate side effect of rendering certain values in dialog boxes in Microsoft Dynamics CRM 2011 blank. Among those items affected were column field names in Advanced Find’s Add Columns, and the ability to select items to be added to some queries.

ie essue 1

Same behavior is even for Handler Properties in CRM 2013 while adding a event for a JavaScript. The Library dialog appears to be blank.

Ie issue 5

The Microsoft Knowledge Base article for the update doesn’t show notes about this issue, when checked, but removing the update consistently cleared the issue.

To remove the update, Open Control Panel > Programs and Features > Installed Updates and select the update: Security Update for Microsoft Windows (KB3008923).

ie issue 2

NOTE: This update was issued as an important security update, so you may want to check it’s posting (http://support.microsoft.com/kb/3008923) for more information about what it covered before deciding whether to remove it or just switch to Firefox or Chrome until the issue is resolved.

Customize Dialog box in Dynamics CRM

Many times we face a requirement where we are asked to customize a dialog box in CRM, either with the help of JScript or HTML page. But Dialog are not available for client side extensions except custom assemblies. You cannot use JScript to Customize a dialog.

But there is always an UNSUPPORTED way:

You can customize the CRM 2011 Dialog page by customizing the page that run the dialog, the page is existing under the folder

$Microsoft Dynamics CRM Installation Folder$\CRMWeb\CS\dialog\rundialog.aspx , but it is not a recommended solution.

You can write some scripts to customize the dialog, but be careful when install a hot-fix that replace this page with default one, so keep a backup for this page on your solution after you customize it.

Dialogs with Input Argument cannot be called as on demand

Dialog are mainly used to run on demand in CRM, but if your dialog is using Input Arguments, you cannot set the dialog to run on demand. You can only set it to run as child process. Logically it sounds ok as you will need some value to be passed to Input Argument before executing an dialog process, but CRM also provides a way to set a default value and setting default is mandatory. Now question is:

When we can have a default value for input arguments, why can’t we call such dialogs as On Demand? Why should I maintain an extra parent dialog to this?

dialog2.jpg

CRM 2011 : Dialogs with Input Argument cannot be called as on demand

Important to know (at least I didn’t knew it till date J).

Dialog are mainly used to run on demand in CRM, but if your dialog is using Input Arguments, you cannot set the dialog to run on demand. You can only set it to run as child process. Logically it sounds ok as you will need some value to be passed to Input Argument before executing an dialog process, but CRM also provides a way to set a default value and setting default is mandatory. Now question is:

When we can have a default value for input arguments, why can’t we call such dialogs as On Demand? Why should I maintain an extra parent dialog to this?