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

Bild Microsoft Dynamics NAV 2017

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon Ted » 5. Dezember 2016 12:17

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?
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon Kowa » 3. Mai 2017 17:26

Ein paar Tipps von FreddyDK fĂĽr weitere Entwicklungen: What would you do?
GruĂź, Kai

Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, Messenger oder Telefon! DafĂĽr ist dieses Forum da.

Download: Dynamics NAV Object Text Explorer (Alternativlink). MVP Alumni
Benutzeravatar
Kowa
Moderator
Moderator
 
Beiträge: 7835
Registriert: 17. Juni 2005 17:32
Wohnort: Bremen
Realer Name: Kai Kowalewski
Arbeitsort: Osterholz-Scharmbeck
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics 365
Microsoft Dynamics Version: BC, NAV 2018 bis Navision 2.01

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon Ted » 4. Mai 2017 18:20

Hey zusammen,

Kowa hat geschrieben: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?
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon fiddi » 4. Mai 2017 20:03

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. :twisted:
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7091
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon Ted » 5. Mai 2017 09:59

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.
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon fiddi » 5. Mai 2017 10:12

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
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7091
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon Ted » 5. Mai 2017 10:37

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
GruĂź
Ted
Ted
 
Beiträge: 328
Registriert: 18. September 2014 11:16
Realer Name: Dennis Reinecke
Arbeitsort: Berlin
Bezug zu Microsoft Dynamics: End-Anwender
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: 2015+

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon fiddi » 5. Mai 2017 11:02

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
Wer aufhört besser zu werden, hat aufgehört gut zu sein. (frei nach Philip Rosenthal)
Frage beantwortet? Schreibe bitte [Gelöst] vor den Titel des ersten Beitrags.
Bitte erst suchen, dann fragen. Bitte beachte den kleinen Community-Knigge.
Kein Support per PN, Mail, IM oder Telefon! DafĂĽr ist dieses Forum da.
fiddi
Moderator
Moderator
 
Beiträge: 7091
Registriert: 9. Juni 2008 10:13
Realer Name: Hans Heinrich Fiddelke
Arbeitsort: Bremen
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV
Microsoft Dynamics Version: NAV2.6-aktuell

Re: Von 'Corfu' nach 'Madeira' (NAV 2017, 365 Business Editi

Beitragvon enh » 11. Mai 2017 20:31

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.
enh
 
Beiträge: 2330
Registriert: 5. Februar 2014 15:42
Bezug zu Microsoft Dynamics: Microsoft Partner
Microsoft Dynamics Produkt: Microsoft Dynamics NAV

Vorherige

ZurĂĽck zu NAV 2017

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast