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

[George Nordic]

Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.

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

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

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

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

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

[Vadik]

Bingo!

[mazzy]

Цитата:

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

Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
...
Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля.

даже не столько в парсинге, сколько в валидации входащих данных.

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

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

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

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

Цитата:

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

Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.

Я уже сказал, пусть будет 1 запись в секунду. Пусть будет 10 записей в секунду.
По-моему, не принципиально для заданного вопроса.

[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?" уже успешно решен?

[gl00mie]

Цитата:

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

всё ещё надеюсь услышать мнения по вопросу:
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

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

Цитата:

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

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

Мне лично думается, что как только возникает 100500 элементов для передачи, интеграция должна становиться асинхронной, а связь ax2012 и ax2009 через WCF как-то не очень ложится на идею асинхронного обмена (без собственных dll, "и чтобы эти собственные dll'ки работали в адресном пространстве аксапты"). Это вроде само собой разумеется уже: если требуется обрабатывать в системе много документов, то надо писать пакетную обработку с распараллеливанием. Если требуется передавать между системами большие объемы данных, то надо делать асинхронный обмен.
На тему проектирования интеграций есть хорошая статья у Дениса Трунина, где он предлагает для начала определиться с такими моментами:

• Топология решения интеграции
• Требования для потока данных
• Анализ свойств потока данных
• Определение качества обслуживания (QoS)
• Производительность
• Доступность и надежность
• Безопасность
• Масштабируемость
• Логирование и м... "неподдельность" (nonrepudiation)

И уже по совокупности требований будет ясно, WCF это окажется или не WCF...

Цитата:

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

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

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

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

Цитата:

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

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

Брокер/транспорт при асинхронном обмене даст принимающей стороне возможность обрабатывать сообщения тогда и в таком темпе, в каком ей комфортно, не просаживая другие поддерживаемые бизнес-процессы. А стороне-отправителю даст возможность не ждать ответа и не отправлять все 100500 элементов, скажем, одним куском повторно, если у принимающей стороны что-то не заладилось.
В обсуждении много говорилось про очереди, шины данных и т.п. По-моему, если нужно перебрасывать между двумя системами такие объемы данных, стоит посмотреть в сторону какого-нить RabbitMQ хотя бы. Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах, но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на размер буфера под значимые типы (тот же string), которое по умолчанию, кажется, равно 1Мб - см. Падает клиент при прикреплении файла. Так что если утоптать 100500 элементов в один большой XML/JSON, то на принимающей стороне с ним может быть непросто работать. Я бы в связи с этим постарался разбивать передаваемые данные на блоки меньше 1Мб каждый.

Цитата:

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

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

Кажется, у Макконнелла в Code Complete было:

Цитата:

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

[mazzy]

Цитата:

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

...тоже не беспокоит?

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

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

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

Цитата:

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

...при асинхронном обмене

[mazzy]

Цитата:

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

Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах

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

Цитата:

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

но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на

а с чего ты решил, что об этом кто-то забыл?

Цитата:

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

и не отправлять все 100500 элементов, скажем, одним куском повторно

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

[CDR]

Цитата:

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

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

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

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