Apply-NAVDelta to add and remove customizations

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… .