Navision Upgrade Strategie (Objekte)

Hallo,
wir sind gerade dabei BC14 (RTC) auf BC23 zu bringen.
Nun haben wir relativ viel in den Standard Objekte angepasst.
Bei ca. 130 Tabellen, 240 Pages, 35 Reports und 50 Codeunits wurden Anpassungen durchgeführt.
Nun müssen diese Anpassungen ja heraus genommen werden.

Meine Frage wäre nun wo sollte ich den Code für die Event Programmierung hingeben.
z.B. Tabelle Sales Line haben wir Felder (Table Extension) und auch Code in den verschiedenstes Triggern bzw. OnValidate hinzugefügt.
Sollte ich hier eine eigene Codeunit machen, welche nur den Code für diese Tabellenanpassungen beinhaltet oder sollte ich eine Codeunit Verkauf machen, welche alle Anpassungen für den Verkauf beinhaltet.

Wie sollte man das am besten strukturieren bzw. wie habt ihr das gemacht. Und ich müsste meine Lizenz um die Anzahl der Codeunits erweitern, was natürlich zusätzliche Kosten verursachen würde.

lg
stony

naja, also es kommt darauf an - den einen richtigen Weg gibt es vermutlich nicht.

wir haben das zum Beispiel in Bereiche unterteilt - sprich Sales, Purchase, Finance etc.
in Kundenanpassungsapps, die wir bereits unter BC14 im Umlauf haben/hatten, haben wir das leider nicht gemacht - die werden mit der Zeit aber überarbeitet, sodass wir da auch Bereiche haben.

Sobald du von anderen Modulen außer MS abhängig bist, kannst du auch überlegen, dafür eine eigenständige App zu generieren.
Sagen wir mal ne DMS-App, erweiterst du diese dann, dann würde ich die Erweiterung (wenn möglich) in eine eigene App schießen und nicht in deine "Base" schreiben - kann ja sein, dass ihr die DMS-App nicht mehr nutzen wollt oder die nicht mehr funktioniert, dann funktioniert dafür aber weiterhin eure eigene "Base" noch.

Du kannst auch für jeden Bereich eine eigene App bauen - Sales-App, Purchase-App....etc ABER das wird sehr schnell sehr kleinteilig - also würde ich das nicht unbedingt empfehlen.
Man muss tatsächlich ein bisschen darauf "herumhirnen" - einen Plan erstellen, nochmal nachdenken, Plan anpassen und dann feuer^^

In unserer BC14-Datenbank hatten wir auch unterschiedliche Apps für die unterschiedlichen "Module" gebaut.
In der Theorie super, doch dann stellt man in der Praxis sehr schnell fest, dass die Individual-App "MySCM" auf Erweiterungen aus "MyFinance" und "MyBase" zugreifen muss.
"MyFinance" greift ebenfalls auf "MyBase" zu.
Wenn wir jetzt etwas in "MyBase" ergänzen/ändern, ist der Roll-out sehr umständlich, da wir zuvor die davon abhängigen Apps "MySCM" und anschließend "MyFinance" deinstallieren müssen, um sie nach dem Update der "MyBase" wieder zu installieren.

In unserem nächsten BC-Projekt (nächstes oder übernächstes Jahr) werden wir daher pro Datenbank (länderspezifisch) nur noch eine einzige App erstellen.
App-übergreifende Funktionalitäten unserer bisherigen "MyBase" werden wir zwar in einem eigenen VSCode-Projekt entwickeln, jedoch nicht publischen, sondern den Source Code in den Source Code der datenbank-spezifischen App mergen.

Meine Idee wäre mit möglichst wenigen Apps/Extensions auszukommen. So separat sind die Bereiche oder Module, die man gern trennen würde, i. d. R. doch nicht, so dass man immer wieder Über-Kreuz-Beziehungen haben wird. Früher hätte ich gesagt dass ich auf jeden Fall eine Base App mache in der aber alle Table Extensions drin sind, so dass man nicht mehr als eine Table Extension pro Source Table hat. Das ist aber heute nicht mehr so wichtig ist seit die Table Extensions auf SQL Ebene nicht mehr separiert werden. Ansonsten ist vieles Philosophiefrage und On Premise auch eine Preisfrage, z. B. wie viele Codeunits man für Event Subscriber verbraten will - Codeunits sind ja teuer.

Wir haben 3 Apps erstellt.

Eine mit Tabellen (Extensions) / Pages / Enums /Querys und ein paar allgemeinen Codeunites

eine für Reports
und eine für den Rest (Codeunits/pageextensions und XML Ports)
Aus die Weise müssen wir nicht bei jedem Feld das hinzugefügt wird immer alle Dienste neu starten.

Aber ich denke, DIE Lösung gibt es nicht, da muss jeder seinen Weg finden

Gruß Frank

Wenn wir jetzt etwas in "MyBase" ergänzen/ändern, ist der Roll-out sehr umständlich, da wir zuvor die davon abhängigen Apps "MySCM" und anschließend "MyFinance" deinstallieren müssen, um sie nach dem Update der "MyBase" wieder zu installieren.

ja, aber die deinstalliert ihr ja nicht von Hand, oder?
Wir haben Scripte, die die Abhängigkeiten auflösen, die notwendigen Apps deinstallieren und die neue Version reinbügeln - alle deinstallierten abh. Apps werden dann autom. nachinstalliert.
Somit sollte das kein Problem darstellen

Hallo,

ja, aber die deinstalliert ihr ja nicht von Hand, oder?

Selbst wenn, wer eine wirklich integrierte Lösung wie Timo hat, bei der nahezu alle Bereiche auf andere zugreifen müssen. dann nervt dieses App-deinstallieren und installieren bei Updates einfach nur.
Wenn du dann auch ein paar mehr Apps im System hast, die dann plötzlich auch aktualisiert werden wollen, weil Sie eine Abhängigkeit haben, dann dauert das u.U. sehr lange.

Gruß Fiddi

Wenn du dann auch ein paar mehr Apps im System hast, die dann plötzlich auch aktualisiert werden wollen, weil Sie eine Abhängigkeit haben, dann dauert das u.U. sehr lange.

ja klar - wir haben 28 Apps....frag nicht warum (fassen gerade wieder welche zusammen) - aber lange dauert ein Update (sofern von uns kein dramatischer UpdateCode angesprochen wird) nicht - vielleicht maximal 5 Minuten (wie gesagt, ohne UpdateCodeunits)

Hallo,

aber lange dauert ein Update (sofern von uns kein dramatischer UpdateCode angesprochen wird) nicht - vielleicht maximal 5 Minuten (wie gesagt, ohne UpdateCodeunits)

Sorry, bin anderes gewohnt. 5 Minuten um einen Schreibfehler zu korrigieren, sind schon ein wenig lang.

Gruß Fiddi

hehe, da Laufen unsere Pipelines länger.
klar vohrer in der DEV-DB müssen alle abh. Apps raus und als DEV gepublished werden - das dauert defintiv länger und nervt maximal, da bin ich bei dir