[RTC][WC] Extension - Wo/Wie werden Daten gespeichert?

Hi und Guten Morgen,

ich versuche gerade

Building Your First Sample Extension With Extension Objects, Install Code, and Upgrade Code

Building an Advanced Sample Extension

Mal abgesehen davon dass ich noch nicht weiß wie ich das ganze im Visual Studio Code organisieren soll...

Code:

pageextension 50106 "Customer Card Ext" extends "Customer Card"
{
    layout
    {   
        addafter(Name)
        {

            field(RewardPoints; RewardPoints)
            {

1. Was passiert wenn ich eine andere Extension entwickle, bzw. man eine Extension von jemand anderes bekommt der auch addAfter(Name) drin stehen hat.
Würde das dann vor oder nach meinem Feld platziert?

2. Wo werden die "Physikalischen" Daten gespeichert? Ich dachte zumindest Tabellen Objekte würden angelegt, wenn bei der Extension aus dem Beispiel oben, die User die Level /Bonus Stufen pflegen,
und diese nun Exportiert werden sollen, wie ginge das dann?

Danke

1. Was passiert wenn ich eine andere Extension entwickle, bzw. man eine Extension von jemand anderes bekommt der auch addAfter(Name) drin stehen hat.
Würde das dann vor oder nach meinem Feld platziert?

Das kommt darauf an, welche Extension zuerst geladen wird (wovon das wiederum abhängig ist, weiß ich nicht).
Du hast ein Standardfeld (für AddAfter), ExtensionA mit Feld A, ExtensionB mit Feld B.
A wird zuerst geladen. Wir sehen Standardfeld - A.
B wird geladen und platziert sich hinter das Standardfeld. Wir sehen also Standardfeld - B - A.

2. Wo werden die "Physikalischen" Daten gespeichert?

Als zusätzliche Tabellen mit automatischer Verknüpfung zur Standardtabelle, welche du nur auf dem SQL-Server siehst:
https://www.hougaard.com/new-database-l ... xtensions/

Alles was du nun liest sind meine eigenen Erfahrungen die ich mit 2018 und AL gemacht habe, ich kann dir nicht sagen ob es genau SO gemacht werden sollte, für das Unternehmen für welches ich arbeite hat es bisher aber gepasst :)

Erst einmal wichtig:
Geb allen Objekten und extendet Tabellen/Page Feldern und auch Gruppen ein Prefix!
Dies verhindert, dass du Namenskonflikte mit anderen Extensions oder der Baseapplication hast.
Hier mal nen Beispiel von mir:

Code:

tableextension 61290 "IN-GST Vendor" extends Vendor
{
    fields
    {
        field(61200;"IN-GST GSTIN";Code[15]) {
            Caption = 'GSTIN';
        }
    }
   
}


Die erste Frage kann ich nicht beantworten, hab ich noch nicht drauf geachtet.

Zu deiner 2. Fragen
Die Daten werden physikalisch ganz normal in der Datenbank gespeichert. Nur bei TableExtension laeuft es nun Datenbankseitig etwas anders. Die Felder werden nicht mehr in der bestehenden SQL Tabelle hinzugefügt sondern eine neue Tabelle angelegt.

Um die Daten zu exportieren hast du mehrere Möglichkeiten:
a) Rapidstart (mag ich nicht :D)
b) Nen XML Port
c) Ne Liste mit CTRL + E
Wenn ich mich recht erinnere, gibt es in der DEV Preview auch schon die Möglichkeit im Webclient die Tabelle direkt über ne URL aufzurufen.


Strukturierung ist Geschmacks- und/oder Philosophiesache. Ich hab bei uns am Anfang einfach ne Struktur festgelegt und dies ziehen wir nun durch. Es gibt für jeden Objekttyp nen eigenen Ordner, ich mach allerdings für extended und neue Objekte keinen Unterschied.

Hier mal wieder mein Beispiel:

Code:

Codeunit
  - 61200 Meine Codeunit.al
Page
  - 61200 Meine Tabelle List.al
  - 61201 Meine Tabelle Card.al
  - 61299 ext. Vendor.al
Table
  - 61200 Meine Tabelle.al
  - 61299 ext. Vendor.al


Extended Objekte pack ich immer ans Ende der IdRange, da man für diese Objekte im laufendem Betreiben keine Lizenz benötigt. (aber Achtung: beim Publishen der App brauchst du eine Lizenz für die Objekte )

Hallo,

danke für eure ANtworten und Erfahrungen.

Ok. Habe die Rewards Tabelle mit dem SSMS gefunden. Frage mich nun was passiert wenn jemand anderes eine Extension hat die eine Tabelle gleich benennt.
Da finde ich den Tipp mit den Prefixes für eigene Entwicklungen schonmal gut. (Wobei auch passieren kann das man gleiche Prefix und Tabellenname nimmt, wird wohl eher selten vorkommen)

Auch habe ich die Tabelle "Customer$GUID" gefunden. Wo die Felder drin welche die Tabelle Customer erweitern.
Gäbe es viele Erweiterungen auf die Tabelle Customer dann ist man aber erstmal ein wenig mit Suchen beschäftigt

Um Daten zu exportieren über Rapid Service sehe ich beim Customer nicht die erweitern Felder um diese exportien zu können.
Ebensowenig über XML Port?

Wenn ich mache wie in den Link den Natalie gepostet hat, aus der DEV Umgebung die Tabelle direkt aufrufen, sind die Felder beim Debitor dabei.

OK. Also Daten sind da... irgendwo ...

Angenommen, ich möchte jetzt auf diese Daten durch Codeunit oder sonstwie zugreifen. Das geht nicht?
Ich müsste also wieder eine Erweiterung programmieren welche auf die Daten der anderen erweiterung zugreift?

Grundsätzlich frage ich mich gerade allerdings wann sollte ich eine Erweiterung programmieren und wann "normal" programmieren wie immer.
Also, Ich hätte ja auch die Tabelle Customer ändern können , erweitern um die 2 Felder, Neue Tabelle Rewards anlegen können, und mein programmiercode irgendwo unterbringen.

Wahrscheinlich kann man dann auch mit WebServices nicht auf solche von Extensions erstellen Tabellen und erweiterte Felder zugreifen?

Verzeiht mir mein Unwissen, muss mir alles selber beibringen, ich bin da etwas langsam

Mit der Strukturierung muss ich nochmal schauen, ich weiß ja auch noch nicht was da irgendwann mal kommt, habe momentan ein Arbeitsbereich in VS Code eingerichtet, mit Unterordner wo in jedem ein Projekt (erweiterung) drin ist, damit ich den "kompletten strang" in ein repository ins Github schieben kann.

Da weiß ich jetzt auch nicht ob man da lieber mehrere Projekte /Ordner erstellt, oder ob man alles in einem macht, und die Erweiterung dann "MeineFirmaErweiterungen" nennt, und da alles reinpackt was man selber programmiert.

Danke.

Prefixes:
Wenn ich das Richtig in Erinnerung habe müssen Partner ihr Prefix bei Microsoft beantragen, so wird verhindert das sie sich gegenseitig in die Quere kommen.
Microsoft hatte dazu auch mal nen Artikel veröffentlicht: https://docs.microsoft.com/de-de/dynamics-nav/compliance/apptest-prefix-suffix
Wir selbst nutzen "xxx-yy" wobei x = 3 Buchstaben ausm Firmennamen und y = 2 Buchstaben fürs Modul sind.

Daten/Felder Zugriff:
Rapidstart:
Ich hab am anfang genau das selbe gedacht. Dann hab ich das Ganze irgendwann noch einmal in ner Cornus DB getestet und dann gings. Es liegt daran, dass du die Tabelle NACH App installation erst hinzufügen darfst. Leg einfach mal nen neues Template an.

Mit XML Port meint ich natürlich einen in deiner Extension geschriebenen.
Du kannst aus C/Side direkt nicht wie gewohnt auf deine AL Felder zugreifen, denn die Felder sind erst zur Laufzeit bekannt. Du kannst dir aber mit Record- und FieldRefs behelfen wenn du doch unbedingt im C/Side auf die Felder zugreifen musst.

Code:

RecRef.Get(Customer.RecordId());
FieldRef := RecRef.Field(xxx); // deine ID
Message(FieldRef.Value);

Wahrscheinlich kann man dann auch mit WebServices nicht auf solche von Extensions erstellen Tabellen und erweiterte Felder zugreifen?

Du kannst die Felder in deine Pages mit ner PageExtension hinzfügen oder ne neue Page anlegen und dann kannst du auch per WebService wie gewohnt drauf zugreifen.

Mit der Strukturierung muss ich nochmal schauen, ich weiß ja auch noch nicht was da irgendwann mal kommt, habe momentan ein Arbeitsbereich in VS Code eingerichtet, mit Unterordner wo in jedem ein Projekt (erweiterung) drin ist, damit ich den "kompletten strang" in ein repository ins Github schieben kann.

Da weiß ich jetzt auch nicht ob man da lieber mehrere Projekte /Ordner erstellt, oder ob man alles in einem macht, und die Erweiterung dann "MeineFirmaErweiterungen" nennt, und da alles reinpackt was man selber programmiert.

Wir haben für uns an der Stelle so entschieden das wir die Module logisch trennen und jedes Modul auch sein eigenes Repo hat.
Dies kann aber auch durchaus komplex werden da du dann ggf. Abhängigkeiten zwischen den Apps haben kannst.
Wenn du nun App2 hast die Abhängig ist von App1 musst du, wenn du App1 updaten möchtest, App2 erst deinstallieren.

Ich denke du wirst deine eigenen Erfahrungen damit machen müssen und dann für dich/euch entscheiden was praktikabler ist.

Grundsätzlich frage ich mich gerade allerdings wann sollte ich eine Erweiterung programmieren und wann "normal" programmieren wie immer.
Also, Ich hätte ja auch die Tabelle Customer ändern können , erweitern um die 2 Felder, Neue Tabelle Rewards anlegen können, und mein programmiercode irgendwo unterbringen.

Möchtest du irgendwann in die Cloud wechseln wirst du spätestens zum wechsel nicht drum herum kommen Extensions zu entwickeln, da du ab diesen Zeitpunkt nicht mehr an den C/Side Code kommst.
Solltet Ihr aber bei der OnPrem Lösung für unbestimmte Zeit bleiben, kannst du bei der gewohnten Entwicklungsumgebung und Entwicklung bleiben.

Guten Morgen,

danke für die Ausführliche Antwort.

Für mich als "Endkunde Entwickler" etwas schwierig einzuschätzen das alles, weil ich auch nicht weiß in wie fern wir (falls wir das Update jetzt beschliessen)
eine Entwicklerlizenz bekommen bzw. was für Möglichkeiten wir als Endkunde damit haben.

Ich Vermute stark, falls wir Updaten, dass wir auch weiter On Premise fahren werden, da müsste ich mich nicht viel Umstellen/Umdenken, da aber scheinbar alles in Richtung Erweiterungen geht, möchte ich das lernen, und auch anwenden wenn es sich anbietet. Wahrscheinlich würden zukünftige Updates dann einfacher wenn die "individuellen" Änderungen über Extensions gemacht werden?

Wenn man im Falle der Cloud solche Apps ([img=https://mibuso.com/downloads/warehouse-control-system]Warehouse Control System[/img]) programmieren möchte, wie ginge das dann von statten. Bei dem Beispiel werden Tabellen angelegt, andere Tabellen und Pages erweitert, eine Codeunit als WebService veröffentlicht, die App Consumiert den Webservice.

Ist es möglich eine CU einer Extension als Webservice zu veröffentlichen, oder geht man die Sache anders an?
Oder, wenn man jetzt z.b. eine Anbindung an ein eigenes WebShop System braucht. Wie würde man das realisieren wenn "NAV" in der Cloud liegt, oder eine Schnittstelle um bestimmte Daten zu Im/Exportieren.

Das führt mich weiter zu der Frage, wenn ich eine Extension hätte welche Daten Importiert, wie würde man diese in den TaskScheduler einbinden so dass diese regelmäßig ausgeführt wird ?

Nach so vielen Jahren NAV 2009 CC, fällt mir das Umdenken gerade etwas schwer, wobei neue Technik ja auch neue Lösungswege mit sich bringt

Danke

Wahrscheinlich würden zukünftige Updates dann einfacher wenn die "individuellen" Änderungen über Extensions gemacht werden?

Theoretisch schon. Praktisch lassen sich aber nicht alle Anpassungen in Extensions verfrachten, bzw. nur mit großen Umwegen, da man Ergänzungen nicht mehr einfach im Code machen kann, sondern nur noch über Events, die aber an der Stelle, an der man Sie benötigt u.U. nicht verfügbar sind. Versuch mal nur ein Feld "Beschreibung 2" in den Varianten- Stamm oder Artikelreferenz einzufügen, und dieses Feld sauber (wie Beschreibung) in alle Belege zu bekommen.

Außerdem wird die Datenhaltung auch sehr viel komplexer, und es ist dadurch auch nicht mehr bzw. nur noch schwer möglich Updates zu optimieren, die gerade bei großen Datenbanken mit vielen Posten nötig sind, damit man Sie überhaupt in vertretbarer Zeit durchgeführt werden können.

Gruß Fiddi

Ist es möglich eine CU einer Extension als Webservice zu veröffentlichen, oder geht man die Sache anders an?
Oder, wenn man jetzt z.b. eine Anbindung an ein eigenes WebShop System braucht. Wie würde man das realisieren wenn "NAV" in der Cloud liegt, oder eine Schnittstelle um bestimmte Daten zu Im/Exportieren.

Das ändert sich nicht, du kannst weiterhin Codeunits/Pages als Webservice Publishen.

Praktisch lassen sich aber nicht alle Anpassungen in Extensions verfrachten, bzw. nur mit großen Umwegen

Dies ist momentan leider der Knackpunkt.
Microsoft muss selbst noch viel refactor'n. In erster Linie müssen sie aufhören in Codeunites Globale Variabeln zu benutzen.
Auch kann ich es nicht für gut heißen das sie Weiterentwicklungen, die sie derzeit an der Cloudversion machen, nicht in den CU's releasen und man explizit nachfragen muss wenn man unbedingt etwas braucht. Bisher ist es ja noch absehbar und es kommt alles im Oktober mit der neuen Version, aber was ist danach?


Man muss aber auch Sagen das Extensions einige Vorteile haben.
Es ist super einfach geworden ein AddIn zu entwickeln ohne lästige .dll Dateien die man von Server zu Server kopieren muss!
Die Neuen Variablen Typen HTTP*, JSON*, XML* sind in meinen Augen Gold wert.

Wie würde man das realisieren wenn "NAV" in der Cloud liegt, oder eine Schnittstelle um bestimmte Daten zu Im/Exportieren.

Bei Appentwicklung für die Cloud sind viele bislang nutzbare Wege versperrt, u.a. sind die üblichen Dateioperationen mit File.Open, File.Read, komplette Verzeichnisse einlesen alle nicht zulässig. Bei einer On-Prem-Extension kann man die aber durchaus weiter nutzen.

Als Alternative in der Cloud um Dateien zu verarbeiten ist z.B. Microsoft Flow in Verbindung mit Tabelle 1220 Data Exch. einsetzbar. Aber es sind definitiv im Bereich Extensions zwei separate Baustellen, für die man dann entwickeln muss.

In erster Linie müssen sie aufhören in Codeunites Globale Variabeln zu benutzen.

Das ist aber manchmal gerade sinnvoll und nötig, siehe Salesheader in SalesLine. Da wird der Salesheader manchmal auch nur temporär von extern mit SetSalesHeader gesetzt (für Preisfindung), und niemand (auch keine Extension) tut gut daran ein get auf diesen SalesHeader zu machen, geschweige denn ihn zu verändern. (bin gerade nicht im Thema: komme ich in einer Extension an den gesetzten SalesHeader der SalesLine?)
Genauso darf eine Extension keine Daten des SalesHeaders verändern, während der in der SalesLine benutzt wird, oder er muss daran denken den in die SalesLine zurückzuschreiben. Ich bin mir nicht sicher, ob das überhaupt jemand weiß?

Es ist super einfach geworden ein AddIn zu entwickeln ohne lästige .dll Dateien die man von Server zu Server kopieren muss!

Du meinst sicherlich den Merge, NAV verwendet normalerweise keine DLLs für die Geschäftslogik.

Es ist sicherlich einfacher geworden ein 08/15 Addin zu schreiben.
Das nützt dir aber meist nur wenig, denn die richtigen Anpassungen gehen ins eingemachte, und dafür fehlt die Unterstützung, und wenn Sie da wäre, würden wir wegen der ganzen Events und Trigger nicht mehr wissen wann wir welchen benutzen dürfen bzw. müssen.
Versuch doch mal ohne Klimmzüge einen skontierfähigen Betrag zu implementieren. Das ist in Deutschland für bestimmte Artikel Pflicht (Tabak, Bücher,..) bzw. ist üblich das auf Dienstleistungen kein Skonto gewährt wird.

Selbst ein neues Feld in Debitor oder Beleg erfordert Nachdenken und Programmierung nicht nur in den Tabellen und Pages.
Du musst dir überlegen "Wo muss ich das Feld sonst noch einbauen? (gebuchte Belege, Posten,..), "Wie kommt es wann dahin?" (das funktioniert nicht ohne genaue Kenntnis der Abläufe des Programmcodes in NAV, also mit einer Black-Box). Selbst beim Kopieren eine Belegs musst du dir für jede Richtung überlegen, was mit dem Feld passieren soll. Dafür gibt es bis heute nicht alle nötigen Events und Trigger.

Die Neuen Variablen Typen HTTP*, JSON*, XML* sind in meinen Augen Gold wert.

Das wäre sogar auch in C/AL zu lösen, siehe DotNet, das man auch implementiert hat.

Gruß Fiddi

Bei Appentwicklung für die Cloud sind viele bislang nutzbare Wege versperrt, u.a. sind die üblichen Dateioperationen mit File.Open, File.Read, komplette Verzeichnisse einlesen alle nicht zulässig. Bei einer On-Prem-Extension kann man die aber durchaus weiter nutzen.

Wir nutzen dafür Azure-Functions, schicken die Dateien als Blob's hin und erhalten das Ganze als JSON oder XML zurück.

Du meinst sicherlich den Merge, NAV verwendet normalerweise keine DLLs für die Geschäftslogik.

Nein ich meine JavaScript ControlAddIns die es ermöglichen dem Nutzer eine bessere usability zu bieten.
Wie zum Beispiel dieses hier: https://www.hougaard.com/wysiwyg-editing-control-for-dynamics-nav-2013-and-2015/

Selbst ein neues Feld in Debitor oder Beleg erfordert Nachdenken und Programmierung nicht nur in den Tabellen und Pages.
Du musst dir überlegen "Wo muss ich das Feld sonst noch einbauen? (gebuchte Belege, Posten,..), "Wie kommt es wann dahin?" (das funktioniert nicht ohne genaue Kenntnis der Abläufe des Programmcodes in NAV, also mit einer Black-Box). Selbst beim Kopieren eine Belegs musst du dir für jede Richtung überlegen, was mit dem Feld passieren soll. Dafür gibt es bis heute nicht alle nötigen Events und Trigger.

Das ist doch das gleiche wie du jetzt auch machen musst.
Du musst überlegen wo das Feld noch hin muss und wie die Daten von a nach b kommen.
Ich kann mir nicht vorstellen das Microsoft aus NAV so schnell eine Blackbox machen wollen würde. Du darfst den Code weiter sehen, nur nicht mehr ändern.
Neue/Fehlende Events werden doch momentan regelmäßig hinzugefügt.

Die Neuen Variablen Typen HTTP*, JSON*, XML* sind in meinen Augen Gold wert.

Das wäre sogar auch in C/AL zu lösen, siehe DotNet, das man auch implementiert hat.

Sicherlich ist das auch mit DotNet zu lösen, aber ist eben einfacher wenn du nur ein
v1: JSONToken;
statt
v1 dotnet Newtonsoft.Json.JsonToken.'Newtonsoft.Json, Version=7.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
zu machen und dann auch noch Sicher zu stellen das die richtige NewtonJSON.dll auf allen Servern liegt wo das ganze hin soll.


Ich sage nicht das die Lösung wie sie jetzt ist bereits perfekt und ausgereift ist, dafür Fluche ich auch einfach noch zu viel wenn ich wieder feststellen muss, dass ich nun doch ne Hybridfunktion entwickeln muss.
Aber für meinen Geschmack geht Microsoft die richtige Richtung und in ein paar Jahren sieht das Ganze schon viel besser und ausgereifter aus!

Aber für meinen Geschmack geht Microsoft die richtige Richtung und in ein paar Jahren sieht das Ganze schon viel besser und ausgereifter aus!

Hast du dir mal andere Projekte angeschaut, die eine ähnliche Komplexität haben, wie NAV?

Der Linux-Kernel z.B. wird nicht als Black-Box gepflegt, weil das gar nicht möglich wäre, denn durch sich ständig ändernde Strukturen, aufgrund neuer Technologien wäre es gar nicht möglich eine API über Hooks und Events zu garantieren. Das wird auch in NAV so passieren.

Der Linux- Kernel wird konsequenterweise ein TextMerge bzw. Patch genutzt, und das schon seit Jahrzehnten erfolgreich.

Wenn du mal realistisch überlegst, benötigst du z.B. vor und nach jedem Modify/Insert/Delete einen Trigger, die aus dem Kontext des aufrufenden Objekts aufgerufen wird (einen BeforeBefore- bzw. AfterAfter- Trigger also).
Nur mal als Beispiel wofür: Abhängig von wo ein Insert auf die SalesLine aufgerufen wird, könnte es notwendig sein zusätzliche Felder VOR dem Insert zu befüllen, weil die OnInsert- Extension die Werte benötigt. Das weiß aber nur der aufrufende Kontext , nicht der OnInsert-Trigger selbst. Genauso kann es notwendig sein einen Trigger zu haben, der erst nach dem Insert ausgeführt wird, weil der aus dem aufrufenden Kontext heraus neue Records in dieser oder anderen Tabellen erstellt, die aber den gespeicherten Record benötigen. Von dieser Art Trigger bzw. Events gibt es übrigens schon einige in NAV2018.

Da wir nicht wissen, wer wann diese Funktion benötigt, müssten wir theoretisch überall diese Funktion implementieren. Das würde z.B. für NAV 2015 bedeuten, das ca 17000 Insert/Delete/modify enthält, das wir 34000 zusätzliche Events hätten, die verwaltet werden müssten. Allein in den Buchungscodeunits dürfte das eine Unmenge solcher Events bedeuten. Mal ganz davon abgesehen, dass das irgendwann zu Performance- Problem wird, würdest du komplett den Überblick verlieren.

Was machst du denn, wenn du so einen Event in einer Extension benötigst an die du nicht einsehen kannst? Heute rufst du den Partner an, kannst du mal da eine Call auf eine Funktion irgendwo mit den Parametern einbauen, und nach ein paar Stunden hast du das Ganze und kannst weiter machen.

Statt heute die Variable die zusätzlich gefüllt werden muss einfach an passender Stelle dazu zu schreiben, musst du mit Extensions erstmal ein neues Objekt erstellen, das den Event abonniert, und dann überlegst du dir wie du die Variable aus der (von dir so gewünschten ) lokalen Variable bzw. lokalen temporären Tabelle in die Extension bekommst, da diese Tabelle ja beim Event nicht übergeben wird.
Was daran schnelle Entwicklung sein soll, erschließt sich mir nicht so ganz. Einen Textmerge übersteht so eine direkte Anpassung in der Regel mehrere Versionen ohne Probleme.

Aus meiner Sicht ist das ganze Konzept etwas halbgar, und im wesentlichen aus den (SQL) Cloud- (Kosten-) Anforderungen und einigen anderen politischen Entscheidungen getrieben, und hat wenig mit einer flexibel und (vor allem schnell) an Kundenwünsche anpassbaren ERP- Lösung zu tun, die Navision einmal war.

Gruß Fiddi

Wir nutzen dafür Azure-Functions, schicken die Dateien als Blob's hin und erhalten das Ganze als JSON oder XML zurück.

Technisch geht das sicherlich, das hatten wir auch erwogen. Aber da bei uns sensible Personen- und Kontodaten im Spiel sind, haben wir das erst einmal nicht weiterverfolgt,
trotz der Beteuerungen von Microsoft, dass ab 25.05. die DSGVO bei dem Cloudfunktionen eingehalten wird. Das hat sich ja nun eher zufällig mit unserer Appentwicklung überschnitten. Eventuell werden die dadurch jetzt nutzbar, vorher wäre es auf jeden Fall indiskutabel gewesen.

Langfristig soll es lt. Microsoft aber durchaus auch On-Prem mit Azurefunktionen laufen, die geplante .NET-Unterstützung soll wohl nur mittelfristig ermöglicht werden.
Die kann man sich schon heute installieren:
Code and test Azure Functions locally

Wenn ich das all so lese, dann scheint für mich wohl die beste Lösung erstmal weiter machen wie bisher, solange ich beim Endkunde sitze und enwtickle, und wir OnPremise Lösung haben.
Und nebenbei dann immer mal wieder Extensions und den anderen Krams testen was neu dazu kommt, um für später dann fitter zu sein wenn das alles ausgereifter ist.
Kann ich jetzt nur hoffen dass wir das Update machen, und ich vielleicht auch noch die ein oder andere Schulung machen darf.