NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 08:47

Können NAV-Objekte außerhalb von NAV erstellt werden? Sie können, und es gibt dafür "Fertiges".
Dieser Blog-Artikel berichtet von der Möglichkeit, mittels einer eigens entwickelten DLL für .NET neue NAV-Objekte außerhalb von C/SIDE zu erstellen. Ergebnis ist eine Textdatei, die nur noch im Object Designer importiert werden muss.

Für wen dies interessant klingt, findet hier mehr Informationen: http://www.uncommonsense.nl/cbreeze/

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 09:14

Hallo,

wenn man den Textimport benutzen kann, muss man da nicht unbedingt auf externe Komponenten zugreifen. Ein simpler Report tut es oft auch. Da ein NAV- Objekt eine relativ statische Angelegenheit ist.
Ich habe schon häufiger Tabellen aus anderen Tabellen erstellen müssen. dann habe ich mir einen Report gebaut z.B. basierend auf der Tabelle Field, der eine Textdatei erstellt. Im einfachsten Fall schreibt der im OnPreReport den Kopf der Tabelle, in den Dataitems die Felddefinitionen, und was sonst noch so gebraucht wird. Und im OnPostReport das Ende der Tabellendefinition. Was im Kopf und Fuß des Objekts stehen muss, kann man leicht durch eine selbst definiertes Objekt herausfinden. Das exportiert man als Text, kopiert die Passagen als Text- WRITES in den Report und ersetzt die Variablen Passagen durch ein paar STRSUBSTNOs.

Das ganze kann man beliebig komplizieren und aufwändiger gestalten, erfordert aber nicht unbedingt DotNet .

Gruß, Fiddi

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 09:46

Ich habe in dem ein oder anderen Projekt auch schon Tabellen automatisiert per Report bzw. Codeunit erstellen lassen.
Basis war eine Excel-Tabelle, in welcher der Consultant jede anzulegende Tabelle mit allen anzulegenden Feldern, Datentypen, Längen, TableRelations, ... definiert hatte.

Existierte die Tabelle noch nicht, so wurde sie als Text-Objekt in ein definiertes Verzeichnis geschrieben.
Existierte die Tabelle schon, so wurden die neuen Felder in der Tabelle Field eingetragen und das Objekt ggfls. in der Versionsliste markiert, falls CalcFormulas oder komplexe TableRelations nachgepflegt werden mussten.

Umgekehrt habe ich auch schon Reports geschrieben, die mir aus bestimmten Tabellen bestimmte Felder für ausgewählte Mandanten in einen SQL-View geschrieben haben und parallel dazu eine Text-Objekt schrieben, welches die dazu passende LinkedObject-Table repräsentierte.
SQL-View auf dem Server installiert, Table in NAV importiert, fertig war die mandantenübergreifende Sicht auf bestimmte Daten. ;-)

Trotzdem ist es natürlich interessant zu erfahren, dass es auch eine DotNet-basierte Lösung hierfür gibt.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 09:50

Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 10:05

Wenn man das als Endkunde liest, macht mir eine solche Vorgehensweise ehrlich gesagt auch mehr Angst.
Das ist aber meine Meinung.

mfg,
winfy

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 10:39

HattrickHorst hat geschrieben:Die Frage ist: Warum?

Es ist natürlich völlig sinnbefreit, ein Programm zu schreiben, welches einem eine Tabelle erstellt.
Wenn man jedoch im Zuge eines großen Projektes unzählige Tabellen zu erstellen hat, dessen detaillierte Definition bereits in einer anderen Datenquelle (z. B. Excel) existiert, dann sieht die Welt schon anders aus.
Im meinem o. g. Fall hätte ich hunderte Tabellen mit insgesamt tausenden Feldern anpassen bzw. erstellen müssen.
Durch die automatisierte Anlage bzw. Änderung sparte ich mir viele Tage "stupides Abtippen einer Excel-Tabelle" und konnte mich darauf konzentrieren, die wenigen neuen Felder in bereits vorhandenen Tabellen nachzuarbeiten (CalcFormulas, TableRelations, ...).

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 10:41

HattrikHorst hat geschrieben:Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.


Z.B. möchte für ein Upgrade alle Felder aus einer alten Version in einer Update-Tabelle sichern, die in einer neuen Version nicht mehr vorhanden sind. Mit einem geeigneten Bericht kann ich die komplette Kette der Objekte Sichern,Sicherungstabelle,Restore- Coderahmen automatisch erstellen. Das funktioniert automatisch wesentlich einfacher und sicherer, als wenn das ganze von Hand einzeln zusammen gebastelt wird.

Gruß, Fiddi

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 14:58

Timo Lässer hat geschrieben:
HattrickHorst hat geschrieben:Die Frage ist: Warum?

Es ist natürlich völlig sinnbefreit, ein Programm zu schreiben, welches einem eine Tabelle erstellt.
Wenn man jedoch im Zuge eines großen Projektes unzählige Tabellen zu erstellen hat, dessen detaillierte Definition bereits in einer anderen Datenquelle (z. B. Excel) existiert, dann sieht die Welt schon anders aus.
Im meinem o. g. Fall hätte ich hunderte Tabellen mit insgesamt tausenden Feldern anpassen bzw. erstellen müssen.
Durch die automatisierte Anlage bzw. Änderung sparte ich mir viele Tage "stupides Abtippen einer Excel-Tabelle" und konnte mich darauf konzentrieren, die wenigen neuen Felder in bereits vorhandenen Tabellen nachzuarbeiten (CalcFormulas, TableRelations, ...).

Da frage ich wieder warum? Wenn jemand in der Lage ist, eine Tabellendefinition so im Detail anzugeben, dann ist er doch auch in der Lage die Tabelle selbst anzulegen. Warum sollte man die Definition einer Tabelle irgendwohin (in dem Fall Excel) auslagern, wo man keine (Test-)Kontrolle mehr per Compiler hat? Das kann doch nur vernünftig (fehlerfrei) funktionieren, wenn man sich auf einfache Felddefinitionen beschränkt und keine Logik in die Tabelle einbaut. Da fehlt mir im NAV-Umfeld einfach die Rolle des reinen Datenbank-/Relationsdesigners, so daß man diese Tätigkeit klar abtrennen könnte.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 15:02

fiddi hat geschrieben:
HattrikHorst hat geschrieben:Die Frage ist: Warum? Ich meine, wenn man schon eine 4G-Entwicklungsumgebung hat, warum sollte man dann wieder auf textbasierte, nicht-herstellerunterstützte Eigenprogrammierung zurückgreifen? Erschließt sich mir nicht ganz.


Z.B. möchte für ein Upgrade alle Felder aus einer alten Version in einer Update-Tabelle sichern, die in einer neuen Version nicht mehr vorhanden sind. Mit einem geeigneten Bericht kann ich die komplette Kette der Objekte Sichern,Sicherungstabelle,Restore- Coderahmen automatisch erstellen. Das funktioniert automatisch wesentlich einfacher und sicherer, als wenn das ganze von Hand einzeln zusammen gebastelt wird.

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 15:13

Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?


und woher kommt das Migrationstool für die Kundentabellen? :roll:

Gruß, Fiddi

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 15:32

HattrickHorst hat geschrieben:Das kann doch nur vernünftig (fehlerfrei) funktionieren, wenn man sich auf einfache Felddefinitionen beschränkt und keine Logik in die Tabelle einbaut. Da fehlt mir im NAV-Umfeld einfach die Rolle des reinen Datenbank-/Relationsdesigners, so daß man diese Tätigkeit klar abtrennen könnte.
In Großprojekten gibt es manchmal wirklich so getrennte Tätigkeitsfelder.
Und ja, in der Excel-Tabelle ist nur die Tabellen-/Feld-Definition beschrieben, nicht jedes einzelne Property und erst recht kein C/AL-Code.
Dennoch erspart es viele Tage Arbeit, wenn wenigstens die hundert Tabellen mit tausenden Feldern automatisiert angelegt werden konnten.

HattrickHorst hat geschrieben:Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?
Wie Fiddi schon schrieb, kennt das Migrationstool nur die Standard-Tabellen und -Felder.
Sämtliche Individualfelder und -tabellen werden von diesem Tool nicht erfasst, so dass man es kundenindividuell erweitern muss.
Darüber hinaus müssen auch die Standardtabellen der neuen Version um die Individualfelder ergänzt werden, da sich diese beim Upgrade sonst nicht importieren lassen würden.

Es gibt also zahlreiche Fälle, wo es sinnvoll ist, Felder und/oder Tabellen automatisiert anzulegen.
Wie ich schon schrieb: Bei kleinen Anpassungen wäre es völlig sinnbefreit, ein Programm zu schreiben, welches die Anpassung vornimmt, aber bei größeren Projekten kann dies sehr nützlich sein, um entweder viel Zeit einzusparen oder wirklich alle Individualfelder und -tabellen zu erwischen.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 15:50

Ich hatte das Thema sehr intensiv, als ich eine DB, deren Tabellen und Felder aus dem Individualbereich in den Nummernbereich einer Branchenlösung verschieben musste.

Gruß, Fiddi

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 17:58

fiddi hat geschrieben:
Ich verstehe nicht ganz, was du da beim Updateprozess genau machen möchtest, aber die Daten sichert man doch über das Migrationstool, oder nicht?


und woher kommt das Migrationstool für die Kundentabellen? :roll:

Im Migrationstool kann ich doch die Tabellen und Felder angeben, die ich möchte. Also auch individuelle.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 18:02

Im Migrationstool kann ich doch die Tabellen und Felder angeben, die ich möchte. Also auch individuelle.


meinst du das "RIM"- Toolkit mit Migration?

Wie machst du denn ein Update von einer NAV- Version auf eine andere? Dafür benutzt man das Upgradetoolkit, und das kann das nicht automatisch.

Gruß, Fiddi

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 18:10

Generell würde ich sagen, das ist eine Frage der Vorgehensweise. Wenn man dem Kunden möglichst jeden Wunsch erfüllen möchte, ungeachtet der Tatsache, daß eine Prozessanpassung langfristig vielleicht die bessere Alternative für ihn wäre, dann kommt man evtl. auf sehr viele Tabellen und dann können sicherlich in Excel definierte Tabellengrundgerüste interessant sein. Wobei ich mir dann immer noch die Frage stelle, wie sichergestellt wird, daß das Konzept des Excelbearbeiters in NAV Sinn macht und umsetzbar ist, und wer wie überprüft, ob die Prozesse, die mit der Exceldefinition umgesetzt werden sollen, nicht besser anders, vielleicht sogar anders in NAV, umgesetzt werden? Aber ich denke, das ist eine Frage der grundsätzlichen Vorgehensweise beim Update und würde hier zu weit führen, auch wenn ich die Diskussion hier ansich gerade interessant finde.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 18:14

fiddi hat geschrieben:Wie machst du denn ein Update von einer NAV- Version auf eine andere? Dafür benutzt man das Upgradetoolkit, und das kann das nicht automatisch.

Für Datenkonvertierungen braucht man das Upgradetoolkit als Vorlage, das ist richtig.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 18:32

fiddi hat geschrieben:wenn man den Textimport benutzen kann, muss man da nicht unbedingt auf externe Komponenten zugreifen. Ein simpler Report tut es oft auch. Da ein NAV- Objekt eine relativ statische Angelegenheit ist. [...]
Das ganze kann man beliebig komplizieren und aufwändiger gestalten, erfordert aber nicht unbedingt DotNet .
Jepp, ich wollte euch aber nicht vorenthalten, dass es sehr wohl so etwas - Fertiges - gibt.

Re: NAV-Objekte außerhalb von C/SIDE generieren

10. April 2014 19:17

Für Datenkonvertierungen braucht man das Upgradetoolkit als Vorlage, das ist richtig.

Wieso Vorlage?