We have a requirement to invoke the customer API after 8 hours, 16 hours, and 24 hours from the ticket status change to ‘Need Details’ status. The one-time scheduled event option can be leveraged to invoke the custom app at a specified time and notify the customer API, but it sounds like it only supports a maximum of 1000 schedules simultaneously.
The customer has a large number of ticket transactions daily, and it is required to schedule more than 1000 to invoke the customer API. Is there any option to increase this limit or an alternative option to accomplish it?
I think you will be limited by the 1000 limit. A possible alternative to do this would be store the ticket status change and timestamp in a custom object and then set up a schedule event to check every 5 mins for tickets that have aged to the point you want to alert the customer API.
I already explored the custom objects, but it doesn’t support the range querying on the datetime fields. So you will be unable to find the aged records when the recurring scheduled event checks every 5 mins.
As a workaround, we can use some enum type for the time part (1,2,3,4…24), narrow down the records by using the filter options, check the eligibility, and act. But it doesn’t sound like a perfect solution for time-based scheduling.
This might be a little involved as a solution, but do you think this is worth trying @sujeshmathew?
Assuming you are OK with a delay of up to 5 min for the scheduled invocation, let’s come up with a key for each 5min interval in a given day. For example, your keys may look like - “2023-01-09 09:00”, “2023-01-09 09:05”, “2023-01-09 09:10”, … “2023-01-09 10:00”, … and so on.
Your app subscribes to the ticket update event, evaluates the state change predicate, and then decides to use the update operation to append the ticket-id to the key that covers the current 5min interval. For example, if the update event occurred at 09:08, you will want to append the ticket-id to the “2023-01-09 09:05” key.
Each key in the key-value store also has a TTL (say 25hrs, or 48hrs if you want to be safe).
Create a recurring schedule with a frequency of 5min for your app that is registered during installation, and prepare a handler for the same.
The handler would basically look up 3 values from the key-value store - t_now - 8hr, t_now - 16hr, t_now - 24hr - where t_now is the current timestamp rounded down to the most recent 5min interval. (The same function used to derive the key you want to use to store a ticket-id).
It would then process each ticket-id in the list and make the necessary API calls.
Caveats to keep in mind:
Key value store rate limits that apply to your app (default - 50 per min)
The time you need to process all ticket-ids in one scheduled invocation (default 20 s)
Note: You could try to do the same using Entity Storage as well, but an atomic update operation is not supported in entity storage today.
We are trying a solution with a combination of the below feature to mitigate risks like 20-sec timeout, 50 requests/min, 5 min delay, etc.
Entity storage - hold the ticket and next reminder details based on the Ticket status and other conditions.
Key elements - Next reminder time stamp (current time + next reminder window), Next reminder Date (MM-DD-YYYY), Next reminder Hour (24 hours format). This will helps to filter and narrow down eligible reminders from the Entity storage.
Recurring scheduler - to check any eligible trigger for the next 15 min by filtering the Entity storage and creating a One-time scheduler
One-time scheduler - to meet the exact trigger time requirement and perform the other business logic like call customer API, notify users, etc. This will help to distribute the works to different threads instead of performing everything in the Recurring scheduler.
Custom fields - to track whether a trigger has already been created in the Entity storage. This would help to reduce the entity storage API calls.
Since this approach only focuses on the next 15 mins’ reminders and creates the one-time scheduler, we hope it will not exceed the max 1000 limit.
All these workarounds appear to be a little complex and require extensive testing. It would be great if there is any mechanism to get past this 1000 one-time scheduler limit.