4

I am trying to build an Enterprise level framework on the top of Platform Events accessible to our external vendors, internal API's and internal developers. After doing a deep analysis on the capabilities, we came around the following road blocks which won't be applicable or doesn't has solution when we go live with the Platform Events Framework.

Is there anything I should be wary about apart from the list mentioned below ? Does anyone has prior experience of building a developer oriented framework on the top of Platform Events, making it easier for development.

  1. Fatal Error - User's need explicit access to classes if getting invoked by a Flow. Platform events runs as Automated Process user and if it runs a trigger which starts a flow which calls an invocable Apex. It will fail at "Flow fails: FLOW_ELEMENT_ERROR Profile does not have access to: no invocable"

How to replicate :

  1. Publish Platform Event Xxxx__e 
  2. Subscribe to Xxxx__e with trigger, save data in sObjects Foo__c (running user = automated process)
  3. Process Builder on Foo__c creation calls invocable apex class NopInvocable.cls

Here's a link -

https://success.salesforce.com/ideaView?id=0873A0000003aTkQAI https://releasenotes.docs.salesforce.com/en-us/summer19/release-notes/rn_forcecom_flow_cruc_security.htm

  1. Exception Handling - Platform Events fired triggers executes as Automated Process user, if it exceeds CPU Limits - no notification will be sent to developers even though you've Apex Exception Email Configured or Apex Warning Emails configured.

This means that if our PE is bulkified and one event in batch fails (Apex CPU or Heap) , the other members will fail and will be undetected.

Possible Workaround : have a logging object - track job id , status and error message, move your core logic in queueable, from the trigger fire the core logic and synchronously store the log record, you'll lose chaining of records and possibly replay of your logic.

This error will make our Production System with no notifications to uncatchable limit exception.

Other workaround : ○ Use EventLogFile to track error but it’s a part of Shield so extra $$. ○ Use setResumeCheckpoint helps in retry from last limit exception.

  1. API Calls - How do we hold the event published by external app and retrieve within 24 hours to update the record with the architecture.

  2. Bulkification - Due to optimistic tuning - PE event processing doesn't gets limited to 200 records per transaction, rather it goes to 2000. Meaning Trigger.new.size() can be up to 2000 - meaning even with careful bulkification the potential to hit Apex DML Limits will be higher. List of sObjects of Size 500 having multiple workflows, flows etc. will fail on DML Limit. This can only be addressed if we have proper checkpoints setting.

  3. API Calls - Scenario of invoking API Calls directly from Platform Events won't work. Also, there's no way to control number of events that are processed in each trigger. So we would end up using a Custom Object Architecture.

  4. Audit & Maintenance - The ability to know the list of subscribers to a particular event isn't defined yet in Platform Events.

  5. Merge Fields and Visualforce Templates - As running via Automated Users, Platform Events do impose severe issues on merge fields wherein the templates aren't accessible likewise the ability to fetch the most recent (changes during same transaction).

  6. Refreshed Sandbox Issue - In the past, there have been issues with PE requiring subscriber classes to be complied after Sandbox Refresh within Sandbox. This was ideally fixed in Win 19, but still come around for some users or the other.

Improve this question
2
  • I am trying to build an Enterprise level framework on the top of Platform Events accessible to our external vendors, internal API's and internal developers - would be interesting to understand the problem you're trying to solve, perhaps there are options better than Platform Events. (Not to detract from this Q&A, it's still valuable, so maybe a different thread/question)
    – identigral
    Jul 31, 2019 at 22:33
  • thanks for ur response @identigral, the basic problem which i am trying to solve is to help out 100 developers within the same company to give them methods & interfaces which encapsulate the heavy lift of platform events architecture and makes readability and maintenance low. consider it as a util sitting on the top of platform events, much needed in an enterprise environment.
    – Gautam
    Jul 31, 2019 at 23:00

1 Answer 1

Reset to default
1

I hit these problems about year ago:

Until the first one of these is addressed, we are only using platform events as a last resort.

Improve this answer
2
  • For #1, isn't having a field to track the owner work ? i know the history tracking will unfortunately tie it to automated user. we have chnaged salesforce as per business logic making a custom field tracking history object and a logger to track as per needs - don't know if that helps
    – Gautam
    Jul 31, 2019 at 21:37
  • @Gautam Well that is a work-around at best that leaves those SObjects as special cases in your org and when in the future you want to use e.g. normal sharing rules these records will need special handling. You need the Platform Events to be giving you a lot of benefit in exchange for this irregularity.
    – Keith C
    Jul 31, 2019 at 21:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .