The Event Platform

#Best practices

#Deal with events generated by your own business logic

When working with the Akeneo Event Platform, it's crucial to handle events generated by your own business logic carefully. Each event payload includes an "author" field, which contains information about who is responsible for the action that generated the event. This field is essential for tracking the source of actions and ensuring that events are processed appropriately.

However, if the business logic of your event consumer requires calling the PIM API to update a value for example, it will generate a new event. This can lead to an infinite loop of events, which is highly undesirable.

To prevent this, it's important to implement checks within your event consumer to identify and handle events generated by your own business logic. By doing so, you can avoid the risk of infinite loops and ensure the stability and efficiency of your event processing system.

Let's take an example:

  • Your application is making authenticated API calls with the following client_id: b238e9f7-fcec-45bd-9431-d43cd624b244
  • You'll receive an event containing the author identifier which match your client_id
  • You can ignore this event on purpose

    {
      "specversion": "1.0",
      "id": "018e197c-dfe2-70f8-9346-1a8e016f5fbb",
      "source": "pim",
      "type": "com.akeneo.pim.v1.product.updated",
      "subject": "0190fe8a-6213-76ce-8a9f-ba36a5ef555a",
      "datacontenttype": "application/json",
      "dataschema": "https://event.prd.sdk.akeneo.cloud/spec/com.akeneo.pim.v1.product.updated.schema.json",
      "time": "2024-03-07T15:16:37Z",
      "data": {
        "product": {
          "uuid": "3444ec1b-058e-4208-9b6c-284f47a7aa17"
        }
        "author": {
          "identifier": "b238e9f7-fcec-45bd-9431-d43cd624b244",
          "type": "api"
        }
      }
    }

#Handling 429 Responses for HTTPS destinations

The platform can send many events in a short time, potentially causing overload and leading to 500 responses from your side. In such cases, event will enter the retry mecanism and your subscription may be suspended. By implementing a proper 429 response mechanism, you will optimize the event reception flow thanks to our optimizez throughput.

If your 429 responses contains a Retry-after header, the platform will not take it into account.

#Suspending and Resuming Subscriptions

If you are unable to guarantee a positive response when events are sent (e.g. during infrastructure maintenance) you may decide to suspend/resume your subscription to avoid it being suspended in accordance with our suspension policy. During the suspension period, events in the pipeline and new events generated by the PIM can't be recovered. You'll be able to receive new events as soon as you resume the subscription.

#Ignoring Duplicate Events

Due to the scalable and distributed nature of our service, in addition with its ability to provide some retry capability in case of temporary failure, you might receive the same event multiple times. To identify and handle these duplicate events, you can rely on the id of the event. This allows you to process each event only once and maintain data integrity.

#Implement Reconciliation Processes

Your app shouldn't rely solely on receiving data from the Event Platform. Because you may not receive events if you suspend your subscription or your server is not able to handle them during the maximum retry period, you should implement reconciliation jobs to periodically fetch data from the PIM.

You could do this in the background or offer reconciliation and syncing options to the user. For example, your app's UI could contain a button that triggers a manual reconciliation process by calling the relevant API endpoint and fetching the requested data.

#Batch your PIM API calls

You must be prepared to ingest events from the event platform with a significant throughput. But you must be gentle on the Akeneo PIM API, and respect the PIM API rate limits.

  • Do not call back the Akeneo PIM API synchronously when you receive an event: always store the event and implement a background process to handle data retrieval asynchronously.
  • You'll receive a lot of unitary events. Ensure your background process can make batch calls to the PIM API.
    • example: you receive 9 product update events in your PubSub Topic, and your background process pulls 10 messages every second from the PubSub queue. You make 1 API call on the get list of products endpoint instead of 9 unitary calls.
Let's see some integration examples !

Next