SEMDA is not a simple pass-through service.
It provides advanced and simpler integration services than the native RI
services.
The RI-API is strictly synchronous.
Consequently, the Local CMS are dependent
on the availability and performance of the RI systems. This is cumbersome,
because the Local CMS are designed as interactive systems used by several
thousand users concurrently. SEMDA provides asynchronous services to the Local
CMS and makes it independent on RI.
The target RI systems are very complex and have long response times. Data passed to RI is validated in the target systems. This causes even longer response and unpredictable processing times. For
the Local CMS it is difficult to receive errors at a later stage.
SEMDA validates request data and reports validation errors before RI-API is
invoked. This allows Local CMS to implement state of the art error handling and notification service.
This massively reduces the support overhead, because users are notified
directly.
The granularity of the RI-API is given by
the internal structures of RI data. This has an impact on the Local CMS
implementation of the interface and requires mapping and restructuring of the date sent to RI. SEMDA API uses services operating on simple and common objects
instead.
The RI-API
itself has changed several
times in the past and will change soon again. Local CMS systems will have to
adapt quickly to the new API in due time. When this happens, SEMDA will adapt
the gateway, but keep the API to the local CMS compatible for as long as
possible. Of course, new functions may be introduced with new SEMDA versions.
RI-API is granular and requires multiple requests to be issued for certain functions. SEMDA provides advanced services by
combining various RI services and consolidates the response to the Local CMS.
This does massively simplify the integration into the Local CMS.
The usage of the RI-API requires
certification of the corresponding Local CMS by the RI authorities. This
requires substantial effort and costs. SEMDA validates requests received from Local CMS, but is not responsible for bad data sent through it. SEMDA requires only a simplified proof of technical functions with the connected Local CMS.
However, the same security and data protection measures must be fulfilled by all Local CMS systems. This means similar contracts as with RI must be signed between the Local CMS and RCS.
