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

[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 лабуда.

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

[DSPIC]

Цитата:

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

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

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

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

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

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

2.

Цитата:

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

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

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

[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 документ придумали, о чём я и говорю. Какой к черту порядок в интеграции + многопоточной. Ты серьёзно?

[mazzy]

Цитата:

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

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

И в самом деле!
Никакого порядка!