Newer Version Available

This content describes an older version of this product. View Latest

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:

1/services/data/v62.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. Also, in rare cases, after repartitioning is initiated, it can take longer for the system to finish processing events in the old partitions and delete those partitions. The reason 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