This topic describes how to raise events from the Navision business logic and it outlines some of the background and terminology used.
Business entity: the name used by Business Notification for the representation of a "real-world" object, such as a sales order.
In Navision, however, a business entity, such as the sales order, is typically represented as a number of tables, at least a header table and a lines table. Furthermore, some of the data that would be on a traditional, paper-based sales order, is stored in related tables: For example, in a Navision sales order, the header table contains a Payment Terms Code. This field has a table relation to the Payment Terms (in relational database terms it is a foreign key). Yet on the printed order confirmation (a report) the text from the related table is used in order to print a more readable version of the payment terms ("1 Month/2% 8 days" instead of "1M(8D)".)
So, in a way, a Navision report is already, in some ways, a "business entity." The business entities relevant for Business Notification are, however, created as XMLports in Navision.
XMLports are a new feature in Navision 4.0. In short, they provide a way to produce an XML document from one or more tables, somewhat equivalent to what you can do when designing a report. The Navision documentation contains all the details about how to design an XMLport in general.
For the purpose of Business Notification, an extension has been made to XMLports that allows such an XML document to be transmitted to Business Notification from C/AL code.
The mechanism used for this is the event. An event serves two purposes:
Firstly, in Navision, when a event has been defined for an XMLport, it can be called just like a function. But an event does not have a function body: when it is called, the XML document that the XMLport the event "belongs to" is sent to Business Notification.
Secondly, in the Business Notification designer, events serve to communicate between the C/AL developer and the Business Notification scheme developer. Choosing good names for events, that clearly communicate the circumstances under which the event is raised in the C/AL code makes it a lot easier for the scheme developer to decide how to handle the event, what filters to set, what internal users should have permission to subscribe, what title and description to give the scheme to support internal users when they use the subscription application, and what external recipients it would be relevant to send the notification message to.