Creating Events in Navision

The following is a very simple example of how to raise events from the Navision business logic. Navision simply detects a condition, and raises an event immediately.

  1. State and analyze your business problem. The example followed here is: notify when a customer is blocked (when the Blocked status changes from False to True).

  2. Decide what data should be in the XMLport. For example, the ID and Name of the customer; the date when the change happened; and the salesperson code. The salesperson code can then be used for filtering in Business Notification so that each salesperson can get notifications about their own customers.

  3. Create an XMLport that contains the data you need. "The Application Designer’s Guide" and the C/SIDE online Help provide the information you need. In this example, it could be called "Customer" (although you may want to establish some naming convention. For example, you may want to call it something like "Customer Notification.") Remember that this is the name that will be seen as the "business entity" in the Notification Designer.
    TagNames should not contain spaces and the Format/Evaluate property of the XMLport must be set to "XML Format/Evaluate" (this is not the default, so you do have to change it yourself.)

  4. Add an event to the XMLport by using the Events Designer (accessed from View menu, under the XMLports Events option). In this example, it could be called "HasBeenBlocked." This name is also visible in the Notification Designer.

Now you have to find where to raise the event in the business logic. In this example, this would be in the OnModify trigger in the Customer table (obviously, we will then not catch the case where a customer is created and Blocked is set to True from the beginning - but that was not the purpose, either. The purpose was to catch situations where a customer that was previously unblocked is being blocked.)

  1. To raise the event in the business logic, you must  declare the XMLport you have created as a local variable. It could, for example, be called "CustXMLDoc" (this name is not visible in the Notification Designer).

  2. Next, add the following to the OnModify trigger: 
    IF Blocked = Blocked::All THEN
    IF Blocked <> xRec.Blocked THEN

  3. Now you can use the Notification Designer to create a scheme that handles this event which will be available as the "HasBeenBlocked" event for the "Customer" business entity.


This example is obviously very simple. Most solutions will, however, be much more complex. This raises the issue of how to test the solution and find errors. If nobody is receiving notifications and you think that they should be, there are at least three places to look for mistakes: (1) in the Navision business logic, (2) in the scheme in Business Notification, or (3) in the infrastructure setup such as problems with mail servers and so on. It could also be due to a genuine bug in either of the components in the system. In order to see if Navision actually raises the event when you think it should, you could replace


with, for example:

DIALOG.MESSAGE('%1 blocked', Name);

Then you will get a confirmation dialog when the event should be raised and you can test if it is, indeed, raised when it should be. This approach is obviously best suited when events are raised "interactively" and not when run as a batch job. Still, in the second case, you may be able to adopt a similar approach.