Vorhandene Funktion mit Extension ändern

Hallo zusammen,

in einer alten NAV-Version wurden einige Dinge direkt in den vorhandenen Funktionen im Code geändert, z.B. in der Funktion InitRecord() der Tabelle 36.

Bei der Migration auf BC stellt sich die Frage, wie man das mit einer Extension nachstellen kann. Bisher haben wir keinen Weg gefunden und bei der Suche im Forum wurde ich auch nicht fündig.

Ist das möglich?
Kann man ggf. die komplette InitRecord()-Funktion in der Extension nachschreiben und "überdeckt" damit die Funktion aus dem Originalobjekt?
Oder gibt es ggf. OnBefore- oder OnAfter-Trigger für solche Funktionen, so dass man damit auf eine eigene Funktion springen kann?
Oder gibt es einen anderen Vorschlag, wie man mit solchen bisherigen Anpassungen umgehen soll?

Danke :)

Welche Änderungen möchtet ihr denn machen? Wenn es um Felder geht, welche vor dem Einfügen gefüllt werden sollen, dann ist OnBeforeInsert dein Freund.

OnBeforeInitRecord wurde schon in 2019 für Tabelle 36 angefordert und von MS angenommen.
https://github.com/microsoft/ALAppExtensions/issues/1025
Funktioniert damit etwas nicht?

Danke schon mal für die Tipps. Für den konkreten Fall hilft das evtl. schon.

Wir haben allerdings noch mehr solcher Stellen vor uns und daher geht es mir auch um das allgemeine Verständnis, wie damit grundsätzlich umgegangen werden soll.

Ausgehend von Euren Antworten verstehe ich es jetzt so:

Direkt in den "internen" Funktionen kann man nichts machen, man kann nur schauen, ob es dafür einen Trigger "in der Nähe" (z.B. OnBeforeInsert) gibt und ob man die Änderung dahin verschieben kann.

Es gibt "EventRequests", mit denen man sich Funktionsaufrufe an den gewünschten Stellen in den "internen" Funktionen wünschen kann und diese werden dann (evtl.) von Microsoft eingebaut. Siehe: https://github.com/microsoft/ALAppExten ... nt-request

Stimmt das so?

Gibt es irgendwo mehr Infos zum Vorgehen für Event Request? Kann die jeder stellen?

On Prem kannst du die Base App auch ändern, wenn du willst. Wenn der Kunde aber erst neu nach BC migriert dann muss er dafür hohe Strafzahlungen leisten, weil dein Code dann ja nicht Cloud-tauglich ist. Ansonsten kannst du an vielen Stellen den Microsoft Code abschalten, wenn es an der Stelle, wo du was anders lösen willst, eine "IsHandled" Logik und entsprechende Event Publisher gibt, mit denen du arbeiten kannst. Du erstellst dann einen Event Subscriber mit deinem Code und setzt IsHandled:=true, damit der Microsoft Code nicht durchlaufen wird. Fehlende Stellen kannst du bei Microsoft melden, dann bauen die dir das ein, sofern sie deine Begründung anerkennen. Das kann dann aber etwas dauern.

Gibt es irgendwo mehr Infos zum Vorgehen für Event Request? Kann die jeder stellen?

Jeder mit einem GitHub-Account , weitere Hinweise hier.

Hallo zusammen,

vielen Dank schon mal für die bisherigen Antworten.

Über einen Punkt bin ich gerade gestolpert, das: "wenn der Kunde aber erst neu nach BC migriert dann muss er dafür hohe Strafzahlungen leisten".

Der Kunde hat aktuell noch NAV und wir würden diese Tage die Migration zu BC on prem durchführen.

In der Preisliste eines anderen Kunden habe ich die Positionen "Implemented code is not cloud-optimized" und "Implemented code is not in extensions" per named user gefunden. Ist das mit den Strafzahlungen gemeint?
Wenn diese Module nicht gekauft werden, hat das dann reale technische Auswirkungen? Also wird der Code dann u.U. geblockt?

Microsoft macht es einem aber auch gerne immer schwerer.

In der Preisliste eines anderen Kunden habe ich die Positionen "Implemented code is not cloud-optimized" und "Implemented code is not in extensions" per named user gefunden. Ist das mit den Strafzahlungen gemeint? Wenn diese Module nicht gekauft werden, hat das dann reale technische Auswirkungen? Also wird der Code dann u.U. geblockt?

Genau. Wenn der Code nicht Cloud/SaaS-tauglich ist dann muss der Kunde entsprechende Module lizensieren und bezahlen, in diesen beiden Kategorien.

Also wird der Code dann u.U. geblockt?

Das ganze System kann dann nicht benutzt werden, weil die Lizenz nicht korrekt erstellt wurde.
Details hier bzw. https://aka.ms/BCUniversalCode

Microsoft macht es einem aber auch gerne immer schwerer.

ACHTUNG - folgende Aussagen sind meine Meinung und können für viele verstörend oder verletzend sein!

Ich möchte nicht unhöflich, arrogant oder respektlos sein, aber ihr seid doch Microsoft-Partner - im Dynamics 365 Business Central-Umfeld, richtig?
Was ich meine - wir haben 2023 und der Einsatz von Extensions ist seit NAV2016 möglich -> warum stellst du diese Fragen jetzt?
Ja damals war das noch ein "bisschen" Gefrickel und Hybrid-Dev ist/war auch nicht immer das Wahre, ABER man hatte seit NAV 2016 Zeit, sich eingehend
mit der Materie auseinander zu setzen.

Das MS "natürlich" seine Cloud-Strategie verfolgt und "mittlerweile" auch OnPrem cloudfähig programmiert werden muss, ist vielen ein Dorn im Auge,
da man ja nun den über Jahre und Jahrzehnte geliebten Quellcode mal überarbeiten und andere Techniken einsetzen muss - willkommen in 2023 (eigentlich könnte hier auch eine wesentlich kleiner Jahreszahl als 2023 stehen!)!

Am besten gefällt mir die Strategie einiger Partner, ihre "alte" Lösung durch den Schlauch (Konverter) zu jagen und dann zu sagen - "yo, wir können auch BC15++"
Ich hab genug Lösungen gesehen, bei denen das gemacht wurde und bekomm weiterhin Kotzkrämpfe davon (sorry für die Ausdrucksweise).

Wenn MS die Thematik mit der Cloudfähigkeit in Zusammenhang mit den Strafzahlungen nicht eingeführt hätte, würden es immer so weiter gehen und der bisher verwendete
Quellcode in den Lösungen nicht einmal geprüft und optimiert werden.

Hallo,

auch wenn ich dir eigentlich recht gebe, und mir manchmal auch danach ist (manche programmieren in AL wie in NAV2, und haben außer der Programmiersprache nichts dazu gelernt (JSON was ist das?, da ist eine Textdatei die ich verarbeiten muss))

Aber leider hat auch BC einiges verlernt, was NAV hervorragend konnte, und BC damit performancemäßig immer noch ins Hintertreffen bringt.

Außerdem gibt es bei unseren Kunden externe Systeme, auf die wir keinen Einfluss haben (auch unsere Kunden nicht).
Für die benötigen wir auch alte Schnittstellen nötige Schnittstellen SDKs. Auch aktuelle Funktionalität kann BC nicht aus dem Karton bedienen, z.B. ein Etikettendrucker der RFID- Etiketten bearbeitet, und die gerade bearbeitete RFID- ID an den druckenden Prozess zurückschicken möchte, weil der damit was anstellt, z.B. die Daten auf das Etikett drucken.

So gerne ich alte Technologie abschalten möchte, solange kein adäquater Ersatz da ist, darf das eigentlich nicht passieren.

Gruß fiddi