SEMDA Vendor Names

The vendor names follow the convention "SEMDA <CMS-name> <country-code>".

SEMDA Vendor Name	Districts
SEMDA Polaris AT&BIH	Districts: D-1910, D-1920
SEMDA Polaris BE&LUX	Districts: D-2130, D-2140, D-2150, D-2160
SEMDA Polaris CH&FL	Districts: D-1980, D-1990, D-2000
SEMDA Polaris ES	District: D-2202
SEMDA Polaris FR	Districts: D-1520, D-1650, D-1680, D-1690, D-1710, D-1740, D-1790
SEMDA Polaris IS	District: D-1360
SEMDA Polaris SE	Districts: D-2335, D-2355, D2405
SEMDA RoCas DE	All Districts: Rotary Germany
SEMDA Aurora DE	All Districts: Rotaract Germany
SEMDA Kiosk IT	District: D-2032
SEMDA Gero IT	Districts: D-2041, D-2042
SEMDA romeo FI	All Districts Finland
SEMDA LEAD NL	All Districts Netherlands
SEMDA TRIO KE	District: D-9212

For new customers having a new Local CMS using SEMDA, {{glossary.RCS}} will request RI to create a new vendor.

Vendor configuration at Rotary International

The vendor must be correctly configured for each club at Rotary International. Only the club secretary or executive secretary can do this.
For each club only one vendor with access view-update and several vendors with access view-only can be configured. If SEMDA is used for updating information stored in Rotary International, then view-update access must be set.

Read the instructions how to set vendor in RI

Authorization

The authorization to use the SEMDA systems is issued by the {{glossary.RCS}}. Respective product contract and SLA must be signed. {{glossary.RCS}} will then pass the required unique authentication key to the Local CMS. This key must be used for the connection to SEMDA and in all requests. This key represents a confidential information and must not be shared with any other CMS.

Authentication

Each request from Local CMS to SEMDA must contain a unique authentication key which identifies the Local CMS. This authentication key is created by the {{glossary.RCS}} and passed to the Local CMS after contract and SLA have been signed. Request without valid authentication key are discarded.

Access and encryption

Access to SEMDA is possible only through https protocol.

All data in transfer between Local CMS and SEMDA and between SEMDA and RI is encrypted.

Data security

SEMDA does not have persistent storage like a database. It uses a reliable message broker (RabbitMQ) to temporarily store requests from various Local CMS. The requests are managed in a queue, assigned to each particular Local CMS. The request data is automatically destroyed when a request has been processed. The reliability feature of RabbitMQ ensures that the system survives a power failure or software crash without loss of data.

The access to the request data is possible only through the programmatic components of SEMDA.

There is no interface (GUI) or tool available to show the request data for SEMDA customers.

SEMDA fulfills the highest security requirements because:

No data is persistently stored in SEMDA
No data is exposed to a user interface or an interactive tool.
Data related to a particular Local CMS is separated and isolated from all other connected systems.
The data exchanged between the particular Local CMS and RI is not passed to any other system.