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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.03.2021, 21:46   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

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

в одной аксапте (назовем ее клиентом) есть огромная коллекция очень важных данных. коллекция - список/массив/мап/контейнер/таблица

как передать эти данные в другую Аксапту (назовем ее сервером) через WCF?

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

передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разрвет все внутренние буфера.

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

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

в общем,
как правильно передать 100500 элементов коллекции через WCF?

ЗЫ
а может где-нибудь еще есть такое? не только в WCF...
__________________
полезное на axForum, github, vk, coub.
Старый 29.03.2021, 22:47   #2  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
https://docs.microsoft.com/en-us/dyn...-query-service
__________________
-ТСЯ или -ТЬСЯ ?
Старый 29.03.2021, 22:55   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
спасибо.
только это и есть разбивать на чанки, насколько я понимаю. только в особо извращенной форме.

во-первых, этот сервис только для запросов к базе.

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

в-третьих, query service только слушатель (т.е. кто-то может запросить query service, а query service этому кому-то может вернуть данные в ответ).
если же нужно передать данные другому, то нужно как-то организовать callback. что то еще удовольствие.

в-четвертых, "другая сторона" будет слишком много знать о деталях реализации, если будет использовать query service.
и тут дело даже не в безопасности, а в том, что
комплекс из двух систем, которые используют слишком много знаний о деталях реализации друг друга
становится слишком мнонлитно-хрупким.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 29.03.2021 в 23:03.
Старый 02.04.2021, 20:31   #4  
Damn is offline
Damn
Участник
 
436 / 154 (6) ++++++
Регистрация: 28.05.2003
Адрес: в глуши
Похоже что это вопрос больше для форума разработчиков WCF-сервисов.
Или для stackoverflow, например.
__________________
Дмитрий
Старый 06.04.2021, 04:45   #5  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от mazzy Посмотреть сообщение
как правильно передать 100500 элементов коллекции через WCF
Я бы не ограничивался конкретной технологией. В зависимости от конкретных требований, можно подобрать более подходящие инструменты.
С какой периодичностью нужно данные передавать? Вызовы синхронные? Насколько универсальным и масштабируемым должно быть решение? Используется ли middleware? Кто будет публиковать данные и кто будет подписчиками?
__________________
Isn't it nice when things just work?
Старый 06.04.2021, 09:39   #6  
AlexMoskvichev is offline
AlexMoskvichev
Участник
 
23 / 44 (2) +++
Регистрация: 08.11.2011
Адрес: Новосибирск
Цитата:
Сообщение от mazzy Посмотреть сообщение
разрвет все внутренние буфера.
...
возиться и тоже никакой гарантии, что не разорвет...
"Внутренние буфера" конфигурируются https://stackoverflow.com/questions/...ize-quota?rq=1

Можно разной толщины сообщения послать и точно узнать, разорвет или нет. Если сервер свой, то и с настройками поиграться.
По умолчанию вроде 64Кб лимит на сообщение.

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

Цитата:
наверное было бы идеально передавать в какой-нибудь метод элементы коллекции, а WCF сам бы делил на чанки исходя из своих внутренних резервов. Но я не знаю такого метода.
Это похоже на описание какого-то балансировщика нагрузки. Вряд-ли такое будет в голом фреймворке.

Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming
Стриминг как раз автоматически делит данные на куски, но подойдет ли он в конкретном клиенте?

Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF?
Старый 06.04.2021, 09:54   #7  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от macklakov Посмотреть сообщение
С какой периодичностью нужно данные передавать? Вызовы синхронные? Насколько универсальным и масштабируемым должно быть решение? Используется ли middleware? Кто будет публиковать данные и кто будет подписчиками?
периодичность - раз в 5 минут, например.
универсальность - это и есть вопрос
для простоты будем считать, что middleware не используется. Но хотелось бы понять как middleware влияет на ответ.

а как влияет на ответ кто будет подписчиком?

Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
По умолчанию вроде 64Кб лимит на сообщение.
причем 64Кб несжатого xml. что очень немного.

Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
Кстати не сказано, элементы однородные или размер может варьироваться.
даже если элементы однородные, внутри могут быть строковые значения очень разной длины.


Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
Для очень больших объемов есть стриминг https://docs.microsoft.com/ru-ru/dot...-and-streaming
...
Просто непонятно о чем точно идет речь. Если WCF указан как фреймворк, а не конкретный продукт, тогда можно широко подойти. Или это про AIF?
AIF. net.TCP адаптер
но хотелось бы понять как это влияет на ответ. можем и свой middleware сделать
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 10:00.
Старый 06.04.2021, 11:12   #8  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от mazzy Посмотреть сообщение
Но хотелось бы понять как middleware влияет на ответ.

а как влияет на ответ кто будет подписчиком?
Да на всё влияет. Подписчик может иметь очень ограниченные возможности по интеграции. А хорошее middleware имеет все вообразимые коннекторы, а обычно и преднастроенные шаблоны интеграции. Плюс управление очередью сообщений. Но если прямое соединение, то приходится анализировать, какая система на что способна.
Если интеграция ассинхронная, а издатель и подписчик сидят в одной сети, то вообще можно данные выставить как view и пусть таскает когда и сколько ему нужно. Можно вытягивать данные в DW, поближе к подписчику.
Если синхронная, то к предыдущий варант сопровождается сообщением:"данные брать здесь"
Обмен данными можно наладить десятками разных способов. Все зависит от конкретики.
P.S. Универсальное решение писать дело увлекательное, но неблагодарное. Много я их видел, одни лучше, другие хуже. Но выкупаются те, которые созданы школьными друзьями.
__________________
Isn't it nice when things just work?
Старый 06.04.2021, 11:23   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от macklakov Посмотреть сообщение
Да на всё влияет. Подписчик может иметь очень ограниченные возможности по интеграции. А хорошее middleware имеет все вообразимые коннекторы, а обычно и преднастроенные шаблоны интеграции.
конечные точки - ax2012 и ax2009
предположим, что все под нашим контролем.

Цитата:
Сообщение от macklakov Посмотреть сообщение
Плюс управление очередью сообщений.
Собственно в этом и вопрос. как правильно управлять очередью?


Цитата:
Сообщение от macklakov Посмотреть сообщение
Но если прямое соединение, то приходится анализировать, какая система на что способна.
ax2012 и ax2009. в одном домене.
middlware любой. для начала пустой набор. можно добавлять что угодно.

как правильно?

Цитата:
Сообщение от macklakov Посмотреть сообщение
можно данные выставить как view и пусть таскает когда и сколько ему нужно.
вопрос рассматривался.
в аксапте view скорее для чтения. и уж точно НЕ для удаления.

и кроме того, чтобы использовать view конечные точки должны слишком много знать друг о друге. разве не так?

точно так же как и в QueryService, которые Vadik предлагал выше.

можно я повторю:
Цитата:
Сообщение от mazzy Посмотреть сообщение
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

Цитата:
Сообщение от macklakov Посмотреть сообщение
Можно вытягивать данные в DW, поближе к подписчику.
а зачем?

Цитата:
Сообщение от macklakov Посмотреть сообщение
Обмен данными можно наладить десятками разных способов. Все зависит от конкретики.
Всё?! Это обсуждение "как правильно" зависит от конкретики?!
Серьезно?!

Ну, дай вводную "я говорю о таких условиях" и расскажи как правильно в этих условиях.
собственно тема об этом.


Цитата:
Сообщение от macklakov Посмотреть сообщение
P.S. Универсальное решение писать дело увлекательное, но неблагодарное. Много я их видел, одни лучше, другие хуже. Но выкупаются те, которые созданы школьными друзьями.
Не спорю.
Могу только повторить свое первое утверждение в моем первом сообщении в этой ветке:
Цитата:
Сообщение от mazzy Посмотреть сообщение
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно
__________________
полезное на axForum, github, vk, coub.
Старый 06.04.2021, 12:43   #10  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Это сугубо мое личное мнение, но по-моему "правильно" было бы не запрашивать "огромную коллекцию из 100500 элементов" "раз в 5 минут" а держать ее в обеих системах, синхронизовывать изменения и работать с ней в обеих системах локально ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 06.04.2021, 11:44   #11  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?
1 мастер система или 2? Т.е. если справочники вбиваются в систему 1, и они должны точно отображаться в системе 2 - это один вариант. Если и в системе 1, и в системе 2 ведутся справочники, которые должны быть синхронизированы, включая контроль совпадений - это уже другой вариант, посложнее.

Просто Change Data Capture не подойдет, так как разные системы и разные RecID. Тогда просто кроликом гоняем изменения во временную таблицу. А раз в час или в 5 минут запускаем пакет, в котором делаем импорт средствами системы и удаляем (помечаем) обработанную запись. Надо предусмотреть не только добавление, но и изменение / удаление данные, что тоже возможно посредством передачи пакетов.

Вопрос в гарантированной доставке. Возможно, раз в неделю / месяц стоит полностью синхронизировать справочники.

С Уважением,
Георгий
Старый 06.04.2021, 12:03   #12  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
А не подойдет ли для этой задачи очередь сообщений (RabbitMQ или даже Debezium) + пакетная обработка?
А вот хорошая тема. или Kafka. или даже MSMQ. В общем, любой вменяемый брокер сообщений

и ты конечно имеешь в виду, что пакетная обработка в обеих конечных точках (ax2012, ax2009).

но тут возникает вопрос следующего уровня - а как правильно обращаться к этим брокерам сообщений из Аксапты?
причем и с брокерами нужно как-то решать тот же вопрос про 100500 элементов коллекции.

или где-то решен вопрос как передавать коллекции через брокер?
или в брокер можно передавать элементы по одному и не париться о накладных расходах?
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 12:08.
Старый 06.04.2021, 12:24   #13  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
А вот хорошая тема. или Kafka. или даже MSMQ. В общем, любой вменяемый брокер сообщений
Только имей в виду, что большинство брокеров - под Linux или Apache стек, как это будет жить с MS средой или Azure - тот еще вопрос.
Цитата:
Сообщение от mazzy Посмотреть сообщение
и ты конечно имеешь в виду, что пакетная обработка в обеих конечных точках (ax2012, ax2009).
Если надо в 2 системах отслеживать изменения. Иногда брокер или агента просто можно настроить на изменение таблицы: появилась или изменилась запись - данные изменения отражаются в другой таблице, а там уже приёмник с пакетной обработкой. Но можно и и на источнике пакетами проходить и добавлять в очередь сообщений, так что есть варианты.
Цитата:
Сообщение от mazzy Посмотреть сообщение
но тут возникает вопрос следующего уровня - а как правильно обращаться к этим брокерам сообщений из Аксапты?
Про источник - выше. Про приемник - а что мешает использовать специальную таблицу для синхронизации? Все равно или её, или очередь надо разбирать имеено внутренними средствами Аксы - RecId и прочее сами себя не добавят.
Цитата:
Сообщение от mazzy Посмотреть сообщение
причем и с брокерами нужно как-то решать тот же вопрос про 100500 элементов коллекции. или где-то решен вопрос как передавать коллекции через брокер?или в брокер можно передавать элементы по одному и не париться о накладных расходах?
Да, оставь технику брокеру. Просто добавляй в очередь и успевай разгребать приёмник. В первый раз будет больно синхронизация может занять продолжительное время, но потом все будет обрабатываться по мере поступления: на лету (по триггеру или по пакетной обработке) со стороны источника, со стороны приёмника же - по пакетной обработке.

С Уважением,
Георгий
Старый 06.04.2021, 13:35   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Только имей в виду, что большинство брокеров - под Linux или Apache стек, как это будет жить с MS средой или Azure - тот еще вопрос.
имею. поэтому и говорю о "каком-то брокере"

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Про приемник - а что мешает использовать специальную таблицу для синхронизации?
таблица - это уже знания структуре данных на той стороне.
таблица - это права на той стороне

понятно, что можно.
но является ли это правильным подходом?
а как правильнее?

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Все равно или её, или очередь надо разбирать имеено внутренними средствами Аксы - RecId и прочее сами себя не добавят.
угу. именно поэтому в вопросе явно указаны аксапты

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

да, знаю, что для решения задачи все нормальные инструментарии обзавелись стримами.
но в вопросе указано, что обсуждаем Аксапты

или правильным является "сделать собственные dll'ки, которые снаружи работают со стримами, а аксапте отдают объекты по одному"?
и чтобы эти собственные dll'ки работали в адресном пространстве аксапты...
https://coub.com/view/12jn53

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

я не стал акцентировать, когда увидел прошлый твой ответ,
но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать"
ты считаешь, что это одинаковые действия? почему?

и понятно, что регулярно раз в 5 минут 100500 элементов передаваться не будут. но при пиковых нагрузках элементов будет много.

собственно об этом и вопрос:
как правильно передавать много элементов коллекции?
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 13:42.
Старый 06.04.2021, 13:59   #15  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
как правильно передавать много элементов коллекции?
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир к Informatica PEC, Oracle GoldenGate, Qlik Data Integration и Debezeum. Вариантов, увы, нет.

Все эти продукты могут в режиме, близко к реальному, переносить данные из таблицы А в одной среде к таблицы В в другой. Не все могут переносить структуру таблиц - обычно только поля (только Qlik Attuniy умеет, кстати). Почти все (кроме, кажется, Debezeum) умеют маскировать выбранные поля. Ни одна не умеет генерить локальный RecId из другой системы. Это означает одно - синхронизировать-то мы можем, а вот доп. обвязку в виде тех же RecID необходимо будет делать силами интегрируемой системы, такой как Аксапта. Я знаю про пакетную обработку, возможно, если и другие пути добавления необходимой служебной информации, но я про них не наслышан.

С Уважением,
Георгий
Старый 06.04.2021, 15:58   #16  
AlexMoskvichev is offline
AlexMoskvichev
Участник
 
23 / 44 (2) +++
Регистрация: 08.11.2011
Адрес: Новосибирск
Цитата:
Сообщение от mazzy Посмотреть сообщение
имею. поэтому и говорю о "каком-то брокере"
В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.

Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа.
При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке)

Возвращаясь к вопросу.
100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?.

Если проблема в размере сообщений, можно попробовать их сжать при отправке.

Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла
Старый 06.04.2021, 16:18   #17  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от mazzy Посмотреть сообщение
но обрати внимание, что в вопросе было "передавать", а ты постоянно отвечаешь "запрашивать"
ты считаешь, что это одинаковые действия?
Нет, не считаю, действия действительно разные. Я считаю что это не царское (издателя) дело пихать (передавать) данные во всех подписчиков число которых в общем случае может превышать единицу. Иногда может быть оправдано, но в общем предпочел бы чтобы этим сам подписчик или брокер занимался. Можешь считать это вкусовщиной, настаивать не буду
Цитата:
А как ты представляешь себе синхронизацию таблиц?
Я наверное не понял вопрос. Упрощенно - издатель публикует данные (все или инкремент), подписчик читает и овновляет свою локальную копию (в том виде, в котором он может с ней эффективно работать)
Цитата:
Что с RecId делать?
Снова не понял вопрос, потому ответ будет дурацкий - по классику, чаще мыть
Цитата:
Если чуть экстраполировать вопрос до как "правильно регулярно передавать много элементов коллекции", то ответ только один - change data capture. Добро пожаловать во взрослый мир
Я всегда немного смущаюсь когда начинают сыпать названиями продуктов и аббревиатурами. Поэтому просто напомню что AIF в 2012 (за 2009 не скажу, не уверен) вполне себе умеет change tracking "из коробки" и отойду в сторонку, послушаю остальных
__________________
-ТСЯ или -ТЬСЯ ?
Старый 07.04.2021, 10:22   #18  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.

Давай уточню сначала по CDC: из БД 2009 в БД 2012 скорость репликации будет очень высокой, если RecID будет выделяться самой БД. Но если Rec будет выделять AOS, то он станет бутылочным горлышком, а если еще и номерные серии надо заполнять...

То же самое и с брокерами. В принципе, за счет распараллеливания и оптимизации размера пакетов - то хоть 1К в секунду, хоть миллион. Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.

Абстрагируясь от DAX, то если мы говорим про надежную доставку, то это - запись на диск. Таким образом надо смотреть на пропускную способность сети и скорость записи на диск. Например, для AWS это 40 000 IOPS составляет при пакете в 16 КБ и 20 000 IOPS при 32 КБ

Таким образом, я не вижу проблемы в передаче 100500 сообщений. Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля. Если доверить эту задачу БД, а служебные поля заполнять автоматом по некому шаблону механизмами БД, то данная проблема снимается. Но вряд ли этим снимается проблема последовательной обработки сообщений.

С Уважением,
Георгий
Старый 07.04.2021, 10:34   #19  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Bingo!
__________________
-ТСЯ или -ТЬСЯ ?
Старый 07.04.2021, 10:42   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
...
Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля.
даже не столько в парсинге, сколько в валидации входащих данных.

т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне.

все понимаю про принимающую сторону.
поэтому в вопросе сформулировано о передать/отправить.

принимающая сторона в части парсинга и валидации входящих данных - отдельный вопрос.

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

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.
Я уже сказал, пусть будет 1 запись в секунду. Пусть будет 10 записей в секунду.
По-моему, не принципиально для заданного вопроса.
__________________
полезное на axForum, github, vk, coub.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Denis Trunin's Blogs: Examples of AX2012/ AX2009 performance problems Blog bot DAX Blogs 0 12.01.2020 05:02
Перенос и адаптация кода с Ax2009 на Ax2012 R3 matew DAX: Прочие вопросы 10 23.01.2015 19:52
как передать значение из диалога в форму, вызываемую через menuItem? алька DAX: Программирование 9 25.06.2007 16:46
Передать контейнер в job через COM sao DAX: Программирование 5 21.02.2006 19:34
Как в параметрах подпрограммы передать массив элементов. Yuri Safronov DAX: Программирование 3 14.10.2002 16:35
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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