(And now for something completely different)
Someone recently pointed out to me that AX (as of version 6) has the possibility of using publishers.
For those of you who are not familiar with the concept, let me offer a brief, somewhat skeptical, explanation.
Pub/sub is a concept where a class A reports (publishes) an event rather than acts on it (Extra! Extra! Read all about it! Somebody just clicked on me!). Its subscribers, any number of classes, receive the event and perform whatever action it is they think they should do.
A publisher is therefore essentially an event splitter (Do not quote me on that. Some people might just bite your head off).
For old-school developers (Yes, I started out as a COBOL clown back in the 80s) this is totally dreadful. Structured programming is completely out the window, as execution becomes somewhat unpredictable.
Let me show an example:
The publisher class:
class Elsevier
{
public static void publisher(XppPrePostArgs _args)
{
}
public void callme()
{
this.eventBroker();
}
delegate void eventBroker()
{
}
}And three subscribers:
class ReadElsevier1
{
static void method1()
{
info("Oh when the Saints");
}
}
class ReadElsevier2
{
static void method1()
{
info("Go marching in");
}
}
class ReadElsevier3
{
static void method1()
{
info("That's when I like to be in that number.");
}
}Next I’ll write a little job to test the workings and outcome…
static void pubsubdemo(Args _args)
{
Elsevier elsevier = new Elsevier();
elsevier.eventBroker += eventhandler(ReadElsevier1::method1);
elsevier.eventBroker += eventhandler(ReadElsevier2::method1);
elsevier.callme();
elsevier.callme();
elsevier.eventBroker -= eventhandler(ReadElsevier1::method1);
elsevier.eventBroker -= eventhandler(ReadElsevier2::method1);
elsevier.eventBroker += eventhandler(ReadElsevier3::method1);
elsevier.callme();
elsevier.eventBroker += eventhandler(ReadElsevier1::method1);
elsevier.eventBroker += eventhandler(ReadElsevier2::method1);
elsevier.eventBroker -= eventhandler(ReadElsevier3::method1);
elsevier.callme();
}Nutshell: Publisher Elsevier has a delegate method (event broker) that rings the bell every time the method callme is executed. With the eventhandler we subscribe (and unsubscribe) the classes ReadElsevierX to the ringing of the bell.
I first subscribe ReadElsevier 1 and 2, then call the publisher twice.
Then I unsubscribe 1 and 2, subscribe 3 and call the publisher again.
Finally, I subscribe 1 and 2, unsubscribe 3 and make one last call.
When I execute the job, I get:
Wonderful! Exactly what I was going for. Louis lives.
But oh horror! When I run the job again, I get a different result…
Chaos has descended upon us! The order of events is determined by heartbeats and clock ticks, not through structure and programming lore. Surely the end of the world is neigh and Beelzebub has a devil put aside for me.
I am not exactly sure what goes on under the hood, but what I like to think is that the execution of events is determined by processor availability rather than through processing wait time. From that perspective this methodology is the slicing of the bread in an era where single core systems are as extinct as COBOL programmers.
Of course you need some serious processes to rake in the benefits of this multi-threading technique, but it’s good to know that it’s available if you ever should need it. And in case you always wondered what these oddball delegate methods are doing, you now have the answer: PubSub has come to your neighborhood.
There is much more to say about the subject. PubSub is intended for asynchronous messaging between applications and will without doubt be available as such in the future. Imagine that an AX class can publish an event to any of your other software. The possibilities are unlimited.
But there are pitfalls. For one thing, I recently ran into some custom code that used a publisher for a single threaded process. When I asked the programmer why he had chosen a pub/sub solution, he answered that this is what he was taught in training as being the Microsoft preferred customization standard. No doubt this is related to Microsoft’s vision on 365 cloud solutions, but I think there are better ways to avoid overlayering. Delegates are a performance risk (I will elaborate on that in the future), and they are a potential security hazard. What also bothers me is the lack of check. Sometimes (most of the time?) it is good to know that action B follows as result of action A and that B is actually done. This may be challenging using delegates. Don’t get me wrong, I love them. However the fact that I love space ships doesn’t mean they are the best mode of transportation to the nearest convenience store.
In the future it will be great to have AX publish to other applications. This really offers unlimited potential. For now however AX Won’t even allow publishers and subscribers to be on different tiers. If a publication is made server side, then the subcription class must also run on the server or it will simply misfire.
More reading:
Thanks for that very clear explanation.