|
14.01.2021, 13:43 | #1 |
Участник
|
Цитата:
Сообщение от DSPIC
Начинается... Подумал, не знаю. Поделись, сэкономь мне 50$ времени
Пример: Выгрузке подлежат клиенты, у которых CommissionSalesGroup.Export=Yes. Выгружать нужно в т.ч., если изменились их адреса. Итак, поменялся RecVersion у 10К адресов, в которые входят наши 5 клиентов для выгрузки.Ну, вдовесок там ещё контакты и прочая DirParty лабуда. Аж интересно мне.. выгрузи только те, что относятся к измененным клиентам. ты говоришь: * клиенты используют адреса в FK * это бизнес локика наверняка заложена и в Аксапте и во внешней системе * значит с огромной вероятностью во внешней системе будут заданы constraints на адреса у клиента * это значит, чтобы приемник смог принять без ошибок, система источник ДОЛЖНА сначала передать адреса, а уж потом клиентов. * будет ли источник передавать сначала все 10К изменившихся адресов или будет как то приоретизировать... вопрос реализации, а не вопрос подхода. и я сильно подозреваю, что этот вопрос уходит сильно за рамки исходного вопроса. говорю жеж, подумай еще раз. там много соображений, относящихся к бизнес-логике и к инфраструктуре, а не к кодингу. кодинг - не так уж и сложен в этой задаче. а прикинь есть еще удаление. и на приемнике может присутстовать каскадное удаление данных Последний раз редактировалось mazzy; 14.01.2021 в 13:49. |
|
14.01.2021, 13:59 | #2 |
Боец
|
Цитата:
Сообщение от mazzy
эээээ. а зачем выгружать 10К адресов?
выгрузи только те, что относятся к измененным клиентам. ты говоришь: * клиенты используют адреса в FK * это бизнес локика наверняка заложена и в Аксапте и во внешней системе * значит с огромной вероятностью во внешней системе будут заданы constraints на адресе * это значит, чтобы приемник смог принять без ошибок, система источник ДОЛЖНА сначала передать адреса, а уж потом клиентов. * будет ли источник передавать сначала все 10К изменившихся адресов или будет как то приоретизировать... вопрос реализации, а не вопрос подхода. и я сильно подозреваю, что этот вопрос уходит сильно за рамки исходного вопроса. говорю жеж, подумай еще раз. там много соображений, относящихся к бизнес-логике и к инфраструктуре, а не к кодингу. кодинг - не так уж и сложен в этой задаче. а прикинь есть еще удаление. и на приемнике может присутстовать каскадное удаление данных 1. Мне нужно выгрузить клиентов с их адресами и контаками. Мне не нужно выгружать по-отдельности клиентов, адреса и контакты (в этом случае порядок важен, но соблюсти его технически невозможно). Т.е. ещё раз - минимальной единицей экспорта является посылка с подарками, а не коробка и подарки по-отдельности. 2. Так в этом суть задачи - среди множества изменившихся 10К адресов найти 5 клиентов, кторые подлежат выгрузке. Как? |
|
|
За это сообщение автора поблагодарили: EVGL (3). |
14.01.2021, 14:14 | #3 |
Участник
|
Цитата:
Сообщение от DSPIC
Так-с давай синхронизируемся.
1. Мне нужно выгрузить клиентов с их адресами и контаками. Мне не нужно выгружать по-отдельности клиентов, адреса и контакты (в этом случае порядок важен, но соблюсти его технически невозможно). Т.е. ещё раз - минимальной единицей экспорта является посылка с подарками, а не коробка и подарки по-отдельности. насколько я понимаю у автора топика был другой вопрос... и я отвечал про справочник. ну и фиг с ним. давай поговорим о DataEntity. Цитата:
в контексте DataEntity нужно записи в подчиненных таблицах, которые связаны с главной: есть 5 клиентов - надо найти адреса, относящиеся к каждому из них т.е. в рамках кода, который выгружает клиентов нужно сделать запрос к адресам, которые связаны с передаваемым клиентом и только для этих адресов проверить - изменились ли они. И тут... Классический DataEnity предполагает, что в DataEntity содержатся все данные, относящиеся к главной. Т.е. DataEnity - это конечное целевое состояние которое должно быть у главной записи. (по крайней мере я так понимаю подход с DataEnity) В рамках такого подхода DataEnity, можно ли с логической точки зрения передавать изменения в подчиненных таблицах? Не будет ли принимающая сторона трактовать отсутствующие в DataEnitity записи как команду удалить, все что не перечислено в DataEnity? Понятно, что если и источник, и приемник контролируются одной командой разработки, то может быть всё что угодно. Но как правило команда не одна. И я бы не рассчитывал, что в DataEnity можно передавать отличия, а не конечное целевое состояние. ======= Другими словами, 1. если Клиенты и Адреса - выгружаемые справочники, то рано или поздно система источник все равно должна выгрузить все данные. Причем выгрузка должна учитывать, что приемник может содержать constraints на бизнес-логику 2. если клиенты+адреса - это DataEnitity, то совершенно не обязательно выгружать все адреса (DataEnitity никогда этого и не делает). Но вот можно ли выгружать в DataEnitity только изменившиеся адреса - большой вопрос, требующий согласования на уровне публичных интерфейсов между системами. Насколько я понимаю, предполагается, что DataEnitity дложна содержать все данные, относящиеся к главной записи. Последний раз редактировалось mazzy; 14.01.2021 в 14:18. |
|
14.01.2021, 14:52 | #4 |
Участник
|
Цитата:
Получается остается только решение предложенное DSPIC. Цитата:
Сообщение от Ace of Database
тут пишу про SysDatabaseLog потому что это прикольно и тоже работает.
PS: А D365FO как-то решает эту задачу? |
|
14.01.2021, 15:25 | #5 |
Участник
|
Цитата:
Будь проклят тот архитектор, который начал портить Аксапту с этого фреймворка Смотри: 1. с точки зрения бизнес-логики адреса - это не бесконечный список произвольных адресов, это вполне конретные адреса с определенной ролью - юридический адрес, адрес склада 1, адреса склада N, почтовый адрес и т.п. причем один и тот же адрес может использоваться для разных ролей адресов 2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец) 3. но я сильно сомневаюсь, что в системе приемнике адреса реализованы точно также Поэтому, с точки зрения бизнес-логики нужно синхронизировать адреса в разных ролях. если есть "запасные" адреса, то нужно очень четко синхронизировать primary и "остальные" адреса. (например, если зарегистрировано несколько адресов с ролью "юридический адрес", то выгрузить-и-загрузить нужно единственный, верный, указанный в уставе. например, если есть разные адреса доставки для разных отделов, то нужно выгрузить-и-загрузить правильные адреса для правильных ролей и с правильной принадлежностью) поэтому, задача "выгрузить-и-загрузить LogisticsPostalAddress, LogisticElectronicAddress" - это полный бред программистского подхода. нафиг это никому не нужно. нужно, чтобы в системе приемнике получились правильные адреса и правильной ролью и в правильных местах. хошь-не-хошь, а для выгрузки этой части DirParty придется делать интеграционную бизнес-логику, которая из универсальной таблицы (мать ее) расставит адреса в правильные места. Цитата:
Сообщение от trud
И простой связи с клиентом тоже нет, она идет через несколько джойнов. Т.е. можно сделать предположение что изменений адресов клиентов которых надо выгружать немного(это действительно так), но делать предположение что изменений всех адресов будет немного - это слишком сильно, может они вообще вбивают отдельные емейлы и телефоны для заказа
как скажешь. я не верю, что данные из dirParty можно и нужно синхронизировать универсальным однопроходным алгоритмом даже в случае аксапта-аксапта. для решения конкретной технической задачи "быстро, запросом узнать изменились ли записи в конкретной таблице с таким-то фильтром" вполне подойдет shadow-таблица как скажешь. Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса. Но если остается только это. что ж поделать. как скажете Последний раз редактировалось mazzy; 14.01.2021 в 15:29. |
|
14.01.2021, 16:08 | #6 |
Боец
|
Цитата:
Эмм... как скажешь |
|
14.01.2021, 17:34 | #7 |
Banned
|
Цитата:
0) Intercompany 1) В теории так легче синхронизироваться с CRM. В теории. 2) В самой таблице может быть тоже много общего, например между клиентом и поставщиком: название и юридическая форма, естественно, но и DUNS, номер в "ЕГРЮЛ", "ИНН" (меня регулярно разочаровывает, что в DirPartyTable нет VatNum). Недавно имел диагностику на клиенте, у которого почти каждый грузоотправитель одновременно и грузополучатель. |
|
14.01.2021, 17:49 | #8 |
Banned
|
К сожалению, отдельные поля не проверяются: либо все [подпадающее под фильтр], либо только CustTable, либо ничего. |
|
Теги |
aif, ax2012, change tracking, интеграция, как правильно |
|
|