Can you call a webservice from a Platform Event Trigger?

Question

For webservice callouts, I assume the same rules apply, but I just wanted to double check. I haven't found any information about Platform Events and Webservices. I assume I would just make it a @future method to avoid erroring out?

Answer 1

Just to clarify: The question appears to be "CAN" you do it, not "SHOULD" you do it.

So the answer is YES, you can execute a callout from a trigger on the Platform Event object, much like you could when you, say, insert an Account.

I refuse to comment on whether or not you SHOULD do it - there are experts in architecture here who are much smarter than I am. :)

Answer 2

Older question but felt compelled to add an answer, as I was confused by what was presented here so far.

If you are asking "can I make an Apex HTTP Callout from my Apex Platform Event Trigger?" then the answer is NO.

System.CalloutException: Callout from triggers are currently not supported.

Here's John Brock, the product owner for Platform Events, in the Platform Events success community chatter group March 7, 2019 (a comment against this posting):

Longer term we also hope to relax some of the limits and restrictions on Platform Event triggers since they are executed asynchronously -- such as, I would love to be able to do callouts directly from Apex Triggers.

What you can do, and I think the OP alluded to this when mentioning @future, is to call an asynchronous context like @future or Queueable from your trigger, and do the HTTP Callout from that context instead.

Answer 3

Yes, Even I was wondering with the same kind of questions when I first heard about platform event in Salesforce.

But after taking up Platform Event Trailhead Module, All of my doubts got cleared And here are some major takeaway from the same :

1. Platform events are like other salesforce records(but can't be edited or deleted.)
2. You can perform only after insert(in triggers).
3. After you (publisher) create a platform event, consumer(subscriber) can listen to it.

But i don't think that you would make a web service callout after creating a platform event(just ponder over this use case again and you will know that this is not proper use case for platform events, because when you are creating a platform event, your subscribers which are connected to event channel is already polling/listening for this event).

But still, if you are curious to try out, Because platform events are published by inserting the event sObjects, standard API request limits apply. Referencing a link for further help.

Considerations for Publishing and Subscribing to Platform Events with Apex and API

Answer 4

The event driven architecture approach is subscribing to the platform event in the external service instead of calling a external service - but this only works if you are in control of the service you wan't to call

Answer 5

I found this blog: https://developer.salesforce.com/blogs/developer-relations/2017/05/first-impressions-platform-events-salesforce-enterprise-messaging-platform.html

One of the items they hit on is the point of the Platform Events. He says:

The vision for Platform Events is simple: Empower our customers to increase business productivity and efficiency through integrations via events. We want to enable customers to create more integrations between Salesforce and their systems. Using Platform Events, customers can support more interaction between Salesforce and their data. The goal is to reduce the number of point-to-point integrations and expand on the existing capabilities of our other integration options such as Outbound Messaging, Apex Callouts, and the Streaming API.

I interpret this as a green light to connect the two. If anyone has any thoughts on this feel free to comment.

Answer 6

It seems like a rather odd scenario to need to use a platform event, but I think I'm hitting one of those scenarios. I have an integration receiving messages via platform events. These process a number of payloads in bulk. Since the bulk operation can hit governor limits, I have limit checks around various operations. If there is one of the records in the bulk that will cause the limits to be hit, we stop processing that message and add it to a list. An after trigger then looks at the list, and if it is non-empty daisy chain queuable classes to process these messages one at a time. There are also error conditions that force the one at a time processing.

So the point is a process can only invoke queueable once. And to add the service call into the daisy chain list will inherently make it less reliable. @future calls can be silently dropped, so also is a bad idea if we want to reliably perform the callouts.

The solution seems to be to fire the platform event, and allow that to use queueable to do the callouts. This avoids having a nested chain of different types of queueable callouts, and keeps the system in a reliable state. It also allows for better bulkification and logging.