当前位置：文江博客话题详情

如何在Salesforce中保存ID列表以供其他过程使用？

发布于 2025-01-23 04:25:01 字数 57 浏览 0 评论 0原文

我想在某一时刻查询ID列表。...暂时保存。..然后在以后的Apex过程中使用该列表。有办法做到吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我不吻晚风 2025-01-30 04:25:01

许多选择都可以选择，将有助于了解您的用例或一些伪代码。它可以很简单，可以是一些成熟的 /a>。甚至还有一个概念称为“

如果您来自Java背景 - Apex的静态行为的行为不同。在Java/tomcat/任何静态的静态物质之间都可以在页面加载之间存活，它是所有用户/流程/WHATEVERS可见的真正类变量。在Apex中，如果您将某些内容标记为静态的东西，则当交易结束时，它将从内存中擦除。

如果它确实用于@future方法，一个Queuue -able或批处理作业 - 您可以称其为传递设置？

您可以随时调用类似的东西

insert new Task(
    Subject = 'stuff to process',
    Description = String.join(myIds, '\n')
);

，然后对这些任务进行其他查询，处理这些任务并完成后删除（或标记为完整？）。取决于您是任务还是自定义对象还是TXT文件（保存为contentversion），这并不重要。也许即使是“大对象”，

您也可以将某些东西存储在平台缓存。如果您需要保证处理，但它在那里可能不是最好的想法。

您可以研究一些以事件为导向的架构。具有API/FLOW/APEX提高平台事件，然后订阅它们（还使用API/Flow/Apex）。 API访问甚至可以重新播放72h。流动和顶点无法做到，但仍然（在顶点中，您会写一个插入式触发器几乎好像是正常的对象，这是一种分离的方式）

Lots of options to choose from, would help to know more about your use case or some pseudocode. It can be something simple, it can be some full-blown producers-consumers pattern. There's even a concept called "unit of work" but it might be an overkill for you.

If you're coming from java background - Apex's static behaves differently. In Java/Tomcat/whatever statics survive between page loads, it's truly class variable visible by all users/processes/whatevers. In Apex if you mark something static it'll be wiped from memory anyway when the transaction ends.

If it's really for @future method, a Queueable or batch job - you can just call it passing Set?

You can always call something like

insert new Task(
    Subject = 'stuff to process',
    Description = String.join(myIds, '\n')
);

and then have something else querying for these tasks, processing them and deleting (or marking as complete?) when done. Up to you whether it'll be a Task or custom object or a txt file (saved as ContentVersion), doesn't matter much. Maybe even "big Object"

You could store something in Platform Cache. Probably not best idea if you need to guarantee processing but it's there.

You could look into some event-driven architecture. Have API/Flow/Apex raise platform events and then subscribe to them (also with API/Flow/Apex). API access could even replay events up to 72h back. Flows and Apex couldn't do it but still (in Apex you'd write an after insert trigger almost as if it's normal object, it is a way of detaching)

回复收藏 0 原文

~没有更多了~