Object Manager Advanced

Hallo Allerseits,

ich war lange nicht mehr hier (Asche auf mein Haupt).

Ich habe mal eine Frage zum Object Manager Advanced von idyn.

Wir sind grade dabei einen Update von NAV 4 auf 2009R2 vorzubereiten.
Großes Problem dabei ist, dass die Datenbank eine riesige Menge undokumentierte Modifikationen enthält, die jetzt alle gefunden und nachdokumentiert werden müssen, bevor wir uns ans eigentliche Update machen können.
In einem zweiten Schritt nach dem Update soll auch der RTC Abteilungsweise eingeführt werden.

Da das NAV DevToolkit schon lange nicht mehr weiterentwickelt und verkauft wird, liebäugle ich mit dem OMA.

Hat der OMA Funktionen um z.B. unsere Aktuelle Datenbank gegen eine Referenzdatenbank gleicher Version (ohne eigene Modifikationen) zu vergleichen, und so relativ schnell zumindest alle Objektmodifikationen zu finden.
Daraus dann eine stimmige Dokumentation mit Funktionsbeschreibung zu machen ist ja wieder eine andere Sache. Aber mir wäre schon sehr geholfen erst mal alle Anpassungen aufzuspüren.

Und hat der OMA auch Funktionen die bei der Erstellung einer Doku unterstützen?

Danke und Gruß
Rolf

OMA kann pro NAV-Objekt eine Historie verwalten, in dieser Historie makiert man dann 2 Posten und ruft aus OMA eine separates 2-Weg Compare Tool auf, wo diese Versionen dann gezielt verglichen werden können. Das erleichtert die Arbeit schon enorm.

In deinem Fall würde ich aber erst mal einen 3-Weg-Vergleich machen (Open Source Möglichkeit : KDiff3, die Versionen aufbauen wie seinerzeit beim NAV DevToolkit bzw. wie hier beschrieben). Nur mit 3-Weg- findet man alles im Bezug zu den Basisversionen (auch die Sachen die da ggf. nicht hingehören).

Ja die OMA kann das (wir nennen es liebevoll DIE Oma ;) ). OMA kann 2 verschiedene Datenbanken abgleichen (leider nur den Objektheader ...)

Alternativ kann man aber auch einfach jedes Objekt exportieren, mit dem Object Splitter von Carsten splitten und mit einer Vergleichssoftware gegenüberstellen (kostet dann nicht ganz so viel). Das ist genauer und sinnvoller.

Zu den Dokumentationen: Was genau verstehst du unter Doku? Nur den Doku-Trigger? Was erwartest du?

@Kowa
3-Wege-Vergleich? Wenn ich ein Objekt gegen ein Referenzobjekt vergleiche, hab ich doch alle Änderungen, oder stell ich mir das zu einfach vor.
Was genau verstehst du unter einem 3-Wege-Vergleich. Was wäre die dritte Instanz gegen die geprüft wird?

@Sebastian
du schreibst, beim abgleich zweier Datenbanken werden nur die Objektheader verglichen. Was genau kann ich mir darunter vorstellen?
Das mit dem Export in eine Textdatei und Vergleich mit einem Diff-Tool ist das was ich aktuell grade mache. Damit sehe ich alle Änderungen aber ich muß halt jedes Objekt manuell exportieren.
Den Object Splitter muß ich mir mal anschauen. Wo find ich den am schnellsten? Hier im Board?

Bzgl. Doku
Ich gehe normalerweise eigentlich so vor, dass ich alle Anpassungen klassifiziere.
Also erst mal einen aussagekräftigen Titel für die Anpassung und eine Änderungsnummer, und je nach Komplexität eine Ausführliche Beschreibung, in denen die Abläufe und Zusammenhänge erklärt sind-
Dazu noch eine Objektliste alle Objekte die dazu modifiziert wurden.
In den Objekten selbst gibts dann im Doku-Trigger eine entsprechende Rubrik für jede Anpassung mit Titel und Nummer der Anpassung und der Auflistung was in dem Objekt gemacht wurde.
Z.b. Neues Feld "xyz" eingefügt oder Code in Funktion "abc" oder in Feld-"OnValidate" eingefügt.
Der C/AL-Code wird dann auch noch entsprechend markiert, so dass klar ist, zu welcher Anpassung er gehört.

Ich denke das ist soweit Standard, oder sollte es sein.

Nur habe ich hier eine Datenbank, in der Jahrelang programmiert und das alles nicht gemacht wurde.

Ich erwarte nicht dass ein Tool wie OMA das alles automatisch macht, das geht ja auch gar nicht.
Aber gibts dort vielleicht die Möglichkeit solche Dokumentationen, zumindest was Name oder Nummerierung der Änderung, Objektliste und ne kurze Beschreibung angeht, zu pflegen?
Dann hätte man alles an einem "Fleck".

@Kowa
3-Wege-Vergleich? Wenn ich ein Objekt gegen ein Referenzobjekt vergleiche, hab ich doch alle Änderungen, oder stell ich mir das zu einfach vor.
Was genau verstehst du unter einem 3-Wege-Vergleich. Was wäre die dritte Instanz gegen die geprüft wird?

Die drei Wege:

• NAV4-Standard
• NAV4 mit Anpassungen
• NAV2009-Standard

@Sebastian
du schreibst, beim abgleich zweier Datenbanken werden nur die Objektheader verglichen. Was genau kann ich mir darunter vorstellen?
Das mit dem Export in eine Textdatei und Vergleich mit einem Diff-Tool ist das was ich aktuell grade mache. Damit sehe ich alle Änderungen aber ich muß halt jedes Objekt manuell exportieren.
Den Object Splitter muß ich mir mal anschauen. Wo find ich den am schnellsten? Hier im Board?

Es wird Versionsliste, Name, Änderungsdatum etc. verglichen. Jedoch nicht der "BLOB-Wert" der beiden Objekte.

Was die Doku angeht: Ja, da kann die OMA dich unterstützen. Es gibt Projekte in denen quasi alle deine Änderungen "assignt" werden. Alle modifizierte Objekte werden dort angehangen. Der Dokutrigger kann automatisch erstellt werden und die Versionsliste kann hochgezählt werden.

Hallo,

NavObjSplitter findest du hier

Zum 3-Fach Merge findest du hier ein Beispiel wie man es mit ecmerge abwickeln könnte.

ein Diff3- Tool verwendet man nicht um die Differenzen herauszufinden, sondern um auf eine neue Version zu aktualisieren.
Dazu benötigt man eine Basis-Version, die sowohl für die eigene gerade verwendete Kundenversion als auch für die neu einzuführenden Ziel- Version die Basis war. Je dichter die Basis- Version an den beiden anderen Versionen dran ist, desto geringer ist der Merge- Aufwand, d.h. ein Merge zwischen NAV3.0 als Basisversion, NAV 4 als Kundenversion und NAV2009 als Zielversion würde zwar funktionieren, einfacher wird es aber mit einer Standard NAV4- DB von der Installations- CD und den beiden anderen Versionen. Noch besser funktioniert es, wenn ihr eine Branchenlösung einsetzt und du hast die jeweiligen Grundversionen der Brachenlösungen.

Gruß, Fiddi

@Kowa
3-Wege-Vergleich? Wenn ich ein Objekt gegen ein Referenzobjekt vergleiche, hab ich doch alle Änderungen, oder stell ich mir das zu einfach vor.
Was genau verstehst du unter einem 3-Wege-Vergleich. Was wäre die dritte Instanz gegen die geprüft wird?

Die drei Wege:

• NAV4-Standard
• NAV4 mit Anpassungen
• NAV2009-Standard

Genau. Mit "NAV4 mit Anpassungen" wird ja aktuell gearbeitet. Wenn damit aber nicht begonnen wurde, sondern die auch schon ein Upgrade aus z.B. Version 3 war, dann kann dort noch Code aus Version 3 enthalten sein, wenn beim damaligen Upgrade nicht alles 100%ig richtig gemergt wurde. Solche falschen Codezeilen findet man nur im 3-Wege durch den Vergleich gegen eine saubere(!) Basis, aber nicht im 2-Wege.

Nochmal das (grobe) Vorgehen:

• Export aller Objekte (die drei genannten Datenbanken)
• Vergleich 4.00 mit 4.00 (modified)
• 3-Wege-Merge der unterschiedlichen Objekte (aus vorherigem Schritt)

Nochmal das (grobe) Vorgehen:

Export aller Objekte (die drei genannten Datenbanken)
Vergleich 4.00 mit 4.00 (modified)
3-Wege-Merge der unterschiedlichen Objekte (aus vorherigem Schritt)

Es findet nicht zunächst ein Vergleich zwischen 4.00 und 4.00 (modified) statt und danach ein 3-Wege-Merge, sondern es findet ein Diff3 zwischen den 3 Versionen statt, der gleichzeitig zum Merge genutzt wird.

Gruß. Fiddi

Erst mal vielen Dank an alle.
Das OMA klingt wirklich gut, einziger Haken ist, dass ich als "Endkunde" fast den doppelten Preis zahlen muß als ein NAV Partner.
Wobei mir bisher keiner schlüssig erklären konnte warum, aber das ist ein anderes Thema.

Das mit dem 3-Wege hab ich jetzt auch kappiert.
Wir arbeiten mit einer Brachenlösung und ich hab die Basisversionen davon, sowohl in der aktuellen als auch in der Zielversion.

Die größte Herausforderung ist aber nicht nur das finden der Modifikationen sondern auch das wiederherstellen der Zusammenhänge, und das herausfinden des Warum und Wieso um dann auch eine vernünftige Doku zu haben.
Aber auch das ist ein anderes Thema ...

Es findet nicht zunächst ein Vergleich zwischen 4.00 und 4.00 (modified) statt und danach ein 3-Wege-Merge, sondern es findet ein Diff3 zwischen den 3 Versionen statt, der gleichzeitig zum Merge genutzt wird.

Naja, wie mans macht. Ich finde es so schöner, dann hat man nur noch die zu ändernden Objekte übrig. Wenn sich von 4.00 (Standard) auf 4.00 (Modifiziert) sich nichts geändert hat, dann muss das Objekt (im Regelfall) auch nicht für den Upgrade angepasst werden (auch wenn Unterschiede von 4.00 auf 2009 vorhanden sind).

Naja, wie mans macht. Ich finde es so schöner, dann hat man nur noch die zu ändernden Objekte übrig. Wenn sich von 4.00 (Standard) auf 4.00 (Modifiziert) sich nichts geändert hat, dann muss das Objekt (im Regelfall) auch nicht für den Upgrade angepasst werden (auch wenn Unterschiede von 4.00 auf 2009 vorhanden sind).

Das sehe ich genauso, aber ein gutes Mergetool erledigt das in einem Arbeitsgang

Es könnte ja auch Objekte geben, die zwischen Kundenversion und neuer Version identisch sind, weil man Sie schon früher aus 2009 eingebaut hat. (z.B. autentifizierte SMTP-Mail), auch die kann man so in eine Zielversion kopieren.

Gruß, Fiddi

Die größte Herausforderung ist aber nicht nur das finden der Modifikationen sondern auch das wiederherstellen der Zusammenhänge, und das herausfinden des Warum und Wieso um dann auch eine vernünftige Doku zu haben.
Aber auch das ist ein anderes Thema ...

Aber das allerwichtigste, hinter dem "Warum und Wieso" dieser Abweichungen sind die betrieblichen Prozesse verschlüsselt, und die müssen klar zu Tage treten. Es ist ohne eine aktuelle Doku leider immer sehr schwierig, aus den Codefragmenten einen Prozess zu erkennen, wenn den keiner ausformuliert hat.

Auf jeden Fall wird das eine schöne Aufgabe :D
Wir sind aktuell bei Version 3.70 (technisch 4.0 SP3) und 2009 könnte schon zur Herkulesaufgabe werden (nicht zu sprechen von 2013).

kleiner Tipp noch
Für einen (Diff3-) Merge exportiert man die Text-Objekte möglichst mit dem gleichen Client aus dem gleichen Dabenbanktyp, also z.B. aus einer NAV 2009 Buid XXXX -SQL.DB die man für jeden Objekt-Satz aus den FOBs erstellt hat. Dann hat man einigermaßen die Gewähr, das nicht unterschiedliche Clinet- Versionen (teilweise sogar auf Build-Ebene) unterschiedliche Textausgaben produzieren, die Diffs produzieren, wo eigentlich gar keine sind.

Gruß, Fiddi

@Kowa
Ja das Herausfinden der Zusammenhänge und Prozess und diese dann auszuformulieren ist die eigentlich essenzielle Aufgabe, ganz klar.


@Sebastian
wenn Ihr noch auf 3.70 seit, wie hast du das Thema SEPA und neue ZM Meldung gelöst?

@fiddi
danke für den Tipp mit den Client Versionen. Aber das mach ich immer so, dass ich für die Exporte der Objekte immer eine einheitliche Version nutze.
Eben weil verschiedene Versionen, unterschiedliche Exportformate produzieren.

Aus dem Compare Databases kann man beide Seiten als Text exportieren.

Es gibt auch Spalten in der Liste, die zeigen, welche Objekte geändert/unterschiedlich sind. Darauf filtern und links und rechts exportieren. Entweder Single-File oder gesplittet (vom OMA).

Beim Upgrade geht es aber natürlich nicht nur stumpf um einen Merge. Man muss auch schon prüfen, ob sich neue Anpassungen mit den alten nicht beissen oder komplett überflüssig geworden sind. (insb. Funktionalitäten die man selbst reinprogrammiert hat, welche aber schon im Standard gibt, aber es nicht besser wusste.)

Soweit ich weiß gibt es OMA in verschiedenen Ausführungen, basierend auf Deinen Entwickler-Granules. Wenn ihr Solution Developer habt, zahlt ihr einen sehr hohen Preis im Vergleich wenn ihr "nur" einen Application Builder habt.

Ich persönlich würde ja dazu raten, das Pferd von hinten aufzuzäumen. Bei derart alten Versionen hapert es meistens nicht nur am ERP-System.

D.h., zunächst einmal eine Bedarfsanalyse zu machen, welche Prozesse denn überhaupt im Unternehmen gefordert sind. Die kann man dann vielleicht sogar noch kategorisieren in zwingend (kritisch), notwendig (unkritisch), hilfreich und nice to have oder so ähnlich. Vorab sollte bereits mit einem (starken) Partner gesprochen werden, was man vor hat. Die Prozessanalyse kann man dann einerseits dazu nutzen, eine Prozessoptimierung im Unternehmen durchzuführen, andererseits kann man diese dem Partner vorlegen, der dann eine Art Gap/Fit-Analyse gegen den 2009er Standard machen sollte. D.h. auch, evtl. werden bestimmte Prozesse einfach über einen anderen Weg dargestellt, als es bisher der Fall war.

Der große Vorteil dieser Vorgehensweise ist, neben der Restandardisierung (Updateaufwand für folgende Versionen minimiert sich, Dokumentationsaufwand für die aktuelle Version minimiert sich, evtl. kann man auch die Wartungs- und Supportgebühren reduzieren) werden gleichzeitig auch noch die Prozesse innerhalb des Unternehmens verschlankt. Sicherlich ist der Aufwand etwas höher und es muß sehr genau geplant werden, aber am Ende hat man nicht nur sein ERP-System auf den neusten Stand gebracht, sondern auch die Arbeitsabläufe und etwaige Nebensysteme.

Ich sehe das so, bei einem derart weiten Update müssen eh sehr viele Dinge passieren (z.B. Serverlandschaft umgestalten, User neu schulen, Dokumentationen und Unterlagen aktualisieren, etc.). Warum dann nicht hier und da den Aufwand reduzieren bzw. noch etwas mehr investieren und in eine Optimierung des Unternehmens stecken?!

Wir haben folgende Entwickler Ganules in der Lizenz
7110 Report and Dataport Designer
7120 Form and Page Designer (includes 100 Pages & Forms)
7130 Table Designer
7140 XML Port Designer
7200 Application Builder
7300 Solution Developer

Aber warum das Auswirkungen auf den Preis von OMA haben soll hab ich auch schon bei iDyn nachgefragt. Eine Antwort die das wirklich erklärt habe ich aber nicht bekommen.
Dass OMA eventuell unterschiedliche Funktionen hat, je nach Lizenz, hat mir bisher keiner gesagt. Klingt aber erst mal logisch.
Ich finds nur etwas unbefriedigend, wenn der Hersteller sich da so bedeckt hält und es selber nicht wirklich erklären will oder kann.

@Sebastian
wenn Ihr noch auf 3.70 seit, wie hast du das Thema SEPA und neue ZM Meldung gelöst?

Noch gar nicht ...

Wir haben folgende Entwickler Ganules in der Lizenz
7110 Report and Dataport Designer
7120 Form and Page Designer (includes 100 Pages & Forms)
7130 Table Designer
7140 XML Port Designer
7200 Application Builder
7300 Solution Developer

Aber warum das Auswirkungen auf den Preis von OMA haben soll hab ich auch schon bei iDyn nachgefragt. Eine Antwort die das wirklich erklärt habe ich aber nicht bekommen.
Dass OMA eventuell unterschiedliche Funktionen hat, je nach Lizenz, hat mir bisher keiner gesagt. Klingt aber erst mal logisch.
Ich finds nur etwas unbefriedigend, wenn der Hersteller sich da so bedeckt hält und es selber nicht wirklich erklären will oder kann.

Die Version für den Solution Developer erlaubt auch Modifikationen vom OMA selbst. Da dies so gekoppelt ist, gibt es keine Möglichkeit zu sagen "Ich habe SD, will aber OMA gar nicht modifizieren."

Das sich das nicht trennen läßt ist klar.
Aber ob das einen Preisaufschlag von 40% rechtfertigt ist was anderes. Begründen oder erklären wollte das halt so wirklich bisher keiner bei idyn

Das sich das nicht trennen läßt ist klar.
Aber ob das einen Preisaufschlag von 40% rechtfertigt ist was anderes. Begründen oder erklären wollte das halt so wirklich bisher keiner bei idyn

Partner sind dann ja auch gerne Reseller, daher günstiger für Partner.

Ausserdem soll bei der teuren Variante auch eine kostenlose Schulung dabei sein, soweit ich weiß. (Wird aber glaube ich nicht vom Reijer durchgeführt)