Process.Plugin Interface — Overview & Implementation

同学们，我们来看看这张幻灯片上讲的内容——一个有点“历史悠久”的技术点，叫做 Process.Plugin 接口。 简单说，它就像一个“翻译官”，让我们写的 Apex 代码能和 Salesforce 里的“流”（也就是那个拖拽式的自动化工具）互相传递数据。为什么需要它呢？因为流很聪明，能可视化地操作数据，但有些复杂逻辑还得靠代码，这时候就得有个桥梁，把流的输入传给 Apex，Apex 处理完再把结果送回给流。 不过大家注意，这个 Process.Plugin 现在已经是遗留接口了。用是可以用的，但 Salesforce 官方更推荐我们使用 @InvocableMethod 注解。为什么呢？因为新的注解好太多了——它支持所有数据类型，还能一次性批量处理很多条记录。更厉害的是，不仅流能调用，流程构建器、甚至 REST API 都能直接调用这些加上注解的方法，特别灵活。所以我们现在学 Process.Plugin，主要是为了看懂老代码，或者维护旧系统。 那这个 Process.Plugin 具体怎么用呢？它内部需要配合三个小帮手类一起工作。 第一个类叫 Process.PluginRequest，你可以理解成“请求包裹”。它专门用来接收从流传过来的输入参数，里面其实就是一个 Map 结构，就像个 key-value 对的小字典，流的参数就打包在里面。幻灯片里提到它的构造函数可以传入一个 Map，用起来很方便。 第二个类叫 Process.PluginResponse，它负责“回传结果”。返回的时候，可以是一个 Map 包含很多字段，也可以只返回一个 key-value 对，看实际需要。相当于把处理好的数据重新打包，交给流。 第三个类是用来描述插件自身信息的，名字有点像 Process.PluginDescribeResult（但咱们幻灯片里叫 PluginCredibeRecord，大家知道有这个描述类就行）。这个类里会定义插件的名称、标签，还有输入参数的数据类型是什么——幻灯片提到一个叫 inputMechanics 的枚举字段，用来告诉流这个输入是怎么个形式。另外还有 outputFields，列出插件会输出哪些字段。等于说，这个描述类就是插件的“说明书”，让流知道该怎么跟它对接。 幻灯片里还举了一个 FlowChat 示例。这个示例演示了怎么用 Process.Plugin 接收一个输入参数（幻灯片上误写成了 “WRING”，估计是想说“一个单一的输入参数”），然后把这个参数作为内容，从流里发一条消息到 Chatter 协作平台上去。你们可以想象，用户在流里输入一段文字，点一下按钮，背后代码就自动发出一条 Chatter 动态，很实用。 不过再强调一次，虽然 Process.Plugin 能干活，但它确实老了。咱们现在写新功能，一定要优先考虑 @InvocableMethod，写起来更简单，功能更强大，还支持批量处理。但万一维护旧项目时遇到了，你也能知道它是干什么的，怎么读。 好了，关于这个小知识就先讲到这里，有什么问题随时问。