Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Edition)

Mich wuerden in diesem Zusammenhang viel mehr die Lizenzmodelle interessieren.
Oder auch wie es danach mit Inhouse-Entwicklungen aussieht. Ich hoffe ein wenig das Sie sich hier an Salesforce orientieren.
Was auf den TechDays vorgestellt wurde war ja sehr Partner orientiert.

Hat schon jemand etwas drüber gehoert?

Ein paar Tipps von FreddyDK für weitere Entwicklungen: What would you do?

Hey zusammen,

Ein paar Tipps von FreddyDK für weitere Entwicklungen: What would you do?

ich würde gerne einmal über das Vorgehen und die weitere Entwicklung diskutieren und Erfahrungen austauschen

Ich habe meinen Entwicklungsstand im Step 3 - es lässt sich in alle möglichen Länderversionen mit der Powershell ohne manuelle Nacharbeiten integrieren.
Für Step 4 habe ich angefangen den Code aus den Standardobjekten zu entfernen und nur noch mit Events zu arbeiten. (Ich liebe das OnAfterInsertEvent <3 )
Nun komm ich aber an Grenzen welche dem Auszug wiedersprechen:

Like 2 or 3 – except that the solution is using event based architecture, using events to modify base behavior where possible and if no events are available, a new event is introduced in the base app as the only code modification to merge. A merge tool or the merge Cmdlets are used to automagically merge updates from Microsoft with the solution.

Zum Beispiel wird beim Vendor auf dem Feld Contact OnValidate folgendes aufgerufen: VALIDATE("Primary Contact No.",'');
Im Validate von "Primary Contact No." ist die erste Zeile: Contact := '';
Somit ist es nicht mehr möglich einfach einen Namen als Kontakt zu hinterlegen.

Nun sagt der Step4 das man im Standard Code keine Änderungen machen soll (außer neue events).
Die Änderung dafür wäre simple und schnell erledigt indem man die Anweisung einfach in die Bedinungen setzt, aber das wiederspricht der Aussage.
Soll ich nun hoffen das Microsoft dies irgendwann ändert?


Anderes Beispiel:
Auf der Tabelle Purchase und Sales Line wurde in der Desription - OnValidate hinzugefügt das nach "anderen" Artikeln mit der gleichen Beschreibung gesucht wird dann ein Confirm kommt ob man dieses gern übernehmen möchte.
Das ganze geht so lang gut, bis man anfängt die Daten per Webservice in die Tabelle zu schreiben.
Jetzt steh ich wieder an der gleichen Stelle, ich kann einfach ein "IF GUIALLOWED THEN" davor setzen und es funktioniert. Ich soll in Step 4 aber keinen Standard Code verändern.


Mir fehlt irgendwie eine Option "Skip Standard Code" oder ähnliches.
Ich hab noch 2 .. 3 andere Sachen wo ich mir noch nicht sicher bin wie ich das Ganze erledige, aber ich denke das reicht fürs erste.



Wie geht ihr damit um?

Hallo,

Ich persönlich stehe dem ganzen Eventing noch ein wenig skeptisch gegenüber.

Man müsste glaube ich, nicht lange überlegen um noch zig andere Fälle zu finden, bei denen man mit Events an die Grenzen stößt.

• Bräuchte man das Ergebnis eines Events (gesetzte Variablen) um im gleichen Trigger/Event weitere Programmschritte durchzuführen. (hier Zahlungsverkehr generiert Variablen, die mit einer Branchenlösung synchronisiert werden müssen, die ähnliche Felder enthält) Hier hat man gleich zwei Probleme: 1. Normalerweise weiß man gar nicht, was das andere Modul macht, weil man den Sourcecode ja nicht kennt. 2. es ist meines Wissens nicht definiert, in welcher Reihenfolge Eventfunktionen abgearbeitet werden.
• Das Einfügen eigener Eventfunktionen (was zwangsläufig passieren wird, um die Reihenfolge der Ausführung zu gewährleisten) führt Irgendwann zu einer Eventhölle, bei der niemand mehr weiß, wann welcher Event wofür zu benutzen ist.)
• Die Reihenfolge der Abarbeitung des Codes ist in einem ERP- System leider nicht unwichtig, damit das ganze funktioniert, da darf niemand eine Schreibtransaktion anfangen, wenn noch Meldungen angezeigt werden müssen. Das lässt sich bei unbekannten Events nur schwer prüfen. Auch ein unmotiviert eingestreutes COMMIT in einer Extension an der falschen Stelle, weil der "geniale" Programmierer sich gerade nicht anders zu helfen wusste, kann zu merkt würdigen Effekten führen.
• Schon eine einfache Branchenlösungs-/ Kundenanpassung, die z.B. standortabhänge Preise benutzen möchte, was eine Erweiterung des Primärschlüssels der *Price7Discount- Tabellen bedeuten würde, dürfte die meisten Extensions, die auf die gleichen Tabellen zugreifen, zum Einstürzen bringen.
• Eine Anpassung der Preisfindung, die z.B. Edelmetallzuschläge (Preis auch abhängig vom enth. Edelmetallgewicht) würde es in der Preisfindung CU7000 bzw. CU7010 nötig machen an diversen Stellen Hooks bzw. Events einzubauen, mal ganz davon abgesehen, das man die Anzahl der Parameter der enthaltenen Funktionen (siehe auch vorheriges Beispiel) eigentlich erweitern müsste, was aber aus Kompatibilitätsgründen nicht geht, da andere Extensions ja eben diesen Standard erwarten, und somit die eigentlich angepasste Preisfindung in diesen Extensions falsche Informationen liefert.
• Wie sich die Extensions bei Updates verhalten, wenn Feld- Erweiterung in den Postentabellen enthalten sind, sollte man auch ausführlich testen. Ich glaube es ist keine gute Idee bei einigen 10 Mio- Posten zunächst alle Extensionfelder aus den Tabellen zu entladen, um sie nach dem Update wieder an ihre ursprüngliche Stelle zu befördern. Mal ganz davon abgesehen, das sich die Anzahl Datensätze ändern könnte, und man eigentlich hätte diese entladenen Daten ebenfalls hätte konvertieren müssen.
• Was passiert bei einem NAV- Update, und es gibt keine passende Extension- Version für die aktuelle NAV- Version, weil der Anbieter es nicht fertig hat, oder es ihn nicht mehr gibt.? (interessant für die Cloud- Version)

Lange Rede kurzer Sinn:

• Extensions sind eine schöne Sache, wenn Sie sich weitestgehend aus dem System heraus halten, und etwas tun, das den Rest des Systems nicht oder kaum tangiert.
• Extensions und Events funktionieren auch dann gut, wenn sie in Ihrem jeweiligen Gebiet alleine sind. Zwei oder mehr Preisfindungserweiterungen in einem System werden mit nahezu 100 prozentiger Sicherheit nicht funktionieren. Das ist aber, was durch die Extensions suggeriert wird, ich muss nur in den Appstore gehen, mir eine Extension kaufen und dann geht das.
  In Deutschland gibt es noch das Thema des Zahlungsverkehrs, der als Erweiterung von verschiedenen Anbietern in einem großen Teil der NAV- Systeme integriert ist.
• Events kann man gut nutzen, wenn es nicht so darauf ankommt, wann was passiert (z.B. OnDelete- Trigger oft aber nicht immer), aber das ist ziemlich selten in NAV. Aber schon beim Ondelete kann es kompliziert werden: Wenn ich einen Beleg in NAV löschen möchte, muss ich sicherstellen, das ich den Beleg (und evtl. auch die Daten aus der Extension) archivieren kann, bevor ich die Daten lösche.
• Es ist sicherlich keine Gute Idee in einer Standardfunktion 200 Zeilen Spagetti- Code einzufügen, das sollte man mit einem oder mehren Funktionsaufruf(en) (Hooks) erledigen. Das macht das ganze übersichtlicher, und das Mergetool wird es dir danken. Dafür braucht man aber keine Events.
• Es aber auch keine gute Idee alles in eine endlose Verschachtelung von einzeiligen Funktionen, was in NAV2017 anscheinend gerne gemacht wurde, zu verfrachten. Dadurch gewinnt man nicht unbedingt Übersicht, und man stellt sich u.U. selbst ein Bein, weil man nicht mehr mitbekommt was eigentlich passiert, und programmiert alles doppelt.

Wenn ich das auf den TechDays richtig verstanden habe, werden die Events nach der Objekt Reihenfolge (Id) aufgerufen.
Nach meinem Verständnis her:
wenn ich auf die Reihenfolge der Aufrufe angewiesen bin, dann nutz ich den falschen Trigger. Eigentlich müsste der erste Triggeraufruf dann auch wieder Events zur Verfügung stellen.
Da stellt sich dann aber die Frage wie das Ganze gemacht wird, wenn ich auf das Ergebnis/Triggers eines gekauften Moduls angewiesen bin, da der Code davon hier ja nicht mehr bekannt ist.

Schon eine einfache Branchenlösungs-/ Kundenanpassung, die z.B. standortabhänge Preise benutzen möchte, was eine Erweiterung des Primärschlüssels der *Price7Discount- Tabellen bedeuten würde, dürfte die meisten Extensions, die auf die gleichen Tabellen zugreifen, zum Einstürzen bringen.

Wenn ich es richtig verstehe ist es gar nicht mehr Möglich die PK's anzupassen. In einen der Vorträge wurde überlegt ob NAV nicht einfach nur die Grundfunktion zur Verfügung stellt (das akutelle 365) und anschliessend der Kunde entscheiden kann welche "Branchenlösung" er installieren möchte. Die Version von Microsoft oder eine vom ISV es soll aber nur eine dieser Lösungen erlaubt sein.

Wenn ich es richtig verstehe ist es gar nicht mehr Möglich die PK's anzupassen. In einen der Vorträge wurde überlegt ob NAV nicht einfach nur die Grundfunktion zur Verfügung stellt (das akutelle 365) und anschliessend der Kunde entscheiden kann welche "Branchenlösung" er installieren möchte. Die Version von Microsoft oder eine vom ISV es soll aber nur eine dieser Lösungen erlaubt sein.

Gute Idee, aber wie löse ich das mit der Zahlungsverkehr- Extension, der Webshop-Extension, die ich bei Bedarf bei den Kunden dazu installieren möchte/muss/will, die aber Programmcode verwenden, der das Wissen des bzw. über den jeweiligen anderen bedürfen?

Gruß Fiddi

Man kann zumindest einer Extension sagen wovon sie Abhängig ist.
https://msdn.microsoft.com/en-us/library/mt600278(v=nav.90).aspx
Wie es dann aber in deinem Beispiel mit verschiedenen Lösungen aussieht, weis ich natürlich nicht.
Spontan würde ich nun sagen das du gar keine Abhängigkeiten angibst und in dem Webshop dann "Connectoren" zu allen von dir Supporteten Zahlungsverkehr- Exntension entwicklest. Wie sich das dann allerdings gestaltet, ohne das du den Code kennst, ist dann natürlich die Frage. Ich geh davon aus, dass die Extensionanbieter untereinander reden müssen ala "Hey wir würden gerne euren Zahlungsverkehr an unserem Webshop anschliessen, wir bräuchten dafür xy"


Ich finde Extensions und der Trigger gesteuerten Idee echt super (mag vielleicht daran liegen das ich aus ner Entwicklungssparte komme).
Mir fehlen allerdings an einigen Ecken einfach die Ideen zur Umsetzung. Deswegen auch meine angefangene Diskussion dazu

Ich geh davon aus, dass die Extensionanbieter untereinander reden müssen ala "Hey wir würden gerne euren Zahlungsverkehr an unserem Webshop anschliessen, wir bräuchten dafür xy"

Das würde aber dem widersprechen, was die Extensions eigentlich bewirken sollen, eine Vereinfachung.
Z.Zt. muss einer für eine bestimmte Kombination aus ISV-Lösungen etwas tun, bzw. sich darum kümmern, das alles in der richtigen Reihenfolge abläuft. (den Merge machen), und eine Schnittstelle an den Überschneidungen prüfen bzw. implementieren.

Stell dir mal vor zu Zahlungsverkehr und Webshop kommt noch eine Logistiklösung, und eine Zollanmeldung dazu. Alle greifen auf die gleichen Daten zu, und müssen miteinander verzahnt sein, wie willst du das noch mit Extensions lösen?

Das Prinzip der Extensions an sich, ist keine schlechte Idee, und man sollte Sie durchaus im Hinterkopf haben. Aber man kann auch mit normalem C/AL eine ähnliche Funktionalität realisieren (z.B. über Hooks), die sich aber wesentlich besser steuern lässt, und auch mit einem brauchbaren Mergetool keinen größeren Pflegeaufwand bedeutet.

Gruß Fiddi

Fiddi: Schön dass ich hier mal von jemandem lese der genau die Bedenken hat die ich auch habe. Ich höre & lese nämlich sonst nur von Realitätsverweigerern die mir erzählen wollen wie toll das alles mit Events und Extensions und der "Code-Optimierung" von Microsoft über die letzten Verisionen hinweg sei.