Requirements and Limitations

嗨，同学们，我们接着来看看在Apex中使用报告和仪表板API时需要知道的一些要求和限制。这块儿虽然看起来简单，但踩坑的还真不少，所以我们多花两分钟把它理解透。 首先，这个功能不是所有Salesforce版本都默认打开的。你要想在Apex代码里操作报告或者仪表板，组织必须已经启用了API访问权限。通常来说，如果你是Enterprise、Unlimited或者Performance版本，那一般就带这个权限；如果是专业版，可能需要单独购买。总之，写代码前跟管理员确认一下，API有没有开，否则调用时会直接报错。 那开了API就万事大吉了吗？其实不完全是。我们以前学过的一般API限制，像24小时内整个组织能发起的API请求总数，这些当然还是算在里面的。但我想让你特别留意的是，报告和仪表板API还有自己额外的、很重要的限制. 第一，同步报告执行限制。什么意思呢？就是当你在Apex里直接同步调用Report对象，等待马上拿回结果的时候，每个用户在同一时间最多只能跑20个同步报告。所以，如果你在循环里动不动就同步取一份大报告，还忘关调用，用户一多很容易撞到上限。 第二，异步报告限制。如果你改用异步方式，把报告丢到后台去跑，那每个用户最多可以有200个异步报告作业在排队。这个池子大一点，但也不是无限，设计功能时得留个余地，别一股脑儿全塞进去。 第三，仪表板刷新也有类似的并发限制。通过Apex去触发仪表板刷新的时候，整个组织同时处理的刷新请求不能太多——通常最多也就3个。所以如果是给很多用户并发刷新不同仪表板，那可能会被婉拒掉一部分。 最后还有一个容易忽略的，就是数据量的限制。你通过API取报告结果时，返回的行数可能会被截断。即便你的报表本身定义能展示几千行，API默认一次可能只给一部分，而且Apex里有堆内存和CPU时间的限制，一次取太多数据容易让整个事务超时或撑爆堆。所以咱们的实际代码里，尽量只请求当前业务真正需要的那部分字段和记录数，能加过滤就加过滤。 总的来说，记好这几点：先确认组织开了API，注意一般API请求次数，再小心报告和仪表板特有的并发与数据量限制。这样你的Apex代码在和报告交互时就能稳稳当当地跑起来，不会莫名其妙撞墙了。 好了，这节课就先讲到这儿，大家有任何问题随时提出来。