В salesforce.com вы можете иметь многозначные атрибуты?
Я разрабатываю драйвер 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>
Я знаю, как добавить значение (AttrValue) к атрибуту (FieldName), добавить узел, как:
<FieldName>AttrValue</FieldName>
Все это работает и довольно просто.
У меня такой вопрос: может ли значение в SFDC быть многозначным? В eDirectory изменение многозначного атрибута может происходить двумя способами:
- Все значения можно удалить, а новый набор заново добавить.
- Одно удаленное значение может быть отправлено как событие такого рода (remove-value), или многие значения могут быть удалены за одну операцию.
Глядя на SFDC, я вижу только атрибуты Multi-picklist, которые, кажется, хранятся в одной записи: или; разграничены. Есть ли другой тип многозначного атрибута, который по-разному управляется в SFDC? И если да, то как можно было бы манипулировать им через SOAP API?
Мне все еще нужно решить, хочу ли я отобразить эти мультиспиклеты в одну строку или в многозначный атрибут строк. Первый способ проще, второй - полезнее... Хм... Выбор...
Некоторые ссылки:
- Я использовал страницу примеров SOAP-сообщений, чтобы понять, как должны выглядеть документы.
- Apex Explorer - это инструмент для просмотра базы данных и тестирования запросов. Как и DBVisualizer, для баз данных, подключенных к JDBC. Это было бы намного сложнее без него!
- SoapUi также требуется, и прекрасный инструмент!
1 ответ
Насколько я знаю, нет поля с несколькими значениями, кроме списков выбора с множественным выбором (и они отображаются в строку, разделенную точкой с запятой). Обычно платформа поощряет вас создавать правильные отношения с другой (возможно, новой, пользовательской) таблицей, если вам нужно иметь несколько значений, связанных с вашими данными.
Единственная другая "необычная" вещь, о которой я могу подумать, это то, как поле OwnerId на определенных объектах (Case, Lead, может быть, что-то еще) может использоваться для указания на запись User или Queue. Выглядит странно, когда вы привыкли к связям внешних ключей из традиционных баз данных. Но это не совпадает с тем, что вы спрашиваете, поскольку будет только одно значение за раз.
Конечно, иногда вы можете быть удивлены значениями, которые вы увидите в базе данных, в зависимости от локали просмотра пользователя (например, профиль системного администратора становится Systeembeheerder на голландском языке). Но это все равно будет одно значение, переведенное на лету перед тем, как результаты запроса будут отправлены вам.
Когда мне приходилось выполнять интеграцию SOAP с SFDC, я всегда использовал WSDL-файлы, и большую часть времени мне нравился код Java, сгенерированный из них с помощью Apache Axis. Самостоятельное создание сообщения SOAP кажется... вау, немного хардкорным. Вы уверены, что предпочитаете визуализацию XML над созданием классов, исключений и всего этого, готового к использованию одним из нескольких готовых методов интеграции? Если они когда-нибудь изменят WSDL, мне нужно просто восстановить классы из него; тогда как изменения в вашей библиотеке создания сообщений SOAP могут быть болезненными...