Designing an integration gateway between EDMS and external EDMS
When building end-to-end document workflows, a common situation arises where an internal contract is successfully approved in the internal system, but its status does not update automatically after being sent to the counterparty. This gap forces users to manually check external provider portals and creates risks of using outdated document versions. Building a reliable gateway between an internal electronic document management system and an external one requires solving a series of engineering tasks related to status synchronization, signature validation, and long-term data preservation.
Architectural features of combining document workflow circuits
Most enterprises use isolated systems for internal approval and external exchange. Attempting to connect them via a simple synchronous point-to-point connection often leads to failures. If the external service is temporarily unavailable, the internal system may not receive updates, which disrupts the business process sequence. This creates additional load on the support team and slows down deal closures.
To solve this problem, an architect must design an integration gateway that separates the systems' areas of responsibility. The choice between synchronous and asynchronous exchange should be based on document volumes and acceptable user wait times. Synchronous exchange is suitable for operations where receiving an immediate response is critical, while an asynchronous approach allows isolating systems from the temporary unavailability of adjacent services. Stability also depends on queue capacity, retry rules, and failure control.
- Synchronous interaction via API
Returns the result within the current request but requires constant availability of both integrated systems.
- Asynchronous exchange via queues
Allows accumulating messages during temporary receiver unavailability, reducing rigid system dependency.
- Periodic polling
Used for systems that do not support event notifications, but creates additional load.
- Event notifications (Webhooks)
Allow prompt reaction to document status changes on the external provider's side.
Technical aspects of electronic signature verification
According to Ukrainian legislation, a qualified electronic signature has the same legal force as a handwritten signature, provided a qualified public key certificate and special tools are used. During integration, it is important to ensure signature verification for compliance with interoperability and technological neutrality requirements.
Signature verification is performed according to the applicable validation policy. In this process, the signature itself, the signer's authority, and the time proof are separate entities that require individual verification. An expired current certificate does not automatically mean the invalidity of a signature applied during its validity period, provided a time proof was recorded at the moment of signing. Therefore, the gateway architecture must correctly handle historical data and not require re-signing of original documents. Any attempts at automatic re-signing may lead to the loss of primary evidence.
- Verification by validation policy
Defining signature verification rules according to the requirements of a specific business area or regulator.
- Analysis of separate evidence
Separate verification of the signature's mathematical integrity, the person's authority, and timestamps.
- Handling historical certificates
Validation of signatures created in the past without mandatory re-signing of original files.
- Preserving original bytes
Ensuring the immutability of the signed file and associated metadata during transport.
Organization of message queues and retries
Temporary unavailability of an external provider should not lead to automatic data loss. To ensure reliability, the integration gateway must use message queues with support for durability, processing idempotence, and reconciliation mechanisms. It is necessary to verify message persistence after restarts, limit retries, and provide for manual resolution of unrecoverable errors.
Using Webhook technology facilitates receiving notifications, but it does not eliminate the need for periodic reconciliation of statuses. Not all external APIs support Webhooks, and network failures can lead to the loss of individual messages. Therefore, the gateway must combine an event-driven model with background reconciliation processes to detect discrepancies in document statuses between internal and external systems. Such a combined approach minimizes the risks of data desynchronization.
Features of long-term electronic document storage
Organizing long-term storage of electronic documents requires maintaining their integrity, authenticity, and accessibility throughout the entire specified period. Archival timestamps themselves do not prevent file modification; they only record the state of data at a certain moment. To preserve the evidentiary base, it is necessary to ensure the preservation of the document's original bytes, applied signatures, and historical verification evidence.
The evidence update policy depends on the chosen storage format and is not universal (for example, the CAdES-A format is not used in all scenarios). Furthermore, using the PDF/A format does not guarantee document readability forever in any environment, so one should not impose mandatory conversion of signed originals into other formats if it might damage the integrity of the signature itself. Preserving the original binary representation of the file is a priority task for the archival module.
Risk analysis when choosing integration solutions
When designing a gateway, developers often face a choice between ready-made connectors and developing a custom solution. It is important to consider that no ready-made solution provides absolute guarantees of the legal force of documents, compatibility with all future versions of external systems, or guaranteed reduction in implementation time. Each integration requires an individual analysis of business processes and technical constraints.
Recommendations for choosing an architecture should be based on security risk assessment, scalability requirements, and the ability to support the system in-house. Building a gateway based on open standards and technologically neutral solutions allows reducing dependence on specific service providers and ensuring flexibility when changing external EDMS providers. This also simplifies future system modernization when business requirements change.
Methods of periodic reconciliation and consistency control
To ensure data consistency between internal and external circuits, it is necessary to implement regular reconciliation procedures. This allows detecting documents that changed their status on the counterparty's side but were not updated in the internal system due to network failures or queue processing errors.
The reconciliation process should run in the background on a schedule. It analyzes the identifiers of documents in transit statuses and requests their current state via the external provider's API. This approach compensates for the limitations of the event-driven model and helps detect discrepancies; unresolved errors should be displayed to responsible employees. The frequency of runs is determined by business requirements for data timeliness.
FAQ
How to minimize engineering risks when losing connection with an external EDMS provider?
To reduce the risks of message loss, the gateway should use queues with support for idempotence and state persistence (durability). In case of failure, requests are accumulated in the queue and processed again after the connection is restored. It is also mandatory to implement a mechanism for periodic status reconciliation via API.
How to ensure signature format compatibility when integrating different systems?
Compatibility is checked for specific formats, trust service providers, and library versions. The test suite must include supported signature variants, proper time proofs, and invalid documents. Declarations of an open standard are insufficient without practical verification.
How is historical QES verification performed after a certificate expires?
Historical verification is based on analyzing stored time proofs and certificate statuses at the time of signing. For this, the archive must store the corresponding OCSP responses or CRL lists along with the original document, which confirm the certificate's validity at the moment of signing.
