Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
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
This blog title are the exact words of someone I bumped into at the airport after Directions USA in Orlando, to let me tell you in this blog what I told her.
One of the pitfalls, or let me rephrase, the biggest pitfall of NAV using open code is upgradability. Microsoft allows us to change everything in their application using raw source code modifications.
The downside of this: merging code. Even worse: code conflicts.
Another challenge is one we got with multi tenancy. With hundreds of tenants using the same software we lose the flexibility that people love NAV for.
Events is something we got as a new option in the NAV2016 framework that we borrowed from DotNet. It allows us to create a loosely coupled connection between two application areas. At the publisher side we allow other people to run business logic before or after ours and multiple subscribers can run their code without the publisher knowing what is going on.
When using the merge commandlets in PowerShell that Microsoft introduced in NAV2013R2 we can create delta files that define differences (deltas) between two objects.
The extensions are the solution to Upgradability and customizing a multi-tenant environment. It leverages the options we have with events and delta files allowing us to create modifications that “auto merge” using (almost) runtime compilation and execute code based on events.
The feedback I got was; “there are so many limitations”. This is true and my opinion is that this is really version 0.9 of what we will get in the (near) future. After the cut-off for NAV2016 the development for Madeira immediately continued.
The reason that we have version 0.9 is to get used to the concept and start shipping small extensions.
Based on talking to people at the events I have a couple of ideas of examples for the current technology that will get you started
James Crowter had a good suggestion of shipping a role center for the Phone as an extension. In contrary of vertical solutions, people will use the phone in a generic way. Approvals, credit limits, KPIs. A lot of phone role centers will look quite similar and can be shipped as an extension as long as you don’t use a query for the cue.
Stuart Glasson mentioned during his session that custom workflows can be packaged as an extension using the current possibilities. Here I can also see a huge advantage of a workflow marketplace where customers and partners can share workflow extensions or sell them for as much as 10 euro/USD.
One of the typical examples Partner Ready Software has always used for façade was the weighbridge interface. Using events and extensions and creating dependencies a specific interface can be shipped as an extension as long as you do not need XMLPorts for WebServices.
One of the limitations of extensions is that the development environment does not know they are there. As an end user I cannot create a report based on a table that is part of an extension. The designer does not see the changes. This would require some major changes in how the development environment works, but it would be nice to be able to continue development based on the extension layer.
Per Mogensen had the idea of making hybrids. Shipping new objects as fob so that the development environment knows they exist, with zero impact on existing code, and then making extensions for pages you want to modify or leveraging events when executing business logic based on existing code.
Thomas Hejlsberg and Joe Little told me that RecRef and FieldRef at runtime are aware of the extensions. This means you can actually have a backdoor trying to find extensions in your database by looking for a delta between the object table, field table and recref and fieldref.
This option also allows JetReports to use any extensions that exist in a database making Joe a happy guy. JetReports can make the reports that NAV cannot.
The PowerShell commandlets and C/AL commands that you need for this can be found looking for the word APP, or NAVAPP. This has historical reasons for naming during development of the extensions that I cannot mention in my post, (Microsoft already slapped me on the fingers once).
Every single Microsoft Employee and MVP misspoke at least once during their presentation. :-)
Most important is to remember that everything with extensions can be found looking for these keywords.
I hope this post clarifies what you can do with extensions in this release. It is a great new way of making changes to NAV2016 that will make upgrades easier in the future.
I am very happy to have been part of this journey taking and discussing about this feature with the program managers and architects in the last 12-24 months.
You can get started using the 5 Steps tutorial I blogged earlier before Directions
With NAV Skills we will schedule a four-series webinar about Events and Extensions. Together with Soren Klemmensen, Gunnar Gestsson, Eric Wauters (Waldo) I will get you started with this great new technology.
Business Applications communities