Yep, PowerShell again. So the people that deny PowerShell can stop reading now :-).
Although I do think this is quite an interesting blogpost on how to work somewhat more easily with deltas, by the use of a function that is part of my PowerShell Module, called: Apply-NAVDelta.
I was actually just thinking after my two previous posts, where I talked about “reverse deltas” and “Export NAV Application objects“: why not making the “update-delta” part much easier. Even more: I want to be able to import deltas into a database (of a ServerInstance) with one command. Not more!
That’s where Apply-NAVDelta comes into place
Let me start how an install-script could look like, if there were only deltas in the house (this is an example of my WaldoNAVPad):
$AppName = 'WaldoNAVPad' $WorkingFolder = "C:\_Workingfolder\$($AppName)" $ServerInstance = 'WaldoNAVPad_DEV' Apply-NAVDelta -DeltaPath 'C:\Users\Administrator\Dropbox\GitHub\Waldo.NAV\WaldoNAVPad\AppFiles\*.DELTA' ` -TargetServerInstance $ServerInstance ` -Workingfolder $WorkingFolder ` -OpenWorkingfolder ` -SynchronizeSchemaChanges Force ` -DeltaType Add ` -VersionList $AppName Start-NAVIdeClient -Database $ServerInstance
As you can see .. simply call the Apply-NAVDelta function, and provide:
- The Deltafiles that you want to apply
- The TargetServerInstance you want to apply it to
- What type of “apply” (are you adding it, or removing it?)
- What the VersionList should be
- How to synch schema changes
- Open the workingfolder when done
You can see the last version of Apply-NAVDelta here.
In short, these are the steps:
- Prepare workingfolder. I’m going to export/apply deltas which basically means: working with textfiles quite a lot. I need a folder to do so, so this is a very necessary step.
- Figure out which objects I need to export by reading the deltas. I use a new function Get-NAVApplicationObjectPropertyFromDelta for this, that is basically going to read a delta, and figure out which object we’re talking about, and returns an object that can be worked with further in the script. Thanks Vjeko, to help me with the RegEx again :-).
- Export these objects one-by-one and remove the empty files (when object doesn’t exist)
- Apply deltas to these text files by the default “Update-NAVApplicationObject” CmdLet.
- Update or remove versionlist: obviously we don’t forget to work with the VersionList, as this is never decently managed by any merge-cmdlet.
- Update date/time to now
- Manage the Modified flag: if we add the delta: change to “yes”, if we remove it, get it from the modified version of the reverse delta.
- Create reverse deltas (in case you don’t have it already – you will always be able to “unapply” the deltas)
- Import the result file, with merged objects, updated versionlist, .. .
- Delete objects – Analyze the “UpdateResult” to figure out which objects need to be deleted – and delete them. This is really important: part of a delta, an object can be deleted, but by importing a text file, you are not able to delete anything. So this needs to be managed separately
- Compile uncompiled
- Open workingfolder if requested
So .. that’s quite a sandwich, isn’t it. Applying deltas to a database is not just the Update-NAVApplicationObject CmdLet. Far from it. You need to do much more. But as you can see – you can easily script your way through it, so you can have one CmdLet, that does it all. And thanks to this script, I have been using DELTA-files much more than any text or fob file. Especially in situations where I need to be very flexible in regards to implementing “apps” in multiple versions/localizations of Microsoft Dynamics NAV.
It’s all available for you .. hope you use it! 🙂
Can I UnApply as well?
Yes, you can remove your customizations just as easily as you would import anything else – just as long as you create the “reverse delta” .. because removing your customization, is applying the reverse delta, and tell the script you’re removing by using the Deltatype “Remove”. As an example, this is the UnInstallscript for WaldoNAVPad:
$AppName = 'WaldoNAVPad' $WorkingFolder = "C:\_Workingfolder\$($AppName)" $ServerInstance = 'WaldoNAVPad_DEV' Apply-NAVDelta -DeltaPath 'C:\_Workingfolder\WaldoNAVPad\CreateDeltas\AppFiles_Reverse\*.DELTA' ` -TargetServerInstance $ServerInstance ` -Workingfolder $WorkingFolder ` -OpenWorkingfolder ` -SynchronizeSchemaChanges Force ` -DeltaType Remove ` -VersionList $AppName Start-NAVIdeClient -Database $ServerInstance
Is this a replacement for Extensions?
Most definitely not. Extensions bring us much more… , like transportability (with the navx file), upgradability (and taking care of the data), per tenant customization, the promise it won’t cause conflicts, prerequisites, dependencies, … . The above, is merely a way to add customizations to a database by not importing text files, but importing deltas – to not face the risk to overwrite stuff you don’t want to overwrite. And a way to remove these customizations, without the risk of removing too much ;-). Call it “Extensions on a valium” ;-). Extremely useful when you’re developing small generic functionalities that have to be imported in different customer db’s, db versions, localizations, whatever… .
Great stuff! Succesfully managed to apply my delta. When removing the Delta I get an error when trying to delete objects.
I think this is because the Delete-NAVApplicationObject2 script doesn’t take the SQL Server instance into account, but only works on the default SQL server instance.
My test database is on the servername\NAVDEMO instance and deleting the objects results in the error:
“Delete-NAVApplicationObject : :  The servername server cannot be found.”
Maybe an optimisation for the next release of the Tools?
Thanks for mentioning! I have been updating my functions to support this SQL Instance. Apparently not for the Delete-one just yet ;-). Will do. I created an issue in github: https://github.com/waldo1001/Cloud.Ready.Software.PowerShell/issues/13 .