Hi All,
You can extend and customize a Dynamics NAV deployment without modifying the original application objects. With extension packages, you install, upgrade, and uninstall functionality in on-premises deployments or for select tenants in a multitenant deployment. Customers can easily add or remove horizontal or customized functionality to their solution that upgrade much easier than past solutions.
The main difference from classical development is that source code modifications are not allowed. Instead, you use C/AL events to extend and customize objects.
Extensions are delivered as .navx package files. A .navx package contains the various artifacts that deliver the new functionality to the Dynamics NAV deployment as well as a manifest that specifies the name, publisher, version, and other attributes of the extension. You manage .navx packages with a series of Windows PowerShell cmdlets that are available in the Microsoft Dynamics NAV 2017 Administration Shell. There are also cmdlets available to ISVs and developers in the Microsoft Dynamics NAV 2017 Development Shell that help create packages.
How Extensions Work
Extensions are in the simplest terms the runtime application of objects and object deltas for a specific combination of an extension package and a tenant. When an extension is published to a Dynamics NAV deployment, it compiles the objects in it against the current application database. Then, when the extension installs for a tenant, it stores the association and builds the relevant database schema. At runtime, Dynamics NAV simply loads the associated objects for that extension and tenant.
You can publish multiple extensions to a Dynamics NAV deployment and, in multitenant deployments, install any combination of published extensions for each tenant. For example, consider a scenario with a multitenant deployment with extensions A, B, C, and D published to it. Each tenant can have their own unique combination of extensions. So tenants 2, 3, and 4 can have the same extensions (extensions B and C) while tenants 1 and 5 only have one extension each, extension A and D, respectively. This provides for a great degree of customer functionality choice while at the same time maximizes the server hardware and administration workload.
In most cases, two extension packages can coexist and work independently of each other; however there is the possibility that two apps will try to modify the same object properties. In those cases, if the conflict cannot be resolved, the installation of the conflicting extension fails.
You can refer below MSDN Link for detailed explanation about Extensions.
https://msdn.microsoft.com/en-us/dynamics-nav/extending-microsoft-dynamics-nav-using-extension-packages
As per my understanding we will have a dilemma whether to go for extensions or use the traditional development methods.
We can have below consideration while choosing Extensions :
1) Is the database going to be heavily customized or not?
2) Is the development done can be easily maintained and monitored?
3) How frequently the changes will come in your existing extensions ?
4) What level of IT hardware & Configuration needed for extension?
5) More the extensions used, more consideration to be given for Server hardware configuration as the extensions will be loaded by NAV at run time.
6) Upgrade Flexibility
7) Multi Tenant Environment Flexibility
8) Using extensions for third party App, ISV, etc.
Anyways we need to move forward and start using Extension packages for most of our developments.
.
I feel in future Extensions will be heavily concentrated on and improvements will come in this regard. As its obvious from NAV 2016 and NAV 2017 releases and changes w.r.t to Extensions.
Thanks & Regards,
Nandesh Gowda
You can extend and customize a Dynamics NAV deployment without modifying the original application objects. With extension packages, you install, upgrade, and uninstall functionality in on-premises deployments or for select tenants in a multitenant deployment. Customers can easily add or remove horizontal or customized functionality to their solution that upgrade much easier than past solutions.
The main difference from classical development is that source code modifications are not allowed. Instead, you use C/AL events to extend and customize objects.
Extensions are delivered as .navx package files. A .navx package contains the various artifacts that deliver the new functionality to the Dynamics NAV deployment as well as a manifest that specifies the name, publisher, version, and other attributes of the extension. You manage .navx packages with a series of Windows PowerShell cmdlets that are available in the Microsoft Dynamics NAV 2017 Administration Shell. There are also cmdlets available to ISVs and developers in the Microsoft Dynamics NAV 2017 Development Shell that help create packages.
How Extensions Work
Extensions are in the simplest terms the runtime application of objects and object deltas for a specific combination of an extension package and a tenant. When an extension is published to a Dynamics NAV deployment, it compiles the objects in it against the current application database. Then, when the extension installs for a tenant, it stores the association and builds the relevant database schema. At runtime, Dynamics NAV simply loads the associated objects for that extension and tenant.
You can publish multiple extensions to a Dynamics NAV deployment and, in multitenant deployments, install any combination of published extensions for each tenant. For example, consider a scenario with a multitenant deployment with extensions A, B, C, and D published to it. Each tenant can have their own unique combination of extensions. So tenants 2, 3, and 4 can have the same extensions (extensions B and C) while tenants 1 and 5 only have one extension each, extension A and D, respectively. This provides for a great degree of customer functionality choice while at the same time maximizes the server hardware and administration workload.
In most cases, two extension packages can coexist and work independently of each other; however there is the possibility that two apps will try to modify the same object properties. In those cases, if the conflict cannot be resolved, the installation of the conflicting extension fails.
You can refer below MSDN Link for detailed explanation about Extensions.
https://msdn.microsoft.com/en-us/dynamics-nav/extending-microsoft-dynamics-nav-using-extension-packages
As per my understanding we will have a dilemma whether to go for extensions or use the traditional development methods.
We can have below consideration while choosing Extensions :
1) Is the database going to be heavily customized or not?
2) Is the development done can be easily maintained and monitored?
3) How frequently the changes will come in your existing extensions ?
4) What level of IT hardware & Configuration needed for extension?
5) More the extensions used, more consideration to be given for Server hardware configuration as the extensions will be loaded by NAV at run time.
6) Upgrade Flexibility
7) Multi Tenant Environment Flexibility
8) Using extensions for third party App, ISV, etc.
Anyways we need to move forward and start using Extension packages for most of our developments.
.
I feel in future Extensions will be heavily concentrated on and improvements will come in this regard. As its obvious from NAV 2016 and NAV 2017 releases and changes w.r.t to Extensions.
Thanks & Regards,
Nandesh Gowda
No comments:
Post a Comment