Von 'Madeira' nach 'Tenerife', NAV 2018, D365FOBE, D365BC

Frohes Neues Jahr!

gibt es bei den Extensions eigentlich die Möglichkeit Objekte zu kopieren und die daran hängenden Extensions mit zu nehmen?

Wenn du gedanklich bei C/AL startest: Nein, zumindest nicht inklusive der Extensions, die daran hängen. Zur Zeit kannst du ein C/AL-Objekt als AL exportieren und für die Übernahme in ein AL-Projekt händisch Nummer + Name ändern.
Extension kopieren geht meines Wissens nach nur, wenn dir der AL-Quelltext (der AL-Projektordner) vorliegt. Diese AL-Objektdateien kannst du direkt in dein AL-Projekt kopieren und auch hier alles unbenennen.

Wie mache ich das eigentlich bei einem Merge, wenn das System im wesentlichen auf Extensions beruht. Wie bekomme ich mit welche Objekte sich geändert haben, und wo ich eingreifen muss, damit das ganze noch zusammenspielt?

Merge von was? C/AL- oder AL-Dateien?
Änderungen im AL-Teil managt du zukünftig mit Git - das ist im Vergleich zu bisher eine echte Verbesserung, sobald wir "nur NAVler" uns gedanklich flexibel gezeigt haben
In AL-Projekten können Dateien theoretisch beliebig angelegt werden, also z.B. mehrere Objekte in einer AL-Datei, jedoch geht der Konsens dahin, pro C/AL-Objekt auch eine AL-Datei anzulegen. Dann siehst du schon dem Namen nach, wo sich Extensions integrieren.

Die Übergangsphase von C/AL nach AL ist wohl die eigentliche Herausforderung und nur eine vorübergehende, händische Plackerei wie damals von Forms auf Pages. Sobald alles auf AL umgestellt ist (inkl. wenn Microsoft das komplette Basisprodukt auf AL migriert hat), wird das eigentliche Extension-Management viel einfacher.

Ebenfalls ein frohes neues Jahr an Alle!

Ist denn schon bekannt wie sich das mit dem Standardcode verhält? Ich habe den Eindruck, dass man am Standard keine Änderungen mehr vornehmen kann. Oder täusche ich mich da?

Ich habe den Eindruck, dass man am Standard keine Änderungen mehr vornehmen kann. Oder täusche ich mich da?

Wenn du mit Standardcode die Programmierung in C/AL meinst: Die gibt es mind. in NAV 2018 noch immer, völlig unverändert.

Ja, in 2018 schon, aber wie sieht das aus in 2018 R2 oder dann in 2019? Der Weg geht doch Richtung Extensions. Ich fürchte, MS wird C/AL für Anpassungen im Standard abschalten und nur noch Extensions und AL zulassen. Gibt es hier schon verlässliche Aussagen dazu?

Gibt es hier schon verlässliche Aussagen dazu?

Habe eher den Eindruck, man trifft nur Aussagen unter Verbehalt: Microsoft schaut, wie es sich in der Praxis entwickelt. Ich denke, sie wollen aber schon "so früh wie möglich" das Licht für C/AL ausmachen. Ich glaube nicht, dass das schon für 2018 R2 passieren wird.

In 2018R2 wohl nicht, das denke ich auch. Aber 2019? Und für mich die grösste Frage überhaupt: werden wir auch in Zukunft Zugang zum NAV-Sourecode haben und diesen anpassen können? Wenn nicht, wäre das aus meiner Sicht der Verlust des grössten Vorteils, den NAV bisher gegenüber anderen Lösungen zu bieten hat. Extensions können hier wohl kaum die Alternative sein.

wird das eigentliche Extension-Management viel einfacher.

Ich fürchte dem ist nicht so.

Heute schaust du in den Quelltext und kannst sehen, ob eine Erweiterung, die du planst oder nötig ist, möglich ist oder evtl. schon realisiert ist.
Eine Anforderung, die ich gerade bei einem Kunden hatte, wäre die Notwendigkeit das Feld "Qty. per Unit of Measure" in Belegen bearbeitbar zu machen, da in dessen Bussiness die Menge pro Basiseinheit von Auftrag zu Auftrag variieren kann.

Heute schaue ich in den OnValidate- Trigger, sehe da ist nichts, also wird das aus dem Standard nicht funktionieren, und ich muss selbst Hand anlegen, und muss auf niemanden Rücksicht nehmen.
In Zukunft werde ich dafür erst im RTC oder was auch immer schauen müssen, ob da nicht evtl. doch jemand was macht.

Heute schaue ich mir den Quelltext an, der erzählt mir eine Geschichte, und Anhand dieser Geschichte erkenne ich, an welcher Stelle ich meine eigenen Erweiterungen einhängen muss. Mit den Events weiß ich das nicht mehr, da ich nur den Aufruf des Events sehe, aber nicht zu was er führt, und was ich evtl. berücksichtigen muss.

Wenn ich heute eine eigene Erweiterung schreibe, die eigene Pages oder Tabellen verwendet, kann ich durch Aufruf der Funktionen aus der Erweiterung dafür sorgen, das trotzdem die Erweiterungen auch mit dieser neuen Page/Tabelle funktionieren. Wenn die Erweiterung aber nur als Eventsubscriber läuft, habe ich da wohl in Zukunft verloren.

Wenn ich heute einen Text-Merge mache. kann ich sehen, wo sich Veränderungen ergeben haben, und ich evtl. eingreifen muss. schon bei den Events sehe ich das nicht mehr direkt, weil ich gar nicht sehe das da was passiert ist.

Die Nutzung von Events wird das ganze nicht vereinfachen, da es immer mehr werden,und da leider nicht nur die heutigen Events OnBefore*,OnAfter*, sondern auch die OnBeforeBefore* und OnAfterAfter* Events (die aus dem aufrufenden Kontext aufgerufen werden) benötigt werden (was MS in NAV2018 an einigen Stellen anscheinend selbst gemerkt hat). Das ganze wird zu einer Event-Hölle führen (in NAV 2017 ca 17000 wenn man das generell einführt), durch die niemand mehr durchschaut.

Gruß Fiddi

werden wir auch in Zukunft Zugang zum NAV-Sourecode haben

Ja, wie ich vorhin schrieb: Microsoft arbeitet daran, diesen komplett auf AL umzustellen. Momentan weiß vermutlich niemand, wann das fertig ist.

und diesen anpassen können?

Erweitern (mit Extensions) definitiv ja, alles andere werden wir sehen.
Microsoft sammelt fleißig von allen Usern Hinweise, wo Events hinzuzufügen sind bzw. wo C/AL-Code umgeschrieben werden müsste, DAMIT Extensions für noch mehr Zwecke als bisher eingesetzt werden können.

Microsoft arbeitet daran, diesen komplett auf AL umzustellen

OK, damit könnte ich leben. Wie das in der Praxis aussieht muss man dann sehen. Extensions an sich finde ich gut, wenn sich damit der Migrationsaufwand auf neue Versionen vereinfachen lässt. Und wenn ich dann halt CU 80 in AL anpassen muss anstatt in C/AL, ok.

Microsoft sammelt fleißig von allen Usern Hinweise wo Events hinzuzufügen sind

OK, das schaue ich mir mal an. Mal sehen, ob es schon einen Vorschlag für einen Event 'OnBetweenCodeAfterCommentedOutCode' gibt

Na super,
da meine Antwort an dich, fiddi, nicht den Server erreicht hat, hier in komprimierter Form nochmal:

In Zukunft werde ich dafür erst im RTC oder was auch immer schauen müssen, ob da nicht evtl. doch jemand was macht.

In Zukunft ist die ganze NAV-Basis in VS Code ersichtlich, und die AL-Extension(s) in VS Code werden bis dahin noch viel mehr als jetzt können. Ich denke, die Möglichkeiten der neuen Entwicklungsumgebung sollten nicht unterschätzt werden. Ich glaube daran, dass das meiste, was wir heute als Hindernis/Einschränkung sehen, bald keins mehr ist. Hellsehen kann ich aber auch nicht

Wenn ich heute eine eigene Erweiterung schreibe, die eigene Pages oder Tabellen verwendet, kann ich durch Aufruf der Funktionen aus der Erweiterung dafür sorgen, das trotzdem die Erweiterungen auch mit dieser neuen Page/Tabelle funktionieren. Wenn die Erweiterung aber nur als Eventsubscriber läuft, habe ich da wohl in Zukunft verloren.

Habe ich nicht verstanden - ein einfaches Beispiel bitte?

Hallo,

Wenn ich heute eine eigene Erweiterung schreibe, die eigene Pages oder Tabellen verwendet, kann ich durch Aufruf der Funktionen aus der Erweiterung dafür sorgen, das trotzdem die Erweiterungen auch mit dieser neuen Page/Tabelle funktionieren. Wenn die Erweiterung aber nur als Eventsubscriber läuft, habe ich da wohl in Zukunft verloren.

Habe ich nicht verstanden - ein einfaches Beispiel bitte?

Nehmen wir mal als Beispiel die Artikelkarte und eine Extension, die auf Page 30 liegt, weil z.B. ein zusätzliches Feld benötigt wird.

Jetzt baue ich eine neue Page, die mit nur ein paar Feldern (auch dem der Extension oder einem OnModify- Trigger) eine Artikelschnellerfassung ermöglicht. Wie bekomme ich da die Extension der Page 30 rein?

Gruß Fiddi

Jetzt baue ich eine neue Page, die mit nur ein paar Feldern [...] eine Artikelschnellerfassung ermöglicht. Wie bekomme ich da die Extension der Page 30 rein?

Um beim Beispiel des Zusatzfeldes aus einer anderen Extension zu bleiben:
Wenn dir die Extension als AL-Quelltext vorliegt (*), kopierst du die Datei der P30-Erweiterung (anhand des Namens schnell zu finden) in dein Extension-Projekt und änderst die Referenz auf deine neue Page. Das geht ganz fix.
Hast du keinen Zugriff auf das Projekt, bleibt nur das händische Nachprogrammieren in AL (unter der Kenntnis, was da überhaupt hinzuzufügen ist) direkt in deine deine Page-Datei.

(*) Ich weiß nicht, ob und wie das in Zukunft automatisch bei Dritt-Extensions möglich sein wird bzw. ich kann es gerade nicht nachsehen. Vielleicht wissen das andere besser.

Hallo,

Um beim Beispiel des Zusatzfeldes aus einer anderen Extension zu bleiben:
Wenn dir die Extension als AL-Quelltext vorliegt (*), kopierst du die Datei der P30-Erweiterung (anhand des Namens schnell zu finden) in dein Extension-Projekt und änderst die Referenz auf deine neue Page. Das geht ganz fix.
Hast du keinen Zugriff auf das Projekt, bleibt nur das händische Nachprogrammieren in AL (unter der Kenntnis, was da überhaupt hinzuzufügen ist) direkt in deine deine Page-Datei.

Bisher musste ich nicht "ganz fix" suchen, ich habe page 30 kopiert, alles rausgeschmissen was ich nicht brauche, und es funktioniert. Das ganze dauerte weniger als eine Minute.

Und wenn ich hier mal schaue: https://blogs.msdn.microsoft.com/nav/2017/12/06/nav-development-preview-december-update/

Show My Code

The manifest has a new setting: Show My Code. It specifies if the source code must be visible when other extensions debug it.

For example, an amazing library is developed and shared on AppSource for other people to use, but the author doesn't want the users to see the code when they try to debug into it from their extension. The author sets the ShowMyCode setting to make sure that the code is not shown when the user tries to debug into it. By default ShowMyCode is false but can be overriden in the app.json file to true.

Dann fürchte ich, ist dein Vorschlag eher Wunschdenken.

Und wenn ich den BLOG- Beitrag von Marije Brummel lese, dann https://dynamicsuser.net/nav/b/mark_brummel/posts/navision-stories-some-thoughts-for-2018 bin ich mir auch nicht sicher, was aus dem Ganzen wird.

Gruß Fiddi

Die Fragen stellen sich ja nur, weil du mit einer P30-Kopie arbeiten willst bzw. musst.
Ob das Anlegen von Kopien von Basisapplikationsobjekten in der neuen Architektur überhaupt noch sinnvoll sein wird, stelle ich mal vorsichtig in Frage.
Solange du jedenfalls in der Original-Page verbleibst, verbleiben auch alle Drittextensions.

Ob das Anlegen von Kopien von Basisapplikationsobjekten in der neuen Architektur überhaupt noch sinnvoll sein wird, stelle ich mal vorsichtig in Frage.

Nun dann fangen wir mal mit einem anderen Beispiel wie den Beleg- Reports an.
Die erfordern u.U. eine komplett andere Struktur als der Standard, damit Sie im Kundenumfeld funktionieren. U.U. auch in mehreren Mandanten unterschiedliche Reports für unterschiedliche Kommunikationswege.

Das mit der Page war nur ein Beispiel.
Es gibt sicherlich noch hunderte einfache Beispiele, die z.Zt. mit Extensions noch nicht möglich sind. Führe mal ein Feld "Beschreibung 3" im Artikelstamm und in allen relevanten abhängigen Tabellen ein, und versuche das mal mit Extensions zu lösen.
Selbst eine so einfache Sache wie das ändern des Default- Wertes beim Buchen von Belegen von "Liefern & Fakturieren" auf nur "Liefern" oder das Abschalten der Fakturierungsfunktion für bestimmte Benutzer ist mit Extensions z.Zt. ein Problem.

Gruß Fiddi

Führe mal ein Feld "Beschreibung 3" im Artikelstamm und in allen relevanten abhängigen Tabellen ein, und versuche das mal mit Extensions zu lösen.

Wo liegt jetzt das Problem? Das Suchen der relevanten Tabellen (hier erhoffe ich mich in Zukunft mehr Hilfe von der AL-Erweiterung in VS Code), oder ob die Umsetzung überhaupt geht (das geht nämlich problemlos)?

Selbst eine so einfache Sache wie das ändern des Default- Wertes beim Buchen von Belegen von "Liefern & Fakturieren" auf nur "Liefern" oder das Abschalten der Fakturierungsfunktion für bestimmte Benutzer ist mit Extensions z.Zt. ein Problem.

Dafür gibt es die o.g. Meldemöglichkeit für Microsoft, damit die den Quelltext so weit aufbohren, bis du das machen kannst. Die Verantwortung, dies JETZT zu melden, liegt bei dir (und natürlich vorher zu schauen, ob das nicht schon jemand vor dir gemacht hat, irgendwie kommt mir das Thema nämlich bekannt vor).

Wo liegt jetzt das Problem? Das Suchen der relevanten Tabellen (hier erhoffe ich mich in Zukunft mehr Hilfe von der AL-Erweiterung in VS Code), oder ob die Umsetzung überhaupt geht (das geht nämlich problemlos)?

Wo das Problem liegt? Ganz einfach: Die Description- Felder werden in so vielen Schleifen oder If-Abfragen zugewiesen, an den Stellen kannst du gar nicht sinnvoll überall Events einbauen. Andrerseits funktioniert ein Tabellen- Trigger auch nicht, weil der den Kontext nicht kennt.

Dafür gibt es die o.g. Meldemöglichkeit für Microsoft, damit die den Quelltext so weit aufbohren, bis du das machen kannst. Die Verantwortung, dies JETZT zu melden, liegt bei dir (und natürlich vorher zu schauen, ob das nicht schon jemand vor dir gemacht hat, irgendwie kommt mir das Thema nämlich bekannt vor).

Ja hatte ich schon mal angesprochen.
Leider kenne ich die Anforderungen meiner zukünftigen Kunden heute noch nicht, und kann JETZT noch nicht Microsoft melden, was die evtl. für Anforderungen haben

Worauf ich hinaus will, ist dass es anscheinend noch nicht allen Beteiligten klar ist, was NAV heute kann, und welche Möglichkeiten wir heute benötigen und anwenden um unsere Kunden zufrieden zu stellen.
Wenn ich dann höre, das in AL Dotnet wieder deaktiviert werden soll, für das wir so lange gekämpft haben, dann frage ich mich, wie ich in Zukunft eine Produktionsmaschine ansteuern, oder mit Ebay oder Amazon kommunizieren soll, die eben nur diese Funktionen zur Verfügung stellen.

Was wir benötigen ist ein möglichst offenes System, das flexibel anpassbar ist, und die Entwickler nicht mehr als nötig behindert. Das war mal die große Stärke von NAV, und der Grund für viele Kunden es zu kaufen.

Gruß Fiddi

Was wir benötigen ist ein möglichst offenes System, das flexibel anpassbar ist, und die Entwickler nicht mehr als nötig behindert. Das war mal die große Stärke von NAV, und der Grund für viele Kunden es zu kaufen.

Genau hier liegt auch meine grösste Sorge. Ev. bekommen wir dann einmal in ferner Zukunft alles wieder was wir schon mal hatten. Wenn ich da an den ersten RTC-Client denke und daran, was der alles nicht hatte und konnte von dem was wir davor hatten (und das ist 'nur' Oberfläche), und dann daran denke das es ev. in dieser Richtung auch mit AL weitergeht, naja, dann überspringe ich wohl lieber 2019 und 2020 und 2021 (und geh dann in Rente)

Being able to see the source code of our application is an important way of learning what to change/extend.

Currently the base-app is still written in C/AL using C/SIDE. In the future we will develop everything in AL. When we have fully moved to AL, you will be able GoTo definition into base-objects as well.

This doesn't mean that you can't view the source. We will still continue to make the source available, the complete move to AL will just make it possible to build even better navigation/discoverability between symbols/source.

For future OnPremise development you will still be able to change/customize everything - if the extension model isn't sufficient. The only change is that the development tools will then be AL + VsCode and not C/AL + C/SIDE. Being able to do so will of course still require access to standard objects.

I hope that this answers your question and removes any worries about source code visibility for standard objects.

Die Nutzung von Events wird das ganze nicht vereinfachen, da es immer mehr werden,und da leider nicht nur die heutigen Events OnBefore*,OnAfter*, sondern auch die OnBeforeBefore* und OnAfterAfter* Events (die aus dem aufrufenden Kontext aufgerufen werden) benötigt werden (was MS in NAV2018 an einigen Stellen anscheinend selbst gemerkt hat). Das ganze wird zu einer Event-Hölle führen (in NAV 2017 ca 17000 wenn man das generell einführt), durch die niemand mehr durchschaut.

Naja, wenigstens wird VS Code Intellisense uns ein Stückchen dabei unterstützen: https://github.com/Microsoft/AL/issues/ ... -341940228

Micrososoft hat geschrieben:....

Das ist doch mal eine Aussage, die ich so bisher nirgends gehört hatte

Naja, wenigstens wird VS Code Intellisense uns ein Stückchen dabei unterstützen:

Es würde mich genauso sehr interessieren (auch im Textexport) bei der Eventfunktion oder beim Trigger zu sehen, welche Subscriber vorhanden sind, damit man die Abläufe besser verstehen kann.

Gruß Fiddi

Ich schliesse mich fiddi an, das ist gut zu hören, vielen Dank für die Info, Natalie. Neues Jahr mit guten Nachrichten, wenigstens für unsere kleine NAV-Welt

Und hier ein Tool, um bereits von anderen Extensions belegte Objekt- und Feld-IDs zu sehen: https://dynamicsuser.net/nav/b/peik/pos ... namics-nav

Richtige gemein wird's wenn in zwei Extensions die gleichen Namen/Caption mit ungleicher ID aber für womöglich die gleiche Bedeutung verwendet haben. (z.B. Verband)

Gruß Fiddi

Solche Probleme gibts doch aber jetzt schon. Der Bereich 50'000 ist für Kundenpassungen gedacht. Und alle Extension-Bespiele, die ich bis jetzt in den diversen Videos gesehen habe, bewegen sich in genau diesem Bereich. Das müsste doch so gehandhabt werden wie AddOns. Ich habe ein cfmd-zertifiziertes AddOn entwickelt und dafür einen komplett eigenen, reservierten Objektbereich zugewiesen bekommen. Da bekomme ich nicht Probleme mit Extensions, höchstens vielleicht mal mit einem Objektnamen, aber auch das habe ich jetzt ab und zu bereits. Dann muss ich halt einen anderen Namen erfinden.