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

Ja, natürlich gibt es diese Probleme jetzt schon, deshalb gibt es eigentlich auch nur wenig Unterschiede zwischen Extensions und FOBs.
Der einzige wirkliche Unterschied, der mir einfällt, ist die Möglichkeit Felder unabhängig von anderen Addons in Tabellen und Pages einzufügen.
Alles andere funktioniert genauso wie bei FOBs, mit den gleichen Problemen.
D.h. im Zweifel funktioniert Extension A nicht mit Extension B, wenn nicht Extension C dafür sorgt, das die beiden kompatibel werden.
Wenn du heute zwei Addons als FOBs in eine DB einspielen kannst, ohne das sie sich bekriegen, wird es wahrscheinlich auch als Extension funktionieren, bzw. eher nicht.

Gruß Fiddi

Na, dann ist ja alles in Ordnung

Bei Extensions gelten für Feldnamen strengere Regeln.
Extensions soll sich der Endkunde ja selber installieren können, also muss vorab sichergestellt sein, dass sich Feldnamen in einer Tabelle nicht wiederholen können, in jedes Feld muss also ein dem Hersteller zugeordneter eindeutiger Code mit dazu, den auch kein anderer Hersteller verwenden darf.

in jedes Feld muss also ein dem Hersteller zugeordneter eindeutiger Code mit dazu, den auch kein anderer Hersteller verwenden darf.

Das mag ja alles sein, aber auf dem Bildschirm werden Felder/Actions mit der gleichen Bedeutung wahrscheinlich gleiche Captions haben.
Was soll der Anwender denn dann machen? Evtl. müssen diese Felder dann auch noch synchronisiert werden (habe ich alles im normalen Umfeld schon mehrfach erlebt, und ich habe keine 17 ISV- Lösungen wie Timo am laufen)
Wie löse ich das, wenn beide Actions ausgeführt werden müssen? Soll der Anwender dann beide Buttons drücken??

Gruß Fiddi

in jedes Feld muss also ein dem Hersteller zugeordneter eindeutiger Code mit dazu, den auch kein anderer Hersteller verwenden darf.

Das mag ja alles sein, aber auf dem Bildschirm werden Felder/Actions mit der gleichen Bedeutung wahrscheinlich gleiche Captions haben.

Mir fallen da spontan so Felder ein, wie "E-Mail" in der Benutzereinrichtung. Alle Lösungen, die in irgendeiner Art und Weise E-Mails im Kontext des Benutzers versenden wollen, werden auf die Idee kommen, in der Benutzereinrichtung ein Feld "E-Mail" anzulegen.
Wenn man dann mehrere AddOns installiert hat (z. B. Workflow, DocumentCapture, Intercompany, EDI, ...), dann wird es hier möglicherweise richtig "lustig".

Wenn man - wie wir - mehrere größere AddOns hat, dann wiederholen sich nicht nur einzelne Felder, sondern manchmal sogar ganze Module.
Wir haben dadurch z. B. die Objekte von vier verschiedenen Workflow-Modulen unterschiedlicher Anbieter in unserer Datenbank, weil diese einfach immer mit derem AddOn zusammen ausgeliefert werden.
Und wenn wir Belege per E-Mail versenden wollen, dann können wir uns theoretisch schon eine von fünf Lösungen in unserer Datenbank aussuchen.
Die Erfassung von Fließtexten können wir auf drei verschiedene Arten bewerkstelligen, und für eine DMS-Anbindung haben wir auch die Objekte für vier verschiedene Schnittstellen.

Das kommt dabei heraus, wenn die Partner es gut meinen und mehrere Funktionalitäten in ein und demselben Objektpaket ausliefern.

in jedes Feld muss also ein dem Hersteller zugeordneter eindeutiger Code mit dazu, den auch kein anderer Hersteller verwenden darf.

Das mag ja alles sein, aber auf dem Bildschirm werden Felder/Actions mit der gleichen Bedeutung wahrscheinlich gleiche Captions haben.

Das Problem gibt es auch jetzt schon, verursacht aber keine Merge-/Installationskonflikte sondern "nur" Verwirrung beim Anwender. Da hilt nur entweder separate Pages zu erstellen oder eben den eindeutigen Code auch in die Caption durchzuziehen. Schöner wäre aber das eigene Firmenlogo als Mini-Icon in der Caption, aber das ist leider technisch ja nicht möglich .

Es gibt in einem erweiterbaren ERP, wie NAV es ist, generell das Problem, dass fast jede Anpassung Auswirkungen auf das ganze System hat, du kannst da kaum etwas machen ohne das es andere Anpassungen ebenfalls beeinflusst.
Beispiel:
Extension A definiert ein neues Feld im Debitorenstamm als Extension. Dieses Feld muss bei jeder Neuanlage individuell gefüllt werden. Jetzt gibt es eine Extension B, die einen Onlinehandel anbindet. Bei (fast) jedem Verkauf wird ein neuer Debitor angelegt. Wie schaffe ich es, dass Extension B Daten von Extension A füllt, die nichts von einander wissen?

Aus deiner Sicht als Addon-Anbieter sind die Extensions eine feine Sache und ganz hervorragend. Für denjenigen, der Sie beim Kunden unter einen Hut bringen muss, eher die Hölle.
Und das der Kunde mal eben so eine Extension installiert ist eher Wunschdenken, da wenn er Extensions nutzen will die für seinen Job wichtig sind, die eher miteinander verzahnt sind, als das sie nebeneinander her laufen können.
Weiteres Beispiel:
Ein Zahlungsverkehr-Addon mit Paypal, und ein Webshop. Der Webshop erstellt neue Aufträge mit Zahlungsform Paypal, sperrt die aber, bis die Paypal- Zahlung eingetroffen ist. Der Zahlungsverkehr verarbeitet die Paypalzahlungen, soll aber
im Anschluss den Auftrag freigeben. Ohne die beiden Addons mit einander zu verbinden wird das nicht funktionieren. Noch schlimmer wird es, wenn sowohl der Zahlungsverkehr als auch der Webshop eine Paypal- Schnittstelle haben, und beide aus verschiedenen Gründen benutzt werden müssen.

Gruß Fiddi

@fiddi:
Wir sind alle skeptisch was die Extensions betrifft. Ich sehe es eher als Chance, dass das System in der Cloud wachsen kann.
Solange Microsoft OnPremise erlaubt, (und das ist in allen Bereichen der Fall, hoffen wir das es so bleibt) kannst du theoretisch so weiterarbeiten wie bisher. Ob und welche Einschränkungen sich da ergeben, wird sich zeigen.

Auch der RTC wurde von vielen skeptisch gesehen (heute noch). Im Nachhinein war es die komplett richtige Entscheidung, weil die Bedienung und Ergonomie deutlich besser ist.

Wie schaffe ich es, dass Extension B Daten von Extension A füllt, die nichts von einander wissen?

Technische Antwort: mit Extension C oder einer Ergänzung der Extension B, siehe How to reference another extension from an extension

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

Ich bin ja noch nicht so im Thema
Ich wünsche mir einfach nur dass man eine Entwicklungsumgebung hat aus der man alles irgendwie machen/erreichen kann, und nicht X Tools, oder extra Coding, und dann noch Powershell hier und das dort...

Gibts eigentlich Infos zu NAV2018 was das Entwicklen für Anwender/Endkunden angeht? Wir haben derzeit (Nav 2009) eine (Eingeschränkte?) Developer Lizenz mit der ich Basisobjekte (nicht alle) so wie Objekte in unserem Nummernbereich ändern/erstellen kann. Was werde ich als Endanwender in NAV 2018 programmieren/ändern dürfen? Bzw. gibts da überhaupt passende Lizenz?

Die Frage ist ja immer ob du solche Tools überhaupt benötigst.
In der derzeitigen Version benötigst du die ID der Objekte nur noch für Eventsubscriber, an allen anderen Stellen kannst du mit den Namen arbeiten. Und ich gehe davon aus das Sie es an der Stelle auch noch ändern.

Die ersten paar Tage wo ich Tabellen und Pages erstellt und bearbeitet habe, hab ich mir immer eine "Übersicht" der verfügbaren Spalten und Variabeln gewünscht (ala F5). Ist aber alles nur eine Frage der Gewoehnung.

Solange Microsoft OnPremise erlaubt, (und das ist in allen Bereichen der Fall, hoffen wir das es so bleibt) kannst du theoretisch so weiterarbeiten wie bisher. Ob und welche Einschränkungen sich da ergeben, wird sich zeigen.

Das Problem ist weniger "Onpremise", sondern FOB.
Wenn Addon- Anbieter der Meinung sind, dass ihr Addon hervorragend als Extension läuft, was ja beim Test mit der CRONUS- DB in deren Entwicklungsabteilung durchaus sein kann, aber nicht mitbekommen das die freie Wildbahn doch etwas anders aussieht, könnten versucht sein, ihr Addon nur noch als Extension anzubieten, um Kosten zu sparen. Dann steht derjenige, der das dann beim Endkunden zum Laufen bringen soll später auf dem Schlauch.

Auch der RTC wurde von vielen skeptisch gesehen (heute noch). Im Nachhinein war es die komplett richtige Entscheidung, weil die Bedienung und Ergonomie deutlich besser ist.

Den sehe ich ganz und gar nicht skeptisch.
Das war die einzige Möglichkeit das Ganze für mehrere Clienttypen zum laufen zu bringen.
Die Bedienung hätte aber ein wenig kompatibler zum CC sein können, ohne die neue Funktionalität einzuschränken. Poweruser beklagen sich heute noch, warum Alt-F3 nicht funktioniert, wie im CC F7, nämlich mehrere Filter damit setzen zu können, und was an der Auswahl der Felder im erweiterten Filter ergonomisch sein soll, muss mir auch mal jemand erklären. Im Tabellenfilter des CC konnte man die Feldnamen einfach eingeben, wenn man sie wusste. Im RTC muss ich erst in "Zusätzlich" oder "Alle" nach dem Feld suchen .

Ich versuch(t)e eigentlich nur dazulegen, dass die Extensions eigentlich nichts anderes sind als eine neue Art FOBs mit fast den gleichen Möglichkeiten, aber mit Sicherheit mit den gleichen und neuen Problemen.

Gruß Fiddi

...könnten versucht sein, ihr Addon nur noch als Extension anzubieten, um Kosten zu sparen. Dann steht derjenige, der das dann beim Endkunden zum Laufen bringen soll später auf dem Schlauch.

Ist heute auch schon so, wenn der Partner entscheidet, dass er die Objekte von jemandem anders nicht bearbeiten lassen möchte.

...Poweruser beklagen sich heute noch, warum Alt-F3 nicht funktioniert, wie im CC F7, nämlich mehrere Filter damit setzen zu können...

Da hast du allerdings Recht.

Ist heute auch schon so, wenn der Partner entscheidet, dass er die Objekte von jemandem anders nicht bearbeiten lassen möchte.

Nur heute rufe ich beim Partner an und sage ihm ich benötige die Funktionalität, stell mir mal einen Hook oder Feld zur Verfügung, er schickt mir eine neues Objekt, und das Thema ist durch, genauso kann ich relativ problemlos Tabellen und Felder synchronisieren, weil ich auf die Daten zugreifen kann. Wird die Lösung nur als Extension angeboten habe ich ein Problem, weil ich die Daten nicht sehe. Vom Update mal ganz zu schweigen.

Gruß Fiddi

...weil ich die Daten nicht sehe...

Du meinst in der Entwicklungsumgebung?

Ja, natürlich gibt es diese Probleme jetzt schon, deshalb gibt es eigentlich auch nur wenig Unterschiede zwischen Extensions und FOBs.
Der einzige wirkliche Unterschied, der mir einfällt, ist die Möglichkeit Felder unabhängig von anderen Addons in Tabellen und Pages einzufügen.

Ein wesentlicher Unterschied ist, dass man bei der Extension festlegen kann, welcher Tenant in einer Multi-Tenancy-Datenbank diese nutzen darf.

Und das der Kunde mal eben so eine Extension installiert ist eher Wunschdenken, da wenn er Extensions nutzen will die für seinen Job wichtig sind, die eher miteinander verzahnt sind, als das sie nebeneinander her laufen können.

Das von MS anfangs propagierte ERP-Modell, dieses wie Hamburger zu verkaufen, wo sich Endkunden wie im Fast-Food-Restaurant das Menü ausschießlich auf Grundlage der Base App in Form von Extensions zusammenklicken, wird nur im anspruchlosen Umfeld funktionieren. Das ist mir allerdings auch noch nie irgendwo begegnet .
Endkunden erwarten fast immer Betreuung von Menschen mit Branchenknowhow, das kann es da nicht im sinnvollen Umfang geben.

Wesentlich mehr Chancen sehe ich für von Partnern aufgesetzten Cloud-ERPs, welche die notwendigen Add-ons für die Branche enthalten (eher als normaler Code, weil Extensions bislang noch zuwenig können, vor allem eben nicht die Ausführung von Funktionen und Codestellen der Base App unterbinden, was manchmal ja erforderlich ist) und die zusätzlche Feinheiten und eben auch die Kundenanpassungen über Extensions abbilden.
Wenn man das als Multi-Tenant-DB mit Shared Schema aufsetzt, ist es ja nun erstmals möglich, das auch kostengünstig als Gesamtpaket anzubieten; trotzdem kann man gezielt auf Kundenbedürfnisse eingehen, weil Extensions nur für bestimmte Tenants freigeschaltet werden können, was mit normalen Codeerweiterungen eben nicht geht.

Extensions machen die Entwicklung bestimmt nicht einfacher, weil man im Vorfeld sehr viel über mögliche Konflike nachdenken muss und immer auch einen komplett autarken automatisch ablaufenden Upgradecode mitliefern muss, der ohne weiteres Zutun eines Entwicklers vor Ort alles abdeckt, wenn ältere Versionen upgedatet werden müssen.

Dass sich Endkunden aus dem AppSource die eine oder andere Extension dazuholen, wird man kaum verhindern können. Das müssen ja nicht immer "umfängliche Werke" sein. Eine Miniextension, die nicht viel kostet, aber gezielt etwas anbietet, was praktisch fast jeder Betrieb brauchen kann, kann sich nur durch Stückzahlen rentieren. Das kann immer zu Konflikten führen, aber zum Glück ist der Störenfried ja genauso schnell wieder deinstalliert wie installiert, wenn es Probleme geben sollte.

Wenn man die Extension als .app-Datei vorliegen hat, kann man die übrigens entzippen (einfach Dateiendung ändern) und dann in den Code schauen (JSON-Addons für Notepad++ helfen weiter). Das ist natürlich wesentlich unpraktischer als normalen Code zu kontrollieren, aber immer noch besser als eine komplette Black Box.

Hallo,

dem kann ich im wesentlichen zustimmen.
ich frage mich nur welchen Vorteil die Tennants haben?
Die sollten die gleichen Probleme haben, wie die Extensions.
Wenn die Exstension A in Tennant A inkompatibel zu Extension B in Tennant B ist läuft das auch nicht, wenn die Mandanten Daten austauschen müssen. Was aber ja häufig der Fall ist, wenn man mit mehreren Mandaten arbeitet.

Gruß Fiddi

ich frage mich nur welchen Vorteil die Tennants haben?

Tenants ermöglichen das Verwalten von rechtlich getrennten Unternehmen in einer Datenbank. Mandanten sind ja immer Mutter- bzw. Tochterfirmen oder sonstwie verbandelt.

Wenn dein Kunde aber z.B. beim Buchen- Knopf möchte (um Fehlerquellen zu reduzieren), dass der Default nicht "Liefern u. Fakturieren" sei, sondern nur "Liefern", oder das bestimmte Anwender nur Liefern dürfen, und nicht fakturieren, dann war das bisher nur eine kleine Änderung in CU 81 oder 91, die auch beim Merge keinen Ärger gemacht hat.

Wie wird das dann mit VS- Code gehen?

Hab gerade mal Codeunit 81 (gilt auch fuer 82, 91, 92)* offen gehabt da ist mir aufgefallen:

Code:

OnBeforeConfirmPost(PurchaseHeader,HideDialog);
IF NOT HideDialog THEN
  IF NOT ConfirmPost(PurchaseHeader) THEN
    EXIT;

*Stand 2018CU02

nun kannst du dann mit nem Subscriber deine anforderung auch im VSCode umsetzen :)

Hallo,

du hast recht.

Ich kann dann aber nur hoffen, das keine andere Extension die gleiche, oder schlimmer, eine etwas andere Idee hatte, dann muss ich u.U. mehrfach die Auswahl durchführen.

Außerdem kann es nach meiner Meinung nicht Sinn der Extensions oder Events sein, Code des Standards nach zu programmieren.

Gruß Fiddi

Bei Extensions gelten für Feldnamen strengere Regeln.
[...] in jedes Feld muss also ein dem Hersteller zugeordneter eindeutiger Code mit dazu, .

Hier ist der Artikel dazu: Benefits and Guidelines for using a Prefix or Suffix

James Crowter fasst hier diverse Aspekte zu einer oft gestellten Frage zusammen.
What is Microsoft Dynamics 365 Tenerife, really?

Wird die Lösung nur als Extension angeboten habe ich ein Problem, weil ich die Daten nicht sehe.

Mal mehr, mal weniger. Besonders dick kommt es mit dieser OnPremise-Extensionoption, das als Runtime Package bereitzustellen, da sieht man gar nichts mehr, auch nicht beim Debuggen .

Hallo,

ich hatte jetzt gerade einen schönen Fall von Datenfehler. Irgendjemand hatte wohl mal in NAV2.X eine Artikelnr. aus Excel kopiert, und CRLF mit in eine Referenznr. kopiert. Jetzt in NAV 2015 führte das zu Problemen, die sich nicht mehr mit NAV- Bordmitteln lösen ließen. Die einzige Möglichkeit das ganze in den Griff zu bekommen, war der Weg über ein SQL-Skript, das die fehlerhaften Daten gelöscht hat.

Wie soll so etwas in Zukunft funktionieren, wenn man die Daten und womöglich die Referenzen nicht mehr sieht?

Gruß Fiddi

Wie soll so etwas in Zukunft funktionieren, wenn man die Daten und womöglich die Referenzen nicht mehr sieht?

Gruß Fiddi

Ganz einfach: neben C/AL auch noch TSQL lernen. Und wenn nötig noch AL und VisualStudioCode