Thanks for your feedback!
EDIT
Event Status
On the Event Status screen, you can find the list of events that have been sent by publishers to Events Hub and you can check the status of attempts to distribute these events to subscribers.
List of events and filters
By default, the list of events is filtered for the current day, but you can use other filters to display the events.
|
Event listing limitations The display limit for the Event Status screen is 10,000 events per query, duly paged and with a maximum of 50 results per page. In addition, up to 31 days can be used as the data range for each query (the intervals don’t have to end on the current date).
|
In addition to the date range fields (From and To) and Status, the icon 
opens more search filters.
These are all of them:
-
From and To: fields to search by data range referring to when events are received by Events Hub.
-
Status: filters by status code returned by Events Hub when it receives events from publishers — options: Success and Error, with possibility to discriminate between types of error (Client Error or Server Error).
The display of events with errors depends, of course, on requests from publishers having been received by Events Hub. For instance, if a publisher submits a request using incorrect credentials, the request will have been received and the event will appear in the list with error code 401, but will not be distributed to subscribers. -
Contexts: filters by contexts, and more than one can be selected at the same time.
-
Handlers: filters by handlers, and more than one can be selected at the same time.
-
Publishers: filters by publishers, and more than one can be selected at the same time.
-
Subscribers: filters by subscribers, and more than one can be selected at the same time.
-
Event ID: filters by the event ID which is generated by Events Hub whenever a request is received from a publisher (and is displayed in the list of events).
The list of events returned after queries contains a series of columns.
By default, all columns are displayed, but you can select which ones should be exhibited by clicking on the 
icon, which displays all options:
- Notes
-
-
The date and time in the DATE column refer to when the events were received by Events Hub.
-
The EVENT ID column displays a unique event identifier that is generated whenever Events Hub receives a request from a publisher. The icon
copies the ID to the user’s clipboard.
It can be used in the Delivery Retry screen to search for the event and manually distribute it to subscribers who haven’t received it after all automatic delivery attempts. -
The columns HANDLER, TOPIC and CONTEXT can have empty cells in case an event has been sent to Events Hub but to an incorrect URL. As it’s thus impossible to identify the event subscription path, the return to the publisher is a 404 error and there is no distribution of events to subscribers.
-
The PUBLISHER column displays the publisher that sent the request. The publisher is only identified and displayed if there is an interceptor that validates client ID in the policy applied to the handler (Client ID Validation or OAuth Validation).
-
The POLICY column displays the policy applied to the handler. It will contain empty cells if no policy is applied.
-
SUBSCRIBER QTY displays the number of subscribers for the event, which are those subscribed to the topic used and that have the context to which the event was sent enabled.
-
The STATUS CODE column displays the HTTP code that Events Hub returned to the publisher. A success code means that Events Hub has received the event and will try to deliver it to subscribers, but does not report on the success of the delivery.
-
The VIEW MESSAGE column contains the
icon, which displays the headers and body of the request sent by the publisher:
-
The DELIVERY RETRY column contains the icon
to view details about attempts to deliver the event to subscribers.
See more on this below.
-
Event delivery data
The icon under the DELIVERY RETRY column shows details about the delivery attempts to subscribers.
If there is no registered subscriber for the event, the icon will be disabled.
If the STATUS column displays an error code, it means that the event wasn’t successfully received by Events Hub (this happens, for example, if a publisher passes invalid credentials).
In this case, Event Hub makes no attempt to distribute the event to subscribers and there is no data to display when clicking on :
If the event has been successfully received by Events Hub, the icon will open a tab displaying the last attempt to send the event to each subscriber, with the date and time of the delivery attempt, subscriber name, subscriber URL, expected return code when sending the event to the subscriber (column EXPECTED STATUS) and code returned on the last delivery attempt (column DELIVERY STATUS):
| The subscriber URL and expected return code are set when creating or editing a subscriber. See more about it here. |
The HISTORY column contains the icon , which displays all delivery attempts to the subscriber selected.
See examples below.
If the last delivery attempt to a subscriber was unsuccessful, the tab will contain the button VIEW IN DELIVERY RETRY, which redirects the user to the page Delivery Retry filtered with the ID of the event at hand. There, you can try to manually send the event to the subscriber. After a successful manual attempt, the event will be repopulated, as in the example below (referring to the previous image):
History of delivery attempts
In the open tab by clicking on the icon, the HISTORY column contains the icon to redirect to the delivery attempt history page for that subscriber.
The history page displays the date and time of the delivery attempt, subscriber name and URL, the type of attempt — which may be the Initial Delivery, Policy Retry (an automatic retry as per the policy applied to the handler) or a Manual Retry — and the return code received.
In the example below, the event was successfully delivered on the first attempt:
In this example, after the initial attempt, there were three automatic attempts based on the policy applied to the handler, all returned with error:
The next example shows the same event as the previous image. After the three automatic attempts, there was a successful manual delivery:
| Up to 10 automatic delivery attempts may be made, but the number to be followed in each case is configured on the screen Policies by creating or editing a policy (that must then be applied to a handler in the process of creating/editing handlers). |