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

[George Nordic]

Цитата:

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

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

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

Извини, но твой вопрос

Цитата:

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

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

Выглядит как "как вкорячить 1000-лошадный двигатель на шаху?". Мы с Вадимом пытаемся объяснять про тормозную систему и управляемость, в ответ слышим "да ладно тормоза, главное разогнаться!". Результат как бы немного предсказуем.

С Уважением,
Георгий

[mazzy]

можно я еще раз повторю свое первое предложение в первом сообщении этой ветки?

Цитата:

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

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

Цитата:

Сообщение от George Nordic

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

ты это мне говоришь?

===============================
итак,

всё ещё надеюсь услышать мнения по вопросу:

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

дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены

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

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

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

[CDR]

Цитата:

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

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

Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?

[DSPIC]

Цитата:

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

Сразу скажу, что решение есть, конечно.

Ну так и на чем в итоге остановились?

[mazzy]

Цитата:

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

Ну так и на чем в итоге остановились?

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

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

но "остановились" - это неправильное слово.
скорее, приняли в качестве первой версии.

[DSPIC]

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

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

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

[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

давайте я таки скажу какое решение я бы считал идеальным:
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...

[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

[mazzy]

Цитата:

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

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

Ладно, хер с ней, с Аксаптой.

т.е. вы предлагаете:
= либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант)
= либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку.



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

Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"?
и как предлагаемый вами способ в этом поможет

Добавлено: и да, учтите, что gRPC основан на Stream API. Что почти все его хваленые преимущества - это преимущества Stream API.

[ax_mct]

Цитата:

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

т.е. вы предлагаете:
= либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант)
= либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку.

Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"?

Да было бы желание у ударенного на голову .NET разработчика.
С учетом реалий существования .NET и .Core так или иначе есть
попытки писать такие прокси в .NET коммьюнити.

Вот к примеру порт gRPC для Unity .Net 3.5
https://github.com/bwplotka/unity-grpc

Я в свое время Java JSON поток в .NET сборку запихивал. Для AX кстати
Уже даже не помню как. Так или иначе извратиться можно как угодно, было бы желание этим морковкам молиться.

Ни в коем случае ничего не предлагаю эдакого. Но если в качестве варианта то
.NET 3.5 .DLL сообщается с .NET Core DLL через COM interoperability

.NET Framework and .NET Core COM interoperability
https://docs.microsoft.com/en-us/sam...e-com-interop/

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

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

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

В свою очередь X++ работает с данными в этой базе.

Цитата:

"как правильно передать 100500 элементов коллекции"

То есть вариант ответа - через третью, возможно общую, базу данных.

Конечно интересно обсудить чисто программистскую задачу из любви к исскуству. Но в нашем случае какое тут искусство? Размер окошка в камере для раздачи пищи и длина цепи - не предполагают такого понятия. Стул прибитый к полу - наше все.

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

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

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 передаются строго одинаковые бинарные файлы. А на принимающей стороне этот архив собирается и извлекается