В salesforce.com у вас есть многозначные атрибуты?

Question

Я разрабатываю драйвер Novell Identity Manager для Salesforce.com и стараюсь лучше понять платформу Salesforce.com.

У меня был действительно хороший успех на сегодняшний день. Я могу читать практически любые классы объектов из SFDC и создавать для них объекты eDirectory, а что нет. Все это сделано и работает красиво. (Канал издателя). Как только я получил события Query, большинство из них начало работать в Канале издателя.

Теперь я работаю над отправкой событий в SFDC (канал подписчика), когда происходят изменения в eDirectory.

Я использую функцию upsert() в SOAP API, а с Novell Identity Manager вы в основном создаете SOAP-документ и можете видеть результаты по мере его создания. (Вы можете сделать это в XSLT, или вы можете использовать различные разрешенные токены для создания документа в DirXML Script. Я использую DirXML Script, который работает до сих пор.).

В результате этого комментария я могу создать документ SOAP, увидеть его, чтобы убедиться, что я прав. Обычно это отличается от подхода Java/C++, который обычно предоставляет код примера. Это гораздо более визуально.

Есть несколько вещей, касающихся upsert(), которые я не совсем понимаю. Я знаю, как очистить значение, должен ли я получить такое событие. Внутри <urn:sObjects> узла, добавить узел как (предполагая, что вы получите ваши пространства имен уже объявлены):

<urn1:fieldsToNull>FieldName</urn1:fieldsToNull>

Я знаю, как добавить значение (значение атрибута) атрибуту (FieldName), добавить узел, как:

<FieldName>AttrValue</FieldName>

Все это работает, и довольно прямо вперед.

Вопрос, который у меня есть, может ли значение в SFDC быть многозначным? В eDirectory изменяемый многозначный атрибут может происходить двумя способами:

• Все значения могут быть удалены, и новый набор будет повторно добавлен.
• Удаленное одиночное значение может быть отправлено в виде такого события (remove-value), или многие значения могут быть удалены за одну операцию.

Глядя на SFDC, я вижу только атрибуты Multi-picklist, которые, кажется, хранятся в одной записи: или; разграничены. Существует ли другой вид многозначного атрибута, управляемый по-разному в SFDC? И если да, то как можно манипулировать им с помощью SOAP API?

Мне все еще нужно решить, хочу ли я отображать эти мультиколлекторы в одну строку или многозначный атрибут строк. Первый способ проще, второй способ является более полезным ... Хммм ... выбор ...

Некоторые ссылки:

• Я использую страницу Sample SOAP messages, чтобы понять, что документы должны выглядеть.
• Apex Explorer - это инструмент для поиска базы данных и тестирования запросов. Подобно DBVisualizer для JDBC-подключенных баз данных. С этим было бы намного сложнее!
• SoapUi также требуется, и прекрасный инструмент!

Answer 1

Насколько я знаю, нет многозначного поля, отличного от многоколесных picklists (и они сопоставляются с разделительной точкой с запятой). Обычно платформа поощряет вас создавать правильные отношения с другой (возможно, новой, настраиваемой) таблицей, если вам нужно иметь несколько значений, связанных с вашими данными.

Только другие «необычные» вещи, о которых я могу думать, это то, как поле OwnerId на определенных объектах (Case, Lead, возможно, что-то другое) может использоваться для указания записи пользователя или очереди. Выглядит странно, когда вы привыкли к отношениям внешних ключей из традиционных баз данных. Но это не совпадает с тем, что вы просите, поскольку будет только одно значение за раз.

Конечно, вы можете иногда подергиваться со значениями, которые вы увидите в базе данных в зависимости от пользовательской локализации пользователя (например, профиль System Administrator становится Systeembeheerder на голландском языке). Но это будет по-прежнему одно значение, переведенное «на лету» перед тем, как результаты запроса будут отправлены обратно вам.

Когда мне приходилось выполнять SOAP-интеграцию с SFDC, я всегда использовал файлы WSDL, и большую часть времени было отлично с Java-кодом, сформированным из них с помощью Apache Axis. Ручное создание сообщения SOAP кажется ... вау, хардкор немного. Вы уверены, что предпочитаете визуализацию XML над созданием классов, исключений и всего этого материала, готового для использования с одним из нескольких готовых методов integration? Если они когда-либо изменят WSDL, мне нужно просто восстановить классы из него; тогда как изменения в вашей библиотеке создания сообщений SOAP могут быть болезненными ...