ecLearn LMS, developed by Engineered Code, is proud to sponsor Community Summit North America. Visit us at booth #1857 and get on the list for our Summitland Prize!
As I sit in the Dublin airport awaiting my flight back to Canada, I thought I’d jot down a few notes on the week that was D365UG/CRMUG Summit EMEA 2018.
Last month Microsoft unveiled the Spring Release 2018 of Dynamics 365. While there were a lot of interesting items in the announcement (Marketing, Embedded Intelligence, PowerBI Insights apps), the one that I’m most excited about is the latest release of Common Data Service (CDS), version 2.0. In this post I’ll provide my thoughts on this latest update, as well as what it might mean for the Portal capabilities of Dynamics 365.
Dates, times, time zones, daylight savings time, and anything related to those concepts is an area that has always been a huge pain in the you-know-where for developers. There are so many rules and variables that it’s hard to be confident that your solution is handling all cases perfectly. Thankfully frameworks like .NET remove a lot of the guesswork, but you still have to be careful. In this post, I’ll investigate how Dynamics 365 and Portals handle dates and times.
In order to confirm that much of the functionality in Dynamics 365 Portals works with virtual entities, I needed to have data sources with some pretty specific fields. Rather than hunting for an existing service to meet all of my requirements, I was able to quickly setup a fake OData service hosted in Azure Web Apps that I could use as my Dynamics 365 Virtual Entity Data Source.
