0

I am working with High Volume and Publish After Commit Platform Events and I am trying to understand if there is a way to know which Platform Events have been queued successfully.

We invoke the EventBus.publish(events) method providing the list of Platform Events we want to publish and we receive a List<Database.SaveResult>.

Since we are working with High Volume Platform Events, we know that the Database.SaveResult object gives us only the information regarding the successful or unsuccessful queuing operation for a specific Platform Event: it means even we receive a successful SaveResult, the related Platform Event may not be published later on.

My initial goal was to implement a tracking process for all the Platform Events:

  1. I create a list of Platform Events I want to publish;
  2. I invoke the Eventbus.publish() method providing the list of Platform Events;
  3. The Eventbus.publish() method returns a list of Database.SaveResult objects. Each Database.SaveResult object contains a reference (or the values itself) to a Platform Event and it gives information regarding the queuing operation (successfully/unsuccessfully).
Improve this question
6
  • You're conflating queueing and publishing. As the doc explains, publishing of the event by the queue is async. Queueing the event via EventBus is reflected in SaveResult. EventBus with high-volume platform events is at-most once delivery. If you need at-least once delivery or exactly-once, then choose technology that supports this.
    – identigral
    Apr 1 at 15:43
  • @identigral I am not confusing queuing and publishing. I have clearly mentioned that point. As I said, since I am working with High Volume Platform Events, when I invoke the Eventus.publish() method, the Database.SaveResults returned are giving info about the queuing (and not the publishing). And it is exactly what I would know: which Platform Events have been queued successfully/unsuccessfully.
    – vt89
    Apr 1 at 15:55
  • Fair enough - our comment still stands. You're expecting something that doesn't exist.
    – identigral
    Apr 1 at 16:01
  • Looking at the comments, looks like you are clear on what you want to ask. But the question is a bit misleading (at least to me). I guess you want to find whether a PE event was actually published to and received by the subscriber or not. Anyways, take a look at the answer I have posted.
    – arut
    Apr 1 at 19:10
  • there appears to be a pilot for getting callbacks on published events status - twitter.com/RajSFDC/status/1504144908302503942
    – cropredy
    Apr 11 at 23:33

1 Answer 1

Reset to default
2

Salesforce hasn't exposed a REST endpoint or a EventBus method to get the information you are looking for (primarily, this might be because HVPE are persisted and published asynchronously as mentioned in High-Volume Platform Event Persistence). However, you could achieve this via a custom solution making use of EventUuid mentioned here. Fetch the EventUuid while publishing and compare it against the one obtained at subscriber.

  1. Since, you are using EventBus.publish method, you can call EventBus.getOperationId(saveResult) for every Database.SaveResult object returned by the publish method and store the EventUuids in another custom object.

  2. The platform event can be listened by multiple subscribers, which can then carry out different actions. So, you can add another subscriber to the event via apex trigger (the actual subscriber in your case may be an external one), fetch the EventUuid and compare it against the ones stored in custom object.

Note:

  1. I don't think this method was provided in the platform to run for bulk of platform events as proposed in this solution, but rather for checking few platform events. Regardless, the proposed solution should work.
  2. Also, I tried getOperationId method calls within a FOR loop with 10000 SaveResult objects in a single apex transaction and didn't come across any governor limit violation.
Improve this answer
6
  • Thanks arut for your help. Maybe I was not clear enough in my initial request. Your solution is a step ahead of what I am looking for. Basically, your solution helps identify which Platform Events are published (asynchronously) successfully and which ones are not. It means those PEs had been already queued successfully! So, using the UUID we are able to understand if a queued PE is published or not. My investigation is working one step before your solution. I would know if it is possible to know which PEs are queued successfully and which ones are not.
    – vt89
    Apr 1 at 20:41
  • @vt89 List<Database.SaveResult> returned by EventBus.publish(events) give you exactly that info. In SaveResult object, success flag indicates that PE has been queued and error flag indicates that it wasn't queued. AFAIK, the queueing would occur immediately, but the publishing is asynchronous.
    – arut
    Apr 2 at 3:28
  • 1
    @arut The docs are misleading. Getting (an/some) Event UUID from EventBus.getOperationId does not imply successful publish by the queue to the subscriber. There's no reliable (transactional) way to know the result of a publish. At best, you can be notified of an error: see doc. See this related Q&A for more fun with messaging.
    – identigral
    Apr 2 at 18:08
  • @identigral Looks like SF needs to update their documentation. Looking into this & this, its seems like operationId & EventUuid are essentially the same.
    – arut
    Apr 3 at 13:53
  • 1
    @identigral I do agree that getting EventUuid from EventBus.getOperationId does not imply successful publish, but comparing them against the corresponding IDs received at subscriber end will help determine which HVPEs were not published. Async publish errors notification (beta) feature is good (I hadn't noticed it); it simplifies the solution. You should post it as another answer, since it seems to be the only available easier option now. However, I do agree that there is no reliable way for the publish tracking (its documented officially in the developer guide).
    – arut
    Apr 3 at 14:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.