Загрузка записей в Dynamics 365 через ADF

Я использую соединитель Dynamics в фабрике данных Azure.

TL; DR

Поддерживает ли этот соединитель загрузку дочерних записей, которым необходимо передать ключ родительской записи? Например, если я хочу создатьcontact и прикрепить к родителю account, Я добавляю запись с нулевым contactid, действительный parentcustomerid GUID и установите parentcustomeridtype до 1 (или 2), но я получаю сообщение об ошибке.

Длинная история

Я успешно подключаюсь к Dynamics 365 и извлекаю данные (например, lead table) в таблицу SQL Server

Чтобы проверить, могу ли я передавать данные другим способом, я просто загружаю данные обратно из lead стол в lead сущность в Dynamics.

Я получаю такую ​​ошибку:

На стороне "Раковины" произошел сбой. ErrorCode=DynamicsMissingTargetForMultiTargetLookupField,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=,Source=,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message= Не удается найти целевой столбец для многоцелевого поля поиска: 'ownerid'.

В качестве теста я удалил ownerid из списка исходных столбцов загружается ОК.

Очевидно, это значение внешнего ключа.

У меня возникают два вопроса:

  1. В частности, что касается сообщения об ошибке: если бы я знал, какой поиск нужно использовать, как я могу указать, по какой таблице поиска он должен проверять? В разъеме ADF нет настроек, позволяющих мне это делать.

  2. Очевидно, это значение внешнего ключа. Если бы у меня было только имя (или бизнес-ключ) для этой строки, как я могу легко найти значение внешнего ключа?

Как это обычно делается через другие API, например веб-API?

Есть ли надстройка XRMToolbox, которая поможет прояснить ситуацию?

Я также читал несколько сообщений, подразумевающих, что вы можете отправлять предварительно подключенные данные в XML-документе, так что, возможно, это тоже поможет.

ИЗМЕНИТЬ 1

Я понял, что lead.ownertypeid поле в моем исходном наборе данных NULL(вот что было экспортировано). Это также NULL, если я просматриваю его в различных инструментах Xrmtoolbox. Я очень старался кодировать егоsystemuser (что на самом деле есть в owner таблицу против фактической записи владельца), но я все равно получаю ту же ошибку.

Я также заметил, что есть запись с таким же значением PK в systemuser Таблица

Итак, одна и та же запись находится в двух таблицах, но как мне указать динамику, какой из них использовать? и почему это вообще заботит?

РЕДАКТИРОВАТЬ 2

Я получил подобное сообщение для msauto_testdrive за customerid.

Я исключил все записи с customerid=null, и получил ту же ошибку.

РЕДАКТИРОВАТЬ 2

Эта ссылка указывает на то, что мне нужно установитьcustomeridtypeна 1 (Учетная запись) или 2 (Контакт). Я сделал это, но все равно получил ту же ошибку.

Также я считаю, что у меня такая же проблема, как и у этого парня.

Возможно, разъем ADF страдает той же проблемой.

Источник

2 ответа

Решение

Это ограничение ADF в отношении полиморфных поисков CDS, таких как Customer и Owner. Проголосуйте за идею ADF

Обходной путь - использовать два временных поля поиска источника (команда владельца и пользователь в случае владельца, учетная запись и контакт в случае клиента) и с параллельной ветвью в потоке MS для решения этой проблемы. Узнайте больше, также вы можете скачать образец Flow для использования.

  • Сначала создайте два временных поля поиска в сущности, в которую вы хотите импортировать данные поиска клиентов, в сущности Account и Contact соответственно.
  • Затем в потоке конвейера ADF вам нужно будет сопоставить значения GUID для полей "Учетная запись" и "Контакт" с соответствующими полями подстановки, созданными выше. Самый простой способ сделать это - иметь два отдельных столбца в исходном наборе данных: один содержит GUID учетной записи для сопоставления, а другой - "Контакт".
  • Затем, наконец, вы можете собрать Microsoft Flow, который затем выполнит соответствующее сопоставление временных полей с полем поиска клиента. Во-первых, определите точку срабатывания, когда создается ваша затронутая запись Entity (в данном случае, Contact), и добавьте несколько параллельных ветвей для проверки значений в любом из этих двух временных полей поиска.

  • Затем, если выполняется одно из этих условий, настройте задачу обновления записи для выполнения обновления одного поля, как указано ниже, если в поле поиска учетной записи ADF есть данные в нем.
Источник

На момент написания @Arun Vinoth был на 100% прав. Однако вскоре после этого было обновление документации (в ответ на поднятое мной GitHub), в котором объяснялось, как это сделать.

Я запишу здесь, как я это сделал.

Чтобы заполнить контакт с родительской учетной записью, вам понадобится GUID родительской учетной записи. Затем вы готовите такой набор данных:

SELECT 
-- a NULL contactid means this is a new record
CAST(NULL as uniqueidentifier) as contactid,
-- the GUID of the parent account
CAST('A7070AE2-D7A6-EA11-A812-000D3A79983B' as uniqueidentifier) parentcustomerid,
-- customer id is an account
'account' [parentcustomerid@EntityReference],
'Joe' as firstname,
'Bloggs' lastname,

Теперь вы можете применить обычный подход автоматического сопоставления в ADF.

Теперь вы можете выбрать из этого набора данных и загрузить в contact. Вы можете применить обычный подход к автоматическому сопоставлению, а именно: создавать наборы данных без схем. Выполнение действия копирования без сопоставления столбцов

Источник
Другие вопросы по тегам