Best practices and troubleshooting
To make optimal use of event exports, there are a few things we recommend: our best practices. Additionally, we offer some guidance on how to test and/or troubleshoot your event export configurations.
Best practices
It's possible to create an endpoint and have all events sent to it, unfiltered and unverified - it's easy, but inadvisable. So before you head off and create your endpoint and your configurations, there are several things we strongly advise you to take in mind.
Filtering via Event specification
For one, EVA already sends out thousands of events, per second. Your endpoint might be up to the challenge, but a few improvements to EVA onwards and the amount of events might have doubled. Queues will form and your flows will start getting delayed, in short: don't skip Event specification.
This filtering goes hand in glove with the creation of multiple endpoints: if you have critical business flows based on event triggers, create a second endpoint, or a third, or.. You can see where we're going with this. In the same vein, if you're performing BI based on events, create another dedicated endpoint.
Filtering via EventExport scripting
Although you can already limit events via the above mentioned event specification, you can go a level deeper by creating an EventExport extension point.
Though just one of the possibilities, this even allows you to exclude event exports based on the EVA-User-Agent.
Verify
Ensure you won't take just anyone's own Order paid event at face value with our two lines of defense: Authorization and Verification.
Monitor
Monitor if your events are reaching your endpoint and are being processed properly. You might have your own software already doing so, but you can also set up EVA's Event exports monitor.
Synced or async
If you kick-off certain business flows based on your webhooks, which then need to be completed before your endpoint responds with a 200 (OK) message, we call this as being processed in-sync. If your endpoint responds with the confirmation right away upon receipt, we consider it a-sync.
Because your other flows may take several seconds to finish up, we advise you to set it up a-sync. This avoids your webhooks being delayed due to the Exponential backoff.
Whatever way you establish your sync, your export fails if EVA does not receive its reply within 5000 ms. These 5 seconds however are already on the (too) generous side: a proper configuration should respond within < 200 ms.
Bear in mind that if an export is considered failed, EVA will retry. In practice this means you may receive events more than once, if your end point is functional but (too) slow in responding.
Scripting event exports
It is possible to create scripts that let you fine-tune when an export has to be made to your endpoint.
You can create these filters, by means of the extension point called EventExport.
Testing, queues and errors
Testing event exports is extremely easy. Make sure you have an endpoint for testing and make sure your settings are correct.
Don't have an endpoint for testing? We've got you covered with our own EVA event catcher:
https://event-catcher.platform-tools.on-eva.io/events/d572e17fb1424027b19f54896865a06f
If you've got this link attached to your event export configuration, you'll get a perfect overview of the events related to your actions on one of our front ends (or services).
Queuing
As mentioned throughout this document, your endpoint needs to respond with a 200 (OK) message within 5 seconds (strive for < 200 ms). If it doesn't, the event is seen as failed and EVA will retry - at least up to a certain point. The way EVA handles this also differs per type of environment.
Your endpoint needs to be able to handle receiving duplicate event messages due to your endpoint not responding in time, with EVA consequently retrying.
Failed
When an export fails on a PRODUCTION environment, EVA will try again based on exponential backoff: the message will be sent again after 5 seconds, 10 seconds, 20 seconds, etc. up to 24 hours. After this, you can no longer reach the message.
On TEST environments however, where are endpoints are often used liberally, EVA automatically disables your endpoint after either 200 failed messages, or 30 minutes of consecutive error messages. In this case the endpoint will get Status Error (3), but you can simply set it to Status Enabled (1) again if necessary.
Endpoint disabled
This failing/retrying is different from having a disabled endpoint. If you manually disable the endpoint on PRODUCTION, a different kind of queue will automatically start. All your messages will be saved up for you until either the size of the queued messages reaches 20gb, or up to 7 days - whichever comes first.
Replaying events
Although EVA has ways of dealing with endpoint failure (see the Failed status here above), this only goes so far. To facilitate you if you think you've missed out on a series of events (and which have now become unavailable), EVA has additional functionality which allows you to simply "replay" a series of events.
This can be done by using the service ReplayEvents, which accepts an (EventExportConfiguration)ID and an optional date range in the form of From and To.
By using this service, a temporary and uneditable (except for disabling/enabling) EventExportConfiguration will be created which will transition to status Done when all events in the range are replayed. This configuration has the property IsReplay set to true.
Please note that a few events, whether they be from before or after the specified range, might come through.