Как расширять функционал

Данная статья - варианты переопределения какой-либо части функционала интеграции с ЭДО-провайдерами. Рекомендуется использовать их только при необычных требования на проектах заказчиков, а не на коробке. Практически все что тут будет - легальное переопределение бинов в спринге, расширение/обертывание каких-либо компонентов и тд.

При использовании других способов - просьба дополнять статью.

1. Кастомизация поиска контрагента и юр лица

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

Для переопределения рекомендуется унаследоваться от ru.citeck.ecos.integration.edi.counterparty.EdiCounterpartyServiceImpl или от ru.citeck.ecos.integration.edi.legalentity.EdiLegalEntityServiceImpl, имплементировать необходимую логику поиска/получения/задания под проект и после этого отметить ваш переопределяющий класс аннотациями @Primary и @Service. Можно не наследоваться, а расширить полностью интерфейсы, которые расширяют эти классы, но сложно придумать кейс, в котором придется полностью переделывать абсолютно все, а не только часть существующего функционала.

Посмотреть пример можно в проекте ecos-ssg-edi, ru.citeck.ecos.ssg.service.integration.edi.counterparty.SsgEdiCounterpartyService.

2. Кастомизация варианта создания пакетов в alfresco

По умолчанию, что старая реализация интеграции с ЭДО-провайдерами, что вынесенная в микросервис интеграции (в данном случае речь идет о функционале в либе ecos-edi-integration) - создает при получении нового входяшего пакета с документами - ноду типа sam:inboundPackage. При создании такого пакета в альфреско - подключается ru.citeck.ecos.behaviour.AbstractIncomePackageProcessor, а точнее, его конкретная реализация.

К сожалению, сейчас все работает таким образом, что нам обязательно нужна реализация для того чтобы реагировать на создаваемые пакеты, но испокон веков все сложилось так, что пустую реализацию, просто “чтоб все работало” перенесли в finance модуль. Так что, если хочется и пользоваться finance и переопределить - придется придумать как обойти такой подход. Главное, чтобы не срабатывало 2 бихейвиора на создание пакета, следите обязательно за этим, приведет к плавающим багам.

Пример: ecos-ssg-edi, ru.citeck.ecos.ssg.service.integration.inbound.SsgIncomePackageProcessor, где мы создаем кейс из входящего пакета, а не задачу разбора входящих.

3. Переопределение обработки событий от ЭДО-провайдеров (Camel)

Данный подход - создание обертывающего роута в каком-либо из бандлов OSGI и указание в виде Camel эндпоинта для отправки событий в конкретных синхронизациях ЭДО-провайдеров - нашего обертывающего эндпоинта.

Это может выглядеть так:

Уточняю, отправка событий в alfresco способом, который реализован в оригинальным роуте в ecos-edi-integration является условно идемпотентной операцией. То есть, сколько бы раз мы не обработали одно и то же событие, мы должны прийти по результату каждый раз к одному и тому же состоянию.

Условная идемпотентность из-за того, что мы рассчитываем статусы пакетов исходя из текущего состояние документов в альфреско и состояний документов, которые изменились в событии.

4. Расширение способов генерации печатных форм и иных служебных документов

Если интересует использование другого способа генерации ПФ, титула покупателя/продавца или еще чего-то, можно зарегистрировать по определенному ключу в мкр интеграции (можно через бандл) свой генератор конкретного интерфейса и использовать его. Контур и СБИС бандлы передают генерацию генератору, найденному по ключу, так что, это рабочая схема. Стандартный ключ нужно только переопределить в EcosEdiService в альфреске при передаче команды в мкр интеграции.

Способ зарегистрировать свой генератор:

Написать свой генератор. Генератор должен расширять один из интерфейсов в либе ecos-edi-commons, которые располагаются в пакете ru.citeck.ecos.domain.edi.service.generator.interfaces.

Получить из контекста спринга экземпляр ru.citeck.ecos.domain.edi.service.generator.EdiGeneratorResolver. Вызвать для своего генератора метод register с указанием ключа.

Как уже писал выше, запросы необходимо передавать с конкретным ключом, для того чтоб запрос на генерацию попал в ваш генератор. Для всех команд на генерацию есть такое поле, его и надо заполнять при переопределении в alfresco EcosEdiService. Примеры в dto этого поля ниже:

public class GeneratePrintFormRequest {
    private OurId ourId;
    private DocunentEdildentifier_documentEdiId;
    private String printForméenerationControllerid;
    private ObjectData data;

public class RejectionxmlRequest {
    private DocunentEdildentifier documentEdiId;
    private OurId ourId;
    private String comment;
    private String [rejectionsenerationcontrovlerld;
    private ObjectData data;

5. Переопределение EcosEdiService для добавления дополнительных флагов в случае необходимости

Для случаев, когда необходимо как-то по особому выполнять какую-то операцию. Например, в теории, можно переопределить генерацию титула покупателя, вызвав сначала super метод, а позже изменить значения в xml на те, которые необходимы данному проекту. Либо, использовать какой-то конкретный конвертер, специфичный для проекта (см. п. 4).

Аналогично первому пункту, тут про переопределение бина в спринге за счет приоритезации при autowiring с помощью аннотации @Primary. Только на этот раз - это класс ru.citeck.ecos.integration.edi.service.EcosEdiServiceImpl

Пример: ecos-ssg-edi, ru.citeck.ecos.ssg.service.integration.SsgEcosEdiService