[gelöst] NAV APP/ Extension anpassen

Hallo,

undzwar frage ich mich ob und wie ich eine Extension anpassen kann.
Ich habe "Extension A" diese erweitert die Tabelle 18 (Customer) um 2 Felder.
Die "Extension A" ist mein Branchen Modul.
Nun möchte ein Kunde das in der Tabelle 18 ein weiteres Feld hinzugefügt wird in dem sich die Summe der beiden Feldern befindet.
In der Theorie würde ich nun eine weitere Extension erstellen, welche auf die beiden Felder zugreift.
In der Praxis sind die Felder aber überhaupt nicht zugreifbar.
Ich weiß jetzt nicht wie ich auf die Daten/Felder meiner Extension zugreifen soll..
Gibt es dafür eventuell eine magische "GetNavAppData"-Funktion die ich übersehen habe?
Mit den beiden Funktionen GETARCHIVERECORDREF und GETARCHIVEVERSION kann ich an dieser Stelle nichts anfangen.

Ein anderer Ansatzpunkt wäre die Extension anzupassen, hier müsste ich jedoch für jede Kunden Anpassung mein Branchenmodul "Extension A" neuinstallieren.
Ich bin mir nicht sicher ob das Sinn und Zweck ist..

Vielleicht kann mir da jemand auf die Sprünge helfen

Zuletzt geändert von b.denger am 20. Mai 2016 08:44, insgesamt 1-mal geändert.

...Ein anderer Ansatzpunkt wäre die Extension anzupassen, hier müsste ich jedoch für jede Kunden Anpassung mein Branchenmodul "Extension A" neuinstallieren.
Ich bin mir nicht sicher ob das Sinn und Zweck ist..

Vielleicht kann mir da jemand auf die Sprünge helfen

Meiner bescheidenen Meinung nach, ist das so gedacht.

Interessantes Problem dass zeigt dass die Extensions Logik noch nicht völlig durchdacht ist seitens Microsoft - bzw. einige praxisrelevante Punkte damit überhaupt nicht abbildbar sind.

Ich sehe das nicht als Problem. Die Extensions waren von Beginn an dafür gedacht, einfache Erweiterungen bereitzustellen. Einfach und für jeden Tenant unterschiedlich. Da muss man einfach momentan noch Einschränkungen hinnehmen. Ob das besser wird, weiß ich nicht.

Unter folgendem Link sind die Einschränkungen dargestellt.

...
Die "Extension A" ist mein Branchen Modul.
...

Vielleicht hast du das Konzept der Extension falsch verstanden? Die Extensions sind dafür gedacht, den Tenants einfache Erweiterungen zur Verfügung zu stellen, die sie verwenden (installieren) können oder nicht. Ähnlich zu Firefox Plugins. Eine Änderung an der Extension betrifft immer alle Installationen der Ext. Möchtest du grundlegende Änderungen einer globalen Datenbank vornehmen, welche alle deine Tenants betrifft, ist ein Branchenmodul im herkömmlichen Sinne sinnvoller.

Da gab es tatsächlich leichte Verständnisschwierigkeiten.
Also um das ganze nochmal zu wiederholen:
Ich habe meinen NAV-Standard
Dazu kommt mein Branchenmodul auf traditionelle Art in die DB
Dieses sollte dann nicht mehr auf Standardobjekte greifen, sondern in abgekapselten Codeunits mit Events arbeiten.
Somit hätte ich 2 Bereiche die nicht direkt ineinander greifen(also keine Anpassungen mehr an Standardobjekten)
Kundenanpassungen werden dann nur noch über Extensions realisiert, sodass ein Update schlussendlich "kaum" Mergeaufwand mehr mit sich zieht.
Dieses Prinzip lässt sich etwas leichter verstehen
Danke für die Hilfe

Hi,

ich verstehe Extensions anders! Extensions sind wirklich total abgrenzbare Bereiche, die nicht mehr nachher verändert werden sollen. Wenn du nun Kundenanpassungen als Extension veröffentlichen willst, dann musst du eben die Extension anpassen. Das ist nicht zu ändern.

Mir persönlich ist der Aufwand dafür zu hoch. Extension haben einen klaren Produktfokus. Du kannst ja in NAV 2016 schon viel mit Eventing lösen und cleveren Auslagern von Code.

Aber sind wir mal ehrlich: Wenn man eine angepasste Dynamics NAV ordentlich, gewissenhaft, gewissen Regeln anpasst und regelmäßig die kumulative Updates einbaut, dann hat man vom reinen Mergeaufwand von NAV zu NAV Version nur die neuen Features die dazugekommen sind. Dafür liefert Microsoft doch die Rapid Start Code Integration mit den Merge/Update Befehlen.

Extensions sind mehr für Produkte gedacht, die man problemlos auf den verschiedensten Tenants installieren kann.

VG
Robert

Hi,

ich verstehe Extensions anders! Extensions sind wirklich total abgrenzbare Bereiche, die nicht mehr nachher verändert werden sollen. Wenn du nun Kundenanpassungen als Extension veröffentlichen willst, dann musst du eben die Extension anpassen. Das ist nicht zu ändern.

Was spricht denn aber dagegen?
Ich finde es praktikabler das modul ganz normal als fob auszuliefern und dann nur die individuellen Anpassungen als Extension zu veröffentlichen.
Vorteil hier ist eben das ich mein Modul nicht Anpassen und gegebenenfalls mergen muss.

Aber sind wir mal ehrlich: Wenn man eine angepasste Dynamics NAV ordentlich, gewissenhaft, gewissen Regeln anpasst und regelmäßig die kumulative Updates einbaut, dann hat man vom reinen Mergeaufwand von NAV zu NAV Version nur die neuen Features die dazugekommen sind. Dafür liefert Microsoft doch die Rapid Start Code Integration mit den Merge/Update Befehlen.

Wir Mergen noch manuell und nutzen so gut wie nie den Merge Befehl beim import.

Klar, mit Events lässt sich alles super kapseln und strukturieren.
Wenn ein Kunde jedoch aufgrund seiner Geschäftsprozesse zusätzliche Felder an einer Tabelle benötigt, müsste ich zwangsweise die Tabelle anpassen.
Die Extensions vermeiden diese direkten Anpassungen an den Objekten nunmal..

Wir Mergen noch manuell und nutzen so gut wie nie den Merge Befehl beim import.

Die Option "Merge: Existing->New" beim Import ist nur dazu da, mit einer Fob-Datei neue Felder in Tabellen anzulegen, die außerhalb vom eigenen Lizenzbereich liegen.
Das ist Textformat nicht möglich. Teilweise klappt das auch nur, wenn die Tabellentrigger komplett vom Code befreit wurden, und anschließend muss dieses mit der Textdatei wieder nachgemergt werden. Mit den sonstigen Erfordernissen des Codemergens hat das nichts zu tun.
Automatisch mit Cmdlets mergen und das Endergebnis vergleichen geht in der Regel viel schneller und auch fehlerfreier als alles per Hand zu machen.