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

[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 клиентов, кторые подлежат выгрузке. Как?

[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 дложна содержать все данные, относящиеся к главной записи.

[trud]

Цитата:

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

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

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

Цитата:

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

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

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

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

[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

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

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