Запрошенный ресурс не существует [ошибка] в Salesforce. Что не так с Salesforce?

Question

Я выполняю запрос SOQL, чтобы получить все доступные идентификаторы записей объекта SObject 'ObjectPermissions'. Then I use the request to GET /services/data/v48.0/sobjects/ObjectPermissions/{id} to fetch all the necessary info for a specific record. As you can see in the first picture, I received a response with a total of 960 records. The problem is that for 285 entries I can’t get the information. Here is an example of the answer I received for one of 285: введите описание изображения здесь Я выделил идентификатор этой записи. Возможно, этот идентификатор неверен.

Я наблюдаю то же самое со следующими объектами SO:

TaskStatus TaskPriority SolutionStatus PartnerRole Статус заказа FlowDefinitionView FieldSecurityClassification EntityDefinition Состояние контракта CaseStatus

Я могу наблюдать такое же поведение в разных организациях Salesforce с обычными объектами (например, Event, Task и LoginHistory). Но такое поведение не всегда воспроизводится в каждой организации.

Salesforce что-то делает неправильно или я чего-то не понимаю?

Answer 1

TL; DR - я бы не стал беспокоиться об этом.

1. Этот идентификатор выглядит фальшивым. Не существует подходящего объекта с префиксом ключа 000. (есть много сообщений в блогах об «известных ключевых префиксах» на net, но обратите внимание на временные метки, новые объекты добавляются практически с каждым выпуском, поэтому контент может устареть). ObjectPermissions должен иметь префикс 110.

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

   Сообщение в блоге Дэниела Баллинджера является древним, но отличным сборником: http://www.fishofprey.com/2011/09/obscure-salesforce-object-key-prefixes.html. Он действительно перечисляет запись для ключа «000» и указывает на его другое сообщение: http://www.fishofprey.com/2011/06/salesforce-empty-key-id.html

2. Таблицы, которые вы указали, являются настоящими таблицами «но» большинство из них предназначены для внутреннего обслуживания, они «списки на стероидах».

   CaseStatus заслуживает отдельной таблицы, потому что изменение статуса имеет побочные эффекты при закрытии дела. PartnerRole является особенным, потому что он включает роли обратных партнеров для двунаправленного сопоставления. На самом деле вы не можете предоставить им права на чтение / создание / редактирование / удаление, по крайней мере, в отношении того, о чем ObjectPermissions. Это будут флажки в профиле / наборе разрешений, но большинство из них будет охвачено «Настроить приложение».

   У вас такая же проблема с OpportunityStage или CampaignMemberStatus ?

3. LoginHistory не является списком выбора, но, вероятно, защищен «Управлением пользователями», EntityDefinition хм ... возможно, «Просмотр установки и конфигурации».

4. Мне кажется, что SF включает эти записи для полноты, но они пустые, если родительский профиль / разрешение является особенным. Разрешения могут быть всегда включены (системные администраторы, любой другой профиль с «Изменить все данные» и «Author Apex», вероятно, тоже) или всегда отключены (например, заблокированы лицензией). Под блокировкой я подразумеваю такие ситуации, как лицензия сообщества клиентов - вы не можете предоставить доступ к возможности или потенциальному клиенту - флажков просто нет. Аналогично пользователю платформы (доступ только к 10 настраиваемым объектам), лицензии Chatter Plus (или любому другому правильному имени). Так что, если нет возможности изменить его - зачем вообще указывать ему настоящий идентификатор.

   Что вы получите, когда запустите это?

   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 ...), и никто не жалуется. Эти запрашиваемые объекты являются ярлыками, но у них есть ограничения.

Answer 2

Основываясь на описании вашей ошибки и снимке экрана, я предполагаю, что вы делаете это программно (Apex, Python, Java ...) и нет временной задержки между вашим первым запросом (извлечение данных, / Query? Q =), ответ и второй запрос (детали записи на основе идентификатора, / sobjects / ObjectPermissions / {id})

1. Записи с '000' могут быть идентифицированы как EmptyKeys в Salesforce и обычно относится к нулевым значениям отношений.

Контакт - это поле подстановки в Opportunity, и запросы ниже возвращают такое же количество.

SELECT count() FROM opportunity WHERE contactId = null
SELECT count() FROM Opportunity WHERE contactId = '000000000000000AAA'

Что касается записей в разрешении объекта (, начиная с '000' ), мало отличается от пустых ключей, а разбивку идентификаторов можно найти в блоге

Загадка префикса ключа Salesforce «000»

В приведенном выше сценарии мы не можем отфильтровать эти объекты в запросе Metadata API, однако мы можем фильтровать записи перед отправкой второго запроса в коде APEX.

Set responseIds - Response идентификаторы записей, возвращенные из первого запроса, и обработка идентификаторов для фильтрации идентификаторов «000» для второго запроса.

String prefix = Schema.SobjectType.ObjectPermissions.getKeyPrefix();
for(String str : responseIds){
    if(!str.subString(0,3).contains(prefix)){
        responseIds.remove(str);        
    }
}

Объект RecentlyViewed не может использоваться напрямую. Идентификаторы в этом объекте не являются идентификаторами, принадлежащими недавно просмотренному объекту, вместо этого они являются идентификаторами фактических записей. Поэтому, если вы намереваетесь получить доступ к записям этого объекта, вам нужно получить идентификаторы из недавно просмотренного объекта, затем декодировать ключевой префикс, чтобы получить правильное имя 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

Хотя у нас есть отдельный объект для каждого стандартного списка выбора, все они имеют один и тот же префикс ключа / тип объекта. Следующий код удалит все запросы, которые направлены к объектам раскрывающегося списка (Taskstatus, Casestatus, статус решения ...)

for(Id str : responseIds){
     if(Id.getsobjecttype() == 'Picklistmaster'){
         responseIds.remove(str);        
     }
 }

Что касается Loginhistory, записи после 6 месяцев будет удален отделом продаж. Итак, если вы запустите 2-й запрос (запрос-запрос, последующий запрос данных), и если этот 2-й запрос произойдет с l ie между окном обслуживания Salesforce, то во время вашего второго запроса указанный идентификатор уже удален из организации, следовательно, ошибка . И убедитесь, что у вас есть разрешения на управление пользователями.

Answer 3

Судя по ответу об ошибке и вашему описанию, это похоже на неисправное соединение между клиентом, который вы используете (Workbench?), Который пытается получить доступ к вашей организации Salesforce. Вот как я подхожу к устранению неполадок:

1. Проверьте, не является ли это проблемой, связанной с c внешним клиентом (Workbench), по сравнению с запросом данных в другом месте (DataLoader, VS Code, Dev Консольный / внутренний доступ). Если вы можете получить к нему доступ с помощью других методов, вы можете подтвердить, что это конкретное c соединение с вашей организацией.
2. Подтвердить профиль / разрешение Установить доступ к объектам и полям (звучит очевидно, но вы будете удивлены) . Даже индивидуальный доступ на уровне поля может помешать вам получить запись ( даже если вы системный администратор, это не значит, что у вас всегда есть безопасность на уровне поля для каждого поля ).
3. Убедитесь, что у вашего запущенного пользователя на клиенте есть полный доступ к запрошенным вами записям. Это особенно важно для проверки, возвращаются ли некоторые записи для запроса к объекту, но не все из них.

Мне нужно было бы получить более подробную информацию, чтобы помочь дальше, но подтверждение деталей вышеизложенного потребовало бы go долгого пути. Суть в том, что если вы можете получить доступ к определенным записям в объекте, но не к другим, то он сообщает мне, что у вас есть аутентификация в организации, есть доступ к объекту, но, возможно, у вас нет полного доступа или доступа к безопасности на уровне поля для этого. конкретный запущенный пользователь.