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

[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, то это "слишком много знать о внутреннем устройске друг-друга". Вы не понимаете, это другое (с)

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