An asynchronous processing solution for MS Dynamics NAV

Standard

From the earliest to the newest NAV versions, long-running tasks are usually accompanied by a progress bar or windows with multiple progress bars. It’s developer’s preferred choice to inform the user with the progress of the launched task – an obvious choice to an hourglass cursor. There are plenty of business processes in any NAV database that do heavy processing. If we look into a posting task, NAV generates Add-On specific ledger entries, standard specific ledger entries, creates invoices and lines, adjacent records and so on. Therefore these tasks  can take a while and can keep the user session busy.

asyncThis blog is about a solution, my boss and I designed and used it on a few target processes, to allow users to immediately regain control of their session after the launch of a long-running task, while assigning the processing to a NAV background session. The results of the processing are recorded and easily retrievable by the calling page automatically by using PingPong Control AddIn.

PingPong info: msdnGunnar’s and Olof Simren ‘s blog.

How does our solution get implemented?

A table with entities to be processed named in the code sample “Generic Entity”. At the minimum the table should have PK fields. Our sample has three fields that are part of the PK: Field_1, Field_2, Field_3.

asynchronous-processing-in-nav

A card page for “Generic Entity” table named “Generic Entity Card” whose only action will launch the async process.

A factbox “Queue Summary Factbox” used on the “Generic Entity Card” to reflect the status of the last queued record processed. The status gets updated by using a PingPong Control AddIn.

A new table “Processing Queue”. At the minimum add enough fields to be able to locate later the record(“Generic Entity”) that launched the process. Additionally, an Option field, “Status” with at least 4 values: Queued, Processing, Error and Success and a Text field “Error Message” to record the errors that prevented the process to finish successfully.

A new codeunit “Process Queue” (whose Rec is “Posting Queue” ). In the Run function of this codeunit wrap the processing in a TryFunction to be able to rollback if errors are encountered.

If wanted you can add more fields to the “Processing Queue”. In our environment we have “Document No.” of the resulting Posted Sales Invoice and “Elapsed Time” to record the duration of the task. You could also enable Lookup on the factbox field to open a list page for Processing Queue table.

If you want to try our solution download it from here.

NAV 2016 – Applying a new NAV Cumulative Update using Powershell cmdlets

Standard

I’ve done a few C/AL code merging for Dynamics NAV in the past, and while I don’t mind working with BeyondCompare for a few hours every now and then, the task is repetitive and prone to errors so I was searching for a cleaner and faster approach. A few days ago my boss told me about (NAV) Powershell commands and that I should give them a try. Why not?

I liked the idea of running a few Powershell commands that do the bulk of the job, from merging to compiling an entire database with minimal assistance on my side. The less “personal touch” the better. Less time spent on redundant tasks lead to less mistakes, and more time for development and trying new technologies.

And this is where I am now. The process still requires (minimal) developer’s interaction – for updating standard objects (VersionList propery) touched by AddOns objects, comparing a few conflict files and of course, running the commands. Albeit all this, the time I recorded to apply a cumulative update is at the minimum halved. Is there room for further improvement? Definitely, with a few more experiments under the belt and testing, the process can further be refined into a single script run, cutting 4-6 hours task to a few minutes.

The steps below are based on a recent task I worked on: to apply  standard NAV 2016 CU11 on top of a NAV 2016 CU5 database + my employer AddOn.

Pre-requisites:

  • A previous CU demo database (the last one you applied) – let’s call it CU(n-1)
  • The current (the one we want to apply) CU demo database – named here CU(n)
  • The current database based on CU(n-1) and your AddOns
  • A working folder Upgrade with 5 folders in it:
    • ORIGINAL
    • MODIFIED
    • TARGET
    • DELTA (used if you want to compare first the differences)
    • RESULT

Steps:

1. Create objects in text format for all objects of:

  • Demo database CU(n-1) -> in the ORIGINAL folder
  • Demo database CU(n) -> in the MODIFIED folder
  • Current database -> in the TARGET folder

Finsql command=ExportObjects, file=c:\Upgrade\Original\Orginal.txt, servername=myserver, database=Demo CU (n-1)

Finsql command=ExportObjects, file=c:\Upgrade\Modified\Orginal.txt, servername= myserver, database=Demo CU (n)

Finsql command=ExportObjects, file=c:\Upgrade\Target\Orginal.txt, servername= myserver, database=your_current_db_with_addons

2. In the NAV 2016 Development Shell run:

Merge-NAVApplicationObject -TargetPath .\TARGET -OriginalPath .\ORIGINAL -ModifiedPath .\MODIFIED -ResultPath .\RESULT -DateTimeProperty FromModified -ModifiedProperty FromModified -VersionListProperty FromModified

This will populate RESULT folder with txt files and conflict folders.

3. Merge code using BeyondCompare or any other similar tool comparing files from ConflictModified folder against correspondent files from ConflictTarget folder. Copy the merged files(overwrite existent) into the Result folder.

4. In your current database(target db) Development Environment select all standard objects that have been touched by your AddOns

5. Take each object of the list in Development Environment and manually add your AddOn version into the correspondent files from RESULT folder

Note: This is because the -VersionListProperty parameter of Merge_NAVApplicationObject cmdlet does not update the version list with the AddOn signature – need to do it manually for now.

6. Combine all text files from RESULT folder into one:

PS C:\upgrade\result> Join-NAVApplicationObjectFile -Source “*.txt” -Destination “all_objects.txt”

7. Import “all_objects.txt” in the development environment manually or using finsql’s command=importobject” parameter.

8. Compile all objects

More MSDN info here and here.

Useful Powershell commands:

  • Create Delta files

Compare-NAVApplicationObject -OriginalPath .\ORIGINAL -ModifiedPath .\MODIFIED -DeltaPath .\DELTA

  • To apply Delta files:

Update-NAVApplicationObject –DeltaPath .\DELTA -TargetPath .\TARGET\*.txt -ResultPath .\RESULT

  • Join all text files into one:

Join-NAVApplicationObjectFile -Source “*.txt” -Destination “all_objects.txt”

  • Import that single file in NAV

finsql.exe command=importobjects, file=C:\Upgrade\Result\all_objects.txt, servername=myserver, database=”merge_target”

  • Split a big text file into individual text objects

Split-NAVApplicationObjectFile -Source C:\Upgrade\ORIGINAL\*.txt -Destination C:\Upgrade\ORIGINAL\TXT\

More MSDN info on cmdlets here.