// stack · schnittstelle
GRÜN eVEWA4 ist die Branchensoftware für Non-Profit-Organisationen, Verbände und Bildungsanbieter — Mitglieder, Spenden, Seminare und Rechnungen liegen dort in einem System. Für siteway teilt sich die Anbindung an genau einer Linie: Was öffentlich ist, spiegeln wir ins CMS — Seminartermine, Veranstaltungen, Kursbeschreibungen. Was personenbezogen ist, läuft live und geschützt über einen serverseitigen Endpunkt und wird nie zwischengelagert. Diese Seite beschreibt, wie wir diese Verbindung bauen.
// definition
GRÜN eVEWA4 ist eine webbasierte Branchensoftware der GRÜN Software Group GmbH aus Aachen. Der Hersteller beschreibt sie als Lösung, mit der sich umfassende Geschäftsprozesse in Non-Profit-Organisationen sowie bei Bildungs- und Seminaranbietern abwickeln lassen. Sie läuft im Browser und ist nach Angaben des Herstellers als Vor-Ort-Installation ebenso zu beziehen wie als Software as a Service aus dessen Cloud.
Drei Bereiche stehen im Vordergrund. Die Online-Mitgliederverwaltung adressiert Vereine und Verbände, Gewerkschaften, Parteien und Kammern und bringt Mitglieder-Akte, Beziehungsmanagement, Beitragsordnung, Beitrags-Zuordnung und -Veranlagung sowie Abrechnungs- und Mahnwesen mit, dazu ein Mandanten- und Gliederungs-Management für mehrstufige Organisationen. Die Online-Spendenverwaltung deckt den Weg von der Online-Spende bis zur Abrechnung ab. Die Online-Seminarverwaltung dient laut Hersteller der Planung, Durchführung und Abrechnung von Veranstaltungen und Seminaren jeder Art — mit grafischer Belegungsplanung, Veranstaltungskalender, Verwaltung von Dozenten, Räumen und Ressourcen sowie Rechnungs- und Mahnwesen.
Für eine Website zählt daraus vor allem eines: Es ist klar, wo die führenden Daten liegen. Mitglieder, Spenden, Termine und Rechnungen stehen in eVEWA4 — nicht im CMS. Und der Hersteller nennt für die Anbindung Dritter Webservices auf Basis von REST-Technologie, ausdrücklich mit Content-Management-Systemen wie TYPO3 oder WordPress als Beispiel. Damit ist die Mitgliederliste keine Excel-Datei mehr, die jemand zweimal im Jahr exportiert, sondern eine Schnittstelle, an der man bauen kann.
// praxis
öffentlich spiegeln · persönlich live
Die wichtigste Entscheidung fällt vor der ersten Zeile Code, und sie ist bei einer Verbands- oder Seminarsoftware eine andere als bei einem Warenwirtschaftssystem: Hier hängt an fast jedem Datensatz eine Person. Deshalb ziehen wir eine Linie mitten durch die Anbindung. Öffentliche Inhalte werden gespiegelt — sie sollen schnell sein, in der Suche auftauchen und auch dann noch dastehen, wenn das Fachsystem gewartet wird. Personenbezogene Daten werden nie gespiegelt, sondern im Moment der Anzeige serverseitig geholt. Aus dieser einen Linie ergeben sich drei Anwendungsfälle, die in fast jedem Projekt vorkommen.
// fall-01öffentlich
Der Kalender ist der sichtbarste Teil der Anbindung. Ein geplanter Lauf holt Termine, Kursbeschreibungen, Orte, Dozenten und freie Plätze aus eVEWA4 und legt sie als eigene Inhaltsart im CMS ab. Ausgeliefert wird aus dem eigenen Bestand: Liste mit Filter, Detailseite mit dauerhafter URL, strukturierte Daten für Veranstaltungen. Am Ende der Detailseite steht die Anmeldestrecke — und die schreibt zurück.
// fall-02geschützt
Stammdaten ändern, den Beitragsstand einsehen, Rechnungen und Teilnahmebescheinigungen herunterladen: Das sind personenbezogene Daten, und sie werden nicht gespiegelt. Nach dem Login fragt der Server sie zu genau dieser einen Person live im Fachsystem ab und liefert die Antwort direkt an den angemeldeten Browser aus — ohne Zwischenlager im CMS, ohne Suchindex, ohne öffentlichen Cache.
// fall-03rückweg
Spendenformular, Beitrittserklärung, Seminaranmeldung: Was auf der Website entsteht, soll in der Geschäftsstelle ankommen — als Vorgang im Fachsystem, nicht als E-Mail, die jemand abtippt. Das Formular schickt serverseitig, das Mapping ist vorher festgelegt, und für den Fall, dass die Schnittstelle schweigt, gibt es einen zweiten Weg. Eine Spende darf nie an einer Zeitüberschreitung scheitern.
Am Anfang steht eine Sichtung, nicht der Code. Welche Wege sind für eure Installation freigeschaltet, welche Felder liefert die Quelle, wie wird authentifiziert, welche Vorgänge dürfen schreibend angelegt werden? Diese Fragen klären wir vorab mit dem Hersteller beziehungsweise mit der Stelle, die eure Installation betreut. Erst danach entsteht das Feld-Mapping als Dokument: Welches Feld aus dem Fachsystem geht auf welches Feld der Website, was ist Pflicht, was bleibt optional — und was verlässt das Haus gar nicht erst.
Für die gespiegelte Seite brauchen wir einen Schlüssel: eine stabile Kennung je Termin, über die der nächste Lauf denselben Datensatz wiedererkennt und aktualisiert, statt eine Dublette anzulegen. Über denselben Schlüssel läuft auch das Gegenteil — ein Termin, der im Fachsystem verschwindet, muss auf der Website verschwinden oder sauber als abgelaufen markiert werden, samt Regel für die URL, die dann ins Leere zeigt.
Bilder und Dokumente ziehen wir beim Abgleich auf den eigenen Server, statt sie live aus dem Fachsystem zu verlinken. Danach laufen sie durch dieselbe Bildpipeline wie der Rest der Website — skaliert, als AVIF und WebP ausgespielt, mit Maßen im Markup. Für Unterlagen, die nur angemeldete Teilnehmer sehen dürfen, gilt das ausdrücklich nicht: Die bleiben hinter der Zugriffsprüfung und werden bei Bedarf durchgereicht, nie ungeschützt abgelegt.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Antwortet die Schnittstelle nicht oder unvollständig, bleibt der letzte gute Stand des Kalenders stehen, der Lauf wird protokolliert und mit Abstand erneut versucht. Ein abgebrochener Abgleich darf nie eine leere Terminliste erzeugen. Auf der geschützten Seite gilt die umgekehrte Regel: Kommt keine Antwort, zeigt die Seite einen klar formulierten Hinweis — und nicht einen veralteten Beitragsstand aus einem Cache.
// technik · 6 details
belegtes vom hersteller, gebautes von uns
Zur Schnittstelle nennt der Hersteller öffentlich Webservices auf Basis von REST-Technologie für die Anbindung von Drittanwendungen, ausdrücklich mit Newsletter-Systemen und Content-Management-Systemen wie TYPO3 oder WordPress als Beispiel. Eine frei zugängliche Entwicklerdokumentation mit Endpunkten, Feldnamen, Authentifizierungsverfahren oder Abfragegrenzen gibt es öffentlich nicht — für technische Details verweist der Hersteller auf den direkten Kontakt und seine Kundenplattform. Deshalb steht hier keine erfundene Feldliste, sondern das Vorgehen: Der freigeschaltete Weg wird vorab geklärt, und die Schnittstelle wird bis dahin als knappe Ressource behandelt — bündeln, zwischenspeichern, nur nachladen, was sich geändert hat.
// d-01zugang
Am Anfang steht die Frage, welcher Weg für eure Installation überhaupt offen ist — und mit welchen Rechten. Die Website bekommt dafür einen eigenen technischen Zugang mit genau dem Ausschnitt an Rechten, den sie braucht: lesend für die öffentlichen Termine, gezielt lesend für den geschützten Bereich, schreibend nur für die Vorgänge, die sie tatsächlich anlegen darf. Die Zugangsdaten liegen in der Konfiguration des Servers, nie im Repository und nie im Browser.
zweck: authentifizierung
// d-02spiegel
Ein Lauf im Hintergrund holt die öffentlichen Termine im festen Takt und schreibt sie in das Datenmodell des CMS. Er arbeitet idempotent: gleicher Schlüssel, gleicher Datensatz — angelegt beim ersten Mal, aktualisiert danach. Der Takt richtet sich nach der Praxis, nicht nach dem Gefühl: Ein Kursprogramm, das quartalsweise erscheint, braucht keinen Abgleich im Minutenrhythmus.
zweck: öffentliche inhalte
// d-03live
Für den geschützten Teil bauen wir eine eigene Route auf dem Server. Sie prüft zuerst die Sitzung und die Rolle, fragt dann genau die Daten der angemeldeten Person im Fachsystem ab und gibt nur diese zurück. Kein Aufruf geht aus dem Browser direkt ins Fachsystem, keine Kennung aus dem Aufruf entscheidet allein darüber, wessen Daten geliefert werden. Zeitlimit, Wiederholung und eine definierte Anzeige ohne Antwort gehören dazu.
zweck: personenbezogene daten
// d-04rückweg
Der Rückweg schreibt, was auf der Website entsteht. Er läuft ausschließlich serverseitig, prüft vorher fachlich — ist der Termin noch buchbar, ist das Kontingent frei — und legt danach den Vorgang an. Doppelte Absendungen fängt ein Vorgangsschlüssel ab, damit aus einem hektischen zweiten Klick keine zweite Anmeldung wird. Welche Vorgangsarten schreibend erlaubt sind, ergibt sich aus der Freischaltung.
zweck: vorgang ins fachsystem
// d-05mapping
Das Mapping ist ein Dokument, kein Kommentar im Code. Es hält fest, welches Feld auf welches geht, welches Format erwartet wird, was Pflicht ist — und was ausdrücklich nicht übertragen wird. Interne Vermerke, Bonitätsangaben, Gremienzugehörigkeiten oder Notizen aus der Mitglieder-Akte gehören nicht auf eine öffentliche Website. Der Schlüssel je Termin steht ebenfalls dort, weil an ihm Aktualisierung und Löschung hängen.
zweck: datensparsamkeit
// d-06betrieb
Jeder Lauf hinterlässt eine Spur: Wann lief er, wie viele Datensätze kamen an, was ist fehlgeschlagen. Bleibt ein Abgleich mehrfach hintereinander aus, meldet sich das Monitoring, statt dass es jemandem Wochen später am leeren Kalender auffällt. Personenbezogene Nutzdaten stehen dabei nicht im Protokoll — dort steht, dass ein Vorgang lief, nicht wer darin vorkam.
zweck: nachvollziehbarkeit
Aus den gespiegelten Terminen wird kein Datenbank-Auszug, sondern eine Website. Der Veranstaltungskalender filtert über die Felder aus dem Mapping — Thema, Zeitraum, Ort, Format —, arbeitet auf dem eigenen Bestand und braucht dafür keine Wartezeit auf ein fremdes System. Die Detailseite bekommt eine sprechende, dauerhafte URL, die Eckdaten als Tabelle, das Programm als Download und strukturierte Daten aus denselben Feldern, damit ein Termin in der Suche als eigenes Ergebnis erscheinen kann.
Darunter steht die Anmeldestrecke — vorbelegt mit der Kennung des Termins, damit in der Geschäftsstelle sofort klar ist, worum es geht. Ob daraus eine reine Anmeldung wird oder ein Vorgang mit Zahlung, entscheidet das Angebot, nicht die Technik. Für wiederkehrende Mitglieder kommt ein Mitgliederbereich dazu, für Organisationen mit vielen Selbstauskünften ein Self-Service-Portal — beides hinter Login, beides serverseitig abgefragt.
Die Redaktion behält dabei ihren Platz. Neben den gespiegelten Feldern, die der Abgleich pflegt, liegen im CMS eigene Felder, die er nicht anfasst: ein Teasertext, ein Bild, ein Hinweis auf die Anfahrt, eine Empfehlung für verwandte Seminare. So bleibt der Kalender fachlich korrekt und trotzdem redaktionell gestaltbar — statt ein Fremdinhalt zu sein, den niemand anfassen darf.
// integration
drei systeme · ein muster
Der Weg ist in allen drei Systemen derselbe, weil er systemunabhängig gedacht ist: Ein geplanter Lauf holt die öffentlichen Inhalte aus eVEWA4 und legt sie als Inhalte im CMS ab — Seminartermine, Veranstaltungen, Kursbeschreibungen, Orte und Dozenten. Was dafür im CMS existieren muss, ist schnell benannt: eine eigene Inhaltsart mit genau den Feldern aus dem Mapping, eine Medienverwaltung für Bilder und Programme, und eine stabile Kennung aus dem Fachsystem als Schlüssel. Über diesen Schlüssel erkennt der nächste Lauf den Termin wieder und aktualisiert ihn. Erst dadurch werden Veranstaltungen zu echten Seiten mit dauerhafter URL statt zu einem eingebetteten Fremdinhalt — auffindbar, verlinkbar, auch dann noch lesbar, wenn das Fachsystem gerade gewartet wird.
Für alles Personenbezogene gilt die umgekehrte Regel, und sie ist der Kern dieser Seite: Mitgliedsdaten, Beitragsstände, Anmeldelisten, Rechnungen und Bescheinigungen werden nicht gespiegelt. Sie laufen live über einen serverseitigen Endpunkt, den jedes der drei Systeme mit eigenen Mitteln bereitstellt: Die Sitzung wird geprüft, die Rolle wird geprüft, danach fragt der Server genau die Daten der angemeldeten Person ab und gibt nur diese zurück. Diese Antworten landen in keinem Cache, in keinem Suchindex und in keiner Datei auf der Platte. Was unterschiedlich ist, sind allein die Bordmittel — wo die Termine liegen, wie der Takt gesetzt wird und womit der geschützte Bereich abgesichert ist.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler, Frontend-Benutzergruppen und Fluid alles mit, was eine solche Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Inhaltsart für Termine mit genau den Feldern aus dem Mapping. Der Abruf läuft als Scheduler-Task im festen Takt, die Termine liegen als Records in einem Systemordner, Bilder und Programme in FAL. Der geschützte Teil läuft über Frontend-Benutzergruppen: Seiten und Inhalte werden je Gruppe freigegeben, die Live-Abfrage übernimmt ein eigener Controller, der zuerst die Anmeldung prüft. Zugangsdaten stehen in der Extension-Konfiguration und nie im Repository. Sprechende URLs kommen aus dem Site Handling, gerendert wird über Fluid — die Redaktion sieht die Termine im Backend und platziert Teaser als Content-Element.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen. Die Termine werden ein Custom Post Type mit eigenen Meta-Feldern für Zeitraum, Ort, Dozent und Kontingent, dazu Taxonomien für die Filter. Ein geplanter Lauf hält den Bestand nach. Für die serverseitigen Aufrufe legen wir eine eigene REST-Route an: Sie spricht das Fachsystem an, der Browser spricht nur mit ihr. Geschützte Inhalte laufen über Rollen und Fähigkeiten — eine eigene Rolle für Mitglieder, geprüft vor jeder Ausgabe und vor jedem Live-Abruf. Der Schlüssel steht als Konstante in der wp-config.php und nie im Frontend. Fürs Rendern kommen Template-Dateien und Blöcke für den Editor dazu.
// cms-03statamic
Statamic läuft auf Laravel — und genau dieser Unterbau macht die Aufgabe hier besonders geradlinig. Ein Blueprint beschreibt das Datenmodell der Termine, ein Artisan-Command holt sie und schreibt sie als Entries in eine eigene Collection, der Laravel-Scheduler bestimmt den Takt. Für den geschützten Teil kommen Route und Controller dazu: Middleware prüft die Anmeldung, der Controller fragt die Daten der angemeldeten Person live ab und gibt nur diese zurück — vom Static Caching ausgenommen, damit nichts Persönliches in einer ausgelieferten Datei landet. Der Schlüssel liegt in der .env, Bilder und Programme als Assets im eigenen Container. Antlers oder Blade rendern Liste, Filter und Detailseite; im Control Panel pflegt die Redaktion Felder, die der Abgleich nicht anfasst.
// datenschutz
architektur statt absichtserklärung
Bei einer Verbands-, Spenden- oder Seminarsoftware ist Datenschutz keine Rubrik am Ende des Konzepts, sondern die Entscheidung, die den Bau bestimmt. Was nicht doppelt liegt, kann nicht doppelt verloren gehen. Deshalb wandert kein Mitgliederbestand ins CMS, keine Anmeldeliste in den Suchindex und kein Beitragsstand in einen Cache. Die Website hält die öffentliche Seite vor und fragt alles Persönliche im Moment der Anzeige. Das ist gleichzeitig eine Frage der Belastbarkeit: Ein CMS-Backup, das keine Mitgliederdaten enthält, ist ein Backup weniger, das jemand schützen muss. Die drei Muster unten sind die Zuordnung, mit der wir in jedem Projekt anfangen.
// e-01spiegeln
Seminartitel, Beschreibung, Zeitraum, Ort, Format, Preis, Programm als PDF: Das sind Inhalte, keine Momentaufnahmen, und sie enthalten keine personenbezogenen Daten. Sie gehören ins CMS. Die Seite wird dadurch schnell, bleibt bei einer Störung des Fachsystems vollständig lesbar, ist für Suchmaschinen erfassbar und lässt sich redaktionell ergänzen.
inhalt · fester takt
// e-02live
Stammdaten, Beitragsstand, Rechnungen, Teilnahmebescheinigungen, Anmeldelisten: Diese Daten werden hinter dem Login serverseitig geholt und nach der Anzeige verworfen. Keine Spiegelung, keine Ablage, kein Suchindex, kein öffentlich erreichbarer Cache. Dazu Zeitlimit, Wiederholung und ein klar formulierter Hinweis, falls keine Antwort kommt.
abruf · serverseitig
// e-03kombination
Der Regelfall: Die Terminseite wird aus dem gespiegelten Bestand gebaut, und darunter steht für angemeldete Mitglieder ein Block mit dem persönlichen Anmeldestatus, live geholt. Ein Weg für die Substanz, ein Weg für die Person — auf derselben Seite, sauber getrennt in der Auslieferung.
substanz + person
Sicherheit beginnt bei den Zugangsdaten. Sie liegen serverseitig in der Konfiguration, nie im Repository und nie im Browser. Die Website bekommt einen eigenen technischen Zugang mit genau dem Ausschnitt an Rechten, den sie braucht — wird er kompromittiert, ist der Schaden begrenzt und der Zugang tauschbar, ohne dass ein Mitarbeiterkonto betroffen ist. Übertragen wird ausschließlich verschlüsselt.
Im geschützten Bereich zählt die Sitzungsverwaltung: Anmeldung, Rolle und Gültigkeitsdauer entscheidet die Website, die Rechtevergabe im Fachsystem entscheidet, welche Daten überhaupt kommen dürfen — beides muss zusammenpassen. Jede Antwort wird gegen die angemeldete Person geprüft, keine Kennung aus dem Aufruf darf allein bestimmen, wessen Daten geliefert werden. Wie wir Login, Rollen und Sitzungen bauen, steht bei Login & Mitgliederbereich.
Dazu kommen die Pflichten, die kein Code erledigt: Datensparsamkeit im Formular, eine sauber eingeholte und dokumentierte Einwilligung, benannte Löschfristen und ein Auftragsverarbeitungsvertrag mit dem Anbieter — genauso wie mit dem Hoster. Als Anbieterangabe führt der Hersteller für eVEWA4 die Siegel „Software Made in Germany“ und „Software Hosted in Germany“; wo eure Installation tatsächlich läuft, gehört trotzdem schriftlich in die Verarbeitungsübersicht. Mehr dazu im Stack unter Sicherheit & Datenschutz.
// faq
GRÜN eVEWA4 ist eine webbasierte Branchensoftware der GRÜN Software Group GmbH aus Aachen. Der Hersteller beschreibt sie als Lösung, mit der sich umfassende Geschäftsprozesse in Non-Profit-Organisationen sowie bei Bildungs- und Seminaranbietern abwickeln lassen. Drei Bereiche stehen im Vordergrund: die Online-Mitgliederverwaltung für Vereine und Verbände, Gewerkschaften, Parteien und Kammern, die Online-Spendenverwaltung von der Online-Spende bis zur Abrechnung und die Online-Seminarverwaltung für Planung, Durchführung und Abrechnung von Veranstaltungen und Seminaren jeder Art. Dazu kommen Beitragswesen, Rechnungs- und Mahnwesen sowie Auswertungen. Für eine Website ist damit klar, wo die führenden Daten liegen: Mitglieder, Spenden, Termine und Rechnungen stehen in eVEWA4, nicht im CMS.
Ja. Der Hersteller nennt Webservices auf Basis von REST-Technologie, über die sich Drittanwendungen anbinden lassen, und führt dabei Newsletter-Systeme sowie Content-Management-Systeme wie TYPO3 oder WordPress ausdrücklich als Beispiele auf. Eine frei zugängliche Entwicklerdokumentation mit Endpunkten, Feldnamen und Authentifizierungsverfahren gibt es öffentlich jedoch nicht; für technische Details verweist der Hersteller auf den direkten Kontakt und seine Kundenplattform. Deshalb steht am Anfang jedes Projekts eine Sichtung: Welche Wege sind in eurem Vertrag freigeschaltet, welche Felder liefert die Quelle, wie wird authentifiziert. Wir nennen auf dieser Seite bewusst keine Endpunkte und keine Feldnamen — die kommen aus der Freischaltung, nicht aus einer Vermutung.
Die Trennlinie verläuft zwischen öffentlich und personenbezogen. Öffentlich sind Seminartermine, Veranstaltungen, Kursbeschreibungen, Orte, Dozenten und freie Plätze — diese Inhalte spiegeln wir im festen Takt in das Datenmodell des CMS und liefern sie aus dem eigenen Bestand aus. Personenbezogen sind Mitgliedsdaten, Beitragsstände, Rechnungen, Bescheinigungen und Anmeldelisten — diese Daten werden nicht gespiegelt, sondern hinter dem Login serverseitig live abgefragt und nach der Anzeige verworfen. Was genau in welche Richtung läuft, legen wir vorher im Feld-Mapping fest. Nicht jedes Feld aus einer Verbandssoftware gehört auf eine öffentliche Website.
Über einen geplanten Lauf im Hintergrund. Er holt die Termine aus eVEWA4 und legt sie im CMS als eigene Inhaltsart ab: Titel, Beschreibung, Zeitraum, Ort, Dozent, Kontingent, Preis. Über eine stabile Kennung aus dem Fachsystem erkennt der nächste Lauf denselben Termin wieder und aktualisiert ihn, statt eine Dublette anzulegen. Ausgeliefert wird danach aus dem eigenen Bestand — schnell, für Suchmaschinen erfassbar und unabhängig davon, ob das Fachsystem gerade erreichbar ist. Auf der Detailseite ergänzen wir strukturierte Daten für Veranstaltungen, damit ein Termin in der Suche als eigenes Ergebnis erscheinen kann. Wie Kalender, Filter und Anmeldestrecke im Frontend aussehen, beschreibt die Komponente Veranstaltungen und Seminare.
Über einen serverseitigen Endpunkt, nicht über eine Spiegelung. Das Mitglied meldet sich auf der Website an, und erst danach fragt der Server die Daten zu genau dieser einen Person im Fachsystem ab: Stammdaten, Beitragsstand, Rechnungen, Teilnahmebescheinigungen. Die Antwort geht an den angemeldeten Browser und wird im CMS nicht zwischengelagert, nicht in den Suchindex aufgenommen und nicht in einem öffentlich erreichbaren Cache abgelegt. Die Zugangsdaten zur Schnittstelle liegen ausschließlich auf dem Server. Wer angemeldet ist, welche Rolle er hat und wie lange die Sitzung gilt, entscheidet die Website — welche Daten er sehen darf, entscheidet die Rechtevergabe im Fachsystem. Beides muss zusammenpassen.
Ja, das ist der Rückweg. Eine Seminaranmeldung, ein Spendenformular oder eine Beitrittserklärung schickt ihre Daten serverseitig an die Schnittstelle, und daraus entsteht im Fachsystem ein Vorgang: eine Anmeldung, eine Spende, ein neuer Datensatz. Damit nichts verloren geht, sichern wir die Übermittlung ab: Antwortet die Schnittstelle nicht, wird der Vorgang zwischengespeichert, erneut versucht und geht zusätzlich per E-Mail an die Geschäftsstelle. Eine Anmeldung darf nie an einer Zeitüberschreitung scheitern. Welche Vorgänge schreibend angelegt werden dürfen, hängt von der Freischaltung ab und wird vorab mit dem Hersteller geklärt.
Ja, in allen dreien. Die Anbindung bauen wir in jedem System selbst, mit dessen eigenen Bordmitteln. In TYPO3 entsteht eine eigene Extension: Das TCA beschreibt das Datenmodell, der Abruf läuft als Scheduler-Task, die Termine liegen als Records in einem Systemordner, geschützte Bereiche laufen über Frontend-Benutzergruppen, gerendert wird über Fluid. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type mit Meta-Feldern für die Termine, ein geplanter Lauf für den Abgleich, eine eigene REST-Route für die serverseitigen Aufrufe, geschützte Inhalte über Rollen. In Statamic liegt Laravel darunter: ein Blueprint als Datenmodell, ein Artisan-Command im Scheduler, die Termine als Entries in einer Collection, dazu Route und Controller für den geschützten Teil. Die Mechanik bleibt in allen drei Fällen dieselbe — nur der Ort, an dem die Termine liegen, ist ein anderer.
Der wichtigste Punkt ist kein Vertragstext, sondern eine Architekturentscheidung: Personenbezogene Daten werden live abgefragt und nicht ins CMS gespiegelt. Was nicht doppelt liegt, kann nicht doppelt verloren gehen. Dazu kommen die üblichen Pflichten: Zugangsdaten zur Schnittstelle serverseitig und nie im Browser, ein eigener Zugang für die Website mit genau den Rechten, die sie braucht, Übertragung ausschließlich verschlüsselt, Formularfelder auf das Nötige begrenzt, dokumentierte Einwilligung, benannte Löschfristen und ein Auftragsverarbeitungsvertrag mit dem Anbieter — genauso wie mit dem Hoster. Als Anbieterangabe führt der Hersteller für eVEWA4 die Siegel Software Made in Germany und Software Hosted in Germany; wo eure Installation tatsächlich läuft, gehört trotzdem schriftlich in die Verarbeitungsübersicht.
// womit das zusammenhängt
systeme, komponenten & leistung
// leistung · komponente
Was aus den gespiegelten Terminen im Frontend wird: Kalender mit Filter, Detailseite, Anmeldung, Wartelisten und Event-Schema.
zur leistung →
// leistung · komponente
Die Tür vor der Live-Abfrage: Registrierung, Sitzungen, Rollen und Rechte — gebaut in deiner Website, nicht gemietet.
zur leistung →
// leistung · komponente
Wenn Mitglieder ihre Daten selbst pflegen: Stammdaten ändern, Belege abrufen, Vorgänge einsehen — hinter dem Login.
zur leistung →
// leistung · komponente
Anmeldung, Spende, Beitrittserklärung: mehrstufige Strecken mit Validierung, Barrierefreiheit und sicherem Rückweg.
zur leistung →
// stack · schnittstelle
Die Schwesterseite aus der Warenwirtschaft: dieselbe Mechanik aus Spiegeln und Rückweg, nur mit Artikeln statt Terminen.
zur technik →
// leistung · buchen
Die Technik hier, das Angebot dort: Sichtung, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
Dieselbe Logik greift bei anderen Systemen: SAP und weclapp bringen eigene Schnittstellen für Artikel- und Auftragsdaten mit, für Anmeldebestätigungen und Rundschreiben kommt eine Anbindung an Newsletter und E-Mail dazu. Welche Anbindung ein Projekt bekommt und in welcher Reihenfolge sie entsteht, klären wir im Konzept — vor dem Bauen, mit Begründung.
// Seminare und Mitglieder aus eVEWA4 auf deiner Website?
Projekt anfragen