-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Мы пишем кастомный сервер, называемый FAE (fake adapter engine), который регистрируется в SLD/RWB центрального адаптера, получает обновления кэша и прикидывается для головы родными ногами, с ограничениями:
- Голова не видит мониторинга FAE
- Голова не считает Performance Monitor FAE
- FAE не эмулирует стандартные адаптеры, вместо этого используется CamelAdapter для указания, что вписывать в маршруты
Помимо FAE, также пишется FESR (fake ESR), который должен быть сервером схем данных, доступным из абапов по SimpleQuery в SM59 SAP_PROXY_ESR, но работать на новых принципах (брать XSD/WSDL из файловой системы или объекты других ESR, конвертить не-XMLные схемы данных в XMLные для абаперов).
И FAE, и FESR это бэкенды с минимумом UI/UX, безумной задачи сделать "свой редактор графического меппинга" не стоит.
Видение продукта изложено в Верблюдизация v1.pdf.
Зачем такой странный подход? Ведь есть WSO2, Mule, RedMule, Camel-K, Camel/Quarkus, Camel/Spring, Entaxy, 1С:шина, а тут самопис галимый!
В мире столько корявых недоделанных шин, что надо срочно увеличить их количество! ;-)
Изначально идея мелкотравчатая - по-быстрому написать создание кэмельных маршрутов под прикладные задачи, которые сложно делать в SAP PO и чтобы постепенно сваливать с него, плавно и гибридно. Задача №1, акцептованная руководством, выглядит так:
- Читаем из кафки кэмелом подписанные топики
- Avro+Schema registry превращается в JSON
- JSON мепится в уже существующие ABAP Proxy
- XML отправляется по XI31-протоколу либо в абопы напрямую, либо через SAP PO (но тоже XI31)
Кафки на проекте становится всё больше, отправка в кафку сделана через обычный PO REST Receiver + Confluent REST Proxy, схемы и сообщения генерятся груви меппингом, там всё просто, а чтение из кафки сейчас сделано в Apache NIFI, что мне не очень (длинное плечо передачи, стрёмная инсталляция nifi на проекте, для меппинга в шине приходится делать груви если из жсон или REST-канал, а там артефакты трансляции бывают).
Сперва был реализован XI31-протокол, в данном проекте есть средства работы с ним. Поначалу я хотел просто обернуть протокол в компоненты кэмела-4 и на этом часть работы сделана, остаётся в каком-то виде кэмел гонять и писать прикладные мониторинги, шлифовать отказоустойчивость и тд.
Эти маршруты достаточно просто написать в кэмеле но получается что абап-прокси будут в кэмеле "в голове у разработчика", без инструментальной поддержки. Плюс, изменение имени топика и конфигурируемых параметров придётся делать в кубере скажем или в пропертях, а можно же переиспользовать билдер и икохи для стандартного пайплайна, на котором под 80% всей интеграции сделано. Поэтому и возникла сперва идея FAE, а затем и FESR.
Я за! добавляйте, помогу. Коллеги в Атом.Мосте это уже сделали (до меня), такой подход я приветствую.
Предполагается что FAE может генерить кэмельные маршруты в XML DSL или YAML. Как вариант вы можете их смотреть глазками для документации и эстетического чувства прекрасного будующего.
Коллеги с других проектов также делают разные самописы, известный банк выбрал Factor-ESB, атомщики - Атом.Мост, остальные выжидают, так как сам по себе SAP PO внезапно не пропадает.
А может не трогать ничего? Доживёт SAP PO лет 10 ещё, а там и абапы заменят, и будет PO+ERP+HCM как архивная система read-only
Подход разумный, вполне имеет быть как в России, так и за пределами (так как поддержке SAP PO скоро кирдык в мировом масштабе). Но глядя на недо-шины где ты пишешь руками XSD и свалку ендпоинтов а-ля CPI, хочется нормально привившиеся практики адресации и ESR как-то переиспользовать. Сам вендор на эти концепции забил, поэтому "не трогать ничего" означает просто скатиться в макароны микросервисов.
- XI-протокол уже наш
- Регистрация FAE в SLD сделана в юнит-тесте и запускается одним кликом, дальше можно детали шлифовать
- Обновления кэша AE удалось реализовать на отладочном макете, то есть ручных процедур нет
- Так как задача выполнять графические меппинги пока осторожно не ставится, то для начала можно выполнять XSLT и JAR с оговоренными меппингами, либо делать в ESR OM'ки-пустышки с параметром "ссылка на Mapping Runtime", или прописывать ссылки на меппинги в сендерах и ресиверах. Либо внешний реестр меппингов со ссылками на текущие партии|системы и интерфейсы, который FAE будет использовать
На нашем проекте уже реализована похожая задача, когда гениальный коллега сделал наземный мониторинг для наземного CIC неотличимый в целом от облачного, примерно за полтора месяца при спешной миграции с SAP CPI на землю.
Так как у нас есть эластик и реляционка для прикладного мониторинга, мы можем складывать пейлоады и журналы в эти уважаемые продукты, а фронтенды просмотра делать потихоньку-полегоньку, вплоть до быстрой копии SXI_MONITOR на абапе с native sql в неродную БД за пару недель, тогда браузерный фронтенд будет менее насущным.
- В FAE можно будет кафкианстовать, плодить кроликов, другое транспортное протокольное
- JVM 17+ и никакого старья. Скорее всего Quarkus 3 и Camel 4
- ГОСТ TLS, шифры, ЭЦП
- git, CI/CD, автотесты
- Containers first
В новых метаданных каналов предусмотрены поля ввода для ссылок на документацию, на CMDB и возможно будет какая-то информация для отправки алертов, бюджетирования затрат на интеграцию при расчётах внутри холдинга, и иные отсутствующие ныне в шине не-технические атрибуты. Вероятно, эти данные будут в кастомном мониторинге и в отчётах по конфигурации и статистике.
А вот - НАДЁЖНОСТЬ! в SAP PO всё супер надёжно, кластера, болгары и индусы писали 10+ лет. В других платных шинах может и коряво по разработке но рантайм вылизан. А у нас ритейл на сотни мильонов сообщений в день, так что не подойдёт.
Оставив в стороне более-менее надёжный Camel, гарантия доставки и рестарты в FAE будут сделаны вероятно через ActiveMQ Apache Artemis или что-то подобное. Пусть помедленнее чем где-то но за хайлоадом не гонюсь.
Зарплату мне за FAE не платят, так что присылайте сумасбродные идеи -- if any, может и пришью сбоку. Аминь.