What's New für Entwickler (mit VS Code)

Infos zum Umbau der Preisfindung auf Interfaces.
Dynamics 365 Business Central 2020 Wave 1: price management with interfaces

Infos zum Umbau der Preisfindung auf Interfaces.
Dynamics 365 Business Central 2020 Wave 1: price management with interfaces

Da weiß ich gerade gar nicht, was ich davon halten soll.

Das geht mir genauso!

wenn ich das richtig sehe, wollen die alles Preise und Rabatte sowohl EK- als auch VK-Seitig in eine Tabelle werfen. Wohl wegen der Übersichtlichkeit, die nach der alten Methode wohl zu gut war.

...alles Preise und Rabatte sowohl EK- als auch VK-Seitig in eine Tabelle werfen...

Im Sinne der "Duplizierung von Code" macht das schon Sinn.
So richtig wird mir aber jetzt bewusst, dass die das mit dem ganzen neuen Programmierzeugs ernst meinen.

Das meinen die Ernst.

das der Anwender dabei auf der Strecke bleibt interessiert leider niemanden.

Gruß fiddi

Letzte Woche war es noch ein Gerücht, nun ist es offiziell.
Announcing Universal Print: a cloud-based print solution

Using tables instead of table extensions

Docs: Application version for aliasing base application

Dynamics 365 Business Central 2020 Wave 1: FAQ about updating apps for v16

Codeunit API‘s in Business Central

Neue performante Möglichkeiten mit Data Type Dictionary.
What’s faster than temporary tables?

In USA soll es laut Marije Brummel erhöhten Bedarf für AL-Entwickler geben.
Business Central; Developers, Developers, Developers

Application Versions – CI / CD Part 5
Branching Workflow – CI / CD Part 6
Package Types for Business Central Artifacts – CI / CD 7
Release Management with Artifacts & Stages – CI / CD 8
Links für Part 1-4 hier.

Dynamics 365 Business Central and the new Microsoft Application "proxy" app

C/AL to AL Data Upgrade Automation Powershell Script

Error “cannot be used” for “Extension” development

Dynamics 365 Business Central: something more about dependency propagation

Managing Business Central Development with Git: Branching Strategy
Tip: Format AL Files OnSave in Visual Studio Code

Dynamics 365 Business Central: something more about dependency propagation

die Beziehungspfeile in der Mitte des Diagrams hätte man besser machen können - sieht ein bisschen ... naja ihr wisst schon

... naja ihr wisst schon

ist mir auch aufgefallen.

... naja ihr wisst schon

ist mir auch aufgefallen.

Das ist auch eine Frage des kulturellen Hintergrunds. In Indien sieht man das häufiger, aber aus religiösen Gründen, nicht aus politischen.
https://www.indien-fieber.de/swastika-symbol
Man kann ihn ja mal darauf ansprechen.
Nachtrag: Er ändert das Diagramm.

Searching the Business Central Base App with Regular Expressions

New Command in My CRS AL Language Extension: Search Object Names

An update on AL interfaces: implementation details

Dynamics 365 Business Central SaaS: save a file to an SFTP server (the Logic App way)

Hallo,
auch da wird das concurrent apps- Problem nicht gelöst.

Gruß Fiddi

Ich finde die Prioritäten von Microsoft im Hinblick auf NAV/D365BC ja schon seit Jahren merkwürdig. Und so verstehe ich auch nicht was dieser Interface Kram soll. Ich habe in Grundzügen verstanden wozu diese Geschichte sinnvoll sein soll, aber das löst keines meiner Probleme und keines meiner Kunden. Vielleicht kann mir ja mal jemand erklären warum das für Microsoft ein wichtiges Thema war. Das habe ich nämlich noch aus keinem der lobhudelnden Blogs zu diesem Thema herauslesen können. Hat vielleicht aber auch damit zu tun dass ich mit SaaS nix zu tun habe und mit den Problemen die man dort hat.

Die Prioritäten die Microsoft setzt, sind nicht immer für alle einsehbar. Möglicherweise sind deine Probleme wirklich nur deine oder die Weniger.

Zusätzlich müssen sie auch ihre Prioritäten im Hinblick auf SaaS setzen. Der Faktor der dort angewendet wird ist nunmal sehr hoch und das ist auch gut so. BC hat mittlerweile im Bereich Dynamics (BC, FO, CE, PowerApps) mit 50% die Nase vorn, verglichen mit zwei bis drei Jahren zuvor, als CE noch alles angeführt hat.

Auch ich durchblicke nicht immer alles, aber der Erfolg mit BC gibt Microsoft recht. Interfaces sind ein sehr lange von vielen gefordertes Entwicklerfeature und gepaart mit den Enums eine elegante Möglichkeit, die Options/Enum-Hölle etwas in den Griff zu bekommen (erweiterte Enums werden oft nicht vom Code bedient bzw. können dies gar nicht). Das dauert aber halt seine Zeit und ist nicht in ein paar Wochen abgeschlossen.

Und nein, sie lösen viele generelle oder konzeptionelle Probleme nicht. Einige davon werden im ERP-Umfeld auch niemals gelöst werden können. Aber der Weg ist der richtige.

Hallo,

@SilverX
was meinst du mit "Einige davon werden im ERP-Umfeld auch niemals gelöst werden können"?

Nach meiner Meinung kann man Enums/Interfaces nur für den Fall benutzen, dem man bisher mit den "Code","Beschreibung"- Tabellen gelöst hat, für nichts anderes sind die zu gebrauchen.

Das was viele Programmierer haben wollen, z.B. Type in T37 oder T39 zu erweitern ist damit immer noch nicht möglich. Insbesondere dann nicht, wenn mehrere Extensions parallel in den Tabellen installiert sind. Dieses Problem verhindert auch das weitere Aufteilen der BaseApp, weil für jedes Modul andere Interfaces benötigt würde, was ja nicht geht. Genauso muss jedes Modul die alle Enum- Werte kennen, wenn es auf Type zugreift und korrekt darauf reagieren. Das wäre, wenn überhaupt, nur mit tausenden Kompatibilty- Apps möglich.

Was soll ich mit etwas, das versucht eine Lösung zu schaffen für Probleme, die ich nicht hätte, wenn es keine Enums gäbe.

Mir hat bisher noch niemand erklären können, warum es in keiner anderen Programmiersprache erweiterbare Enums gibt. Hat da jemand bei MS den Stein der Weisen gefunden, oder hat derjenige mal wieder nicht nachgedacht?

Gruß Fiddi

was meinst du mit "Einige davon werden im ERP-Umfeld auch niemals gelöst werden können"?

Speziell einige von dir öfter angesprochene Probleme (wie unten) sind nicht für jeden Fall zu lösen.

Nach meiner Meinung kann man Enums/Interfaces nur für den Fall benutzen, dem man bisher mit den "Code","Beschreibung"- Tabellen gelöst hat, für nichts anderes sind die zu gebrauchen.

Interfaces können wie in anderen Hochsprachen genutzt werden. Die erweiterbaren Enums sind dabei nur mittel zum Zweck, um die jeweilig zu benutzende Implementierung zu definieren. Ansich haben die ersteinmal gar nichts miteinander zu tun, sie dienen nur dazu, die Verbindung zwischen Interface und der jeweiligen Implementierung herzustellen.

z.B. Type in T37 oder T39 zu erweitern [...] nicht möglich. [...] wenn mehrere Extensions parallel in den Tabellen installiert sind.

Doch, ist es. Wenn alles fertig ist, was aber ja dauern kann. Das Problem von Störungen zwischen Anpassungen wirst du kaum lösen können. Das Problem ist aber alt, konnte aber, zugegeben, besser gesehen werden in C/AL.

Dieses Problem verhindert auch das weitere Aufteilen der BaseApp, weil für jedes Modul andere Interfaces benötigt würde, was ja nicht geht.

Warum nicht? Es ist komplex, ja, aber ich tippe darauf, dass es für jede Zeilenart eine Implenentierung geben wird, die dann das Handling übernimmt. Interfaces bzw. deren Implementierungen können ja wiederum auf Publisher aufsetzen. Neue Arten werden dann aber von neuen Implementierungen behandelt.

Genauso muss jedes Modul die alle Enum- Werte kennen, wenn es auf Type zugreift und korrekt darauf reagieren. Das wäre, wenn überhaupt, nur mit tausenden Kompatibilty- Apps möglich.

Nicht immer müssen alle Apps alles kennen. Nur Apps, die bestehendes erweitern. Ja, es ist herausfordernd und benötigt ständige Weiterentwicklung.

Mir hat bisher noch niemand erklären können, warum es in keiner anderen Programmiersprache erweiterbare Enums gibt. Hat da jemand bei MS den Stein der Weisen gefunden, oder hat derjenige mal wieder nicht nachgedacht?

Das kann ich dir erklären: Weil es in keiner anderen Programmiersprache Regeln für die zugrunde liegenden Nummern gibt. Sort könnte, wenn es möglich wäre, jeder erweitern und Kollisionen wären unvermeidbar. Da wir aber vom Prozess an unsere Nummernbereiche gebunden sind, kann es dieses Problem nicht geben.

Hallo,

Das kann ich dir erklären: Weil es in keiner anderen Programmiersprache Regeln für die zugrunde liegenden Nummern gibt. Sort könnte, wenn es möglich wäre, jeder erweitern und Kollisionen wären unvermeidbar. Da wir aber vom Prozess an unsere Nummernbereiche gebunden sind, kann es dieses Problem nicht geben.

Ich glaube nicht, das dass Problem ist.
Der Unterschied zwischen den Enums und einem anderen Objekt ist, dass es ein Datenwert ist, und keine abgeleitete Klasse. Erweiterst du eine Klasse, können nur abgeleitete Objekte auf die Erweiterungen zugreifen. Bei einem neuen Enum- Wert müssten alle Funktionen aus dem Basisobjekt(en), die auf eine Variable dieses Typs zugreifen, damit umgehen können.

Mal ein Beispiel:
Du möchtest T37 Type um die Option "Optional Item" erweitern mit einem Addin A von Anbieter A der optional Artikel soll sich verhalten, wie ein normaler Artikel, aber nicht aufsummiert werden. Von Anbieter B hast du eine Extension B, die erweiterte Textbausteine für T37 anbietet. Abhängig von Type und No. soll er den entsprechenden Text einfügen. Das soll er natürlich auch für die optionalen Artikel tun, da die ja auch in normale Artikel umgewandelt werden können.
Ich will jetzt nicht über die Probleme reden, FlowFields mit passenden Filtern zu erweitern,....

Gruß Fiddi

Dynamics 365 Business Central and unpublished extensions during an upgrade

Erweiterst du eine Klasse, können nur abgeleitete Objekte auf die Erweiterungen zugreifen. Bei einem neuen Enum- Wert müssten alle Funktionen aus dem Basisobjekt(en), [...] damit umgehen können.

Nicht ganz. Es muss in der Basis nur eine Möglichkeit geschaffen werden, darauf zu reagieren. Das passiert ja langsam an vielen Stellen in der Basis.

Du möchtest T37 Type um die Option "Optional Item" erweitern mit einem Addin A von Anbieter A der optional Artikel soll sich verhalten, wie ein normaler Artikel, aber nicht aufsummiert werden. Von Anbieter B hast du eine Extension B, die erweiterte Textbausteine für T37 anbietet. Abhängig von Type und No. soll er den entsprechenden Text einfügen. Das soll er natürlich auch für die optionalen Artikel tun, da die ja auch in normale Artikel umgewandelt werden können.

Dieses Problem hatten wir ja auch schon vorher. HasExtendedText() wäre eine Methode des Interfaces, auf die man reagieren kann. Auch in der klassischen Entwicklung kommt es vor, dass mögliche Fälle vergessen wurden. Das muss halt nachgearbeitet werden. Und ja, das wird nicht von heute auf Morgen passieren.

Macht A plötzlich etwas, von dem B nichts weiß und A sorgt nicht dafür, dass B es weiß, dann weiß es B halt nicht.
Wir sind gezwungen, unsere Entwicklungen ständig zu verändern und neuen Begebenheiten anzupassen. Sicherlich aufgrund der straffen Updatepolitik mehr als vorher. Und das ist gut so.

Und es ist auch nicht hilfreich, immer auf Fälle zu zeigen die aktuell nicht oder nur schwer abbildbar sind. Es sind Lösungen gefragt, neue Pattern, Interface-Design, Innovation. Daran sollten wir uns orientieren.

Und es ist auch nicht hilfreich, immer auf Fälle zu zeigen die aktuell nicht oder nur schwer abbildbar sind. Es sind Lösungen gefragt, neue Pattern, Interface-Design, Innovation. Daran sollten wir uns orientieren.

+1

Hallo,

Und es ist auch nicht hilfreich, immer auf Fälle zu zeigen die aktuell nicht oder nur schwer abbildbar sind. Es sind Lösungen gefragt, neue Pattern, Interface-Design, Innovation. Daran sollten wir uns orientieren.

Carsten, da bin ich etwas anderer Meinung:
1. Wenn Fälle aus der täglichen Praxis nicht abgebildet werden können, dann hat das Konzept einen Fehler, egal wie neu, modern oder innovativ.
2. Nur weil Dinge neu oder modern sind, sind sie nicht besser. Vor nicht allzu langer Zeit musste alles in XML verarbeitet werden, mit allen Problemen, die daraus resultieren (RDLC mit großen Datenmengen), heute muss es unbedingt JSON sein.
3. ERP ist aus meiner Sicht kein Spielplatz für Programmierer. Es erfordert intensives NACHdenken bevor man an etwas herum bastelt, und Innovationen sollten ausgereift aber zumindest zu Ende gedacht sein, bevor man sie auf den Markt bringt.

Am Ende müssen wir die Probleme unserer Kunden zu vertretbaren Kosten lösen und unterhalten können, sonst kauft keiner mehr unsere Lösungen, und wir sind unsere Jobs los, egal wie genial wir zu sein glauben.

Macht A plötzlich etwas, von dem B nichts weiß und A sorgt nicht dafür, dass B es weiß, dann weiß es B halt nicht.

Entschuldige bitte, aber solche Algemeinplätze sind keine Antwort.
Hier macht keiner "plötzlich" irgendwas. Das ist das Konzept von BC, dass der Anwender sich Apps aus dem Appstore lädt und in seine Anwendung installiert, und alles funktioniert, oder auch nicht.

Wie soll man das denn lösen, bzw. wie würdest du das den lösen mit dem aktuellen Konzept?

Gruß Fiddi