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

[mazzy]

Цитата:

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

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

Именно, совершенно любого.
поэтому я уже написал:

Цитата:

5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете.

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

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

Цитата:

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

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

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

но это если кодить.

[Ace of Database]

SysDatabaseLog - и есть тот самый shadow. И понятно, что нельзя логировать таблицы типа проводок. Речь же идет о справочнике. А тут сам бог велел логировать, чтобы потом разбираться: кто ввел неправильные данные.
И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog.
А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog
Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая.

[Ace of Database]

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

[mazzy]

Цитата:

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

SysDatabaseLog - и есть тот самый shadow.

нет. в SysDatabaseLog добавляются записи при каждом чихе.
в shadow таблица добавляется максимум 1 запись для каждой записи справочника.

Цитата:

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

И понятно, что нельзя логировать таблицы типа проводок. Речь же идет о справочнике.

теоретически конечно да.
но видели мы на практике эти справочники... и что туда пихают.
особенно, если в справочнике появляется "выгрузка в другую систему"

Цитата:

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

А тут сам бог велел логировать, чтобы потом разбираться: кто ввел неправильные данные.

чтобы разбираться - да.
чтобы выгружать - нет.
никто ж не запрещает и shadow сделать, и в SysDatabaseLog включить.

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

Цитата:

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

И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog.
А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog
Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая.

как скажете.

[DSPIC]

Буквально недавно была такая же задача. Как сделали:

1. Представляем себе, что CustTable+Addresses+Contacts и прочее прилепленное - это XML документ для выгрузки, где CustTable - верхняя запись
2. Каждый раз, когда изменяестя CustTable (либо любая из дочерних) мы формируем этот XML и выгружаем куда-то там во вне. Но при этом, мы храним последнюю выгруженную версию XML где-то в отдельной таблице.
3. Естетсвенно, каждый раз, когда мы хотим выгрузить XML, мы сравниваем его с последней выгруженной версией. Выгружаем только, если отличаются.
4. Важно, что непосредственно выгрузка делается в Batch на основании таблицы-очереди. Т.е. п.2,3 формируют очередь на выгрузку, когда whereas отдельный Batch расталкивает её. Это развяжет по транзакциям, обезопасив работу пользователей и SQL.
4.1 В таблице-очереди мы храним не сам XML, а ссылку на запись верхнюю запись, что изменилась,т.к. ввиду периодичности работы Batch, хранимый XML может потенциально устареть.

Из некрасивого:
=============
- триггеры придется повесить на все таблицы, изменения которых влечёт формирование нового XML
- придется хранить последнюю версию XML (или его хэш)
- нужно покодить

Из красивого:
===========
- Гантированно выгружаете только в том случае, когда изменились нужные для выгрузки поля
- Никаких завязок на modifiedDate\SystemLog, что ведёт приямиков в АД
- Будет работать в любой версии AX.

[mazzy]

Цитата:

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

это XML документ для выгрузки

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

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

[DSPIC]

Цитата:

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

Угу. добавить еще проверку на recVersion, чтобы не сравнивать длинные строки

Имеешь ввиду - убрать триггеры на update\insert и сканить таблицы на предмет изменившегося recVersion, а потом уже смотреть, изменились ли выгружаемые поля? Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable. Т.е. ты получишь 500К изменившихся Addresses, из которых придется найти только 50 клиентов, подлежащих выгрузке. Ну такое: неоптимально и наизнанку. Тригерры всё-таки нужно вешать, а с ними и recVersion сравнивать бессмысленно, т.к. заведомо поменяется.

[mazzy]

Цитата:

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

Имеешь ввиду - убрать триггеры на update\insert и сканить таблицы на предмет изменившегося recVersion, а потом уже смотреть, изменились ли выгружаемые поля?

конечно.

именно, наизнанку.

Цитата:

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

Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable. Т.е. ты получишь 500К изменившихся Addresses, из которых придется найти только 50 клиентов, подлежащих выгрузке. Ну такое: неоптимально и наизнанку. Тригерры всё-таки нужно вешать, а с ними и recVersion сравнивать бессмысленно, т.к. заведомо поменяется.

подумай еще раз на эту тему
я тоже через такие рассуждения прошел

[DSPIC]

Цитата:

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

конечно.

именно, наизнанку.


подумай еще раз на эту тему
я тоже через такие рассуждения прошел

Начинается... Подумал, не знаю. Поделись, сэкономь мне 50$ времени

Пример: Выгрузке подлежат клиенты, у которых CommissionSalesGroup.Export=Yes. Выгружать нужно в т.ч., если изменились их адреса. Итак, поменялся RecVersion у 10К адресов, в которые входят наши 5 клиентов для выгрузки.Ну, вдовесок там ещё контакты и прочая DirParty лабуда.

Аж интересно мне..

[Ace of Database]

Цитата:

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

Имеешь ввиду - убрать триггеры на update\insert и сканить таблицы на предмет изменившегося recVersion, а потом уже смотреть, изменились ли выгружаемые поля? Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable. Т.е. ты получишь 500К изменившихся Addresses, из которых придется найти только 50 клиентов, подлежащих выгрузке. Ну такое: неоптимально и наизнанку. Тригерры всё-таки нужно вешать, а с ними и recVersion сравнивать бессмысленно, т.к. заведомо поменяется.

Я бы такую задачу и сделал через триггеры. А тут пишу про SysDatabaseLog потому что это прикольно и тоже работает. Просто уж очень это не-классически.

[mazzy]

Цитата:

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

Можно, было бы, но много дочерних таблиц... А от них нужно прийти к верхенму CustTable.

и да, еще соображение, которое я вырезал.
но раз уж дошло до дочерних таблиц.

на дочерних таблицах так или иначе, но будут заданы constraints на FK (в аксапте такие валидации выполняются в validateWrite, задаются в reltation)

т.е. чтобы внешняя система смогла принять данные, данные должны быть переданы в определенном порядке - сначала родитель, потом потомок.

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

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

[DSPIC]

Цитата:

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

и да, еще соображение, которое я вырезал.
...

О, отличная мысль. Я так буду заказчикам писать, когда с эстимейтами мимо выйдет.

Цитата:

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

на дочерних таблицах так или иначе, но будут заданы constraints на FK (в аксапте такие валидации выполняются в validateWrite, задаются в reltation)

т.е. чтобы внешняя система смогла принять данные, данные должны быть переданы в определенном порядке - сначала родитель, потом потомок.

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

Для этого XML документ придумали, о чём я и говорю. Какой к черту порядок в интеграции + многопоточной. Ты серьёзно?

[Raven Melancholic]

Я так понимаю, что основная проблема у автора в том, что:

• Разные потребители запрашивают разную информацию.
• Заранее знать что запросит конкретный потребитель и за какой период не получается.
• Ну, конечно, проблема в количестве записей.

Любое логирование, когда непонятно сколько времени хранить, непонятно когда можно удалять данные лога, приведет к взрывному росту таких логов. То есть, методы "выталкивания" вряд ли подходят.
Может быть все-таки есть возможность как-то систематизировать то, кто что получает или это, действительно, непредсказуемо?
Кстати, да, у mazzy прозвучала неплохая мысль про удаление. А как его реплицировать?

[mazzy]

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

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

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

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


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

[Vadik]

Цитата:

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

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

[trud]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

[Ace of Database]

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

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

[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-таблицами - легко.
а в чем ты видишь проблему?