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

[DSPIC]

Я бы воспользовался AIF+FileBased (или без AIF): выгрузил в виде файла в папку, замапленную в облачный файловый сервис (e.g. OneDrive\DropBox\Azure\ На худой конец SFTP). На принимаемой стороне зеркально в обратную сторону. Если хочется ещё быстрее - файл архивировать.

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

UPD: Если нужна синхронность процесса, опубликовать на передаваемой стороне ждуна в виде вэб сервиса, который дернет принимаемая сторона по окончанию приёма.

[CDR]

Цитата:

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

когда ж вы ТЗ научитесь читать?

Как только вы научитесь его писать...
Если серьезно, что значит в вашем понимании передать данные из одной Аксы в другую через WCF ? Можно пример передачи хотя бы простого строкового значения из одной Аксы в другую через WCF в вашем понимании как вы это видите?

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

[CDR]

Цитата:

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

Я бы воспользовался AIF

Это последнее, что стоит рассматривать для обмена данными. Если в AX2012 еще худо-бедно работает, то в AX 2009 - это полное дно с точки зрения производительности.

[DSPIC]

Цитата:

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

Это последнее, что стоит рассматривать для обмена данными. Если в AX2012 еще худо-бедно работает, то в AX 2009 - это полное дно с точки зрения производительности.

Без разницы с AIF или без - главное файл на выходе. Чем хорош AIF - это логирование, масштабируемость, пре и пост обработка сообщений (тот же zip навеcbnm можно) гибкая настройка полей для разных эндпоинтов и прочие прелести. Ну а дальше по отбстоятельствам.

[mazzy]

Цитата:

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

Я бы воспользовался AIF+FileBased (или без AIF): выгрузил в виде файла в папку, замапленную в облачный файловый сервис

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

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

1.
прежде всего из-за возможности компрометации данных в файлах "ответственными" сотрудниками.

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

если учесть, что Retail-модуль обслуживает продажи в сети магазинов. Этот "любой" обязательно появится.

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

2.
файловый обмен делает обмен данными сильно двухфазным:
1ая фаза - передать/отправить файл. отправитель может получить статус "файл передан"
2ая фаза - принимающая сторона должна загрузить данные. как правило это будет через некоторое время. и во время загрузки возможны свои ошибки. из-за файловой природы ошибки могут быть перемешаны, могут не дойти... отправителю получить статус данных сильно сложнее. Вспомни тот же модуль Retail - там статус "отправлено" означает, что отправлены файлы, а не данные. Про данные отправитель ничего не знает.

Получается эдакий TCP поверх UDP.

В общем, обмен файлами - это НЕ обмен данными.
И корректная обработка данных в файлах, которые идут потоком... ну... можно, конечно... но нме не кажется, что это сильно легче.

3.
кроме того, файлы - это те же самые chunk'и.
только оформленные по другому.

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

[gl00mie]

Цитата:

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

а кто-то говорил "одним куском"?!

Ну вот же 2-я опция из 3-х в исходном сообщении

Цитата:

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

передавать по одном элементу - слишком много накладных расходов.

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

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

Цитата:

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

собственно тема КАК правильно решить на местах?

Если речь про разбивку 100500 сообщений на пачки, то - принимать во внимание имеющиеся ограничения в ядре и смотреть по опыту, какой размер лучше подходит в рамках имеющихся ограничений. Поскольку неизвестно, что именно за данные надо передавать и как обрабатывать на принимающей стороне, то сложно тут придумать что-то универсальное на все случаи жизни.
Если уж говорить про "ручную" разбивку сообщений на пачки, то можно пойти таким путем. Допустим, ограничение, которое мы хотим "соблюсти", - это заранее известный размер буфера сериализованных сообщений на принимающей стороне, при этом размеры отдельных сообщений нам заранее неизвестны. Выходит, нам надо адаптивно менять размер пачки так, чтобы он каждый раз был максимально близок к размеру буфера (ограничению), но не превышал его. Под такие требования подходит вариант, реализованный в 12-ке для разноски журналов ГК с распараллеливанием в пакетном режиме. Там аналогично попытались соблюсти баланс между распараллеливанием разноски и накладными расходами, связанными с большим числом пакетных задач.
Суть подхода в том, что есть "сборщик" условных пачек, которому по одному за раз подаются элементы (журналы для разноски или сообщения в нашем случае). Сборщик принимает решение, добавить очередной элемент в текущую пачку или же завершить ее формирование и добавить очередной элемент уже в новую пачку. В случае журналов ГК сборщик смотрит на суммарное количество строк журналов в текущей пачке - эти журналы будут последовательно разноситься в одной пакетной задаче. В случае пакетирования сообщений сборщик может смотреть на суммарный размер сериализованных сообщений в текущей пачке с учетом ограничения на размер буфера и условного размера закрывающих XML-тегов для пачки. Такой подход обычно работает более гибко, чем грубое поштучное деление сообщений на пачки.

Цитата:

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

для начала какую именно технологию ты называешь асинхронным обменом?

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

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

подразумевается, что буферная система:

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

С некоторой натяжкой в качестве буферной системы можно рассматривать файл-сервер Но мне в последнее время, особенно на всяких там "сложных ИТ-ландшафтах" импанируют RabbitMQ и Kafka. Они позволяют реализовать своего рода амортизаторы между разными системами, особенно когда системам выделены разные ресурсы, возможны пиковые нагрузки, периоды недоступности и т.п.

[mazzy]

Цитата:

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

Ну вот же 2-я опция из 3-х в исходном сообщении

Цитата:

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

Если речь про разбивку 100500 сообщений на пачки, то

не-не-не-не!
еще раз: посмотри как сформулирован вопрос.
я сформулировал ровно то, что хотел сформулировать и постарался убрать из вопроса то, что может ограничить решение.

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

давайте я таки скажу какое решение я бы считал идеальным:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

а... понятно.

обрати внимание, что в вопросе используется слово "передать", а не слово "обмен". в вопросе НЕТ ни слова о ждать.

ты как Vadik. только он постоянно говорил что данные должны "запрашиваться" вместо "передаваться".

Ребяты, пожалуйста, прочтите вопрос в самом начале темы.

Ребяты, пожалуйста, не предполагайте, что кто-то забыл об ответах и подтверждениях о приеме данных. Просто вопрос данной темы:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

[S.Kuskov]

Цитата:

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

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

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

И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов.

вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint.

современный правильный ответ - использовать потоки.
но в Аксапте нет потоков.

какой способ отправить много элементов коллекции является правильным для Аксапты?

Я может чего-то не понимаю, но если в самой Аксапте нет потоков, а все остальное устраивает, то нужно решить только два технических вопроса:
- Как из первой аксапты писать сообщения в исходящий поток WCF?
- Как во второй аксапте читать сообщения из входящего потока WCF?

Как эта задача решается на .net: https://weblogs.asp.net/cibrax/strea...rred-execution

Если непосредственно из аксапты нельзя это повторить, то наверняка можно сделать сборку-адаптер, который будет удобно использвать из аксапты.
Нет?

[mazzy]

Цитата:

Сообщение от S.Kuskov

...то нужно решить только два технических вопроса:

именно поэтому в вопросе нет слова поток (stream).
нет слова поток, чтобы не ограничивать возможные ответы.

есть ли еще какой-нибудь другой способ?

Цитата:

Сообщение от S.Kuskov

Если непосредственно из аксапты нельзя это повторить, то наверняка можно сделать сборку-адаптер, который будет удобно использвать из аксапты.
Нет?

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

===========
давайте я повторю вопрос в безнадежной попытке:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

[Skvorcal]

Цитата:

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

давайте я повторю вопрос в безнадежной попытке:

как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

Напомнило анекдот...

Цитата:

Удар головой — штанга!
Еще удар головой — штанга!
Опять удар головой — снова штанга!!!....
Дайте ему наконец мяч или как-нибудь прекратите эту истерику!

[gl00mie]

Цитата:

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

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

прямо вот всю коллекцию сразу? какого же она будет размера?

Цитата:

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

все-таки для мира аксапты хорошие допущения:
= размер элемента до 8кб
= размер буфера рабочего окна 64Кб (максимальный размер XML в WCF по умолчанию)
= размер коллекции более 100500 элементов

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

Цитата:

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

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

Приемник нежданчиком получает на своей стороне под сотни Мб, теоретически до 1 Гб данных, которые ему потом надо профаршить? А потом на 97% обработки падает - и начинай всё сначала?

Цитата:

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

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

Мне кажется, дело не в коллекциях и их передаче через WCF, а в том, что на больших объемах уже не работает подход с отдельными стадиями: подготовил сразу все данные, затем передал сразу все данные (через интеллектуальный траспорт, который сам их порежет на пакеты и утрамбует в маленькие буферы), затем обработал сразу все данные. На больших объемах подход нужно обычно менять - возможно, в случае с WCF на работу через IEnumerable<>, как тут уже предлагали.

Цитата:

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

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

Вся тема на форуме - про такие предложения, разве нет?

Цитата:

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

почему вы считаете этот способ правильным?

Мне кажется, нет тут "правильных" способов, есть способы, которые решают поставленную задачу со всеми ее вводными и ограничениями, есть удобства и стоимости разных решений, есть сложившиеся условия. К примеру, мне думается, что из брокеров сообщений удобней и быстрее работать с RabbitMQ, но часть клиентов уже внедрила Kafka, и в этих условиях RabbitMQ для них не явлеятся "правильным способом" интеграции систем, потому что у них Kafka является общей шиной данных.

Цитата:

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

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

Ваша абстракция дала течь, и теперь надо залезать под капот и разбираться, как всё исправить

Цитата:

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

Ребяты, пожалуйста, прочтите вопрос в самом начале темы.
Ребяты, пожалуйста, не предполагайте, что кто-то забыл об ответах и подтверждениях о приеме данных. Просто вопрос данной темы:
как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009?

Мне тут в очередной раз вспоминается Макконнелл:

Цитата:

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

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

[mazzy]

Цитата:

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

прямо вот всю коллекцию сразу?

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

Цитата:

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

Выходит, вся коллекция может занимать в памяти от нескольких Мб до нескольких сотен Мб, под 1 Гб условно. И это всё - в многопользовательской системе, где параллельно еще десятки процессов тоже что-то лопатят, и им тоже может быть нужно много памяти. Как по мне, так уже на этом этапе решение выглядит неидеальным, лично я предпочел бы начинать отправку сообщений по готовности, а не когда всё-всё будет готово, либо сериализовывал бы их в базу, стараясь избежать затрат в сотни Мб оперативки на одну мою сессию выгрузки данных.
Приемник нежданчиком получает на своей стороне под сотни Мб, теоретически до 1 Гб данных, которые ему потом надо профаршить? А потом на 97% обработки падает - и начинай всё сначала?

о! какое длинное обоснование "как делать не надо".
а как надо?

господи! ну прочитай же первое сообщение!
в аксапте (сюрприз!) данные могут хранится в таблице!

Цитата:

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

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

щас-щас... наверняка будет текст "как надо".

Цитата:

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

На больших объемах подход нужно обычно менять - возможно, в случае с WCF на работу через IEnumerable<>, как тут уже предлагали.

Отлично. И как это сделать из Аксапты? В которой нет генериков.
делать wrapper-объект? накладные расходы на работу wrapper-объекта точно будут меньше, чем накладные расходы при передаче элемента по одному?
"а вы точно режиссёр?"

Цитата:

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

Вся тема на форуме - про такие предложения, разве нет?

Таки да!

Цитата:

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

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

Блин, Кайфолом твоя фамилия!
а я так надеялся, что будут рассуждения как сделать правильно.

Цитата:

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

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

да что вы так упёрлись в серебряные пули в виде Кафки, Кролика, Веб-сферы и т.п. Можно вспомнить и мертвенькую MSMQ (которая уже есть в поставке виндов)

Там тоже есть буфер обмена со своим размером, как в WCF
Там тоже есть потоки, которых нет в Аксапте.

И нет другой магии.
Насколько я понимаю, выбор брокера НИКАК не влияет на рассуждения о том, как правильно передавать 100500 элементов коллекции.

Если вы считаете не так, то просто скажите "1. используем вот это 2. это не буфер ограниченного размера и не поток. 3. и это будет правильно потому-то"

Цитата:

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

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

не, у меня полное ощущение, что это https://xyproblem.info/
что я пытаюсь решить некоторую проблему y, хотя решить надо проблему x...
https://habr.com/ru/company/dododev/blog/467047/

==========================

Чтобы подвести некоторый итог, давайте перечислю варианты, которые здесь прозвучали:

1.
Передавать элементы по одному и не парится
в конечном итоге это может быть и не так уж накладно.

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

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

4.
создать свой middleware с блэкджеком и потоками (stream). не решает проблему передачи между аксаптой и middleware. разве что реализовать middleware как dll и внедрить его в адресное пространство AOS. В этом случае передавать между аксаптой и mdllware можно по одному элементу.

5.
магические внешние брокеры , которые по мнению авторов несомненно решат все проблемы, но ни один из авторов не сказал как именно решат.

хипстеры говорят о кролике и кафке, прагматичные говорят о еще живом умертвии msmq и уже готовом адаптере MSMQ в AIF.
самые отважные говорят, что эти внешние брокеры - всего лишь частный случай middleware.

6.
некоторые самые смелые говорят, что для WCF в настройках app.config можно увеличить размер буфера (вместо 65Кб поставить 100Мб, например). Но отводят глаза, когда их спрашиваешь а что будет если кто-то на каком-либо клиенте забудет увеличить размер буфера...

7.
очень нетрадиционный, но очень привлекательный способ - воспользоваться сервисом Query Service

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

но... привлекательно, чёрт побьери.

8.
как вариант пункта 7 - публиковать view, а не сервис.
достоинства и недостатки такие же как в пункте 7.

9.
и как же я забыл!
ПДБ - промежуточная база данных.
как частный случай middleware.

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

=========================
спасибо за плодотворное обсуждение.
буду думать.

[gl00mie]

Цитата:

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

Цитата:

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

прямо вот всю коллекцию сразу?

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

Ну как же... а это о чем?

Цитата:

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

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

Может, я читаю как-то через слово, но вот написано: "коллекция типизированных объектов". В моем понимании типизированные объекты - это в оперативной памяти.

Цитата:

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

в аксапте (сюрприз!) данные могут хранится в таблице!

Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД.
Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры?

Цитата:

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

И как это сделать из Аксапты? В которой нет генериков.

См. как работают с ними в 12-ке локализаторы, когда генерят документы через OpenXML. В синтаксисе X++ поддержки нет, а работать с ними в Аксапте можно.

Цитата:

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

делать wrapper-объект? накладные расходы на работу wrapper-объекта точно будут меньше, чем накладные расходы при передаче элемента по одному?

В WCF для передачи другой стороне нужно использовать сериализуемые объекты. Если таким объектом будет .NET-овский data transfer object, специально созданный нами в отдельной сборке, то мы при этом будем иметь возможность создать IEnumerable<> для этого .NET-овского DTO, причем создать из X++. Я лично не вижу, почему накладные расходы на работу с таким .NET-овским DTO должны быть выше, чем накладные расходы на работу с каким-нить CLRObject в X++.

Цитата:

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

Насколько я понимаю, выбор брокера НИКАК не влияет на рассуждения о том, как правильно передавать 100500 элементов коллекции.
Если вы считаете не так, то просто скажите "1. используем вот это 2. это не буфер ограниченного размера и не поток. 3. и это будет правильно потому-то"

Когда речь идет о том, чтобы передавать данные между двумя ERP-системами, то мне лично странно слышать постановку задачи вида "передать 100500 элементов" в отрыве от того, как они будут обработаны на принимающей стороне, если там предполагается какая-то валидация и обработка этих данных. А если рассматривать задачу в комплексе (а не просто "вот у меня 10 пивных банок башенкой стоят ровно, как мне поставить 1000 пивных банок, чтоб не падали?"), то как раз и возникают решения, начиная с использования брокера сообщений и заканчивая (о, нет!) реализацией view на стороне отправителя с возможностью принимающей стороне читать этот view по мере возможности.

Цитата:

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

Чтобы подвести некоторый итог, давайте перечислю варианты, которые здесь прозвучали:
1. Передавать элементы по одному и не парится - в конечном итоге это может быть и не так уж накладно.

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

Цитата:

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

2. Вручную создавать пакеты (chunks) с некоторым ограниченным числом элементов
можно до опупения добавлять искусственного интеллекта в автоопределение отптимального числа элементов в чанке.

Можно до опупения поливать грязью варианты, которые не нравятся, придумывая какие-то крайности, которые непонятно, что доказывают. Но, к примеру, майкрософтовская команда Dynamics AX 2012, занимающаяся финансами, поставила себе задачу разнести 100000 журналов ГК - и решила ее, минимизировав накладные расходы пакетной инфраструктуры за счет нарезки журналов на такие вот "чанки", а потом встроила это решение в стандарт. Намного ли эта майкрософтовская команда глупее mazzy, пытающегося пропихнуть 100500 элементов коллекции через WCF? Не думаю...

Цитата:

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

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

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

Цитата:

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

6. некоторые самые смелые говорят, что для WCF в настройках app.config можно увеличить размер буфера (вместо 65Кб поставить 100Мб, например).

Это вот как раз "10-метровые пивные банки"

Цитата:

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

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

Ну конечно же, когда системы дергают друг дружку через кастомные AIF-сервисы, это они ничего друг о друге не знают, а вот если дергать штатный Query Service, то это "слишком много знать о внутреннем устройске друг-друга". Вы не понимаете, это другое (с)

Цитата:

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

9. и как же я забыл! ПДБ - промежуточная база данных. как частный случай middleware.

Да тю!.. В топку эти ПБД - писать уже сразу в чужую базу, в какую-нить промежуточную таблицу, и дело с концом, всё равно ведь обе системы в одном домене. Накладных расходов почти никаких, скорость максимальная, сплошной профит...

Цитата:

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

не, у меня полное ощущение, что это https://xyproblem.info/
что я пытаюсь решить некоторую проблему y, хотя решить надо проблему x...
https://habr.com/ru/company/dododev/blog/467047/

Ну отлегло, а то я уже подумал, что это все превращается в бесконечную игру "Почему бы вам не?.. Да, но..."

Цитата:

ПБВНДН может разыгрываться любым числом участников. Действующий предлагает задачу. Другие начинают предлагать решения, каждое из которых начинается словами: «А почему бы вам не...» На каждое из них миссис Уайт отвечает возражением: «Да, но...» Хороший игрок может противостоять другим сколь угодно долго, пока они не сдадутся, и тогда миссис Уайт выигрывает. В некоторых случаях ей приходится разделаться с дюжиной или больше решений, чтобы подготовить унылую тишину, означающую ее победу.

[mazzy]

Цитата:

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

Ну как же... а это о чем?
Может, я читаю как-то через слово, но вот написано: "коллекция типизированных объектов". В моем понимании типизированные объекты - это в оперативной памяти.

типизированные объекты не обязаны появляться в оперативной памти сразу


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

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

======================

Цитата:

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

Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД.
Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры?

поэтому я и ввел фазу подготовки данных.
обрати внимание не генерация данных

Цитата:

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

См. как работают с ними в 12-ке локализаторы, когда генерят документы через OpenXML. В синтаксисе X++ поддержки нет, а работать с ними в Аксапте можно.

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

gl00mie, участники, заклинаю!
тема НЕ называется как можно передать...!
тема называется как правильно передать!

пожалуйста!

Цитата:

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

Я лично не вижу, почему накладные расходы на работу с таким .NET-овским DTO должны быть выше, чем накладные расходы на работу с каким-нить CLRObject в X++.

X++ тупо медленный.
чем больше кода на X++, тем медленнее он будет выполняться относительно CLR

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

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

Цитата:

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

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

во-первых, кто тебе сказал, что постановка задачи идет "в отрыве"? и кто тебе сказал, что вопрос этой темы - это полная постановка задачи?

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

Цитата:

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

то как раз и возникают решения, начиная с использования брокера сообщений и заканчивая (о, нет!) реализацией view на стороне отправителя с возможностью принимающей стороне читать этот view по мере возможности.

да-да-да... ну же, не томи, расскажи как правильно то?
особенно "передать" "вьюшкой".

просто расскажи как правильно.

Цитата:

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

Через веб-сервис что ли? В один поток успеет ли интеграция всё передать в приемлемое время? А если в несколько потоков, то во сколько?

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

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

расскажи.

Цитата:

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

Есть ли зависимости между разными элементами коллекции, влияющие на порядок передачи, или они все могут передаваться в произвольном порядке?

шикардос вопрос!
зависимости конечно есть, как между таблицами (шапка-строки), так и между записями в одной таблице (всякие деревья с id/parentId)

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

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

Цитата:

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

И чем определение количества потоков будет лучше, скажем, ручной нарезки на пакеты?

да! расскажи пожалуйста.

Цитата:

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

Можно до опупения поливать грязью варианты, которые не нравятся, придумывая какие-то крайности, которые непонятно, что доказывают. Но, к примеру, майкрософтовская команда Dynamics AX 2012, занимающаяся финансами, поставила себе задачу разнести 100000 журналов ГК - и решила ее, минимизировав накладные расходы пакетной инфраструктуры за счет нарезки журналов на такие вот "чанки", а потом встроила это решение в стандарт.

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

Цитата:

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

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

я там был. намного. я это знаю. к сожалению.

Цитата:

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

Ну конечно же, когда системы дергают друг дружку через кастомные AIF-сервисы, это они ничего друг о друге не знают, а вот если дергать штатный Query Service, то это "слишком много знать о внутреннем устройске друг-друга". Вы не понимаете, это другое (с)

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

[Владимир Максимов]

Что-то я перестал понимать, а о чем вообще речь-то? Можно "пальцем ткнуть"? Без общих слов, а именно на конкретном примере

- Если речь идет о передаче структуры (Base Enum) - это одно
- Если речь идет о передаче данных (последняя себестоимость) - это уже другое

- Если система интеграции уже выбрана (WCF, АБВ, ГДЕ и т.п. - что все эти буквы обозначают?) - то смысл вопроса? Все-равно ведь система диктует свои правила работы.
- Если система интеграции еще не выбрана, то принципиально зависит именно от конкретных условий. Нет и не может быть "общего случая". Одно дело ПБД и общий сервер базы данных и совершенно другое передача XML (или файлов) куда-то на внешнее хранилище через web-сервис

Почему так не нравится знание о принимающей стороне? Это дополнительные ограничения интеграции?

Я не понимаю. С задачей интеграции между разными системами сталкивались все. И каждый решал эту задачу по своему. В рамках своих условий. Именно как частный случай. В чем принципиальное отличие в данном вопросе? О каком "общем случае", к которому можно применить "как правильно" идет речь?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Что-то я перестал понимать, а о чем вообще речь-то? Можно "пальцем ткнуть"? Без общих слов, а именно на конкретном примере

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

если вы чего-то не видите в задаче, то исходите из того, что я посчитал это не важным. Не забыл, не "не нравится", а просто это не влияет на ответ, на мой взгляд.

если вы считаете какой-то аспект важным, то вводите его в свой ответ и расскажите
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

Цитата:

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

Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно

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

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

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

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

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

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

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

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

ЗЫ
а может где-нибудь еще есть такое? не только в WCF...

[Владимир Максимов]

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

1. Речь идет о передаче между системами данных, часть из которых может физически не хранится в базе данных MS SQL
2. Речь идет о передаче большого объема данных
3. Система интеграции уже выбрана. Это некая система, реализованная на базе WCF
4. У WCF есть ограничение на размер одного передаваемого сообщения. Т.е. все данные в одном сообщении передать нельзя

Т.е. вопрос сводится к тому "как правильно" порезать на куски все передаваемые данные, если эти данные разных типов. Нет единого правила, кроме предельного размера.

---------------------------------------------

Если в качестве интеграционных сообщений используются XML, то можно копировать данные из Axapta в базу MS SQL перед выгрузкой. Это к вопросу о том, что часть данных нет в базе MS SQL.

Тут идея в том, что для формирования XML можно было бы использовать синтаксис SQL (select ... for xml).

Во-первых, это должно быть быстрее, чем формировать тот же XML в среде Axapta, а, во-вторых, можно заранее оценить размер итогового XML и "резать" по номерам записей в таблице для выгрузки

Ну, и обратный парсинг из XML в среде MS SQL тоже должен работать быстрее.

Цитата:

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

Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла

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

[Skvorcal]

Тема окончательно скатилась в высокомерный троллинг со стороны mazzy.

[ax_mct]

Цитата:

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

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

если вы чего-то не видите в задаче, то исходите из того, что я посчитал это не важным. Не забыл, не "не нравится", а просто это не влияет на ответ, на мой взгляд.

если вы считаете какой-то аспект важным, то вводите его в свой ответ и расскажите
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

Уверен, что недопонимание вызвано простейшей вещью. В силу особенности рыночной ниши, практически все здесь не кодеры, а скорее 3 в 1, программисты создающие решения для конечного пользователя.

И восприятие требований у нас уже профессионально особенное. Задачи практически всегда бизнес-задачи, а не узкие технические задачи как в других IT нишах.

В постановке вопроса просто никто не увидел задачи. А увидел некое решение. И как раз неправильно задачу подменять решением. В собственной голове неправильно.

Но если буквально то на вопрос ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?[/QUOTE]
то "правильно" на мой взгляд следуещее:

C точки зрения современного .NET разработчика. Если узко и без общей картины.

- использовать сборки (DLL) последних версий .NET на обеих серверах.
В X++ просто обращаться к этим DLL. Pagination, streaming, JSON - все опции.

Самое "правильное" c точки зрения .NET разработчика это использовать даже не WCF, а gRPC

https://docs.microsoft.com/en-us/asp...aspnetcore-6.0

https://grpc.io/docs/what-is-grpc/

Для опыта .NET это правильно. Ну там прокси понадобятся между .NET и .Core, но это остается все очень правильным для .NET разработчика.

С точки зрения же Microsoft, "правильно" это
SQL Data Sync for Azure
https://docs.microsoft.com/en-us/azu...r-sql-database
Все на крючок и это правильно.

С точки зрения клиента когда обе базы в одном домене, безусловно правильно
делать обмен данных на уровне баз данных. Как угодно хранимыми процедурами или из X++, не так важно.
WCF как веб-сервис дорога это компромисс когда порты закрыты, организации со своими полиси и пр.
Правильно потому что стоимость.

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

[mazzy]

Цитата:

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

Цитата:

Но если буквально то на вопрос ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

то "правильно" на мой взгляд следуещее:

C точки зрения современного .NET разработчика. Если узко и без общей картины.

- использовать сборки (DLL) последних версий .NET на обеих серверах.

ax2012 использует .net 4.0
ax2009 использует .net 3.5

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

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

https://www.youtube.com/watch?v=G7wz4lZZo2s