Extending PlatformEventDistributor
Closed this issue · 7 comments
We have need, in a very large scale org, to extend the PlatformEventDistributor to allow for synchronous execution of subscribed classes, rather than using a Queueable. We've discussed a few options around this, and based upon the results of this ticket I will be submitting a pull request in the next few days to cover this enhancement.
What it basically comes down to is this:
- Adding a checkbox to the PlatformEvents_Subscriber__mdt to allow indicating a subscription as synchronous ("Call Synchronous" or "Run In Process", defaulting to false/unchecked, not required).
- Checking that value in the triggerHandler portion of PlatformEventDistributor to either call enqueueJob(consumer) or consumer.runInProcess() appropriately.
The trick, and therefor the purpose of this "issue", is to determine how to implement this through the Interface, IEventConsumer.
Option 1: simply add IEventConsumer.runInProcess().
Impact: This will affect any org that has adopted this package and made use of this process thus far. All implementations of IEventConsumer would fail, and runInProcess() would have to be provided a body, even if it did nothing, before use of this pattern could continue in those orgs.
On the bright side, this would allow properly implemented consumers to toggle between async and sync via the new checkbox with no code changes in the Consumer.
Option 2: add a new interface for sync consumers, IE: IEventSyncConsumer or IEventInProcessConsumer
Impact: A lot more code changes to PlatformEventDistributor, and a code change would be required when switching configured consumers between sync and async mode. There would be no ability to quickly toggle between modes.
I am happy to deliver option 2 in order to ease any pain on previous adopters. However, the cleaner and more elegant solution is certain option 1. I am also open to other options for implementation, including keeping said changes within my own org and not pushing them to this repo (if that is desired).
Hey @torynet
Is your team using the "Dynamic Platform Event Subscription" logic?
@rlparker and I are discussing the changes needed for the above. We have a potential solution but it would be a "breaking change".
If your team is not using this part of the framework, then I am inclined to proceed with the changes even though they would be breaking. If you are using this functionality, then we will need to talk through transition of your codebase.
Please let me know when you can.
Cheers!
Hey @stohn777 -- FYI on this
Hey @peterlinbiz -- Same question for you that I just asked Tory above. If you would not mind, please let me know if your team is using "Dynamic Platform Event Subscription" logic?
Cheers!
@ImJohnMDaniel I am looking forward to using this functionality in the near future, but we have not yet written anything.
@ImJohnMDaniel We haven't started using the "Dynamic Platform Event Subscription" logic, but it will be my near term item to learn. Thanks!
Ok . This was resolved by pull request #19