Rash thoughts about .NET, C#, F# and Dynamics NAV.

Today I released two new AssemblyInfo tasks for FAKE and marked the old one as obsolete. One advantage of the new tasks is that they only generate the specified attributes and no more. There are already a lot of predefined attributes but it’s also possible to specify new ones. Here is a small example:

This post has been moved to http://fsharp.github.io/FAKE/commandline.html

Today I’m happy to annouce that we have a new type provider in FSharpx. Yesterday I ported the WMI type provider from the F# sample pack and released it as a nuget package. This type provider allows to use Intellisense on data from the Windows Management Instrumentation (WMI).

Create a new F# project in Visual Studio 2012 and install the FSharpx.TypeProviders.Management package via nuget. The package manager references two libraries and you have to remove the reference to Samples.Management.TypeProvider.DesignTime manually. After you reference System.Management you can start to access WMI:

You can find a lot more samples in the F# Sample pack.

This post has been moved to http://fsharp.github.io/FAKE/nuget.html

The “Walkthrough: Creating and Interacting with a Page Web Service (OData)” shows how we can easily access Dynamics NAV OData from the default company:

But somewhere in this process there seems to be a bug. If I want to access data from a different company I get a timeout:

I found a workaround for this, but if anybody knows more about this please write a comment.

In my last post I described how we can access Dynamics NAV 2009 SOAP web services from F# and the benefits we get by using a type provder. Since version 2013 it’s also possible to expose NAV pages via OData. In this article I will show you how the OData type provider which is part of F# 3 can help you to easily access this data.

Exposing the data

First of all follow this walkthrough and expose the Customer Page from Microsoft Dynamics NAV 2013 as an OData feed.

Show the available companies

Let’s try to connect to the OData feed and list all available companies. Therefore we create a new F# console project (.NET 4.0) in Visual Studio 2012 and add references to FSharp.Data.TypeProviders and System.Data.Services.Client. With the following snippet we can access and print the company names:

As you can see we don’t need to use the “Add Service Reference” dialog. All service type are generated on the fly.

Access data within a company

Unfortunately Dynamics NAV 2013 seems to have a bug in the generated metadata. In order to access data within a company we need to apply a small trick. In the following sample we create a modified data context which points directly to a company:

Now we can start to access the data:

As you can see this approach is very easy and avoids the problem with the manual code generation. If you expose more pages then they are instantly available in your code.

As with the Wsdl type provider you can expose the generated types from this F# project for use in C# projects.

Further information:

• Walkthrough: Accessing an OData Service by Using Type Providers (F#)
• Walkthrough: Creating and Interacting with a Page Web Service (OData)

If you are a Dynamics NAV developer you have probably heared of the web services feature which comes with the 2009 version. In this walkthrough you can learn how to create and consume a Codeunit Web Service. This method works very well if you only need to create the C# proxy classes once. If you have more than one developer, an automated build system, changing web services or many web services then you will come to a point where this code generation system is very difficult to handle.

Microsoft Visual F# 3.0 comes with feature called “type providers” that helps to simplify your life in such a situation. For the case of WCF the Wsdl type provider allows us to automate the proxy generation. Let’s see how this works.

Web service generation

In the first step we create the Dynamics NAV 2009 Codeunit web service in exactly the same way as in the MSDN walkthrough.

Connecting to the web service

Now we create a new F# console project (.NET 4.0 or 4.5) in Visual Studio 2012 and add references to FSharp.Data.TypeProviders, System.Runtime.Serialization and System.ServiceModel. After this we are ready to use the Wsdl type provider:

At this point the type provider creates the proxy classes in the background – no “add web reference” dialog is needed. The only thing we need to do is configuring the access security and consume the webservice:

Access from C#

This is so much easier than the C# version from the walkthrough. But if you want you can still access the provided types from C#. Just add a new C# project to the solution and reference the F# project. In the F# project rename Program.fs to Services.fs and expose the service via a new function:

In the C# project you can now access the service like this:

Changing the service

Now let’s see what happens if we change the service. Go to the Letters Codeunit in Dynamics NAV 2009 and add a second parameter (allLetters:Boolean) to the Capitalize method. After saving the Codeunit go back to the C# project and try to compile it again. As you can see the changes are directly reflected as a compile error.

In the next blog post I will show you how you can easily access a Dynamics NAV 2013 OData feed from F#.

As programmers we often want to express that a special property holds for a method, e.g. we want to say that the associativity law holds for list concatenation. In F# we could define a concat method like this:

As programmers we could write a couple of unit tests which try to check the associativity law. With NUnit enabled we could write this:

But the question is: did we cover all interesting cases? In computer science we have a method to prove that the property holds for all lists. This methods is called structural induction (see also this video lecture by Martin Odersky) and would look like this:

1) Rewrite the code as equations

concat ([],ys)    = ys                  [CON1]
concat (x::xs,ys) = x :: concat(xs,ys)  [CON2]

2) Rewrite the property as an equation

concat(concat(xs,ys),zs) = concat(xs,concat(ys,zs))

3) Check the base case

concat(concat([],ys),zs) 
= concat ([],zs)                 // using CON1
= []                             // using CON1

concat([],concat(ys,zs))

= concat (ys,zs)                 // using CON1
= []                             // using CON1

3) Show the inductive step

concat(concat(x::xs,ys),zs) 

= concat (x::concat(xs,ys),zs))  // using CON2
= x :: concat(concat(xs,ys),zs)  // using CON2 
= x :: concat(xs,concat(ys,zs))  // induction hypothesis
= concat(x::xs,concat(ys,zs))    // using CON2

This math is very clean and shows that the associativity law holds for all lists. Unfortunately even with a slightly more complicated sample this gets at least tricky. Try to prove that reverse(reverse(xs)) = xs with reversed defined as:

As you will see the naïve approach with structural induction will fail (for a nice solution see this video lecture).

There is even a bigger problem with the proof: one assumption of induction is referential transparency of the given functions. We can’t always assume this.

So we can’t always (easily) proof code properties and we don’t want to write too many unit tests – then what can we do?

One compromise solution is to use a tool which systematically generates instances for our tests. There are a couple of tools out there, e.g. there is QuickCheck for Haskell or PEX for .NET. In F# we can use a tool called FsCheck:

Of course a test like this doesn’t prove that the property holds for all lists, but at least it verifies all bases cases and probably a lot more cases than one would manually do.

If you introduce a bug you get a nice report, which even shows a counterexample:

It’s even possible to add these tests to your test suite and to run them during the CI build. So don’t stop at classical unit test – check code properties!

“Footloose is a fast and scalable asynchronous distributed computing and service library that was designed to be secure, simple to use, unobtrusive and without the need of client side code generation or proxy classes.

It was developed to connect or build distributed applications on the .NET/Mono platform with enterprise features like load-balancing, clustering, encryption, service discovery and single-sign on.

Footloose enables you to easily transmit any kind of data between the components of your application over thread-, process- or physical boundaries. Depending on your needs Footloose uses one if its transport channels, e.g. a Named Pipe or a Unix Socket for Inter Process Communication (IPC), AMQP with one of the available Message Broker implementations (like RabbitMQ) in the local network or even XMPP as a secure and fast realtime messaging protocol that enables you to build cloud services.”

http://www.footloose-project.de

If you don’t like WCF then you should really check out Footloose.
Today I want to show you how to use Footloose in a very simple sample with F#.

As a first step we create a F# project for the service contracts. Inside this project we need a service definition like this:

This is just a definition of the remote service and the data. Now we create a F# console project for such a service and reference the service contracts project. We start by implementing the service like this:

Now we use nuget to retrieve the latest version of Footloose. At the time of writing we need to install the pre-release of version 3.0 by "install-package Footloose -pre". In the Program.fs we add the service configuration. Here Footloose wants us to specify the endpoint name, transport channel and a serializer. In order to get Footloose working we also have to retrieve a trial license from the website.

Footloose wants us to provide a ServiceLocator in order to resolve the service. Normally you would use a DI container for this, but here it’s sufficient to fake a IServiceLocator like this:

In the next step we create another F# console project for the client, reference the service contracts and install Footloose ("install-package Footloose -pre"). We also need to install FSharpx ("install-package FSharpx.Core") in order to use the "Quotation to Linq Expression" stuff and the new task monad. Now we are ready to build the client:

As you can see we set up the connection and wrap our service call inside a task monad. The most interesting part is calling the service. Footloose wants to us to provide a LINQ expression:

In order to make the client code compile we also need an active pattern which transforms the service result into something we can pattern match:

As the last step we configure the solution to start both projects and run the sample:

The result should look like this:

The sample code is now part of the FootlooseExamples project on github.

Gestern habe ich schon den ersten Teil meiner Notizen hier auf dem Blog veröffentlicht. Jetzt geht es weiter mit Teil 2.

Scrum

Microsoft hat den internen Prozess auf Scrum umgestellt und ich finde das merkt man wirklich. Es sind zwar nur zwei Tage Konferenz, aber das Produkt fühlt sich tatsächlich “fertig” an. Es ist interessant zu sehen wie eine so konservative Organisation wie NAV auf einen agilen Prozess umstellt. Ich bin gespannt was mit diesen ganzen Wasserfall-Tools wie SureStep und Co. passiert. Hier auf dieser Developer-Konferenz hat jedenfalls keiner davon geredet.

• 20 Scrum Teams mit zweiwöchigen Sprints
• Verwaltung der User Stories im TFS (Source Control irgendwo anders)
• ATDD wird eingesetzt aber kein TDD
• Umstellung auf Kanban steht jetzt bevor

OData

• OData Webservices aus NAV + Excel PowerPivot ist eine geniale Kombination für Auswertungen (Low Cost BI) – MSDN Walkthrough
• OData ist im Moment nur read-only

Dimensionen

• Völlig überarbeitet.
• Viel weniger Kopien der Dimensionen – nur noch über einen Schlüssel referenziert

Datenzugriff

• Neuer Data Access Stack angeblich schneller als Classic Client.
• FIND und FINDSET sind gleich schnell
• SETCURRENTKEY macht Abfragen jetzt nur noch langsamer (da Sortierung) keinesfalls schneller
• SQL Call Stack Traces – Blog post
• Es sind keine Writes in die Object und Company Tabellen mehr möglich
• Security Filters überarbeitet. Erlaubt es Nutzern nur gefilterte Datensätze zu zeigen.
  • Neue Optionen um Probleme mit indirekten Rechten zu lösen
  • Security Filter Feature kann im C/AL direkt an Record-Variablen konfiguriert werden
  • Security-Einstellungen zeigen sofort Wirkung. Keine manuelle Synchronisation der Nutzer oder Neustarts nötig
  • Standard App wurde noch nicht nach möglichen Security Filter Problemen durchforstet
  • Validated Mode sollte möglichst nicht benutzt werden, da es langsamer als die anderen Optionen ist

Locks und Blocks

• Alle Slides und Samples sind auf Stryks Blog downloadbar
• SQL Server Lock Escalation sollte vermieden werden -> „always rowlock” benutzen (jedoch nicht auf 32bit und unter 8GB RAM)
• LOCKTABLE erhöht das Transaction Isolation Level auf Serializable
  • Über einen DB switch kann auf Repeatable Read umgestellt werden (Unterschied wie Tag und Nacht)
  • Das ist sowieso der Standard bei NAV2013
  • Es können zwar Phantom Reads entstehen, aber das sind Probleme die in der Praxis nicht existieren (“habe ich noch nie gesehen”)
• Block und Dead Lock Detection Tool auf seinem Blog
• Job Queue von NAV2013 kann auch in älteren Versionen nachgebaut werden
• Beispiel 1: In Document Dimensions den Clustered SQL Index fixen – Document No.,  Document Type nach vorne -> weniger Blocks da die gelockten Zeilen näher beisammen sind
• Beispiel 2: In Codeunit 80 und 90 gibt es ein globales Lock auf die „GL Entry“. Das wird auch ausgeführt wenn gar keine Sachbuchungen passieren. Lock mit PostToGL Flag fixen (bereits in NAV2013 gefixt)
• Beispiel 3: In Tabelle 36 gibt es einen „Warehouse bug“ – Selbst wenn die Warehouse Tabelle leer ist wird die Tabelle gelockt. Generell sollte immer über ISEMPTY geprüft werden ob überhaupt Datensätze im Filter sind bevor man ein DELETEALL oder MODIFYALL durchführt
• Beispiel 4: Reservation Entry.Lock() hat ein ähnliches Problem. Einfach am Anfang der Funktion prüfen ob die Tabelle leer ist. Wenn ja dann mit EXIT aus der Funktion springen
• Beispiel 5: No. Series Line Tabelle ist „zu klein“ für das Lock und es werden mehr als eine Zeile gelockt. Folge: Wenn jemand eine Rechnung erzeugt kann ein anderer u.U. keine Artikel erzeugen. Lässt sich leicht mit Dummy Feldern fixen. 😉

Reporting

• Es gibt nur noch RDCL Reports
• Classic Sections (und deren Trigger) fallen weg
• Es gibt einen „Dataset designer“ als Ersatz für die Sections (analog Query designer)
• Es wird nun RDLC 2008, Report Viewer 2010 und Visual Studio 2010 benutzt.
• Reports erlauben „Save as Word“
• “Heavy reports” über Background Session auf dem Server drucken (“Server side printing”)
• Im Webclient gibt es “Preview” (nur IE) und „Save as PDF“ (alle Browser)
• „Tray selection“ fixed – zusätzlich ein Codeunit 1 Trigger der es erlaubt die Papierfachsteuerung zu überschreiben
• Upgrade Prozess
  • Hotfixes in NAV 5 und 6 erlauben Trigger in Codeunit 1 „OnBeforeRunReport“ (erlaubt zu zählen wie oft der Report tatsächlich genutzt wird)
  • Automatische Transformation hilft bei Upgrade von existieren NAV 2009 RDLC Reports (Tools/Upgrade Report)
  • Upgrade braucht ein technisches Upgrade auf NAV2013 als Zwischenschritt, da der Report kompilierbar sein muss um das Transformations-Tool zu benutzen
  • Automatisch vergebene Namen im Anschluss aufräumen
  • Doppelte Spalten entfernen
  • UI Guidelines auf MSDN befolgen
  • CreateTotals entfernen

Insgesamt war es ein sehr gute Veranstaltung mit vielen Informationen zu Dynamics NAV 2013. Vielen Dank an die Organisatoren und die Speaker.