Skip to content
Examples

MaMa-CRM arc42 section 7

Deployment View

7.1 Deployment Overview

It was a longstanding goal of MaMa to deploy and operate each MaMa campaign on a dedicated virtual machine, to clearly separate mandator specific data from other instances.

The operating-system level configuration and operation mode of these virtual machines and their host machine directly influences the level of security the campaigns have. These topics have to be subject of regular security inspections and reviews.

Due to the sensitive nature of data handled by the original MaMa system the owner required strict nondisclosure in that aspect. Therefore we are not allowed to go into any detail of security.

MaMa Deployment Overview

Element Description
Campaign-i Virtual machine for one single campaign.
   
Common Metadata Store Used only in eHealth campaigns to synchronize generation of CIN IDs (see below)
   
Campaign Configuration Workstation Workstation (standard PC running Java-enabled OS) used to configure campaigns.
   
CIN request Request for Common Insurance Number (see below)

7.2 Campaign Specific Virtual Machine

For every campaign operated by InDAC there will be a single dedicated virtual machine containing a database instance and all required MaMa code (except the graphical configuration UI).

7.3 Common Metadata Store (CoMeS)

The German government regulations for the eHealth card contained a very specific process to generate the “Common Insurance ID” (CID) for persons: This ID could only be generated by a single government entity (formerly the GPFunds, “Deutsche Rentenanstalt”, since 2012 the ISTG).

Requests for calculating the 10-digit CID have to be wrapped in a request envelope containing the following metadata:

  • Unique ID of the requesting entity (usually the tax ID number of the organization/company issueing the request.) MaMa needed to use the tax ID of the InDAC data center.
  • request purpose (for MaMa, a constant)
  • request sequence number (RSN)

This RSN needed to be an uninterrupted sequence of numbers, as GPFunds wanted to make sure it did not miss any request. For MaMa that implied some synchronization mechanism between otherwise independend virtual machines. We decided to implement the Common Metadata Store for this reason.

For security reasons MaMa did not use a real database for this purpose, but this custom-build synchronization solution.

7.4 Campaign Configuration Machine

One (or several) operator workstations (standard PC’s) will be used to configure MaMa instances after they have been physically deployed on their respective VMs.

The configuration UI is build as Eclipse RCP plugin.