|
07.04.2021, 10:42 | #1 |
Участник
|
Цитата:
т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне. все понимаю про принимающую сторону. поэтому в вопросе сформулировано о передать/отправить. принимающая сторона в части парсинга и валидации входящих данных - отдельный вопрос. но хотелось бы все-таки получить ответ на свой вопрос - как правильно передавать/отправлять много элементов коллекции в Аксапте, где нет встроенных стримов. Цитата:
По-моему, не принципиально для заданного вопроса. |
|
07.04.2021, 10:58 | #2 |
Модератор
|
Цитата:
Извини, но твой вопрос Цитата:
С Уважением, Георгий |
|
07.04.2021, 11:18 | #3 |
Участник
|
можно я еще раз повторю свое первое предложение в первом сообщении этой ветки?
Цитата:
Цитата:
=============================== итак, всё ещё надеюсь услышать мнения по вопросу: ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF? дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке: * "передать" в смысле "отправить" * в аксапте есть recId и нумераторы * в аксапте нет встроенной поддержки потоков (stream). * аксапта 2009 работает на .net 3.5 * аксапта 2012 работает на .net 4.0 (не 4.5) * размер элемента коллекции в Аксапте до 8Кб * размер коллекции до 100500 элементов, но вряд ли больше 2^32 * вместо WCF можно обсуждать любой другой брокер/транспорт * предполагаем, что middlware отсутствует. но мы можем сделать любой * для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения. лично я не вижу, как брокер/транспорт может принципиально повлиять на принимающую сторону. парсинг и валидация на принимающей стороне будут плюс-минус одинаковыми. поэтому сознательно вывел за рамки данного обсуждения вопросы парсинга и валидации на принимающей стороне. и вообще, вывел за рамки обсуждения принимающую сторону. но если вы знаете способ передачи, который существенно повлияет на принимающую сторону, то можно обсудить и её. вводите свои вводные в свое сообщение и вперед. с удовольствием послушаю. Добавлено: огромное спасибо всем участникам обсуждения, что заставили задуматься и сформлировать ограничения и вводные. В результате получается вопрос, который становится похож на правильно сформулированный. Последний раз редактировалось mazzy; 07.04.2021 в 11:36. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
21.04.2021, 02:01 | #4 |
MCTS
|
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
__________________
Dynamics AX Experience |
|
21.04.2021, 14:28 | #5 |
Участник
|
Цитата:
Цитата:
Сообщение от mazzy
дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить" * в аксапте есть recId и нумераторы * в аксапте нет встроенной поддержки потоков (stream). * аксапта 2009 работает на .net 3.5 * аксапта 2012 работает на .net 4.0 (не 4.5) * размер элемента коллекции в Аксапте до 8Кб * размер коллекции до 100500 элементов, но вряд ли больше 2^32 На тему проектирования интеграций есть хорошая статья у Дениса Трунина, где он предлагает для начала определиться с такими моментами:
Цитата:
Сообщение от mazzy
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой * для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения. Цитата:
В обсуждении много говорилось про очереди, шины данных и т.п. По-моему, если нужно перебрасывать между двумя системами такие объемы данных, стоит посмотреть в сторону какого-нить RabbitMQ хотя бы. Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах, но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на размер буфера под значимые типы (тот же string), которое по умолчанию, кажется, равно 1Мб - см. Падает клиент при прикреплении файла. Так что если утоптать 100500 элементов в один большой XML/JSON, то на принимающей стороне с ним может быть непросто работать. Я бы в связи с этим постарался разбивать передаваемые данные на блоки меньше 1Мб каждый. Цитата:
Цитата:
Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.
|
|
21.04.2021, 14:58 | #6 |
Участник
|
конечно же беспокоит.
поэтому и была создана тема. что ж, критика навиного подхода к передаче данных между разными системами - зачетная. именно поэтому и создана тема "как правильно" каковы твои предложения? для начала какую именно технологию ты называешь асинхронным обменом? Последний раз редактировалось mazzy; 21.04.2021 в 15:27. |
|
21.04.2021, 15:03 | #7 |
Участник
|
Цитата:
Цитата:
а кто-то говорил "одним куском"?! Последний раз редактировалось mazzy; 21.04.2021 в 15:11. |
|
21.04.2021, 20:30 | #8 |
Участник
|
Ну вот же 2-я опция из 3-х в исходном сообщении
Цитата:
Сообщение от mazzy
передавать по одном элементу - слишком много накладных расходов.
передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разорвет все внутренние буфера. делить на чанки и передавать чанками по несколько сотен элементов - надо возиться и тоже никакой гарантии, что не разорвет внутренние буфера. Если уж говорить про "ручную" разбивку сообщений на пачки, то можно пойти таким путем. Допустим, ограничение, которое мы хотим "соблюсти", - это заранее известный размер буфера сериализованных сообщений на принимающей стороне, при этом размеры отдельных сообщений нам заранее неизвестны. Выходит, нам надо адаптивно менять размер пачки так, чтобы он каждый раз был максимально близок к размеру буфера (ограничению), но не превышал его. Под такие требования подходит вариант, реализованный в 12-ке для разноски журналов ГК с распараллеливанием в пакетном режиме. Там аналогично попытались соблюсти баланс между распараллеливанием разноски и накладными расходами, связанными с большим числом пакетных задач. Суть подхода в том, что есть "сборщик" условных пачек, которому по одному за раз подаются элементы (журналы для разноски или сообщения в нашем случае). Сборщик принимает решение, добавить очередной элемент в текущую пачку или же завершить ее формирование и добавить очередной элемент уже в новую пачку. В случае журналов ГК сборщик смотрит на суммарное количество строк журналов в текущей пачке - эти журналы будут последовательно разноситься в одной пакетной задаче. В случае пакетирования сообщений сборщик может смотреть на суммарный размер сериализованных сообщений в текущей пачке с учетом ограничения на размер буфера и условного размера закрывающих XML-тегов для пачки. Такой подход обычно работает более гибко, чем грубое поштучное деление сообщений на пачки. Асинхронным я называю обмен, который позволяет системе-отправителю не ждать ответа системы-получателя (этот ответ при необходимости может быть получен в другое время), а системе-получателю позволяет обрабатывать входящие сообщения в отложенном режиме и с той скоростью, которая комфортна системе-получателю, а не системе-отправителю. Это подразумевает, что:
|
|
21.04.2021, 15:07 | #9 |
Участник
|
Цитата:
|
|
21.04.2021, 16:56 | #10 |
MCTS
|
Как только вы научитесь его писать...
Если серьезно, что значит в вашем понимании передать данные из одной Аксы в другую через WCF ? Можно пример передачи хотя бы простого строкового значения из одной Аксы в другую через WCF в вашем понимании как вы это видите? Потому как в моем понимании WCF - это программный фреймворк, предназначенный для написания сервисов. От того, что вы подразумеваете под передачей данных "через WCF" можно будет предложить какое-то решение.
__________________
Dynamics AX Experience |
|
|
|