AX7 – Events and Subscriptions

Again I use mfp’s two cents as inspiration for this blog entry and detail things a little. He showed some subscription and explained that subscriptions now do not force you to modify the publisher of the event anymore. For example, in AX 2012 you had to add a post event to a method and use its properties to tell which method of which class is the subscriber. As mfp points out this has changed by the move to attribute-driven subscriptions. I would like to add the types of events you can subscribe to plus tell you how easy it is to use Visual Studio to define new subscriptions and how existing subscriptions can be found.

Why we should use events

If it’s not clear to you yet what the actual benefit of eventing is I would like to note that in AX 2012 already the first and most important one is upgrade complexity and in the end upgrade cost. Code modifications do need to be merged potentially, event subscriptions don’t. I know that saying so simplifies things a little…
Secondly there were some changes made in the structure of the application that make a transition to eventing mandatory in some cases. I’ll cover this topic later with a separate blog post (or likely several) but for reference the keyword here is Packages.

Types of events

There are three types of “events” you can subscribe to in AX7:

  • Standard events
  • Delegates
  • Pre-/Post-Events

Standard events

AX7 Table EventsThe biggest change here comes with the Events nodes you find in the designer for a lot of object types. Microsoft introduced loads of standard events for the relevant phases of execution. As an example in AX 2012 you needed to modify or at least pre- or post-event the update() method of a table to extend its behavior. Both still is possible but in addition to that there are two events you can subscribe to, onUpdating() and onUpdated().

Delegates

Delegates were there before and still are but subscribing to them changed. What changed and is said to be an ongoing process in the future is that Microsoft adds delegates in certain places to enable us to extend the behavior of things (without having to modify standard code). An random example would be that in class WmsLocationTreeBase there’s a delegate for the change of the tree so you can subscribe and react to that event:

delegate void treeChanged()
{
}

Pre-/Post-Events

You can still add pre- and post-events to any method. Just the way to do it changed.

Subscribe to events and find subscriptions

AX7 Table Events Copy Find Event HandlerTo create a new subscription in all three cases you can simply right-click the event source, standard event / method / delegate, in the designer of the object and click Copy event handler method. This copies the code for a valid and well-formed subscription method to your clipboard. You only need to create a new event handler class (or use an existing one, of course) and paste the code there which then looks like this (for a table named SomeTable’s event onUpdated()):

[DataEventHandler(tableStr(SomeTable), DataEventType::Updated)]
public static void SomeTable_onUpdated(Common sender, DataEventArgs e)
{
}

As you can see there are attributes and parameters; those differ between event types, of course.

To find existing event subscriptions you can simply right-click the publisher in question and Find event handlers to display all the subscribers in the Find Symbol Results area immediately.

Pitfalls

Be aware of the execution order! Getting back to the example there’s a difference between onUpdated() and the post-event to the update() method. Let me explain it with a little example. Having an update() method like this

public void update()
{
    method1();
    super();
    method2();
}

that has a pre-event as well as a post-event has the following execution order:

  1. Pre-event subscriptions
  2. method1();
  3. Subscriptions to onUpdating()
  4. super() call
  5. Subscriptions to onUpdated()
  6. method2();
  7. Post-event subscriptions

12 thoughts on “AX7 – Events and Subscriptions

  1. Hi, and thank you for this post. If a table is updated with doUpdate, can we still subscribe to the changes?

    • I’m glad you like it. That’s a very good question! The answer is no. Using doUpdate() skips the update() logic and therefore OnUpdating and OnUpdated are skipped, too (actually they are generated as an attachment to the super() call of update() by the compiler).

      • OK, thanks for clearing that up. I was afraid it was like this, but kind of hoping there was a way 🙂

  2. Hi!
    What about tables that are being updated with update_recordset and that do not override the update method?
    Will AX notice that there are subscriptions for the Updating/ed event and perform the update row-by-row instead?
    Thanks for the post! 🙂

    • You’re very welcome! 🙂
      Concerning your (very good) question: If there’s no implementation for update() but event handlers for onUpdating() / onUpdated() the logic included there is executed when update_recordset is used (and row-by-row processing is performed). So it behaves just as if you had overwritten the update() method – which is a good and consistent behavior in my opinion.

  3. Hi,
    I have an ‘onUpdating’ event handler on a table and after a successful compile, the handler is not fired. When I right-click on the OnUpdating event and click ‘Find event handlers’ the reference to the event handler that I created is displayed.

    Any ideas? What step have I missed?

    Thanks,
    Todd

    • Well, usually this works very reliably – especially after the build is successful. You might show me some of the code (your handler class) plus the information in which packages it is located (post here or via email) so I can have a look.

      • One thing I can think of is that the event is only fired if the table you’re subscribing to allows it to be. In case of onUpdating this means the update() method of Common has to be there – or in other words the event is not fired if the update() method was overridden and the super() call isn’t made.

        • I think you identified the issue. The table is ProjTable and the ‘update’ method exists but does not have a call to super(). This is standard AX. It’s the same code in AX2012.
          I can try the pre-post event handlers. That seems to work in AX2012 and hoping it will work in here.

          Thanks for your help.
          Todd

  4. Hi
    Thanks for the post!. As you have mentioned, “doUpdate() skips the update() logic and therefore OnUpdating and OnUpdated are skipped”.
    Is there a way to subscribe to doUpdate events in extensions?
    I have customized code which looks like this:

    myCustomClass.beforeUpdate();
    salesLine.doUpdate();
    myCustomClass.afterUpdate();

    How do I move the above piece of logic to extensions?

    • Hi Chandra,
      I think this is (was) a common customization in SalesLineType. Since there is no way of moving your example to extensions Microsoft made changes to SalesLineType and other similar places which are included in the newer versions. I think the July 2017 release includes the first set of changes for that.
      Does this information help you? If the .doUpdate() call is in standard code that has not been changed yet you might want to open a connect extensibility item for it.
      Best regards
      Volker

Leave a Comment