Цитата:
Сообщение от
EVGL
Т.е. вы предложили вашему клиенту создать соответствующие entity, и подключить их через ODBC, учитывая например разницу в структуре между SalesHeaderEntityV2 и SalesTable? Очень хорошо. А то я подумал, что вы напрямую к базе данных подключаетесь.
Если рассматривать гипотетическую возможность перехода с AX2012R3 на D365FO то
каков смысл создания своих DIXF/DMF entity в AX2012R3 при интеграции с третьей системой?
Ведь что такое это entity? Это дополнительный слой состоящий из Entity class и Staging table который отсоединяет нас от Target table.
Target table сегодня SalesTable, а завтра SalesHeaderEntityV2. В стандартных entity вендор меняет "незаметно" Target table и подразумевается что это не больно.
А в "своих" entity эта адаптация сама не случиться и тут неважно принадлежат эти свои "Entity class" и "Staging table" к DMF или нет.
Если использовать стандартные entity, к примеру DMFSalesTableEntity то в теории да, переход это облегчит. Но только в случае отсутствия кастомизаций для или около заказа чего я ни на одном проекте не встречал. Это одно из самых перегруженных в AX мест.
В качестве прослойки может прекрасно служить бизнес-логика AIF сервиса, какую пользу могут принести entity - я не понимаю. Чем моя собственная "entity" в виде моего класса и моей Staging таблицы хуже чем DMF?
Напрямую к базе данных - в этом ничего плохого нет. Даже если речь об ODBC в базу AX. Достаточно создать View для создания слоя. В моем же сценарии смотрит AX в чужую базу. И кладет в Staging. Использует внутреннее AIF "API" для работы с бизнес-сущностями. По сути это та же парадигма "DMF" только намного легче.