Event Subscriber Web Service

This document describes the concept of using events as a trigger point of M3 external functionality. The trigger to the M3 external functions are performed through a user defined web service call including the event information in a JSON (JavaScript Object Notation) format. The trigger is a "Fire and forget" type and does not wait for any reply from the receiver. If information should be sent back to M3 based on the trigger it should be performed using normal M3 APIs.

In 'Event Subscription. Open' (CMS045), add a subscription to the M3 table to be used for the API call. The name of the M3 table is used as the event name and M3 as the publisher.
The subscription must be activated for event based API calls and must also be set as active.
Define the web service call in 'Event Subscriber Web Services. Open' (CMS049).

Call trigger

Define when the call should be triggered using filters where logical expressions like Value changed, Equal to for specific fields can be used.

Web service

Define the web service through a URL including selection of how to authenticate.
A special authentication for connection to Infor Mongoose can also be selected.

Information message to be sent

Define an optional information message to be sent together with the normal event information.
Note that all the original event information is sent together with this additional message as a JSON message linked to the web service call.

From both a performance and volume perspective, it is important that the filters are defined correctly and thoroughly tested in an environment with fewer transactions than a production environment. Since a normal M3 environment generates several hundred events per second, poorly defined filters can quickly generate massive amounts of alert messages.
Once the web service has been defined the corresponding autojob must be restarted before the updated subscriptions become active in the Event Hub and the new definitions updated to cache.
Restart the autojob in 'Subsystem. Open' (MNS050) and select related option 'Job in subsystem' (Option 11) for the autojob subsystem (normally named ASJ).
Find the autojob CMS949 (Event subscription - event log) in the list.
End it and once stopped, start it again.

Troubleshooting

An error log is connected to the web service call. Erroneous calls are logged with reason sent back from the receiver, the primary key of the event as well as the function resulting in the original event. Based on this information, the originating action can be reprocessed if required when the problem has been corrected.

An alternate way to troubleshoot is to turn on the concept log for the autojob in the server view, or admin pages in a cloud environment. Once activated, generate a new event and then view the concept log written to the autojob log. Every validation performed within the autojob is written to the log as a readable text.