请求的资源在 Salesforce 中不存在 [错误]。 Salesforce 有什么问题?

The requested resource does not exist [error] in Salesforce. What is wrong with Salesforce?

我执行 SOQL 请求以获取 SObject 'ObjectPermissions' 的所有可用记录 ID。 然后我使用 GET /services/data/v48.0/sobjects/ObjectPermissions/{id} 的请求来获取特定记录的所有必要信息。 正如您在第一张图片中看到的,我收到了总共 960 条记录的响应。 问题是对于 285 个条目,我无法获取信息。 这是我收到的 285 之一的答案示例: 我突出显示了该记录的标识符。也许这个id是错误的。

我观察到与以下 SObject 相同的情况:

任务状态
任务优先级
解决方案状态
合作伙伴角色
订单状态
FlowDefinitionView
现场安全分类 实体定义
合同状态
案例状态

我可以在具有常规对象(例如,事件、任务和登录历史记录)的不同 Salesforce 组织中观察到相同的行为。但这种行为并不总是在每个组织中都能重现。

是 Salesforce 做错了什么还是我不明白什么?

根据错误响应和您的描述,您正在使用的尝试访问您的 Salesforce 组织的客户端 (Workbench?) 之间的连接似乎有问题。这就是我解决问题的方法-

  1. 与在其他地方请求数据(DataLoader、VS Code、Dev Console/internal 访问)相比,检查这是否是特定于外部客户端 (Workbench) 的问题。如果您可以通过其他方法访问它,那么您可以确认它是与您的组织的特定连接。
  2. 确认Profile/Permission 设置对对象和字段的访问权限(听起来很明显,但您会感到惊讶)。即使是单独的字段级访问也会中断您检索记录(即使您是系统管理员,这并不意味着您始终对每个字段都具有字段级安全性)。
  3. 确认您的 运行 客户端用户对您请求的记录具有完全共享访问权限。 这对于检查某个对象的查询是否有某些记录 return 而不是全部记录尤其重要。

我必须获得更多详细信息才能进一步提供帮助,但确认上述详细信息将大有帮助。要点是,如果您可以访问一个对象中的某些记录,但不能访问其他记录,那么它告诉我您已对组织进行身份验证,具有对象访问权限,但可能没有完全共享或字段级安全访问权限特定 运行 用户。

TL;DR - 我不会担心这些。

  1. 那个身份证看起来是假的。没有具有 000 键前缀的合适对象。 (网上有很多关于“已知密钥前缀”的博客 post,但请注意时间戳,几乎每个版本都会添加新对象,因此内容可能会过时)。 ObjectPermissions 应以 110.

    为前缀
    Id i = '000000003guy001AAA';
    System.debug(i.getSobjectType());
    // System.SObjectException: Cannot locate Apex Type for ID: 000000003guy001AAA
    

    Daniel Ballinger 的博客 post 很古老但汇编很棒:http://www.fishofprey.com/2011/09/obscure-salesforce-object-key-prefixes.html. He does list an entry for key "000" and it points to his another post: http://www.fishofprey.com/2011/06/salesforce-empty-key-id.html

  2. 您列出的 tables 是真实的 tables “但是”它们中的大多数用于内部管理,它们是“类固醇的选择列表”。

    CaseStatus 值得拥有 table 因为改变状态有标记案例关闭的副作用。 PartnerRole 是特殊的,因为它包括用于双向映射的反向合作伙伴角色。您不能真正授予 Read/Create/Edit/Delete 对这些的权利,至少不能授予 ObjectPermissions 的权利。这将是配置文件/权限集上的复选框,但其中大部分将包含在“配置应用程序”中。

    你和 OpportunityStage or CampaignMemberStatus 有同样的问题吗?

  3. LoginHistory 不是选择列表,但可能受“管理用户”保护,EntityDefinition 嗯...可能是“查看设置和配置”。

  4. 我的直觉是 SF 包括这些条目是为了完整性,但如果父配置文件/权限是特殊的,它们是空白的。权限可以始终启用(系统管理员,任何其他具有“修改所有数据”和“作者 Apex”的配置文件也可能)或始终禁用(例如,被许可证阻止)。我所说的阻止是指客户社区许可等情况——您无法授予对机会或潜在客户的访问权限——复选框根本不存在。类似于平台用户(仅访问 10 个自定义对象)、Chatter Plus 许可证(或任何正确名称)。所以如果没有办法改变它 - 为什么要给它一个真实的 ID。

    当你运行这个时你会得到什么?

    SELECT Id, SobjectType, Parent.Profile.Name, PermissionsRead
    FROM ObjectPermissions
    ORDER BY Id
    

是的,它的解释有点薄弱,但请记住 ObjectPermissions 和 FieldPermissions 仍然相对较新。一个真实来源是将配置文件视为 XML(元数据 API)或 运行 宁“描述”调用(Apex、SOAP API、REST API -仅适用于当前用户)。 FieldPermissions 没有对象上所有字段的条目(Id、CreatedById、SystemModstamp...),没有人抱怨。这些可查询对象是一种快捷方式,但它们有局限性。

根据您的错误描述和屏幕截图,我假设您是通过编程方式(Apex、Python、Java...)进行操作,并且您的第一次操作之间没有时间延迟request(提取数据, /Query?q=) , response 和第二个请求(根据ID记录详情, /sobjects/ObjectPermissions/{id})

  1. 带有'000'的记录在Salesforce中可以被识别为EmptyKeys,一般指空关系值。

联系人是商机上的查找字段,下面的查询将 return 相同计数。

SELECT count() FROM opportunity WHERE contactId = null
SELECT count() FROM Opportunity WHERE contactId = '000000000000000AAA'
  1. 参考Object permission中的记录(以'000'开始),与Empty keys差别不大,ids的分解可以在博客中找到

Mystery Behind The Salesforce Key Prefix '000'

  1. 在上述场景中,我们无法在元数据 API 查询中过滤掉这些对象,但是我们可以在 APEX 代码中发送第二个请求之前过滤记录。

设置 responseIds - 来自第一个请求的响应记录 ID return 并处理 ID 以过滤掉第二个请求的“000”ID。

String prefix = Schema.SobjectType.ObjectPermissions.getKeyPrefix();
for(String str : responseIds){
    if(!str.subString(0,3).contains(prefix)){
        responseIds.remove(str);        
    }
}
  1. RecentlyViewed 对象不能直接使用。此对象中的 ID 不是属于 recentlyViewed 对象的 ID,而是实际的记录 ID。 因此,如果您打算从此对象访问记录,则需要从最近查看的对象中获取 ID,然后解码键前缀以获得正确的 sObject 名称,然后以这种方式使用它 /sobjects/{decodedSobjectName}/{ID }

或者您可以使用 /services/data/v48.0/recent(有关详细信息,请参阅 Salesforce 文档)

https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_recent_items.htm

  1. 虽然我们为每个标准选项列表设置了单独的对象,但它们都共享相同的 keyprefix/objectType。以下代码将删除所有针对选择列表对象(Taskstatus、Casestatus、解决方案状态...)的请求

    for(Id str : responseIds){
         if(Id.getsobjecttype() == 'Picklistmaster'){
             responseIds.remove(str);        
         }
     }
    
  2. 对于Loginhistory,超过6个月的记录会被salesforce内部删除。因此,如果您 运行 第二个请求(查询请求,稍后的数据请求)并且如果这两个请求恰好位于 Salesforce 维护 window 之间,那么在您的第二个请求期间,引用的 ID 已经从org,因此错误。并确保您拥有管理用户权限。