Architecture 🚧 ​
DBS-Ticketing with Zammad ​
Citizens submit requests to the form server (e.g Meldung von Insektennestern), which sends the request to an off-the-shelf Zammad via the dbs-ticketing-eai. Zammad serves as the backend of the DBS, where the clerks process the requests and communicate with the citizen via our own frontend dbs-ticketing-webcomponents. This is integrated with Web Components into the official site of the City of Munich.
Data protection ​
As DBS also processes highly sensitive personal data, it is important that we ensure data protection. DBS does not send any information to applicants by e-mail, but only makes it accessible in its frontend dbs-ticketing-webcomponents
Reporting ​
As the Zammad Reports did not meet our reporting requirements, complex reports are created and made available via Metabase.
DBS-P13N ​
The checklist is generated by Kaptara Iason based on a query. The list of services is transferred to our personalization-webcomponents via local storage and citizens can view the calculated services there. They also have the option to save the checklist in their user profile (personalization-service) and edit it in the personalization-webcomponents.
DBS-Login (Authentication) ​
The authentication of applicants and administrators takes place via a Keycloak and not via Zammad. Keycloak uses two realms for this purpose:
- the realm
public, which manages citizens according to their trust level. - and the realm
muenchen.deto manage the city of Munich employees which are automatically created with their associated group structures (department, team, etc) with the zammad-ldap-sync, changed or removed if necessary. This ensures that only authorized persons have access to the pending requests from citizens.
Distribution view ​
The following picture (DRAFT) shows a more technical distribution view of the architecture, also including
- the namespaces in the container infrastructure
- the communication protocols
