AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.01.2021, 13:59   #61  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от mazzy Посмотреть сообщение
эээээ. а зачем выгружать 10К адресов?
выгрузи только те, что относятся к измененным клиентам.

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

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

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

2.
Цитата:
Сообщение от mazzy Посмотреть сообщение
эээээ. а зачем выгружать 10К адресов?
выгрузи только те, что относятся к измененным клиентам.
Так в этом суть задачи - среди множества изменившихся 10К адресов найти 5 клиентов, кторые подлежат выгрузке. Как?
За это сообщение автора поблагодарили: EVGL (3).
Старый 14.01.2021, 14:14   #62  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от 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 дложна содержать все данные, относящиеся к главной записи.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 14.01.2021 в 14:18.
Старый 14.01.2021, 14:30   #63  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
и давайте попробуем вернуться к исходному вопросу:
Выгрузка измененных клиентов во внешнюю систему

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

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

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


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

Последний раз редактировалось mazzy; 14.01.2021 в 14:38.
За это сообщение автора поблагодарили: Vadik (1).
Старый 14.01.2021, 14:37   #64  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от mazzy Посмотреть сообщение
начнем с того, что сама по себе выгрузка нафиг никому не нужна
__________________
-ТСЯ или -ТЬСЯ ?
Старый 14.01.2021, 14:52   #65  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
1. если Клиенты и Адреса - выгружаемые справочники, то рано или поздно система источник все равно должна выгрузить все данные.
Ну проблема что в АХ это не так. Т.е. в таблице LogisticsPostalAddress, LogisticElectronicAddress нет типа адреса(что это клиент или не клиент) и там хранятся адреса для всех сущностей( в том числе и для транзакционных). И простой связи с клиентом тоже нет, она идет через несколько джойнов. Т.е. можно сделать предположение что изменений адресов клиентов которых надо выгружать немного(это действительно так), но делать предположение что изменений всех адресов будет немного - это слишком сильно, может они вообще вбивают отдельные емейлы и телефоны для заказа
Получается остается только решение предложенное DSPIC.
Цитата:
Сообщение от Ace of Database
тут пишу про SysDatabaseLog потому что это прикольно и тоже работает.
Вот это все еще непонятно.Вы делаете предположение что у вас дата-время или RecId в этой таблице монотонно возрастает, но это же не так(данные могут обновляться в транзакции). Т.е. непонятно как вы предлагаете получать изменения за момент времени

PS:
А D365FO как-то решает эту задачу?
Старый 14.01.2021, 14:58   #66  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
начнем с того, что сама по себе выгрузка нафиг никому не нужна.
нужна синхронизация нескольких взаимосвязанных систем.
поскольку вопрос был про выгрузку, то скорее в вопросе можно рассматривать связи в топологии звезда
причем для упрощения обсуждения можно считать, что вопрос относился к центральной системе в топологии звезда
В целом да, у тебя правильное понимание задачи. Но есть небольшое ограниничение, они уже согласовали протокол обмена(вызовы раз в минуту по интервалу с заданной группой клиентов) т.е. в моем случае поменять будет сложно.
Но в принципе интерестно обсудить как это более оптимально сделать. На первый взгляд такой протокол довольно гибкий, т.е. при добавлении к примеру новых полей в синхронизацию или добавлении новых групп клиентов они могут просто получить данные за более больший интервал(т.е. нет отдельной операции перевыгрузить все)

Последний раз редактировалось trud; 14.01.2021 в 15:05.
Старый 14.01.2021, 15:25   #67  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
Ну проблема что в АХ это не так. Т.е. в таблице LogisticsPostalAddress, LogisticElectronicAddress нет типа адреса(что это клиент или не клиент) и там хранятся адреса для всех сущностей( в том числе и для транзакционных).
Ну, во-первых, это не проблема, а задача! А проблема - это DirParty в целом.
Будь проклят тот архитектор, который начал портить Аксапту с этого фреймворка

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

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

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

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

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

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

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

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


Цитата:
Сообщение от trud Посмотреть сообщение
Получается остается только решение предложенное DSPIC.
как скажешь.

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

Но если остается только это. что ж поделать. как скажете
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 14.01.2021 в 15:29.
Старый 14.01.2021, 15:28   #68  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от trud Посмотреть сообщение
Но есть небольшое ограниничение, они уже согласовали протокол обмена(вызовы раз в минуту по интервалу с заданной группой клиентов) т.е. в моем случае поменять будет сложно.
я не очень понимаю каким образом обсуждение
технической и внутренней задачи "найти измененные"
влияет на внешний протокол обмена.

но если это все что вы согласовали в протоколе
то и не меняйте согласованную часть...
__________________
полезное на axForum, github, vk, coub.
Старый 14.01.2021, 15:59   #69  
Ace of Database is offline
Ace of Database
Участник
Аватар для Ace of Database
 
870 / 637 (23) +++++++
Регистрация: 14.10.2004
Найти ближайшее решение, которое, при наименьшей гениальности, будет работать
X++:
select top 1 * from decision 
where IsActive = 1
order by GeniusLevel
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/
Старый 14.01.2021, 16:08   #70  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от mazzy Посмотреть сообщение
Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..
Сошлюсь на то, что ты недопонял концепт и\или задачу, на том удалюсь из дискуссии за нехваткой времени, сорри.

Цитата:
Сообщение от mazzy Посмотреть сообщение
Н
..
Могу сказать только что DSPIC предлагает частный случай shadow-таблицы, в которой отбор идет по memo-полю без индекса.
..
Эмм... как скажешь
Старый 14.01.2021, 17:34   #71  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от mazzy Посмотреть сообщение
2. в Аксапте какой то нехороший человек сделал универсальную таблицу (какой он молодец)
Доводы в пользу DirParty:
0) Intercompany
1) В теории так легче синхронизироваться с CRM. В теории.
2) В самой таблице может быть тоже много общего, например между клиентом и поставщиком: название и юридическая форма, естественно, но и DUNS, номер в "ЕГРЮЛ", "ИНН" (меня регулярно разочаровывает, что в DirPartyTable нет VatNum). Недавно имел диагностику на клиенте, у которого почти каждый грузоотправитель одновременно и грузополучатель.
Старый 14.01.2021, 17:49   #72  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от trud Посмотреть сообщение
А D365FO как-то решает эту задачу?
Нажмите на изображение для увеличения
Название: EnableCustomQuery.PNG
Просмотров: 62
Размер:	91.4 Кб
ID:	13024

К сожалению, отдельные поля не проверяются: либо все [подпадающее под фильтр], либо только CustTable, либо ничего.
Старый 15.01.2021, 16:33   #73  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
.. они уже согласовали протокол обмена(вызовы раз в минуту по интервалу с заданной группой клиентов)

https://youtu.be/XMWiN1mnw7c?t=234

Я не уверен что такая реализация взлетит. Для этого в общем случае надо хранить все изменения (в виде снэпшотов, или как-то еще) по достаточно крупной иерархической структуре (6М клиентов, 17М адресов плюс наверное столько же контактов и т.д.). Хранить и обновлять эту историю годами (так как мы не знаем как далеко назад во времени может потребоваться заглянуть) , и при этом искать по ней в несколько потоков десятками запросов в минуту ? Я бы не стал. Возможно, кастомное и спецализированное решение на X++ и заработает, но "просто, гибко, быстро" - тут наверное придется выбирать и даже не 2, а 1 из 3 Но если заработает, было бы интересно узнать что и как

Цитата:
Но в принципе интерестно обсудить как это более оптимально сделать
У меня есть несколько сделанных проектов где мастер-данные (номенклатуры, клиенты, поставщики) вытягиваются из Ax 2012 стандартным AIF+CT через "скользящее окно" (изменения за последний час, 24 часа, 48 часов). Если есть желание попробовать как это работает, могу отдать проект (C#) на следующей неделе, его наверное надо будет немного почистить от клиентской специфики. Мне тоже будет интересно, на 6М клиентов я CT еще не тестировал
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 15.01.2021 в 16:52.
Старый 15.01.2021, 17:39   #74  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Vadik Посмотреть сообщение
Для этого в общем случае надо хранить все изменения (в виде снэпшотов, или как-то еще) по достаточно крупной иерархической структуре (6М клиентов, 17М адресов плюс наверное столько же контактов и т.д.).
зачем "все изменения" то?

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

Цитата:
Сообщение от Vadik Посмотреть сообщение
Для этого в общем случае надо хранить все изменения... Хранить и обновлять эту историю годами
а это зачем?
вроде исходный вопрос был "есть внешняя система, ей как-то надо передавать клиентов из АХ которые изменились за интервал времени."

Цитата:
Сообщение от Vadik Посмотреть сообщение
и при этом искать по ней в несколько потоков десятками запросов в минуту ?
с shadow-таблицами - легко.
а в чем ты видишь проблему?
__________________
полезное на axForum, github, vk, coub.
Старый 15.01.2021, 17:41   #75  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Спасибо за комментарии.
По итогу оценил переделку в 3 дня, если согласуют, напишу чем закончилось. Это у них работает сейчас(с фильтром по "или" по дате модифиции по всем таблицам в запросе, я выше приводил пример), каждый вызов занимает минуту-полторы, подгружая в постоянном режиме где-то 6 ядер на 100% CPU, при этом большинство запросов возвращают пусто
За это сообщение автора поблагодарили: vmoskalenko (4).
Старый 18.03.2021, 13:33   #76  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Пока разминался красненьким работал над небольшим POC, решил прогнать тест:

Дано: 5M клиентов более-менее равномерно (500К - 1.3М) распределены по 5 компаниям
В сутки обновляется (Insert/Update) 0.1% клиентов

Вопрос: что нам будет стоить идентицифировать обновленных клиентов с помощью Change tracking ?

Потрачено времени:
  • Сгенерировать и импортировать данные через DMF - 4 дня
  • Оттюнить AifSqlCtChangeTracking - 4 часа

Тестируем:
  • Случайным образом обновляем данные по всем уровням AxdCustomer (это в некотором роде в сумме более 0.1% данных, ну и ладно)
  • Запускаем незатейливый джобик в самой большой компании (1.3М клиентов)

Итого: на бюджетной VM в Azure (B4Ms, 4xvCPU, 16 GB RAM, standard HDD) список измененных клиентов (CustTable.RecId) мы получаем за 5 секунд (достаточно шустро). Без перекрытия прочего стандартного кода в .insert(), .update(), event handler-ов и shadow таблиц (просто). Для всех обновлений, в том числе и извне AX (надежно)
Миниатюры
Нажмите на изображение для увеличения
Название: Screenshot 2021-03-18 131300.jpg
Просмотров: 29
Размер:	52.7 Кб
ID:	13146   Нажмите на изображение для увеличения
Название: Screenshot 2021-03-18 131819.jpg
Просмотров: 24
Размер:	54.0 Кб
ID:	13147  

Нажмите на изображение для увеличения
Название: Screenshot 2021-03-18 153859.jpg
Просмотров: 25
Размер:	131.7 Кб
ID:	13150  
Изображения
 
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 18.03.2021 в 15:48.
За это сообщение автора поблагодарили: mazzy (5), trud (5), sukhanchik (6), gl00mie (5).
Старый 18.03.2021, 14:15   #77  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором. Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов
Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось
Плюс сам тест очень простой. Если удалить к примеру e-mail будет работать? Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?
Старый 18.03.2021, 15:35   #78  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Т.е. никакие данные с точки зрения внешней системы вообще не изменились, а у вас выгрузились тысячи клиентов
Change tracking честно говорит что менялось в AX в указанном отрезке времени. Какие из этих изменений актуальны для "внешней системы" (в общем случае - для "внешних систем"), в каком они сейчас состоянии - с этим пусть разбираются сами внешние системы

Цитата:
Плюс все эти выгрузки полностью непрозрачны для пользователя, т.е. он не видит что и когда выгружалось
Мы еще ничего никуда не выгружаем, мы просто спросили систему "что нового". Кто такие пользователи, что они видят, что им "непрозрачно" - пока непонятно

Цитата:
Плюс сам тест очень простой
Ну уж какой есть

Цитата:
Если удалить к примеру e-mail будет работать?
Конкретно для AxdCustomer и email - нет, потому что запрос использует не "физические" таблицы а DirPartyPostalAddressView и DirPartyContactInfoView. Для "физических" таблиц удаления отслеживаются (см. скриншот). Как интеграция отслеживает удаление данных (и должна ли) - это отдельная тема сама по себе

Цитата:
Клиентов как правило требуется выгружать не всех, а принадлежащей определенной группе(при этом группу у клиента можно менять), это поддерживается?
Да. AifChangeTracking::construct() принимает Query в качестве аргумента

Цитата:
Ну тест то как раз показывает что change tracking не всегда будет лучшим выбором
А кто-то утверждал что CT это "лучший" выбор, "всегда" ? Я например знаю сценарии где CT работает плохо и для них его предлагать не буду. Тест показывает решение поставленной задачи с неплохими (как мне кажется) трудозатратами, производительностью и надежностью. Кто захочет - попробует. Если будут альтернативные решения, с удовольствием на них посмотрю. Окажутся проще, быстрее, удобнее - буду иметь их в виду
Миниатюры
Нажмите на изображение для увеличения
Название: Screenshot 2021-03-18 150413.jpg
Просмотров: 25
Размер:	65.4 Кб
ID:	13149  
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 25.03.2021 в 09:34.
Старый 18.03.2021, 16:11   #79  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
Да. AifChangeTracking::construct() принимает Query в качестве аргумента
Так а что туда передавать? Ну т.е. вчера клиент принадлежал группе выгрузки и выгружался, сегодня ему поменяли группу на невыгружаемую. Нужно же как уведомить внешнюю систему об этом
Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"
Хотя тут возможно ошибка выжившего, когда оно работает нормально, консалтинг не зовут, а мы видим только когда оно не работает
Старый 18.03.2021, 16:26   #80  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Так а что туда передавать? Ну т.е. вчера клиент принадлежал группе выгрузки и выгружался, сегодня ему поменяли группу на невыгружаемую. Нужно же как уведомить внешнюю систему об этом
Ну это наверное лучше с клиентскими постановщиками обсудить
Цитата:
Ну пока "insert(), .update() delete()" мне видится единственным правильный подходом, т.е. это будет гарантированно работать в любом случае, плюс позволит покрыть все возможные "хотелки"
Аминь
__________________
-ТСЯ или -ТЬСЯ ?
Теги
aif, ax2012, change tracking, интеграция, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AX2012 Общие справочники поставщиков и клиентов PTG DAX: Функционал 2 11.06.2015 15:39
Импорт адресов для существующих клиентов и поставщиков IKA DAX: Программирование 0 10.12.2013 21:04
ax 3.0 Экспорт справочников во внешнюю систему, по какому ключу связаться? Shakr DAX: Программирование 2 11.11.2008 11:34
Сергей Герасимов: О технической поддержке клиентов по продуктам Microsoft Dynamics Blog bot DAX Blogs 4 13.02.2007 14:58
Коды клиентов в CRM - проблема Zabr DAX: Функционал 5 01.12.2003 12:41
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:35.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.