Implementing integration with a new EDI provider

1. From the EDI provider handling bundle side (integrations microservice)

Create a Java project with a bundle. An example of creating a new bundle can be found here: Bundle creation example.

This project must import the dependency ru.citeck.ecos.ecos-edi-commons. The version must match the one in the integrations microservice of the version you require.

In the activator (class implementing org.osgi.framework.BundleActivator), you need to register your implementations of ru.citeck.ecos.domain.edi.service.sync.EdiEventsSyncService and ru.citeck.ecos.domain.edi.service.api.EdiApiService in the beans of the integrations microservice. Example from Kontur (don’t forget to perform unregister(…) when unloading the bundle):

EdiEventsSyncServiceResolver ediEventsSyncServiceResolver = ApplicationContextReflection.getBean(EdiEventsSyncServiceResolver.class);
MandatoryParam.check("ediEventsSyncServiceResolver", ediEventsSyncServiceResolver);
ediEventsSyncServiceResolver.register(getKonturEventsSyncService()); // в методе get* происходит ленивое создание сервиса

EdiApiServiceResolver ediApiServiceResolver = ApplicationContextReflection.getBean(EdiApiServiceResolver.class);
MandatoryParam.check("ediApiServiceResolver", ediApiServiceResolver);
ediApiServiceResolver.register(getKonturEdiApiService()); // в методе get* происходит ленивое создание сервиса

After this step, requests to your EDI provider within these interfaces will be translated to your service.

In the currently existing bundles, you can also find examples of registering a listener for data changes related to a specific box (box entity, credentials, data source). Can be used for clearing caches inside the bundle.

If your provider is not present in the enum ru.citeck.ecos.domain.edi.dto.enums.EdiProviderType of the ecos-edi-commons library, it will be necessary to add it.

2. From the connecting library ecos-edi-integration side (integrations microservice)

No matter how much we’d like to fully unify the processing of one EDI provider from another, it’s not possible. Different attributes for identifiers, slightly different search policies, etc.

Therefore, a small interface ru.citeck.ecos.edi.domain.integration.service.provider.ProviderHandler was created on the ecos-edi-integration side, which performs actions to search for records in Alfresco (currently in Alfresco).

The implementation for the new provider needs to be registered. This is done simply in ru.citeck.ecos.edi.domain.integration.factory.ApplicationCamelContextFactoryImpl#createProviderResolver:

QOverride
protected ProviderResolver createProviderResolver() {
return new ProviderResolver(
ew CopyOnliriteArrayList<>(Arrays.asList(
new KonturProviderHandLer(getSignatureService(), getEcosConfigService()),
new CorusProviderHandler(),,
new SbisProviderHandler())));

3. From the repository side (Alfresco)

Currently, the repository is Alfresco. It can be changed if a similar option is available, by reworking only the ecos-edi-integration library or creating a similar one for a specific repository.

  1. Create an aspect for storing document identifiers (signatures, in the case of some providers).

  2. Register your implementation of ru.citeck.ecos.integration.edi.documents.identifiers.EdiIdentifiersProvider in ru.citeck.ecos.integration.edi.documents.identifiers.EdiIdentifiersProviderRegistry. If you inherit from ru.citeck.ecos.integration.edi.documents.identifiers.AbstractEdiIdentifiersProvider, then registration during bean initialization will happen automatically via @PostConstruct.

This service is necessary for generating printed forms (checking the existence of EDI identifiers on nodes) and for determining the EDI document type (not to be confused with UZDO).

  1. Register your implementation of ru.citeck.ecos.integration.edi.documents.titles.TitleTypeService in ru.citeck.ecos.integration.edi.documents.titles.TitleTypeServiceRegistry. If you inherit from ru.citeck.ecos.integration.edi.documents.titles.AbstractTitleTypeService, then registration during bean initialization will happen automatically via @PostConstruct.

This service is necessary when signing UZDO (Legal Entity Document Flow). It determines whether it is necessary to generate and sign the document title or if the signature of the attachment itself is sufficient.

  1. The most essential part is preparing requests and post-processing responses. The custom part of this process is handled by ru.citeck.ecos.integration.edi.service.EdiProviderHelper, which is delegated the task of composing DTOs that will be sent to the microservice and, subsequently, to the bundle. As with other services, you need to register your component in its registry; like the other services, there is an auto-registering ru.citeck.ecos.integration.edi.service.AbstractEdiProviderHelper. It’s better to use it, as part of the class functionality is already implemented there.