|
07.04.2021, 10:58 | #1 |
Модератор
|
Цитата:
Извини, но твой вопрос Цитата:
С Уважением, Георгий |
|
07.04.2021, 11:18 | #2 |
Участник
|
можно я еще раз повторю свое первое предложение в первом сообщении этой ветки?
Цитата:
Цитата:
=============================== итак, всё ещё надеюсь услышать мнения по вопросу: ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF? дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке: * "передать" в смысле "отправить" * в аксапте есть recId и нумераторы * в аксапте нет встроенной поддержки потоков (stream). * аксапта 2009 работает на .net 3.5 * аксапта 2012 работает на .net 4.0 (не 4.5) * размер элемента коллекции в Аксапте до 8Кб * размер коллекции до 100500 элементов, но вряд ли больше 2^32 * вместо WCF можно обсуждать любой другой брокер/транспорт * предполагаем, что middlware отсутствует. но мы можем сделать любой * для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения. лично я не вижу, как брокер/транспорт может принципиально повлиять на принимающую сторону. парсинг и валидация на принимающей стороне будут плюс-минус одинаковыми. поэтому сознательно вывел за рамки данного обсуждения вопросы парсинга и валидации на принимающей стороне. и вообще, вывел за рамки обсуждения принимающую сторону. но если вы знаете способ передачи, который существенно повлияет на принимающую сторону, то можно обсудить и её. вводите свои вводные в свое сообщение и вперед. с удовольствием послушаю. Добавлено: огромное спасибо всем участникам обсуждения, что заставили задуматься и сформлировать ограничения и вводные. В результате получается вопрос, который становится похож на правильно сформулированный. Последний раз редактировалось mazzy; 07.04.2021 в 11:36. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4). |
21.04.2021, 02:01 | #3 |
MCTS
|
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
__________________
Dynamics AX Experience |
|
21.04.2021, 15:49 | #4 |
Боец
|
|
|
21.04.2021, 16:02 | #5 |
Участник
|
пока разбиваем на чанки с фиксированным числом элементов.
и написан код для обслуживания этих чанков. сделано с полным пониманием, что это и не оптимально, и не гарантирует от переполнения буферов, и "закат солнца вручную". единственный плюс - быстрее, чем передавать по одному элементу. но "остановились" - это неправильное слово. скорее, приняли в качестве первой версии. Последний раз редактировалось mazzy; 21.04.2021 в 16:06. |
|
21.04.2021, 16:50 | #6 |
Боец
|
Я бы воспользовался AIF+FileBased (или без AIF): выгрузил в виде файла в папку, замапленную в облачный файловый сервис (e.g. OneDrive\DropBox\Azure\ На худой конец SFTP). На принимаемой стороне зеркально в обратную сторону. Если хочется ещё быстрее - файл архивировать.
Если у вас файл тяжелый, то WCF как раз ровно то, что делать не стоит: очень долго, максимальная вероятность креша при передаче через интернет Если вдовесок к WCF бить ещё на чанки, потом их синхронизировать, дожидаять последнего (который, к слову, может и не дойти), ждать таймаута потом по-новой. Все это настраивать, программировать. В общем сложность и надежность данного подхода минимальная, есть риск никогда не передать. UPD: Если нужна синхронность процесса, опубликовать на передаваемой стороне ждуна в виде вэб сервиса, который дернет принимаемая сторона по окончанию приёма. Последний раз редактировалось DSPIC; 21.04.2021 в 16:53. |
|
21.04.2021, 17:03 | #7 |
MCTS
|
Это последнее, что стоит рассматривать для обмена данными. Если в AX2012 еще худо-бедно работает, то в AX 2009 - это полное дно с точки зрения производительности.
__________________
Dynamics AX Experience |
|
21.04.2021, 17:10 | #8 |
Боец
|
Без разницы с AIF или без - главное файл на выходе. Чем хорош AIF - это логирование, масштабируемость, пре и пост обработка сообщений (тот же zip навеcbnm можно) гибкая настройка полей для разных эндпоинтов и прочие прелести. Ну а дальше по отбстоятельствам.
Последний раз редактировалось DSPIC; 21.04.2021 в 17:14. |
|
21.04.2021, 18:52 | #9 |
Участник
|
Цитата:
файлы похоже останутся для первоначальной инициализации подписчиков. в нормальном режиме... ну... лично мне файлы кажутся слишком ненадежным и небезопасным способом. 1. прежде всего из-за возможности компрометации данных в файлах "ответственными" сотрудниками. тут стоит вспомнить передачу файлов в Retail-модуле 2012 (в ax7 вроде бы также) В Retail модуле реализована своя служба на сервере и свой клиент для передачи файлов. На обоих концах готовятся текстовые файлы в незашифрованном и неподписанном виде. любой кто имеет доступ к каталогам, где лежат эти файлы - может сделать с данными что угодно. если учесть, что Retail-модуль обслуживает продажи в сети магазинов. Этот "любой" обязательно появится. WCF - это все-таки процессы в памяти. Здесь квалификация этого "любого" должна быть значительно выше. 2. файловый обмен делает обмен данными сильно двухфазным: 1ая фаза - передать/отправить файл. отправитель может получить статус "файл передан" 2ая фаза - принимающая сторона должна загрузить данные. как правило это будет через некоторое время. и во время загрузки возможны свои ошибки. из-за файловой природы ошибки могут быть перемешаны, могут не дойти... отправителю получить статус данных сильно сложнее. Вспомни тот же модуль Retail - там статус "отправлено" означает, что отправлены файлы, а не данные. Про данные отправитель ничего не знает. Получается эдакий TCP поверх UDP. В общем, обмен файлами - это НЕ обмен данными. И корректная обработка данных в файлах, которые идут потоком... ну... можно, конечно... но нме не кажется, что это сильно легче. 3. кроме того, файлы - это те же самые chunk'и. только оформленные по другому. т.е. в данных получаем ту же самую проблему, плюс еще надо кодить и транспортный уровень вместо WCF. |
|
23.04.2021, 15:40 | #10 |
Участник
|
Цитата:
Цитата:
Цитата:
Сообщение от mazzy
2. отправитель вызывает какой-нибудь специальный метод
3. транспортный уровень, зная о своих возможностях и о размерах буферов, сам организует поток (stream), сам разбивает на пачки, сам их их шифрует, сам собирает эти пачки на приемнике 4. приемник получает собранную коллекцию типизированных объектов Цитата:
Цитата:
Мне кажется, нет тут "правильных" способов, есть способы, которые решают поставленную задачу со всеми ее вводными и ограничениями, есть удобства и стоимости разных решений, есть сложившиеся условия. К примеру, мне думается, что из брокеров сообщений удобней и быстрее работать с RabbitMQ, но часть клиентов уже внедрила Kafka, и в этих условиях RabbitMQ для них не явлеятся "правильным способом" интеграции систем, потому что у них Kafka является общей шиной данных. Цитата:
Сообщение от mazzy
ну... чтобы так сделать, нужно знать как оно работает внутре. для этого придется кодить транспортный уровень вручную.
WCF в вопросе звучит для того, чтобы напомнить, что бывают технологии которые скрывают внутреннюю кухню транспортного уровня. снаружи мы работаем с типизированными объектами. а как оно сериализируется, как сжимается, на какие пачки делится - не знаем. Да и не хотим знать, если честно. Цитата:
Сообщение от mazzy
Ребяты, пожалуйста, прочтите вопрос в самом начале темы.
Ребяты, пожалуйста, не предполагайте, что кто-то забыл об ответах и подтверждениях о приеме данных. Просто вопрос данной темы: как правильно передать 100500 элементов коллекции через WCF или любой другой брокер в ax2012,ax2009? Цитата:
Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.
|
|
23.04.2021, 22:17 | #11 |
Участник
|
а что об этом сказано в моем утверждении? правильно - ничего.
поэтому варианты на усмотрение отвечающего Цитата:
Сообщение от gl00mie
Выходит, вся коллекция может занимать в памяти от нескольких Мб до нескольких сотен Мб, под 1 Гб условно. И это всё - в многопользовательской системе, где параллельно еще десятки процессов тоже что-то лопатят, и им тоже может быть нужно много памяти. Как по мне, так уже на этом этапе решение выглядит неидеальным, лично я предпочел бы начинать отправку сообщений по готовности, а не когда всё-всё будет готово, либо сериализовывал бы их в базу, стараясь избежать затрат в сотни Мб оперативки на одну мою сессию выгрузки данных.
Приемник нежданчиком получает на своей стороне под сотни Мб, теоретически до 1 Гб данных, которые ему потом надо профаршить? А потом на 97% обработки падает - и начинай всё сначала? а как надо? господи! ну прочитай же первое сообщение! в аксапте (сюрприз!) данные могут хранится в таблице! Цитата:
Цитата:
делать wrapper-объект? накладные расходы на работу wrapper-объекта точно будут меньше, чем накладные расходы при передаче элемента по одному? "а вы точно режиссёр?" Таки да! Цитата:
а я так надеялся, что будут рассуждения как сделать правильно. Цитата:
Там тоже есть буфер обмена со своим размером, как в WCF Там тоже есть потоки, которых нет в Аксапте. И нет другой магии. Насколько я понимаю, выбор брокера НИКАК не влияет на рассуждения о том, как правильно передавать 100500 элементов коллекции. Если вы считаете не так, то просто скажите "1. используем вот это 2. это не буфер ограниченного размера и не поток. 3. и это будет правильно потому-то" Цитата:
что я пытаюсь решить некоторую проблему 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 элементов коллекции между разными системами. и ни одного внятного рассуждение а как их правильно передать таки. ========================= спасибо за плодотворное обсуждение. буду думать. Последний раз редактировалось mazzy; 23.04.2021 в 22:45. |
|
24.04.2021, 15:44 | #12 |
Участник
|
Цитата:
Цитата:
Сообщение от mazzy
давайте я таки скажу какое решение я бы считал идеальным:
1. отправитель готовит коллекцию типизированных объектов произвольного размера 2. отправитель вызывает какой-нибудь специальный метод 3. транспортный уровень сам организует поток (stream), сам разбивает на пачки, сам собирает эти пачки на приемнике 4. приемник получает собранную коллекцию типизированных объектов Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД. Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры? См. как работают с ними в 12-ке локализаторы, когда генерят документы через OpenXML. В синтаксисе X++ поддержки нет, а работать с ними в Аксапте можно. Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Сообщение от mazzy
в граничном случае супер-интеллекта придется кодить транспортный уровень вручную. и не факт, что в этом случае накладные расходы получатся меньше, чем при передаче элементов по одному
[...] 5. магические внешние брокеры, которые по мнению авторов несомненно решат все проблемы, но ни один из авторов не сказал как именно решат. Цитата:
Цитата:
Сообщение от mazzy
7. очень нетрадиционный, но очень привлекательный способ - воспользоваться сервисом Query Service
это не совсем то, о чем спрашивалось. и разные системы должны слишком много знать о внутреннем устройстве друг-друга. Цитата:
Цитата:
Сообщение от mazzy
не, у меня полное ощущение, что это https://xyproblem.info/
что я пытаюсь решить некоторую проблему y, хотя решить надо проблему x... https://habr.com/ru/company/dododev/blog/467047/ Цитата:
ПБВНДН может разыгрываться любым числом участников. Действующий предлагает задачу. Другие начинают предлагать решения, каждое из которых начинается словами: «А почему бы вам не...» На каждое из них миссис Уайт отвечает возражением: «Да, но...» Хороший игрок может противостоять другим сколь угодно долго, пока они не сдадутся, и тогда миссис Уайт выигрывает. В некоторых случаях ей приходится разделаться с дюжиной или больше решений, чтобы подготовить унылую тишину, означающую ее победу.
|
|
24.04.2021, 16:17 | #13 |
Участник
|
Цитата:
gl00mie, у меня просьба - можешь перейти от фазы критики постановки задачи к фазе генерации решения? иначе мне постоянно придется тебя тыкать в исходный вопрос. если в вопросе что-то не указано, то это значит, ты можешь фиксировать любой удобный тебе аспект любым удобным тебе способом и предлагать решение. ====================== Цитата:
Сообщение от gl00mie
Данные - могут храниться в таблице, а вот типизированные объекты (коллекцию которых предполагалось создать в рамках идеального решения) - не могут, потому что в таблице могут храниться лишь сериализованные представления объектов. А еще WCF (сюрприз!) не умеет читать данные из таблицы СУБД.
Или сообщение про "идеальное решение" с коллекцией типизированных объектов читать не надо было, потому что оно противоречит исходному сообщению про таблицы и контейнеры? обрати внимание не генерация данных Цитата:
и сразу спрашиваю - накладные расходы на выполнение "этого" X++ точно будут меньше, чем накладные расходы на передачу элементов по одному? gl00mie, участники, заклинаю! тема НЕ называется как можно передать...! тема называется как правильно передать! пожалуйста! Цитата:
чем больше кода на X++, тем медленнее он будет выполняться относительно CLR И пожалуйста, если ты сейчас начнешь говорить о галочке Компилировать в CIL то я снова вынужден ткнуть тебя в формулировку исходного вопроса ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF? Цитата:
Сообщение от gl00mie
Когда речь идет о том, чтобы передавать данные между двумя ERP-системами, то мне лично странно слышать постановку задачи вида "передать 100500 элементов" в отрыве от того, как они будут обработаны на принимающей стороне, если там п/редполагается какая-то валидация и обработка этих данных.
во-вторых, кто тебе мешает ввести в обсуждение те аспекты, которые ты считаешь обязательными и рассказать "как правильно передать" с учетом этих аспектов? Цитата:
особенно "передать" "вьюшкой". просто расскажи как правильно. Цитата:
что это значит? что ты можеешь использовать допущения, которые тебе нравятся. и рассказать "как правильно передать" в рамках этих допущений. я повторюсь, что если я не добавил что-то в вопрос, то не считаю это важным для обсуждения. может быть в силу своих не знаний. расскажи. Цитата:
зависимости конечно есть, как между таблицами (шапка-строки), так и между записями в одной таблице (всякие деревья с id/parentId) но эти зависимости я сознательно оставил ЗА рамками данной темы. ну, где-то данные генерируются, где-то данные принимаются. в рамках данной тебя интересует только "как правильно передать 100500 элементов коллекции через брокер в классических аксаптах" если ты считаешь, что логическая зависимость в данных хоть как-то влияет на передачу данных, то конечно добавляй вводную и расскажи как правильно передать. Цитата:
Цитата:
Сообщение от gl00mie
Можно до опупения поливать грязью варианты, которые не нравятся, придумывая какие-то крайности, которые непонятно, что доказывают. Но, к примеру, майкрософтовская команда Dynamics AX 2012, занимающаяся финансами, поставила себе задачу разнести 100000 журналов ГК - и решила ее, минимизировав накладные расходы пакетной инфраструктуры за счет нарезки журналов на такие вот "чанки", а потом встроила это решение в стандарт.
Цитата:
Цитата:
можешь пояснить? |
|
25.04.2021, 22:16 | #14 |
Участник
|
Что-то я перестал понимать, а о чем вообще речь-то? Можно "пальцем ткнуть"? Без общих слов, а именно на конкретном примере
- Если речь идет о передаче структуры (Base Enum) - это одно - Если речь идет о передаче данных (последняя себестоимость) - это уже другое - Если система интеграции уже выбрана (WCF, АБВ, ГДЕ и т.п. - что все эти буквы обозначают?) - то смысл вопроса? Все-равно ведь система диктует свои правила работы. - Если система интеграции еще не выбрана, то принципиально зависит именно от конкретных условий. Нет и не может быть "общего случая". Одно дело ПБД и общий сервер базы данных и совершенно другое передача XML (или файлов) куда-то на внешнее хранилище через web-сервис Почему так не нравится знание о принимающей стороне? Это дополнительные ограничения интеграции? Я не понимаю. С задачей интеграции между разными системами сталкивались все. И каждый решал эту задачу по своему. В рамках своих условий. Именно как частный случай. В чем принципиальное отличие в данном вопросе? О каком "общем случае", к которому можно применить "как правильно" идет речь?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
26.04.2021, 12:15 | #15 |
Участник
|
Цитата:
в нем я постарался сформулировать задачу масимально кратко и четко. если вы чего-то не видите в задаче, то исходите из того, что я посчитал это не важным. Не забыл, не "не нравится", а просто это не влияет на ответ, на мой взгляд. если вы считаете какой-то аспект важным, то вводите его в свой ответ и расскажите ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF? Цитата:
Сообщение от mazzy
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно для простоты предположим, что есть две аксапты, в которых есть WCF мне кажется, что все равно какой версии, но если для ваших рассуждений важно, то зафиксируйте в своих рассуждениях версию. в одной аксапте (назовем ее клиентом) есть огромная коллекция очень важных данных. коллекция - список/массив/мап/контейнер/таблица как передать эти данные в другую Аксапту (назовем ее сервером) через WCF? передавать по одном элементу - слишком много накладных расходов. кроме того, аксапта-сервер будет создавать неявную транзакцию для каждого элемента. что медленно. передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разрвет все внутренние буфера. делить на чанки и передавать чанками по несколько сотен элементов - надо возиться и тоже никакой гарантии, что не разорвет внутренние буфера. наверное было бы идеально передавать в какой-нибудь метод элементы коллекции, а WCF сам бы делил на чанки исходя из своих внутренних резервов. Но я не знаю такого метода. в общем, как правильно передать 100500 элементов коллекции через WCF? ЗЫ а может где-нибудь еще есть такое? не только в WCF... Последний раз редактировалось mazzy; 26.04.2021 в 12:17. |
|
11.12.2021, 18:47 | #16 |
Banned
|
Цитата:
Сообщение от mazzy
я не знаю как разжевать еще, кроме как процитировать свое первое собщение.
в нем я постарался сформулировать задачу масимально кратко и четко. если вы чего-то не видите в задаче, то исходите из того, что я посчитал это не важным. Не забыл, не "не нравится", а просто это не влияет на ответ, на мой взгляд. если вы считаете какой-то аспект важным, то вводите его в свой ответ и расскажите ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF? И восприятие требований у нас уже профессионально особенное. Задачи практически всегда бизнес-задачи, а не узкие технические задачи как в других 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 (2). |
12.12.2021, 14:23 | #17 |
Участник
|
Цитата:
Сообщение от ax_mct
Цитата:
Но если буквально то на вопрос ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
C точки зрения современного .NET разработчика. Если узко и без общей картины. - использовать сборки (DLL) последних версий .NET на обеих серверах. ax2009 использует .net 3.5 мало того, что классические Аксапты используют старые .net, дык они используют разные версии .net. Собственно поэтому они в вопросе и упоминаются явно. советовать использовать последние версии .net для классических аксапт - это как советовать безногому прыгнуть через лужу, чтобы не испачкаться. Теоретически возможно, практически нужно хорошее обоснование. https://www.youtube.com/watch?v=G7wz4lZZo2s |
|
12.12.2021, 14:51 | #18 |
Участник
|
Цитата:
т.е. вы предлагаете: = либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант) = либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку. если так, как современный .NET разработчик, расскажите (лучше в отдельной ветке) как старые системы будут вызывать и принимать вызовы(!) Stream API, при условии что они ничего не знают о Stream API. Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"? и как предлагаемый вами способ в этом поможет Добавлено: и да, учтите, что gRPC основан на Stream API. Что почти все его хваленые преимущества - это преимущества Stream API. Последний раз редактировалось mazzy; 12.12.2021 в 15:09. |
|
12.12.2021, 20:34 | #19 |
Banned
|
Цитата:
Сообщение от mazzy
т.е. вы предлагаете: = либо перекомпилировать работающие системы в Latest Target (ха-ха-ха, сразу отбросим этот вариант) = либо создать какую-то прокси-библиотеку, которая скомпилирована в Latest Target, а старые системы каким-то волшебным образом будут использовать эту прокси библиотеку. Если не Stream API, то собственно вопрос "как правильно передать 100500 элементов коллекции"? С учетом реалий существования .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 элементов коллекции"
Конечно интересно обсудить чисто программистскую задачу из любви к исскуству. Но в нашем случае какое тут искусство? Размер окошка в камере для раздачи пищи и длина цепи - не предполагают такого понятия. Стул прибитый к полу - наше все. |
|
26.04.2021, 21:58 | #20 |
Участник
|
Судя по дискуссии, заданный вопрос большинство поняли не так, как надеялся автор. Правильно ли я понимаю, что
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 можно управляющие команды подать, с метаданными файла
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
|