Event Publisher/Subscriber Erklärung

Hallo,

in dem Walkthrough hier: Publishing, Raising und Subscribing an Event

ist die Vorgehensweise so beschrieben:
1. Event Publisher OnAddressLineChanged Function in Codeunit Publishers erstellen.
2. In der Page 21 im betroffenen Feld "Address - OnValidate()" der Aufruf zur Publisher Function. (Publisher.OnAddressLineChanged(Address); )
3. Event Subscriber Function CheckAddressLine mit Logik in Codeunit erstellen.

Ich verstehe den zweiten Schritt nicht so richtig (auch schon hier gelesen, Introducing Events)

Was unterscheidet den Aufruf des Events dort zu dem Aufruf einer Normalen Funktion die in einer Codeunit liegt ?
Ich glaub ich hab das Prinzip noch nicht so ganz verstanden

Danke.

Hallo,

Was unterscheidet den Aufruf des Events dort zu dem Aufruf einer Normalen Funktion die in einer Codeunit liegt ?

Das Prinzip soll eigentlich sein, das du im Standard, also auch im Onvalidate- Trigger, keinen eigenen Code mehr hast, sondern nur noch die vom NAV bereitgestellten Events nutzt. Dadurch soll der Update- Vorgang theoretisch vereinfacht werden. Ob das praktisch auch so ist, muss sich noch zeigen.

In deinem Fall würdest du keinen eigenen Publisher definieren und aufrufen, sondern z.B. den OnAfterValidate- Event des Feldes nutzen, um deinen eigenen Subscriber (Code) auszuführen, wenn es denn passt.

Ein weiterer Unterschied ist, dass du den Pullisher aufrufen kannst, ohne das jemand darauf hört. Der Aufruf geht also ins Leere ohne Fehler.
Außerdem kann ein Publisher mehrere Subscriber haben, deren Code nacheinander ausgeführt wird. Nur ist nicht definiert und nicht steuerbar in welcher Reihenfolge.

Gruß Fiddi

Nur ist nicht definiert und nicht steuerbar in welcher Reihenfolge.

Das wird sich sicher irgendwann aendern:
https://github.com/Microsoft/AL/issues/3617

Wann ist irgendwann?

Das ganze ist so komplex, dass niemand dafür wirklich eine Lösung haben kann. Denn kein Programm oder KI der Welt kann entscheiden, in welcher Reihenfolge die Subscriber ausgeführt werden müssten.

Dazu musst du ganz genau wissen, was in den einzelnen Routinen passiert, und welche Daten von wem benötigt werden. Das können nur die Entwickler der Extensions untereinander ausmachen. Du müsstest also für jeden mehrfach- Event für jede Kombination aus Extensions definieren, wer zuerst kommt. Ein Benutzer wäre damit hoffnungslos überfordert, und die Entwickler auch.

Gruß Fiddi

Hi,

Das Prinzip soll eigentlich sein, das du im Standard, also auch im Onvalidate- Trigger, keinen eigenen Code mehr hast, sondern nur noch die vom NAV bereitgestellten Events nutzt. Dadurch soll der Update- Vorgang theoretisch vereinfacht werden. Ob das praktisch auch so ist, muss sich noch zeigen.

Klingt ganz nützlich

In deinem Fall würdest du keinen eigenen Publisher definieren und aufrufen, sondern z.B. den OnAfterValidate- Event des Feldes nutzen, um deinen eigenen Subscriber (Code) auszuführen, wenn es denn passt.

Ein weiterer Unterschied ist, dass du den Pullisher aufrufen kannst, ohne das jemand darauf hört. Der Aufruf geht also ins Leere ohne Fehler.
Außerdem kann ein Publisher mehrere Subscriber haben, deren Code nacheinander ausgeführt wird. Nur ist nicht definiert und nicht steuerbar in welcher Reihenfolge.

Die Events sollen also helfen dass man den Funktionsaufruf welchen ich momentan auf einer Page oder sonstwo setze, nicht mehr nötig ist? (In zukunft?)
Es macht momentan also kein Unterschied ob ich im OnValidate Trigger der Page21

Code:

Publisher.OnAddressLineChanged(Address); 

oder

Code:

Subscribers.CheckAddressLine(Address);

aufrufe? Und irgendwann muss ich weder noch im OnValidate aufrufen?

Geht darum dass wir in Zukunft möglichst ohne viel Aufwand die Updates einspielen können. Da hatte ich heute ein Gespräch mit unserem NAV Partner, ich bekomme zwar demnächst eine Entwicklerschulung welche mir noch NAV2018 Grundlegende Dinge beinringen soll, heute viel aber schonmal Stichwort Events, welches ich bisher nur von Extensions kannte, das ich nicht wusste man Events auch so benutzen kann ohne Extensions, wollt ich das mal ausprobieren.

Die Idee dahinter ist, das du nichts mehr in den Standardobjekten hinzufügst.
"Früher" hast du Sachen in den OnValidate Trigger direkt geschrieben, oder ne Funktion geschrieben welche im OnValidate aufgerufen wird.

Wenn du nun im OnValidate der Address des Customers etwas machen möchtest legst du dir in einer Codeunit einen SubScriber an

Code:

[EventSubscriber(ObjectType::Table, Database::"Customer", 'OnAfterValidateEvent', 'Address', false, false)]
local procedure MeinErsterSubscriber(var Rec : Record "Customer"; var xRec : Record "Customer");   
begin
Message('mach was cooles');
end;


wenn du nur etwas im onvalidate auf einer bestimmten Page machen möchtest passt du den Subscriber an:

Code:

[EventSubscriber(ObjectType::Page, Page::"Meine Bestimmte Page", 'OnAfterValidateEvent', 'Address', false, false)]


Die Events sollen also helfen dass man den Funktionsaufruf welchen ich momentan auf einer Page oder sonstwo setze, nicht mehr nötig ist? (In zukunft?)

Das ist richtig.

Es macht momentan also kein Unterschied ob ich im OnValidate Trigger der Page21

Code:

Publisher.OnAddressLineChanged(Address);

oder

Code:

Subscribers.CheckAddressLine(Address);

Ich glaube, da habe ich mich falsch ausgedrückt:
Statt deines eigenen Eventpublishers, den du in der Page definiert hast, sollst du dich mit einem existierenden Eventpublisher verbinden.
Wenn du einen eigenen Publisher definierst, hast du ja wieder eigenen Code in der Page definiert, das soll ja gerade vermieden werden. Ob du das durchhalten kannst, musst du selbst herausfinden.

Generell ist der Ansatz möglichst wenig eigenen Code im Standard- Code einzufügen sicherlich nicht falsch. Man sollte sich überlegen, ob man ellenlange IF- und Case- Staments direkt da einfügen muss, wo sie gebraucht werden, oder man lagert das ganze in eine Funktion aus, die den Code enthält. Dann hast du im Standard- Code nur eine Zeile stehen, den man leicht mergen kann.

Generell finde ich letztere Art zu programmieren übersichtlicher, da man beim lesen des Codes sieht was passiert. Mit den Events ist da evtl. einer oder mehrere der/die etwas tun, aber man sieht es nicht im Code, bzw. erst im Debugger. Das macht die Fehlersuche nicht einfacher.

Gruß Fiddi

Guten Morgen,

ich glaub dann hab ich es jetzt verstanden.

Ich dachte bei EventFunction ist "schluss" und hatte nicht gesehen dass man noch ein "EventPublisherElement" auswählen kann.

Jetzt habe ich einen Subscriber der "was cooles macht" ohne Code in der Page/Table zuzutun. Coole Sache.

Noch eine "ästhetische" Frage.
Wenn ich im C/AL Code bin und Shift+f4 drücke, komme ich zu den Eigenschaften der Codeunit, welcher ist der schnellste weg um an die Eigenschaften der Funktion zu kommen?
Momentan rufe ich C/AL Globals auf,Funktionsübersicht, gehe zu der passenden Funktion und drücke dort Shift+F4

Danke

Zuletzt geändert von elTorito am 17. September 2018 10:00, insgesamt 1-mal geändert.

Coole Sache.

Du musst dich auf alle Fälle umgewöhnen, da du nicht mehr alles siehst, was dein Programm tut, wenn du dir den Quellcode anschaust.

Gruß Fiddi

Coole Sache.

Du musst dich auf alle Fälle umgewöhnen, da du nicht mehr alles siehst, was dein Programm tut, wenn du dir den Quellcode anschaust.
Gruß Fiddi

Gutes Kommentieren kann da bestimmt helfen?

Coole Sache.

Du musst dich auf alle Fälle umgewöhnen, da du nicht mehr alles siehst, was dein Programm tut, wenn du dir den Quellcode anschaust.
Gruß Fiddi

Gutes Kommentieren kann da bestimmt helfen?

Und auch das ist schwierig, weil es ja am gleichen Event mehrere Subscriber geben kann, die du evtl. gar nicht siehst.
Da man bei Problemen eh immer den Debugger verwenden muss, ist das in meinen Augen kein Problem.

Da man bei Problemen eh immer den Debugger verwenden muss, ist das in meinen Augen kein Problem.

Du kannst aber zur Fehlereingrenzung nicht mal eben einen Subscriber aussperren, wenn du nicht an den Code kommst. Mit normalem C/AL ist das mit '//' getan.

Gruß Fiddi

Hmm. Okay verstehe. Ich könnte 2 Subscriber haben die im OnAfterValidate Address etwas machen, wenn ich eine Codeunit habe mit 100 Funktionen, und der eine Subscriber steht oben, und der andere unten.
Dann kann das schonmal durchgehen dass da noch was ausgeführt wird wo man nicht dran denkt, und man wundert sich über "komische" Auswirkungen. Ganz davon abgesehen dass ein Subscriber in einer Extension oder von wem anderes in einer anderen CU oder Extension den Event auch noch abboniert haben könnte, wo ich dann gar keine Kenntnis von hätte. Hmm. Klingt in der Tat etwas kompliziert den Code nachzuvollziehen.

Da man bei Problemen eh immer den Debugger verwenden muss, ist das in meinen Augen kein Problem.

Du kannst aber zur Fehlereingrenzung nicht mal eben einen Subscriber aussperren, wenn du nicht an den Code kommst.

Und wenn man eine Extension hat, wo nicht ausdrücklich

Code:

"showMyCode": true

in der app.json dazugeschrieben wurde (Vorgabe ist false ), dann kann man die gar nicht mehr debuggen .
ShowMyCode – Politics & Microsoft Dynamics 365 Business Central

...

Code:

"showMyCode": true

in der app.json dazugeschrieben wurde (Vorgabe ist false ), dann kann man die gar nicht mehr debuggen ...

Das halte ich ja persönlich für eine Fehlentscheidung.

Das halte ich ja persönlich für eine Fehlentscheidung.

Das ist nur die Frage, wer da in einer Firma gewinnt, der erfahrene Supporter der sagt, ich brauch den Debugger, oder der Vertriebler, der den Code vor kopieren schützen will.

Gruß Fiddi

Und wenn man eine Extension hat, wo nicht ausdrücklich

Code:

"showMyCode": true

in der app.json dazugeschrieben wurde (Vorgabe ist false ), dann kann man die gar nicht mehr debuggen .

Mit den aktuellen AL-Versionen wird bei Erstellung von einem neuen AL-Projekt nun automatisch eine solche Zeile

Code:

"showMyCode": true

in die app.json eingefügt.