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

[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 как-то решает эту задачу?

[mazzy]

Цитата:

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

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

Цитата:

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

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

как скажешь.

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

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

[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, либо ничего.