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

Seit Microsoft das SP1 für Dynamics Nav 4 heraus gebracht hat, gibt es neue C/AL-Befehle zur schnelleren SQL-Server-Abfrage. Da immer wieder Fragen dazu auftauchen, hier eine kleine Zusammenfassung.

(weiterlesen…)

Im März wurde eine interessante Feld-Studie der Keystone Strategy, Inc. unter Leitung von Dr. Marco Iansiti, dem Professor für Business Administration an der Harvard Business School veröffentlicht. Es wurde gemessen wie Endanwender von ERP-Anwendungen den Einfluß von Microsoft bzw. SAP auf Ihre Arbeitsproduktivität empfinden. Demnach bewerteten Dynamics-Anwender Ihre Produktivität bzw. die Benutzerfreundlichkeit deutlich besser als dies SAP-Anwender taten.

(weiterlesen…)

Navision hat wie alle “größeren” Systeme bei der “ERP-Zufriedenheitsstudie Schweiz 2006” leider nicht so berauschend abgeschnitten – mySAP war sogar auf dem vorletzten Platz.

Besonders interessant an der Studie sind vor allem die Diagramme der Zufriedensheitsaspekte – demnach sind Formulare/Reports zwar stark vom Kunden beeinflußbar, erzeugen jedoch trotzdem den meisten Frust. Irgendwie kommt mir das bekannt vor.

Weitere Informationen:

• InfoWeek-Artikel (unbedingt die Diagramme ansehen)
• Präsentationsfolien
• Bilder der Präsentation

Wenn man nach dem Rating-Portal Benchpark geht, ist Navision (bzw. Microsoft Dynamics .NAV) momentan das beliebteste ERP-System überhaupt und liegt damit deutlich vor Axapta, SAP und SSA Global.

Bei den CRM Systemen ist Microsoft momentan nur auf Rang 4 – aber immerhin vor Siebel…

Today I want to describe a way to integrate Oracle into Navision. We use this way to migrate selected Tables and Views (rawdata) completely automatic into Dynamics Nav. This means we generate the Table-Structure (as a copy of the Oracle data dictionary) and import the data on the fly.

First of all one have to install the ODP.NET (Oracle Data Provider for .NET).

Then create a new C# ClassLibrary-Project and add a reference to the installed OracleDataAccess-Assembly. (see Sample-Project as Reference)

Install your COM-Object. (You can let Visual Studio do this for you)

Then create a Navision-Object which connects to the ClassLibrary and interact with Oracle.

IF g_MigrationHelper.OracleConnect( 
  g_ORAUserName,g_ORAPassword,g_ORADataSource) 
THEN BEGIN 
  IF p_Test THEN BEGIN 
    MESSAGE('Connection open'); 
    g_MigrationHelper.CloseOracleConnection; 
  END 
END ELSE 
  ERROR('Connection failed');

“This form lists the granules and their associated objects for MBS-Navision 3.60, 3.70 & 4.00. Now you can determine which Granules you need to buy in order to gain access to a certain Object or feature.”

Ein wirklich nettes Tool.

In letzter Zeit sind dank dem Einsatz von AutoHotkey einige wirklich nette Tools zur Produktivitätssteigerung und Qualitätssicherung bei uns entstanden.

So ist es jetzt endlich möglich ein Daily-Build laufen zu lassen, dass sich automatisch die neuesten Navision-Objekte vom VSS-Server holt und dann automatisch in die einzelnen Datenbanken einspielt.

Gleich daraus folgend ist ein automatisches Daily-UnitTest-Tool entstanden, dass jeden Abend automatisiert auf einem eigenen Testrechner ein frisches Build zieht und dann mit unserem UnitTest testet. Am nächsten Morgen haben dann alle Entwickler die Möglichkeit das Protokoll zu betrachten und möglicherweise Fehler vom Vortag gleich zu fixen.

Des weiteren wurde ein automatischer Patch-Generator entwickelt, der basierend auf den Differenzen vom letzten Release und dem aktuellen Stand ein Patch-File generiert und dieses testet.

Aber das wirklich allerbeste Tool, das zugegebenermaßen noch einige Kinderkrankheiten aufweist, ist eine VSS-Integration direkt ins Navision. Damit ist es endlich möglich die Objektfiles direkt im Navision auszuchecken, zu bearbeiten und dann wieder ins VSS einzucheken.

Manuelle Tests

Das Testen von Software war schon immer eine der wichtigsten und auch unbeliebtesten Aufgaben beim Software-Entwicklungsprozess. Generell gibt es viele unterschiedliche Arten des Testens. Im herkömmlichen Verfahren wurde meistens während der Entwicklung mit dem Debugger und Tracing-Ausgaben gearbeitet und im Anschluss vor dem Release ein umfangreicher manueller Test des kompletten Systems durchgeführt. Aber damit ist es ja bekanntlich noch lange nicht getan, denn der Entwicklungsprozess ist mit der Fertigstellung von Programmteilen längst nicht beendet. Änderungen am Programmcode, z.B. für Updates oder neue Features können unabsehbare Auswirkungen auf bereits getestete Programmteile haben. Die Folge ist, dass der komplette Test vor jedem neuen Release wiederholt werden muss. Da dies natürliche gewaltige Kosten verursacht wurden schon früh automatisierte Tests eingesetzt, die genau auf die Stellen aufmerksam machen, bei denen nun Fehlfunktionen auftreten. Beispiel für solche Test-Systeme sind JUnit (Java) oder auch NUnit (.NET), was in abgewandelter Form nun sogar in das neue Visual Studio 2005 integriert wurde. Doch was genau verbirgt sich hinter dem Unittesting?

Beim Unittesting (Unit = Einheit, Bauteil) wird die Funktion eines atomaren Teils des Systems (z.B. einer Berechnungsfunktion) isoliert von allen anderen getestet und validiert. Unittests können prinzipiell als Whitebox- und Blackbox-Tests betrieben werden. In der Regel wird jedoch der Entwickler im besten Fall schon vor der Entwicklung der Funktionalität die Testfälle anlegen. Nach jeder größeren Quellcode-Änderung sollte dann durch Ablaufen lassen aller Testfälle die Fehlerfreiheit überprüft werden.

Automatisiert und wiederholbar Testen durch Unit-Tests

Ein Unit-Test prüft in der Regel immer nur einen sehr kleinen und autarken Teil des Software-Systems – wie beispielsweise eine einzelne Funktion. Dabei wird bei jedem Test die zu testende Funktion oder Methode mit Testdaten (Parametern) konfrontiert und deren Reaktion auf diese Testdaten geprüft. Die zu erwartenden Ausgabewerte werden nun mit den von der jeweiligen Funktion oder Methode gelieferten Ergebnisdaten verglichen (Assertions). Stimmt das erwartete Ergebnis mit dem gelieferten Ergebnis der Funktion oder Methode überein, so gilt der Test als bestanden.

Ein TestRun besteht im Allgemeinen aus einer ganzen Reihe von Testfällen, die nicht nur ein Parameter-Ergebnis-Paar prüfen, sondern gleich mehrere.

Unittest mit Navision

Auch für Microsoft Navision Entwickler sollten UnitTests zum täglichen Programmieralltag gehören. Bisher gab es jedoch kein Testframework für Navision, so dass wir uns bei der msu solutions GmbH (Microsoft Certified Partner) entschlossen haben ein eigenes zu entwickeln. Die Einsatzmöglichkeiten des Navision-UnitTest-Frameworks möchte ich hier vorstellen.

Leistungsmerkmale:

• Labeln von Testgruppen und Testläufen:
  UnitTest.LabelTestRun(‘This run has to succeed’);
• Einfache Funktionstest mit definierten Vergleich:
  UnitTest.IntAssert( 4/2 ,2, ‘Is 4/2 = 2?’);
• Unterstützt erwartete Exceptions:
  UnitTest.AssumeError(‘Test 3 Error’);
• Komplette Assertions über Feldinhalte, Recods bis zu ganzen Tabellen:
  UnitTest.TableAssertion(TableID);

Testauswahl-Formular

• Auswahl der zu testenden Testgruppen
• Import/Export von Fehlertextbausteinen

Unittest-Viewer

• Anzeige des Testprotokolls
• Anzeige, welche Methoden fehlerfrei abliefen und wo Fehler auftraten

Im Navision ist es ganz einfach möglich ein einfaches LookUp zu machen. Will man jedoch mehrere Datensätze selektieren, muss man einige Anstregungen unternehmen. Am LookUp-Formular muss folgende Funktion hinterlegt werden:

PROCEDURE SetSelection(myRec : Record) 
BEGIN 
  CurrForm.SETSELECTIONFILTER(myRec); 
END;

Der aufrufende Code könnte dann so aussehen:

myRec.RESET; 
myRec.DELETEALL; 
myForm.SETTABLEVIEW(myRec); 
myForm.LOOKUPMODE(TRUE); 

IF myForm.RUNMODAL = ACTION::LookupOK THEN BEGIN 
  myForm.SetSelection(myRec); 
  myRec.MARKEDONLY := TRUE; 

  // Do something with the marked Records 
END;