Platform Events Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
Platform Events Developer Guide
Delivering Custom Notifications with Platform Events
Defining Your Custom Platform Event
Publishing Platform Events
Subscribing to Platform Events
Set Up Debug Logs
Flows
Processes
Apex Triggers
Apex Trigger Best Practices
Platform Event Processing at Scale with Parallel Subscriptions for Apex Triggers
Order of Events in Parallel Subscriptions
Choosing a Partition Key
Parallel Subscription Limits
Parallel Subscription Configuration Examples in Tooling API and Metadata API
Apex Trigger Repartitioning
Configure Parallel Subscriptions for an Apex Trigger
Testing an Apex Trigger Configured with Parallel Subscriptions
Parallel Subscriptions Considerations
Configure the User and Batch Size for Your Platform Event Trigger with PlatformEventSubscriberConfig
Find Uncaught Exceptions in Event Log Files
Resume a Platform Event Trigger After an Uncaught Exception
Retry Event Triggers with EventBus.RetryableException
Email Notifications for Triggers in Error State
Comparing setResumeCheckpoint() and EventBus.RetryableException
Lightning Components
Pub/Sub API
CometD
Group Your Event Streams
Filter Your Event Streams
Obtain a Platform Event’s Subscribers
Identify and Match Event Messages with the EventUuid Field
Testing Your Platform Event in Apex
Encrypting Platform Event Messages at Rest in the Event Bus
Monitor Platform Event Publishing and Delivery Usage
Considerations
Examples
Reference
PDF

Apex Trigger Repartitioning

To repartition an Apex trigger that is already configured with parallel subscriptions, update the existing PlatformEventSubscriberConfig in Tooling API or Metadata API.

After a trigger's parallel subscription configuration is modified, new partitions are created. The system keeps the old partitions until it finishes processing the remaining events in those partitions. After all the events are processed, the old partitions are deleted and only the new partitions run.

To update PlatformEventSubscriberConfig in Tooling API, make a PATCH request to this URI with the record ID appended:

/services/data/v64.0/tooling/sobjects/PlatformEventSubscriberConfig/record_ID

For information about the request body to send for PlatformEventSubscriberConfig, see Configure Parallel Subscriptions for an Apex Trigger.

In Metadata API, you can redeploy the PlatformEventSubscriberConfig component by using the same developer name and different values.

No new repartitioning can start while another one is in progress. Sometimes, after repartitioning is initiated, it can take longer for the system to finish processing events in the old partitions and delete those partitions while new partitions are processing new events. What can cause the delay in event processing in the old partitions is when event processing in the Apex trigger is slow and a large volume of events is published. Another cause for this behavior is that partitioning depends on event-publish activity in the event bus, which is shared with other Salesforce orgs. If there’s no publish activity from any org, the old partitions don't process events and become stagnant. However, this case is rare because it’s unlikely that no org publishes platform events for an extended time period.

Note