我们希望创建一个出站邮件队列系统，该系统可以单独处理请求，也可以处理任何外部Web服务。应该处理这些请求的频率是可变的，但作为一个例子，我们可能希望该过程每30秒运行一次。
在一小时内每30秒安排相同的工作120次是不可能或不切实的。
我最终确定的方法是连锁计划顶点（等到预定时间，调用未来方法并删除（中止）本身） - ＆gt;将来的呼叫（如果有一个进程请求，则重新安排类在30秒内重新运行） - ＆gt;安排apex（在30秒内调用未来方法，中止自己） - ＆gt;未来的呼叫（处理请求和重新安排）等等无限期。最终的结果是在生产上运行了2个星期，但刚刚没有重新安排自己，我不明白为什么。
我相信发生的事情是我违反了某种州长限制，但我不明白怎么做。我在沙盒上更频繁地遇到类似的问题，并且收到了一个限制例外，说明已超出未来请求的限制。
从服务失败的角度来看，我查询过去24小时内的所有异步作业（不仅仅是未来），它只返回2200.我相信这个数字应该是4400，因为我认为日程安排工作没有显示出来（计划的作业在调用future方法后会自行中止。）
即使如此，Salesforce声称我们每24小时允许250,000个异步顶点执行，所以我不明白发生了什么。有没有人有尝试以这种方式连锁预定工作的经验？有没有更好的方法来实现这一目标？是否存在我不知道的限制，或者我是否以错误的方式测量异步执行？
非常感谢任何帮助或建议。
答案 0 :(得分：0)
我曾经以相当成功的方式让Apex以5分钟而不是30秒的粒度完成这项工作，但无论如何这种方法都存在固有的脆弱性。 @future调用没有保证的运行时间，因此虽然它们通常在调用时立即运行，但它们可能会被延迟。我在执行@future方法时经历了长达20分钟的延迟，这可以解释为什么你的预定运行次数比你想象的要少（尽管事实上它正好是你预期的一半令人费解）。
归结起来，至少在撰写本文时，Scheduled Apex并不是真的针对这个用例。在我的情况下，我最终使用Heroku Scheduler作为中间人。我意识到这不是理想的解决方案（它是一个不同的平台，不同的语言，但仍然是Force.com），但它更强大。
答案 1 :(得分：0)
您的评论正在等待审核。
您好， 请检查以下几点。 1.这是一个DML声明，其管理限制为10,000.您最后更新批次，而不是每次迭代。
在查询结尾处输入“LIMIT 9999”。如果这样可行，那么这就是你的问题。使用 database.executebatch（new SyncCalendarsUpdates（），1）; 2.请检查实例“数据存储”到设置＆gt;＆gt;监视器＆gt;＆gt;系统概述（数据存储） 解决方案请删除一些数据或联系salesforce以增加数据存储限制。