#redbroute — Public Fediverse posts

AS2 в .NET без отдельного Java-гейтвея: EDI-обмен с партнёрами прямо в маршруте

Если вы поставляете товар в крупную розницу, возите грузы для 3PL-оператора, шлёте платёжные извещения банку или обмениваетесь медицинскими транзакциями X12 — вы почти наверняка обмениваетесь этими документами по AS2 . Заказ (EDI 850), счёт (810), уведомление об отгрузке (856), платёжное авизо (820) уходят партнёру не почтой и не через REST, а как подписанный и зашифрованный S/MIME-конверт поверх HTTP, с подписанной квиткой-распиской в ответ. Так работает регламентированный B2B-документооборот в рознице, логистике, финансах, производстве и здравоохранении уже двадцать лет: Walmart, Amazon и их сети поставщиков, банки с host-to-host каналом, автопром, дистрибьюторы — все требуют AS2. В .NET до сих пор было два пути. Либо коммерческий AS2-шлюз — Cleo, Seeburger, BizTalk — отдельная коробка, отдельная лицензия, отдельная команда сопровождения. Либо Java-сервер с открытым кодом — OpenAS2, Mendelson Community — отдельный JVM-процесс рядом с вашим .NET-бэкендом, со своим inbox-каталогом, откуда документы надо ещё забирать джобой. В обоих случаях AS2 живёт сбоку от вашей интеграции, а не внутри неё. redb.Route.AS2 закрывает этот разрыв: AS2 становится обычным шагом маршрута в вашем .NET-процессе. Приняли конверт от партнёра, расшифровали, проверили подпись, отдали документ в pipeline — провалидировали, трансформировали, положили в Kafka или SQL — и вернули партнёру подписанную расписку. Один процесс, один деплой, одна панель наблюдаемости. Разберём, как это выглядит в коде, где применяется и почему нативный коннектор в ESB выигрывает у отдельного шлюза.

https://habr.com/ru/articles/1069840/

#AS2 #EDI #X12 #EDIFACT #SMIME #MDN #B2B #ESB #NET #redbRoute

redb 3.4.0: переигрываем упавшее, патчим фреймворк без пересборки и раздаём права — экосистема.NET

Написать систему и эксплуатировать систему — две очень разные инженерные задачи. Первая заканчивается на «работает под нагрузкой». Вторая начинается с вопросов, которые задаёт человек на дежурстве: что упало ночью и как это переиграть? кто нажал force‑stop? можно ли выкатить патч библиотеки, не пересобирая весь рантайм? почему пароль сервис‑аккаунта видно на странице дашборда? Прошлые релизы нашей экосистемы отвечали на первый вопрос. 3.4.0 — целиком про второй. Напомню, из чего экосистема состоит: типизированное хранилище redb поверх Postgres/MSSQL/SQLite, интеграционный движок redb.Route (наш ответ Apache Camel под.NET, 30+ коннекторов), рантайм redb.Tsak с дашбордом, hot‑reload и кластером, и сервер идентичности redb.Identity (OIDC/OAuth 2.1). Всё это работает у нас в проде и публикуется пакетами, образами и standalone‑архивами. В 3.4.0 появились четыре вещи, каждая из которых — про день после деплоя:

https://habr.com/ru/articles/1063722/

#redb #redbRoute #redbTsak #Apache_Camel #replay #dead_letter_queue #RBAC #OIDC #hot_reload #NET_9

Redb.Route 3.1.1 (LLM, часть 2: enterprise-паттерны)

redb экосистема В предыдущей статье я анонсировал redb.Route.Llm как 24-й транспорт redb.Route — мы делали LLM ещё одним endpoint'ом наравне с Kafka, RabbitMQ и HTTP, чтобы выкинуть отдельную «AI-инфраструктуру», стоящую рядом с интеграционной. Заодно я повесил в конец статьи «честный skip-list» — список того, что в 3.1.0 ещё не доделано: streaming, ToolCacheStore, KnowledgeStore, BatchStore, EvalRunStore, sliding-window память, sandbox-инструменты. Из этого skip-list'а делано больше, чем я планировал. Но не это главное. Главное — что в процессе доделывания обнаружилась настоящая ценность всей затеи: LLM-транспорт оказался не очередным чат-фреймворком, а недостающим звеном в ESB, после которого «бизнес-агент в проде» перестаёт быть отдельным проектом . Эта статья — про то, как чат-демо превращается в enterprise-агентскую платформу, не переписываясь и не превращаясь в «AI-монолит сбоку». Всё, что ниже — реальный код из репозитория, не псевдокод. Ссылки на демо-маршруты в конце.

https://habr.com/ru/articles/1046237/

#C# #NET #LLM #AI #агенты #tool_use #Apache_Camel #EIP #redbRoute #ESB

redb.Route 3.1.0 — LLM как ещё один транспорт: .To(«llm://claude») и .AsLlmTool()

Серия: redb ecosystem (анонс, разбор позже) В 3.1.0 у redb.Route вышло два новых транспорта : redb.Route.Llm (24-й) и redb.Route.Exec (25-й). LLM теперь — обычный endpoint наравне с Kafka, RabbitMQ и HTTP: вызов модели — это шаг .To("llm://claude") , инструмент агента — это маршрут с .AsLlmTool("shell") , периодический агент — From("llm://factory?schedule=5m") . Exec — спавнер процессов с allowlist, working-dir и таймаутом; работает и как backend shell-инструментов агента, и как самостоятельный scheduled consumer (cron-less health-probes, бэкапы и т.п.). Никаких «отдельных AI-фреймворков рядом с ESB»: всё внутри той же DSL, тех же retry/throttle/circuit-breaker/audit, тех же OpenTelemetry-трейсов. Это анонс. Подробный разбор внутренностей — отдельной статьёй позже. Здесь — что появилось, как это выглядит в коде, и что честно ещё не сделано. Если читаете про redb.Route впервые — короткий контекст из предыдущих статей серии: redb.Route — Apache Camel для .NET — зачем вообще, и почему «Apache Camel под .NET» redb.Route изнутри: четыре in-memory канала и Exchange — как устроен runtime redb.Route 3.0.1 — плоская навигация по DSL, рефакторинг CRTP и тихий null — предыдущий патч перед 3.1.0 Самое короткое объяснение From("kafka://orders") .To(Llm.Factory("claude").Temperature(0.2).MaxTokens(1024).AsUri()) .To("kafka://orders.translated");

https://habr.com/ru/articles/1045356/

#C# #NET #LLM #AI #агенты #tool_use #Apache_Camel #EIP #redbRoute #opensource

redb.Route изнутри: четыре in-memory канала и Exchange, который их связывает

Прошлая статья была обзорной — что такое redb.Route, зачем нам понадобился свой Apache Camel под .NET, как выглядит боевой маршрут. Если не читали, коротко: это fluent C# DSL для интеграции — 22 коннектора (~30 URI-схем, если считать https / wss / es -варианты), ~30 паттернов EIP нативно через 41 процессор , 8 in-process компонентов , компилируемый expression-движок. Сегодня заходим внутрь. Не список фич, а рабочий разбор. Серия будет длинной, поэтому сразу скажу, что и в каком порядке:

https://habr.com/ru/articles/1042872/

#C# #NET #ESB #EIP #Apache_Camel #redbRoute #seda #transactions #многопоточность #opensource

redb.Route — Apache Camel для .NET, который мы написали потому что выхода другого не было

У вас не 5 микросервисов — у вас десятки . Бэкенд, который рос три года: монолит, расколотый на куски, GPS-фид от автопарка, мобильное приложение водителя, веб-кабинет диспетчера, интеграции с SAP / 1С / регуляторами / маркетплейсами, отдельный SMTP-воркер, отдельный PDF-генератор, отдельный шедулер ночных пересчётов. Между ними — Kafka (несколько кластеров, по топику на домен), RabbitMQ (RPC + pub/sub + DLQ), Redis (кэш, last-known-state, pub/sub-каналы), пара HTTP-эндпоинтов наружу, SFTP с поставщиком, SQL-polling outbox-таблицы старого монолита, MQTT с трекеров, IBM MQ для одного древнего банковского контура, SignalR-хабы для real-time-дашбордов. На каждом стыке — свой ретрай, свой DLQ (или нет DLQ), своя сериализация, свои метрики (или нет метрик), своя бойлерплейт-обвязка из консьюмеров и try/catch . Каждый из этих стыков живёт своей жизнью в Program.cs соответствующего сервиса. Каждый — это hand-rolled цикл:

https://habr.com/ru/articles/1042392/

#C# #NET #ESB #EIP #Apache_Camel #Kafka #RabbitMQ #интеграции #opensource #redbRoute