Выгрузка измененных клиентов во внешнюю систему

[DSPIC]

Цитата:

Сообщение от mazzy

эээээ. а зачем выгружать 10К адресов?
выгрузи только те, что относятся к измененным клиентам.

ты говоришь:
* клиенты используют адреса в FK
* это бизнес локика наверняка заложена и в Аксапте и во внешней системе
* значит с огромной вероятностью во внешней системе будут заданы constraints на адресе
* это значит, чтобы приемник смог принять без ошибок, система источник ДОЛЖНА сначала передать адреса, а уж потом клиентов.
* будет ли источник передавать сначала все 10К изменившихся адресов или будет как то приоретизировать... вопрос реализации, а не вопрос подхода. и я сильно подозреваю, что этот вопрос уходит сильно за рамки исходного вопроса.

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

а прикинь есть еще удаление. и на приемнике может присутстовать каскадное удаление данных

Так-с давай синхронизируемся.
1. Мне нужно выгрузить клиентов с их адресами и контаками. Мне не нужно выгружать по-отдельности клиентов, адреса и контакты (в этом случае порядок важен, но соблюсти его технически невозможно). Т.е. ещё раз - минимальной единицей экспорта является посылка с подарками, а не коробка и подарки по-отдельности.

2.

Цитата:

Сообщение от mazzy

эээээ. а зачем выгружать 10К адресов?
выгрузи только те, что относятся к измененным клиентам.

Так в этом суть задачи - среди множества изменившихся 10К адресов найти 5 клиентов, кторые подлежат выгрузке. Как?

[mazzy]

Цитата:

Сообщение от DSPIC

Так-с давай синхронизируемся.
1. Мне нужно выгрузить клиентов с их адресами и контаками. Мне не нужно выгружать по-отдельности клиентов, адреса и контакты (в этом случае порядок важен, но соблюсти его технически невозможно). Т.е. ещё раз - минимальной единицей экспорта является посылка с подарками, а не коробка и подарки по-отдельности.

т.е. ты говоришь о DataEntity (запись в головной таблице + несколько записей в подчиненных таблицах)
насколько я понимаю у автора топика был другой вопрос... и я отвечал про справочник.

ну и фиг с ним. давай поговорим о DataEntity.

Цитата:

Сообщение от DSPIC

Так в этом суть задачи - среди множества изменившихся 10К адресов найти 5 клиентов, кторые подлежат выгрузке. Как?

в контексте DataEntity конечно нет.
в контексте DataEntity нужно записи в подчиненных таблицах, которые связаны с главной: есть 5 клиентов - надо найти адреса, относящиеся к каждому из них

т.е. в рамках кода, который выгружает клиентов
нужно сделать запрос к адресам, которые связаны с передаваемым клиентом
и только для этих адресов проверить - изменились ли они.

И тут...
Классический DataEnity предполагает, что в DataEntity содержатся все данные, относящиеся к главной. Т.е. DataEnity - это конечное целевое состояние которое должно быть у главной записи. (по крайней мере я так понимаю подход с DataEnity)

В рамках такого подхода DataEnity, можно ли с логической точки зрения передавать изменения в подчиненных таблицах? Не будет ли принимающая сторона трактовать отсутствующие в DataEnitity записи как команду удалить, все что не перечислено в DataEnity?



Понятно, что если и источник, и приемник контролируются одной командой разработки, то может быть всё что угодно. Но как правило команда не одна. И я бы не рассчитывал, что в DataEnity можно передавать отличия, а не конечное целевое состояние.

=======
Другими словами,
1. если Клиенты и Адреса - выгружаемые справочники, то рано или поздно система источник все равно должна выгрузить все данные. Причем выгрузка должна учитывать, что приемник может содержать constraints на бизнес-логику
2. если клиенты+адреса - это DataEnitity, то совершенно не обязательно выгружать все адреса (DataEnitity никогда этого и не делает). Но вот можно ли выгружать в DataEnitity только изменившиеся адреса - большой вопрос, требующий согласования на уровне публичных интерфейсов между системами. Насколько я понимаю, предполагается, что DataEnitity дложна содержать все данные, относящиеся к главной записи.

[mazzy]

и давайте попробуем вернуться к исходному вопросу:
Выгрузка измененных клиентов во внешнюю систему

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

причем нужна синхронизация данных в этих связанных системах, а не одна только выгрузка.
синхронизацию (выгрузку и загрузку) могут делать разные команды на разных языках и с разными представлениями.

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


так, вот прежде всего, нужно понимать, что:
1. к выгрузке будет и парная операция - загрузка.
2. загрузка предполагает, что могут быть ограничения данных, которых нет в системе-источнике, но система источник должна учитывать эти ограничения
3. синхронизация справочников - рано или поздно все равно должна синхронизировать все данные справочников. нужно ли расставлять приоритеты и передавать записи в определенном порядке - вопрос конкретной реализации. но скорее всего порядок записей не важен - главное, чтобы все записи всех справочников рано или поздно были синхронизированы
4. однако с точки зрения бизнес логики порядок таблиц в выгрузке важен из-за constraints на принимающей системе
5. также с точки зрения бизнес логики важен порядок записей в таблицах, где реализован паттерн (id, parentid) из за constraints на принимающей системе
6. на принимающей стороне возможно реализованы каскадные удаления, которые система источник должна учитывать
7. на принимающей стороне возможны уникальные индексы, отличающиеся от уникальных индексов в системе источнике, поэтому некоторые insert/update могут не выполняться на принимающей стороне
8. и т.п.

[Vadik]

Цитата:

Сообщение от mazzy

начнем с того, что сама по себе выгрузка нафиг никому не нужна

[trud]

Цитата:

Сообщение от mazzy

1. если Клиенты и Адреса - выгружаемые справочники, то рано или поздно система источник все равно должна выгрузить все данные.

Ну проблема что в АХ это не так. Т.е. в таблице LogisticsPostalAddress, LogisticElectronicAddress нет типа адреса(что это клиент или не клиент) и там хранятся адреса для всех сущностей( в том числе и для транзакционных). И простой связи с клиентом тоже нет, она идет через несколько джойнов. Т.е. можно сделать предположение что изменений адресов клиентов которых надо выгружать немного(это действительно так), но делать предположение что изменений всех адресов будет немного - это слишком сильно, может они вообще вбивают отдельные емейлы и телефоны для заказа
Получается остается только решение предложенное DSPIC.

Цитата:

Сообщение от Ace of Database

тут пишу про SysDatabaseLog потому что это прикольно и тоже работает.

Вот это все еще непонятно.Вы делаете предположение что у вас дата-время или RecId в этой таблице монотонно возрастает, но это же не так(данные могут обновляться в транзакции). Т.е. непонятно как вы предлагаете получать изменения за момент времени

PS:
А D365FO как-то решает эту задачу?

[trud]

Цитата:

Сообщение от mazzy

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

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

[mazzy]

Цитата:

Сообщение от trud

Ну проблема что в АХ это не так. Т.е. в таблице LogisticsPostalAddress, LogisticElectronicAddress нет типа адреса(что это клиент или не клиент) и там хранятся адреса для всех сущностей( в том числе и для транзакционных).

Ну, во-первых, это не проблема, а задача! А проблема - это DirParty в целом.
Будь проклят тот архитектор, который начал портить Аксапту с этого фреймворка

Смотри:
1. с точки зрения бизнес-логики адреса - это не бесконечный список произвольных адресов, это вполне конретные адреса с определенной ролью - юридический адрес, адрес склада 1, адреса склада N, почтовый адрес и т.п. причем один и тот же адрес может использоваться для разных ролей адресов
2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец)
3. но я сильно сомневаюсь, что в системе приемнике адреса реализованы точно также

Поэтому, с точки зрения бизнес-логики нужно синхронизировать адреса в разных ролях. если есть "запасные" адреса, то нужно очень четко синхронизировать primary и "остальные" адреса. (например, если зарегистрировано несколько адресов с ролью "юридический адрес", то выгрузить-и-загрузить нужно единственный, верный, указанный в уставе. например, если есть разные адреса доставки для разных отделов, то нужно выгрузить-и-загрузить правильные адреса для правильных ролей и с правильной принадлежностью)

поэтому, задача "выгрузить-и-загрузить LogisticsPostalAddress, LogisticElectronicAddress" - это полный бред программистского подхода. нафиг это никому не нужно.

нужно, чтобы в системе приемнике получились правильные адреса и правильной ролью и в правильных местах.

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

Цитата:

Сообщение от trud

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

а ты похоже пытаешься выгрузить данные из DirParty одним запросом...
как скажешь.

я не верю, что данные из dirParty можно и нужно синхронизировать универсальным однопроходным алгоритмом даже в случае аксапта-аксапта.

для решения конкретной технической задачи "быстро, запросом узнать изменились ли записи в конкретной таблице с таким-то фильтром" вполне подойдет shadow-таблица

Цитата:

Сообщение от trud

Получается остается только решение предложенное DSPIC.

как скажешь.

Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.

Но если остается только это. что ж поделать. как скажете

[mazzy]

Цитата:

Сообщение от trud

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

я не очень понимаю каким образом обсуждение
технической и внутренней задачи "найти измененные"
влияет на внешний протокол обмена.

но если это все что вы согласовали в протоколе
то и не меняйте согласованную часть...

[Ace of Database]

Найти ближайшее решение, которое, при наименьшей гениальности, будет работать

select top 1 * from decision 
where IsActive = 1
order by GeniusLevel

[DSPIC]

Цитата:

Сообщение от mazzy

Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..

Сошлюсь на то, что ты недопонял концепт и\или задачу, на том удалюсь из дискуссии за нехваткой времени, сорри.

Цитата:

Сообщение от mazzy

Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..

Эмм... как скажешь

[EVGL]

Цитата:

Сообщение от mazzy

2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец)

Доводы в пользу DirParty:
0) Intercompany
1) В теории так легче синхронизироваться с CRM. В теории.
2) В самой таблице может быть тоже много общего, например между клиентом и поставщиком: название и юридическая форма, естественно, но и DUNS, номер в "ЕГРЮЛ", "ИНН" (меня регулярно разочаровывает, что в DirPartyTable нет VatNum). Недавно имел диагностику на клиенте, у которого почти каждый грузоотправитель одновременно и грузополучатель.

[EVGL]

Цитата:

Сообщение от trud

А D365FO как-то решает эту задачу?

К сожалению, отдельные поля не проверяются: либо все [подпадающее под фильтр], либо только CustTable, либо ничего.

[Vadik]

Цитата:

Сообщение от trud

.. они уже согласовали протокол обмена(вызовы раз в минуту по интервалу с заданной группой клиентов)

https://youtu.be/XMWiN1mnw7c?t=234

Я не уверен что такая реализация взлетит. Для этого в общем случае надо хранить все изменения (в виде снэпшотов, или как-то еще) по достаточно крупной иерархической структуре (6М клиентов, 17М адресов плюс наверное столько же контактов и т.д.). Хранить и обновлять эту историю годами (так как мы не знаем как далеко назад во времени может потребоваться заглянуть) , и при этом искать по ней в несколько потоков десятками запросов в минуту ? Я бы не стал. Возможно, кастомное и спецализированное решение на X++ и заработает, но "просто, гибко, быстро" - тут наверное придется выбирать и даже не 2, а 1 из 3 Но если заработает, было бы интересно узнать что и как

Цитата:

Но в принципе интерестно обсудить как это более оптимально сделать

У меня есть несколько сделанных проектов где мастер-данные (номенклатуры, клиенты, поставщики) вытягиваются из Ax 2012 стандартным AIF+CT через "скользящее окно" (изменения за последний час, 24 часа, 48 часов). Если есть желание попробовать как это работает, могу отдать проект (C#) на следующей неделе, его наверное надо будет немного почистить от клиентской специфики. Мне тоже будет интересно, на 6М клиентов я CT еще не тестировал

[mazzy]

Цитата:

Сообщение от Vadik

Для этого в общем случае надо хранить все изменения (в виде снэпшотов, или как-то еще) по достаточно крупной иерархической структуре (6М клиентов, 17М адресов плюс наверное столько же контактов и т.д.).

зачем "все изменения" то?

хранить нужно поледнее отданное "состояние" в каждую систему-приемник.
причем и "состояние" нужно только если передаются не все поля,
как правило нужен только признак изменения данных - recVersion или хэш с фиксированной длиной.

Цитата:

Сообщение от Vadik

Для этого в общем случае надо хранить все изменения... Хранить и обновлять эту историю годами

а это зачем?
вроде исходный вопрос был "есть внешняя система, ей как-то надо передавать клиентов из АХ которые изменились за интервал времени."

Цитата:

Сообщение от Vadik

и при этом искать по ней в несколько потоков десятками запросов в минуту ?

с shadow-таблицами - легко.
а в чем ты видишь проблему?

[trud]

Спасибо за комментарии.
По итогу оценил переделку в 3 дня, если согласуют, напишу чем закончилось. Это у них работает сейчас(с фильтром по "или" по дате модифиции по всем таблицам в запросе, я выше приводил пример), каждый вызов занимает минуту-полторы, подгружая в постоянном режиме где-то 6 ядер на 100% CPU, при этом большинство запросов возвращают пусто

[Vadik]

Пока разминался красненьким работал над небольшим POC, решил прогнать тест:

Дано: 5M клиентов более-менее равномерно (500К - 1.3М) распределены по 5 компаниям
В сутки обновляется (Insert/Update) 0.1% клиентов

Вопрос: что нам будет стоить идентицифировать обновленных клиентов с помощью Change tracking ?

Потрачено времени:

• Сгенерировать и импортировать данные через DMF - 4 дня
• Оттюнить AifSqlCtChangeTracking - 4 часа

Тестируем:

• Случайным образом обновляем данные по всем уровням AxdCustomer (это в некотором роде в сумме более 0.1% данных, ну и ладно)
• Запускаем незатейливый джобик в самой большой компании (1.3М клиентов)

Итого: на бюджетной VM в Azure (B4Ms, 4xvCPU, 16 GB RAM, standard HDD) список измененных клиентов (CustTable.RecId) мы получаем за 5 секунд (достаточно шустро). Без перекрытия прочего стандартного кода в .insert(), .update(), event handler-ов и shadow таблиц (просто). Для всех обновлений, в том числе и извне AX (надежно)

[trud]

Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором. Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов
Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось
Плюс сам тест очень простой. Если удалить к примеру e-mail будет работать? Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?

[Vadik]

Цитата:

Сообщение от trud

Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов

Change tracking честно говорит что менялось в AX в указанном отрезке времени. Какие из этих изменений актуальны для "внешней системы" (в общем случае - для "внешних систем"), в каком они сейчас состоянии - с этим пусть разбираются сами внешние системы

Цитата:

Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось

Мы еще ничего никуда не выгружаем, мы просто спросили систему "что нового". Кто такие пользователи, что они видят, что им "непрозрачно" - пока непонятно

Цитата:

Плюс сам тест очень простой

Ну уж какой есть

Цитата:

Если удалить к примеру e-mail будет работать?

Конкретно для AxdCustomer и email - нет, потому что запрос использует не "физические" таблицы а DirPartyPostalAddressView и DirPartyContactInfoView. Для "физических" таблиц удаления отслеживаются (см. скриншот). Как интеграция отслеживает удаление данных (и должна ли) - это отдельная тема сама по себе

Цитата:

Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?

Да. AifChangeTracking::construct() принимает Query в качестве аргумента

Цитата:

Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором

А кто-то утверждал что CT это "лучший" выбор, "всегда" ? Я например знаю сценарии где CT работает плохо и для них его предлагать не буду. Тест показывает решение поставленной задачи с неплохими (как мне кажется) трудозатратами, производительностью и надежностью. Кто захочет - попробует. Если будут альтернативные решения, с удовольствием на них посмотрю. Окажутся проще, быстрее, удобнее - буду иметь их в виду

[trud]

Цитата:

Сообщение от Vadik

Да. AifChangeTracking::construct() принимает Query в качестве аргумента

Так а что туда передавать? Ну т.е. вчера клиент принадлежал группе выгрузки и выгружался, сегодня ему поменяли группу на невыгружаемую. Нужно же как уведомить внешнюю систему об этом
Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"
Хотя тут возможно ошибка выжившего, когда оно работает нормально, консалтинг не зовут, а мы видим только когда оно не работает

[Vadik]

Цитата:

Сообщение от trud

Так а что туда передавать? Ну т.е. вчера клиент принадлежал группе выгрузки и выгружался, сегодня ему поменяли группу на невыгружаемую. Нужно же как уведомить внешнюю систему об этом

Ну это наверное лучше с клиентскими постановщиками обсудить

Цитата:

Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"

Аминь