Apex Rest Vs Platform Events for Inbound SF integration which one to choose?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
15
down vote
favorite
Am in a design dilemma in choosing which would be the best approach in the Integration which we would be doing shortly.
To give a brief idea, the external system wants to send JSON data to SF. We would validate the JSON data and create a few sets of records.
So we have 2 options:
Using Apex Rest : The age-old world accepted Rest based Apex web services. It can do exactly what the API wants.
Using Platform Events : Event-Driven Decoupled Architecture having Messaging bus. This will involve sending JSON in Event's Custom Text area field and then parsing it in Event's trigger.
What should be the deciding factor, in what should be used for this Integration?
I have researched and came with few pointers.
Error/Exception Feedback to external System : Rest Api being Synchronous, can convey this back in the same transaction (realtime), Platform events being Async not so much(Might have to rely on emails/or create new platform error events that external systems will subscribe.
Retry : Yes we can have retry in platform events, but do we really need it here in this Integration? If its a Validation Exception or Nullpointer exception it will still be there no matter how many times you retry. The only advantage I see is If the exception is something like "UNABLE_TO_LOCK_ROW", in that case, yes retry functionality of platform events works, but here we are just inserting few records, so am pretty much sure that record locking wont be happening.
Replay Past Events : SF can't replay past events via trigger or flow/process.
Request JSON Size : Rest API can accept JSON till 6MB, whereas for Platform events its just 1MB,so Rest API can be used for more bulkified JSON records.
API calls and Event Limits : When I publish a platform event I am consuming 2 limits, 1 API calls to Publish events and Platform Events Hourly limit. Whereas in Rest API call its just API calls.
Can anyone point out the design consideration I am missing, plus what points I should consider in selecting the best approach.
apexrest platform-event
add a comment |Â
up vote
15
down vote
favorite
Am in a design dilemma in choosing which would be the best approach in the Integration which we would be doing shortly.
To give a brief idea, the external system wants to send JSON data to SF. We would validate the JSON data and create a few sets of records.
So we have 2 options:
Using Apex Rest : The age-old world accepted Rest based Apex web services. It can do exactly what the API wants.
Using Platform Events : Event-Driven Decoupled Architecture having Messaging bus. This will involve sending JSON in Event's Custom Text area field and then parsing it in Event's trigger.
What should be the deciding factor, in what should be used for this Integration?
I have researched and came with few pointers.
Error/Exception Feedback to external System : Rest Api being Synchronous, can convey this back in the same transaction (realtime), Platform events being Async not so much(Might have to rely on emails/or create new platform error events that external systems will subscribe.
Retry : Yes we can have retry in platform events, but do we really need it here in this Integration? If its a Validation Exception or Nullpointer exception it will still be there no matter how many times you retry. The only advantage I see is If the exception is something like "UNABLE_TO_LOCK_ROW", in that case, yes retry functionality of platform events works, but here we are just inserting few records, so am pretty much sure that record locking wont be happening.
Replay Past Events : SF can't replay past events via trigger or flow/process.
Request JSON Size : Rest API can accept JSON till 6MB, whereas for Platform events its just 1MB,so Rest API can be used for more bulkified JSON records.
API calls and Event Limits : When I publish a platform event I am consuming 2 limits, 1 API calls to Publish events and Platform Events Hourly limit. Whereas in Rest API call its just API calls.
Can anyone point out the design consideration I am missing, plus what points I should consider in selecting the best approach.
apexrest platform-event
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
3
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50
add a comment |Â
up vote
15
down vote
favorite
up vote
15
down vote
favorite
Am in a design dilemma in choosing which would be the best approach in the Integration which we would be doing shortly.
To give a brief idea, the external system wants to send JSON data to SF. We would validate the JSON data and create a few sets of records.
So we have 2 options:
Using Apex Rest : The age-old world accepted Rest based Apex web services. It can do exactly what the API wants.
Using Platform Events : Event-Driven Decoupled Architecture having Messaging bus. This will involve sending JSON in Event's Custom Text area field and then parsing it in Event's trigger.
What should be the deciding factor, in what should be used for this Integration?
I have researched and came with few pointers.
Error/Exception Feedback to external System : Rest Api being Synchronous, can convey this back in the same transaction (realtime), Platform events being Async not so much(Might have to rely on emails/or create new platform error events that external systems will subscribe.
Retry : Yes we can have retry in platform events, but do we really need it here in this Integration? If its a Validation Exception or Nullpointer exception it will still be there no matter how many times you retry. The only advantage I see is If the exception is something like "UNABLE_TO_LOCK_ROW", in that case, yes retry functionality of platform events works, but here we are just inserting few records, so am pretty much sure that record locking wont be happening.
Replay Past Events : SF can't replay past events via trigger or flow/process.
Request JSON Size : Rest API can accept JSON till 6MB, whereas for Platform events its just 1MB,so Rest API can be used for more bulkified JSON records.
API calls and Event Limits : When I publish a platform event I am consuming 2 limits, 1 API calls to Publish events and Platform Events Hourly limit. Whereas in Rest API call its just API calls.
Can anyone point out the design consideration I am missing, plus what points I should consider in selecting the best approach.
apexrest platform-event
Am in a design dilemma in choosing which would be the best approach in the Integration which we would be doing shortly.
To give a brief idea, the external system wants to send JSON data to SF. We would validate the JSON data and create a few sets of records.
So we have 2 options:
Using Apex Rest : The age-old world accepted Rest based Apex web services. It can do exactly what the API wants.
Using Platform Events : Event-Driven Decoupled Architecture having Messaging bus. This will involve sending JSON in Event's Custom Text area field and then parsing it in Event's trigger.
What should be the deciding factor, in what should be used for this Integration?
I have researched and came with few pointers.
Error/Exception Feedback to external System : Rest Api being Synchronous, can convey this back in the same transaction (realtime), Platform events being Async not so much(Might have to rely on emails/or create new platform error events that external systems will subscribe.
Retry : Yes we can have retry in platform events, but do we really need it here in this Integration? If its a Validation Exception or Nullpointer exception it will still be there no matter how many times you retry. The only advantage I see is If the exception is something like "UNABLE_TO_LOCK_ROW", in that case, yes retry functionality of platform events works, but here we are just inserting few records, so am pretty much sure that record locking wont be happening.
Replay Past Events : SF can't replay past events via trigger or flow/process.
Request JSON Size : Rest API can accept JSON till 6MB, whereas for Platform events its just 1MB,so Rest API can be used for more bulkified JSON records.
API calls and Event Limits : When I publish a platform event I am consuming 2 limits, 1 API calls to Publish events and Platform Events Hourly limit. Whereas in Rest API call its just API calls.
Can anyone point out the design consideration I am missing, plus what points I should consider in selecting the best approach.
apexrest platform-event
edited Aug 8 at 14:34
asked Aug 8 at 12:42


Pranay Jaiswal
8,36931848
8,36931848
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
3
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50
add a comment |Â
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
3
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
3
3
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
12
down vote
accepted
UPDATE
I have also discussed this topic with some more detail on on my blog here.
Based on your requirements where:
External System will push data in Salesforce.
My recommendation is to construct REST APIs for this purpose which the External Systems can utilize to send data to Salesforce. Platform Events are more targeted towards a Pub/Sub model, where you may want to "trigger" a notification from/to Salesforce to all subscribers and based on that notification the subscriber then takes necessary action. Excerpt from the documentation:
Platform events simplify the process of communicating changes and responding to them without writing complex logic. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
If at all you want the External System to "act upon" only when an event has occurred in Salesforce, you can then have Platform Events in this case, where the External System (the subscriber) is subscribed to the events in Salesforce and then sends data to Salesforce. Even in this case, you still need an API exposed for the External System to send data in Salesforce.
One of the most important factors to consider here is what is your integration approach. If you want a more "traditional integration", say point to point (not going into M/W details here), and that the External System always knows at what time they need to send data to Salesforce, go for REST API.
If you want your External System to notify you or if you want the External System to be notified for it to initiate the operation, that is when you should consider the event route (pub/sub).
Hope this helps.
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
12
down vote
accepted
UPDATE
I have also discussed this topic with some more detail on on my blog here.
Based on your requirements where:
External System will push data in Salesforce.
My recommendation is to construct REST APIs for this purpose which the External Systems can utilize to send data to Salesforce. Platform Events are more targeted towards a Pub/Sub model, where you may want to "trigger" a notification from/to Salesforce to all subscribers and based on that notification the subscriber then takes necessary action. Excerpt from the documentation:
Platform events simplify the process of communicating changes and responding to them without writing complex logic. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
If at all you want the External System to "act upon" only when an event has occurred in Salesforce, you can then have Platform Events in this case, where the External System (the subscriber) is subscribed to the events in Salesforce and then sends data to Salesforce. Even in this case, you still need an API exposed for the External System to send data in Salesforce.
One of the most important factors to consider here is what is your integration approach. If you want a more "traditional integration", say point to point (not going into M/W details here), and that the External System always knows at what time they need to send data to Salesforce, go for REST API.
If you want your External System to notify you or if you want the External System to be notified for it to initiate the operation, that is when you should consider the event route (pub/sub).
Hope this helps.
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
 |Â
show 1 more comment
up vote
12
down vote
accepted
UPDATE
I have also discussed this topic with some more detail on on my blog here.
Based on your requirements where:
External System will push data in Salesforce.
My recommendation is to construct REST APIs for this purpose which the External Systems can utilize to send data to Salesforce. Platform Events are more targeted towards a Pub/Sub model, where you may want to "trigger" a notification from/to Salesforce to all subscribers and based on that notification the subscriber then takes necessary action. Excerpt from the documentation:
Platform events simplify the process of communicating changes and responding to them without writing complex logic. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
If at all you want the External System to "act upon" only when an event has occurred in Salesforce, you can then have Platform Events in this case, where the External System (the subscriber) is subscribed to the events in Salesforce and then sends data to Salesforce. Even in this case, you still need an API exposed for the External System to send data in Salesforce.
One of the most important factors to consider here is what is your integration approach. If you want a more "traditional integration", say point to point (not going into M/W details here), and that the External System always knows at what time they need to send data to Salesforce, go for REST API.
If you want your External System to notify you or if you want the External System to be notified for it to initiate the operation, that is when you should consider the event route (pub/sub).
Hope this helps.
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
 |Â
show 1 more comment
up vote
12
down vote
accepted
up vote
12
down vote
accepted
UPDATE
I have also discussed this topic with some more detail on on my blog here.
Based on your requirements where:
External System will push data in Salesforce.
My recommendation is to construct REST APIs for this purpose which the External Systems can utilize to send data to Salesforce. Platform Events are more targeted towards a Pub/Sub model, where you may want to "trigger" a notification from/to Salesforce to all subscribers and based on that notification the subscriber then takes necessary action. Excerpt from the documentation:
Platform events simplify the process of communicating changes and responding to them without writing complex logic. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
If at all you want the External System to "act upon" only when an event has occurred in Salesforce, you can then have Platform Events in this case, where the External System (the subscriber) is subscribed to the events in Salesforce and then sends data to Salesforce. Even in this case, you still need an API exposed for the External System to send data in Salesforce.
One of the most important factors to consider here is what is your integration approach. If you want a more "traditional integration", say point to point (not going into M/W details here), and that the External System always knows at what time they need to send data to Salesforce, go for REST API.
If you want your External System to notify you or if you want the External System to be notified for it to initiate the operation, that is when you should consider the event route (pub/sub).
Hope this helps.
UPDATE
I have also discussed this topic with some more detail on on my blog here.
Based on your requirements where:
External System will push data in Salesforce.
My recommendation is to construct REST APIs for this purpose which the External Systems can utilize to send data to Salesforce. Platform Events are more targeted towards a Pub/Sub model, where you may want to "trigger" a notification from/to Salesforce to all subscribers and based on that notification the subscriber then takes necessary action. Excerpt from the documentation:
Platform events simplify the process of communicating changes and responding to them without writing complex logic. Publishers and subscribers communicate with each other through events. One or more subscribers can listen to the same event and carry out actions.
If at all you want the External System to "act upon" only when an event has occurred in Salesforce, you can then have Platform Events in this case, where the External System (the subscriber) is subscribed to the events in Salesforce and then sends data to Salesforce. Even in this case, you still need an API exposed for the External System to send data in Salesforce.
One of the most important factors to consider here is what is your integration approach. If you want a more "traditional integration", say point to point (not going into M/W details here), and that the External System always knows at what time they need to send data to Salesforce, go for REST API.
If you want your External System to notify you or if you want the External System to be notified for it to initiate the operation, that is when you should consider the event route (pub/sub).
Hope this helps.
edited Aug 10 at 18:53
answered Aug 8 at 12:56
Jayant Das
5,6071318
5,6071318
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
 |Â
show 1 more comment
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
Can you expand on why you think external systems should not publish to the event bus? Everything I've seen makes me think that they can. It's documented here: developer.salesforce.com/docs/atlas.en-us.platform_events.meta/… I've read about but not used Platform events, so curious to see why you think using that API is a bad idea. My understanding has always been that SF itself is not special here. Parts of SF can pub, and parts can sub, and it doesn't matter how the event is created.
– Aidan
Aug 8 at 13:58
1
1
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
@Aidan, external systems can definitely publish events. However if you want an external system to write data to SF and that if the external system knows when to write that data, you just don't need an event bus for that purpose. If at all you only want the external system to "notify" Salesforce to take an action or vice-versa, then yes you can definitely use that approach. It all depends who initiates the process and when is that process initiation required. Also it also depends as what are you trying to design - pub/sub or a traditional integration.
– Jayant Das
Aug 8 at 14:03
2
2
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
Thanks, Jayant for your answer, Everyone is excited about using platform events because of their benefits, Unfortunately, people end up molding every integration to use platform events even if its not needed. SF or someone should have a blog for this.
– Pranay Jaiswal
Aug 10 at 16:05
1
1
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
@PranayJaiswal I couldn't agree more :-)
– Praveen
Aug 10 at 16:06
1
1
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
@PranayJaiswal, thanks for asking such a great question I would say. This topic does seem to be hot off press :) I have seen this topic now 3 more times after you posted this. I am actually writing a blog on this, so will share here once done.
– Jayant Das
Aug 10 at 16:06
 |Â
show 1 more comment
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f228160%2fapex-rest-vs-platform-events-for-inbound-sf-integration-which-one-to-choose%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Will SF pull data from External System or it is External System's responsibility to send data in to SF?
– Jayant Das
Aug 8 at 12:47
External System will push data in SF.
– Pranay Jaiswal
Aug 8 at 12:47
3
Assuming you don't want the External System to wait on for a notification from SF to start the push process, my recommendation will to expose your artifacts using REST API. And the reason being Platform Events are more targeted towards a pub/sub model and that when you want any notification going out of SF for external systems to consume and act upon that is the most appropriate use case for it.
– Jayant Das
Aug 8 at 12:50