Der NAV-Entwickler Kurs (für Rookies)- Part 1: Einleitung

Dies soll der Start in einer Reihe von Beiträgen sein, die für NAV Neu-Einsteiger angedacht ist. Dieser soll die Programmierung sowie dessen Datenbank-Design umfassen. Die Zielgruppe dieser Artikel betrifft also Studenten, Schüler, Praktikanten und Neueinsteiger.

Zu allererst einmal: Microsoft Dynamics NAV ist ein ERP-System. Das bedeutet, es dient dazu um die Ressourcen einer Firma zu planen. Zum Beispiel: Wieviele Artikel habe ich noch auf Lager? wie teuer waren diese? was nehme ich für diesen Artikel? Welche Kunden haben diesen gekauft? Wieviel muß mir der Kunde überhaupt noch bezahlen? Was haben wir eingekauft? etc.

Das sind nur einige wenige Dinge die NAV verwalten kann. Wie man an diesem Umfang an existierenden Features schon sehen kann, ist NAV für diese Tätigkeit ausgelegt. Dazu hat NAV zusätzlich, und das interessiert uns hier, eine Entwicklungsumgebung. Diese heißt C/Side (Client/Server Integrated Development Environment) in der man C/AL (C/SIDE Application Language) Programmiert. Fazit ist also (und das muss man sich immer vor Augen halten): NAV ist ein ERP System mit einer kleinen Entwicklungsumgebung!

Warum dieser Satz? Wenn man schon einmal außerhalb von NAV entwickelt hat oder sich mit anderen nicht-NAV Entwicklern unterhält fällt schnell auf, dass die NAV-Entwicklungsumgebung relativ eingeschränkt ist. Diese ist nur über diverse Client Extensebility Möglichkeiten erweiterbar. Aber bis dahin dauerts noch ein wenig 😉

Man kann sich NAV gerne als eine Art Lego-Produkt vorstellen: Microsoft gibt einem das fertige Produkt nach Anleitung aufgebaut und wir erweitern/verändern dies mit den aus der Packung gegebenen Mitteln.

Was muss ich wissen?

Um Anfangen zu können solltest du die folgenden Beiträge mindestens überflogen haben (Auswendig lernen ist nicht notwendig 😉 ):

• http://de.wikipedia.org/wiki/Microsoft_Dynamics_NAV
• http://de.wikipedia.org/wiki/Datenbank
• http://de.wikipedia.org/wiki/SQL

Dies ist ca. Basiswissen mit dem man starten kann.

Wenn man sich eine Datenbank verallgemeinert vorstellen will, ist der Grundsatz nur eine Ansammlung von Tabellen. Natürlich bietet unser Datenbank Management System Microsoft Dynamics NAV noch viel mehr Funktionen aber der Grundsatz ist: es speichert deine Daten.

Jede Tabelle speichert deine Daten anhand von Zeilen und eine Zeile ist ein so genannter Datensatz. In jeder einzelnen Tabelle sollten nur Informationen festgehalten werden, die auch für diese Tabelle interessant ist. Das soll heissen, die Tabelle bekommt einen Namen, z.B. „Mitglieder“ und dann sollten dort keine Informationen zu dem Auto des Mitglieds stehen. Dafür wäre dann eine weitere Tabelle notwendig. In der Mitglieder Tabelle würde somit nur noch ein Verweis zu dem Auto stehen. Hier zum Beispiel:

Autos:

1. Golf II, Weiß, 1988
2. Golf IV, Blau, 2001

Mitarbeiter:

1. John Doe, 1983, Auto 2

Wenn die einzelnen Nummern nun Datensätze wären, hätte der Mitarbeiter 1 nun das Auto 2, einen Golf IV in Blau. Das Stichwort hierzu lautet Datenbank Normalisierung.

Wie entwickle ich in NAV?

Grundsätzlich sollte man, wenn man die Business Logik anpassen will, erst einmal kontrollieren wie man dies im Standard (der vorprogrammierte Code von Microsoft) lösen wurde. Manchmal geht es da sogar nur um das „Look and Feel“ einer Funktion. Als Beispiel: an jedem Auftrag kann ein Kommentar hinterlegt werden. Falls hier eines eingetragen wurde, sieht der Button rechts neben dem „Nr.“ Feld anders aus als ohne Kommentar. Wenn man dies nachprogrammieren möchte, schaut man sich einfach diese Stelle an. Kurz gesagt, sollte man sich zu Anfang die Frage stellen: Wie würde der Standard dieses Problem lösen?

Objekt Orientiertes Programmieren in NAV?

Falls du gerade nur Fragezeichen über dem Kopf hast, überspringe diesen Teil ruhig ODER ließ ihn aus Prinzip zu ende 😉

Grundsätzlich gibt es das OOP nicht in NAV. Es gibt zwar Objekte aber es können keine eigenen neu definiert werden. Sondern nur neue eines Typs (Tabelle, Form, Report, Page …). Allerdings kann man gewisse Prinzipien des OOPs sehr, sehr gut auch in NAV einsetzen.Der folgende Text ist meine derzeitige Meinung, wie man in NAV sauber und gut programmiert:

Eine Tabelle ist eine Klasse und alle enthaltenen Funktionen beziehen sich auf einen Datensatz der Instanz. Bedeutet, wenn für eine Zeile eine Menge an Datensätzen in einer weiteren Tabelle verarbeitet, dessen Parameter alle in dem Datensatz gespeichert sind, sollte diese Funktion in der Tabelle programmiert werden.

Codeunits sind Klassen, die Funktionen bereitstellen die nicht zwingend an einen Datensatz gebunden sind und häufig auch von anderen Codestellen ausgeführt werden müssen.

Forms, Pages sind nur für Ausgaben zuständig und Reports für Ausgaben und Batchläufe (im besten Fall für Funktionen auf den zugrunde liegenden Tabellen).

Wie immer: Das ist die Theorie.

Idee?Inspiration?…womit soll ich nur Anfangen?

Was mache ich als erstes? um etwas Gefühl für den Code zu entwickeln, schlage ich immer gern vor, etwas vollkommen neues zu Programmieren! Der Standard ist zwar Super aber um sich auszulegen (so meine Erfahrung und Meinung) ist man Kreativer in eigener Umgebung 😉

Entweder, du lässt dir nun etwas eigenes einfallen was die folgenden Start-Parameter erfüllt oder du nimmst mein noch kommendes Beispiel. Die Parameter die deine Idee haben sollte:

• Daten die gespeichert werden
• Berechnete Daten
• Benutzer-Interface

Deine eigene Idee muss nun nicht zwingend etwas total neues oder Bahnbrechendes sein, sondern etwas, welches dir am ehesten Vorschwebt oder einfach aus Interesse für dich geeignet ist.

Beispiele, auf die ich nicht weiter eingehen werde: DVD-Sammlung, Bücher-Sammlung, Terminkalender, Quartet-Spiel, Stundenplan, Computerspielfiguren Sammlung (inkl. ingame Werte), etc….

Bitte hinterlasst mir doch einen Kommentar zu diesem Beitrag. Mich würde interessieren wie sinnvoll und Hilfreich dieser Beitrag ist. ich nehme gerne auch Negativ-Kritik und Verbesserungsvorschläge entgegen.