Поделюсь опытом: задача синхронизации справочников поставщиков и клиентов через AIF (в моем случае - из AX 4.0 в AX 2012) ... в общем случае не решается без интерактивной работы и адаптации ведущей программы (CRM итд.) к ведомой (AX2012). Кое-чего, однако, можно добиться с минимумом программирования.
Пусть ведущая система (здесь: AX 4.0) ничего не знает о ведомой. Сразу возникает вопрос: когда новая запись в справочнике достигает той степени полноты, чтобы передать его в ведомую систему? В худшем случае над записью работает несколько отделов. Можно запускать пересылку в конце рабочего дня, можно проверять заполнение обязательных полей.
Так или иначе, ведущая система дает толчок и размещает файл с клиентом/поставщиков в заданном каталоге сети. Для этого в AX 4.0 есть классический код из
\Data Dictionary\Tables\CustInvoiceJour\Methods\sendElectronically(). Учетная запись процесса, записывающего файл, должна быть именованной и быть Owner-ом файла:
http://msdn.microsoft.com/en-us/libr...=ax.10%29.aspx
В AX2012 создается входящий порт, который читает каталог и передает файл сервису CustCustomerService.create, CustCustomerService.update. В параметрах порта добавляем в Pipeline входящее преобразование XSLT к схеме AX2012 (см. ниже).
Создается batch job, в котором вручную (!) прописываются классические 2 процесса для чтения:
-
AifGatewayReceiveService
-
AifInboundProcessingService
Запускаем batch job, и после 100 проб и ошибок получаем первую запись.
Характерно, что можно создать CustTable, DirPartyTable и все до единой связанные таблицы, даже стандартную аналитику. Ключевое слово здесь - это "
создать".
Вслепую
обновить удастся только саму CustTable, поскольку AX2012 требует <EntityKeys> того, что надо обновлять. В качестве этих Keys можно взять Primary Key или RecId таблицы. Если для CustTable есть натуральный ключ AccountNum, то для DirPartyTable есть только PartyId = RecId, который внешней программе не известен без дополнительного запроса
getKeys и целой программной машинерии для обработки этого запроса. Впрочем, и без этого есть пара подводных камней:
1) При запросе на обновление система требует текущую RecVersion записи или Hash записи, который опять-таки надо получать интерактивным запросом. Тем самым система пытается предотвратить конкурентные обновления. Можно вырвать системе ядовитые зубы, закомментировав все проверки на Hash в классе
AxdBaseUpdate.
2) Для обновления AX требует дату и время документа в элементе <ValidAsOfDateTime>. Если ведущая система такой информации не дает, то приходится извращаться, ибо .NET не поддерживает стандарт XSL/XPath 2.0 и, в частности, такую функцию как
fn:current-DateTime()
3) Если в атрибуте action не указать "update", чтобы ввести систему в режим "инкрементного обновления", то AX2012 попытается стереть связанные таблицы типа DirPartyTable. Т.е. в XML файле должно стоять
<CustTable class="entity" action="update">
А теперь привожу плод бессонных ночей - трансформацию XSLT, которая преобразует "плоскую" запись в формат AX2012, включая адреса и телефоны. Это преобразование реагирует на сигнал
<DocPurpose>Duplicate</DocPurpose> и переходит из режима полного create в частичный update:
CustTable_AX40_to_AX2012.zip