You probably already know that platform updates to Dynamics 365 for Finance and Operations and Dynamics 365 for Retail are backward compatible. This means you can apply a platform update on any environment without the need to recompile, reconfigure or redeploy any of your customizations. This also means that when you recompile your code on a recently updated development environment, you will not run into errors that forces you to make changes to your source code. 

In some rare cases, we need to make necessary improvements to the platform that may affect the behavior of the X++ compiler or the test automation framework. The platform update will remain backward compatible, which means you can apply the update to any environment without breaking existing runtime functionality. These cases will only affect developers compiling code or authoring/executing automated tests and will be documented as part of the platform update release notes and blog posts like this one.

Among different experiences users can have when interacting with a cloud service, rendering performance and UI responsiveness are among the most impactful ones. These are the first points of references when describing the product to someone unfamiliar with it. Naturally, lots of effort is going into performance improvements. One of the obvious low-hanging fruits is client/server chattiness. Reducing the amount of actual data flowing back and forth is at the heart of a lot of scenarios. It mostly affects grid performance, when loading the next page triggers a cascade of data flowing to the client. And with infinite scrolling ability, it is so much easier for the user to breeze thru the grid, meanwhile heavy data is being poured over the wire. This is precisely the target of the current performance improvement effort – reduce the overhead of data when working with the grid.

In platform update 17 (Build number to be announced), we are making the following change: Data that is bound to controls that are not visible to the end user will not be sent over from the server until the control becomes visible. Currently, if a control is bound to a table field, the data for that field is sent to the client whether the control is visible to the user or not. As part of an effort to improve performance and reduce chattiness between the server and client, we are making a change so such data is not sent to the client until the control becomes visible. A typical example is a grid that is located on an inactive tab page. The server will not be sending any data for that grid until the tab is activated (becomes visible).

This change will have an effect on some automated test cases. Existing tests may assume that data is being populated for all controls, and therefore do not ensure a control is visible before accessing its data. These tests need to be refactored to account for this change (mainly open a corresponding tab page before reading a control value). This can also apply to form adaptor test cases as well if a control is moved/re-parented at runtime.

Here is an example with form adaptors:

Suppose you have the following on a form
 Tab page 1
 --Group 1
    -- String control

This will make form adaptors generate the following code to access the string control:
activateTabPage(“TabPage1”).activateGroup(“Group1”).getControl(“StringControl”).

Suppose you have code on your form that moves the string control to a different tabPage.

Tab page 2
--Group 2
   --String control

By accessing string control from a SysTestCase class, it will still be opening the original tab pages (Tab page 1). If you have the following test code:

StringControl.validate(10)
Form.MoveStringControl().click()
StringControl.validate(10)

If the control has changed visibility in the process, the above code won’t work (because Tab page2 was never activated to show the control).

To fix this, activate the tab page before you access the control:

StringControl.validate(10)
Form.MoveStringControl().click()
activateTabPage(“TabPage2”).activateGroup(“Group2”).getControl(“StringControl”).validate(10)