Breaking news from around the world
Get the Bing + MSN extension
The views and opinions expressed in this blog are those solely of the author(s) and do not necessarily reflect Microsoft’s current policy, position, or branding. For official announcements and guidance on Dynamics 365 apps and services, please visit the Microsoft Dynamics 365 Blog.
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, Power Apps, Power Automate, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
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:
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:
Business Applications communities