// stack · schnittstelle
HANSALOG vision ist eine Personalwirtschaftssoftware aus Ankum — mit einem Recruiting-Modul, in dem Stellenausschreibungen und Bewerbungen zusammenlaufen. Die spannende Frage für eine Website ist die Strecke dazwischen: Wie kommen diese Stellen auf die eigene Karriereseite — und zwar so, dass sie dort wie eigene Seiten aussehen, funktionieren und gefunden werden. siteway baut diese Strecke.
// definition
HANSALOG vision ist die cloudbasierte Personalwirtschaftssoftware der HANSALOG Gruppe aus Ankum im Osnabrücker Land. Das Unternehmen ist inhabergeführt, wurde nach eigenen Angaben 1973 gegründet und beziffert seinen Bestand auf rund 2.000 Kunden aus allen Branchen. Der Hersteller selbst schreibt die Produktlinie in Versalien als VISION; laut Herstellerangabe deckt sie Entgeltabrechnung, Personalmanagement, Zeitwirtschaft, Reisekostenabrechnung und Recruiting ab. Neben der Cloud-Linie steht mit LN UI eine Linie für den Betrieb im eigenen Haus. Typische Anwender sind Personalabteilungen im Mittelstand, die Abrechnung und Personalprozesse in einem System bündeln.
Für eine Website ist davon genau ein Ausschnitt relevant: das Recruiting-Modul. Dort legt die Personalabteilung Stellenprofile und Ausschreibungen an, dort läuft der Bewerbungsprozess, dort liegen die Unterlagen. Die Website ist die Schauseite dieses Systems — sie zeigt die offenen Stellen und nimmt Bewerbungen entgegen, ohne selbst zum zweiten Datenhaushalt zu werden. Genau diese Trennung macht die Anbindung sauber: siteway behandelt HANSALOG als führendes System und die Website als Anzeige.
// praxis
daten holen · selbst rendern
Der Hersteller beschreibt den Weg aus Sicht der Personalabteilung: Im Recruiting-Modul entstehen Stellenprofile, daraus werden Stellenanzeigen erzeugt und auf dem eigenen Stellenportal veröffentlicht; für die klassische Linie nennt er zusätzlich Bewerbungsformulare mit anpassbarem Layout zur Einbindung auf der eigenen Homepage sowie ein Multi-Channel-Posting auf Jobportale und Social-Media-Kanäle. Das sind Herstellerangaben — was in eurer Installation tatsächlich freigeschaltet ist, steht damit noch nicht fest.
Wir gehen den datengetriebenen Weg: Stellen als Daten übernehmen, ins CMS übersetzen und die Seiten selbst rendern. Der Grund ist nicht Geschmack, sondern Kontrolle. Nur bei eigenem Markup entscheiden wir über strukturierte Daten, Barrierefreiheit, Ladeverhalten und URL-Struktur — also über genau die Punkte, an denen eine Karriereseite gefunden wird oder eben nicht.
Der erste Schritt ist deshalb immer eine Sichtung: Welcher Weg ist in eurer Installation vorgesehen, welche Felder liefert die Quelle, wie sind Standorte und Bereiche benannt, wie sieht der Bewerbungsweg aus. Daraus entsteht ein Feld-Mapping, und erst danach wird gebaut — dasselbe Vorgehen wie bei jeder anderen Schnittstelle.
Drei Bauweisen, drei Charaktere. Sie unterscheiden sich nicht in der Qualität, sondern darin, wo die Arbeit liegt und wem das Ergebnis gehört. Das hier ist die Entscheidungshilfe, mit der wir in ein Briefing gehen — welcher Weg konkret möglich ist, klären wir vorab mit dem Hersteller oder eurer HR-IT.
// w-01export
Das Personalwirtschaftssystem legt die offenen Stellen in festem Takt als Datei an einem vereinbarten Übergabepunkt ab, die Website holt sie dort ab. Der robusteste Weg, wenn das System hinter der Firewall steht: Es muss nichts von außen erreichbar sein, und die Richtung bleibt eindeutig. Format und Felder werden einmal festgelegt und danach eingehalten.
stärke: robust · firewall bleibt zu
// w-02schnittstelle
Ist ein Zugang freigeschaltet, fragt die Website die Stellen gezielt ab — und kann bei entsprechender Freigabe auch etwas zurückgeben, etwa eine Bewerbung aus einem eigenen Formular. Der Weg trägt mehr Felder und feinere Abfragen, verlangt dafür Zugangsdaten, ein abgestimmtes Rechtekonzept und eine klare Absprache, wer den Zugang betreut.
stärke: beide richtungen
// w-03verlinkung
Das Stellenportal des Herstellers bleibt, wo es ist, und die Website verlinkt darauf oder zeigt es im Rahmen an. Das ist der schnellste Start, weil praktisch nichts gebaut wird. Gestaltung, Markup und Ladeverhalten kommen dann allerdings vom Anbieter — inklusive der Frage, unter welcher Adresse der Inhalt zählt.
stärke: sofort startklar
Das ist der Punkt, an dem sich etablierte Personalwirtschaftssysteme von reinen Cloud-Werkzeugen unterscheiden. Sie laufen häufig im eigenen Rechenzentrum oder auf eigenen Servern hinter der Firewall — bei HANSALOG betrifft das die Linie LN UI, während der Hersteller für die Cloud-Linie angibt, ausschließlich in Deutschland zu hosten und vier eigene Rechenzentren an deutschen Standorten zu betreiben. In beiden Fällen gilt dasselbe Prinzip: Ein Personalsystem, in dem Gehälter und Personalakten liegen, wird nicht für Zugriffe aus dem Internet geöffnet.
Der Weg auf die Website ist dann ein Export in ein definiertes Zielverzeichnis oder eine gezielt freigegebene Schnittstelle. Praktisch heißt das: Ein Lauf im Personalsystem schreibt die offenen Stellen an einen abgesicherten Übergabepunkt, die Website holt sie dort ab, und die Richtung zeigt nach außen statt nach innen. Das ist kein Umweg, sondern die saubere Bauweise — sie hält die Angriffsfläche klein und macht den Datenfluss nachvollziehbar.
Zu klären ist deshalb früh, wer den Übergabepunkt einrichtet und betreut, wie er verschlüsselt ist, in welchem Takt geschrieben wird und wer merkt, wenn ein Lauf ausbleibt. Diese Fragen gehören der HR-IT und dem Hersteller, nicht dem Template — und sie stehen bei uns am Anfang des Konzepts, nicht am Ende.
// bausteine · 6 details
jedes teil mit klarem zweck
Zwischen „Stelle steht in HANSALOG" und „Stelle steht auf der Website" liegen sechs Bauteile. Sie sind bei jedem Projekt gleich — was sich unterscheidet, sind die Feldnamen und der Takt.
// d-01abholung
Ein geplanter Job holt die Stellen in festem Takt und legt sie lokal ab. Kein Besucher wartet auf ein Fremdsystem, kein Seitenaufruf erzeugt einen Zugriff nach außen. Antwortet die Quelle einmal nicht, bleibt der letzte gute Stand stehen, statt dass die Karriereseite leer läuft.
zweck: tempo · ausfallsicherheit
// d-02mapping
Jedes Feld der Quelle bekommt ein Zuhause im CMS: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Ablaufdatum, Bewerbungslink. Weil die Benennung je Installation abweicht, wird das Mapping einmal schriftlich festgehalten. Was fehlt, ergänzt die Redaktion daneben — etwa ein Teamfoto oder einen Ansprechpartner.
zweck: felder statt textblock
// d-03liste
Die Übersicht filtert nach Standort, Bereich und Anstellungsart — mit sprechenden URLs, damit ein Filterstand teilbar bleibt. Weil die Liste aus eigenen Daten entsteht, taucht sie auch in der Website-Suche auf statt in einem abgeschotteten Rahmen.
zweck: finden statt scrollen
// d-04detailseite
Jede Stelle bekommt eine eigene, stabile und indexierbare Adresse unter deiner Domain — teilbar per Mail, verlinkbar aus Social, sauber in der Vorschau. Das Layout ist deins: dieselbe Typografie, dieselbe Navigation, derselbe Footer wie auf dem Rest der Website.
zweck: eine stelle · eine url
// d-05lebenszyklus
Verschwindet eine Stelle aus der Quelle, verschwindet sie aus der Liste. Für die Detailseite gibt es drei saubere Optionen: Ablaufdatum in die Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wir wählen je Projekt eine — und leiten Besucher auf die Übersicht statt in die Sackgasse.
zweck: keine karteileichen
// d-06betrieb
Ein Abgleich, der stillschweigend scheitert, ist gefährlicher als einer, der laut abbricht. Deshalb wird jeder Lauf protokolliert, Fehler werden gemeldet, und ein leeres Ergebnis überschreibt niemals einen gefüllten Stand. Mehr dazu unter Deployment & Betrieb.
zweck: fehler fallen auf
An dieser Stelle entscheidet sich, wie sich die Karriereseite anfühlt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerbungsformular des Herstellers. Upload, Pflichtfelder und Eingangsbestätigung liegen dann dort, die Bewerbung ist ohne Umweg im Bewerbermanagement, und auf dem Webserver entstehen gar keine Bewerberdaten. Der Preis ist ein sichtbarer Wechsel — anderes Layout, mitunter ein eigener Consent-Hinweis.
Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über eine freigegebene Schnittstelle übergibt. Der Bewerber bleibt durchgehend bei dir, Felder und Fehlermeldungen sind gestaltbar, die Barrierefreiheit liegt in unserer Hand — wie bei allen Formularstrecken. Dafür braucht es einen freigeschalteten Zugang, ein sorgfältiges Mapping und eine ehrliche Fehlerbehandlung: Was passiert, wenn die Übergabe scheitert, nachdem der Bewerber auf „Absenden" geklickt hat?
Welcher Weg gebaut wird, hängt weniger an der Technik als an der Erwartung: Soll die Bewerbung Teil der Website sein oder Teil des Personalsystems? Wir stellen diese Frage im Briefing — und beantworten sie gemeinsam, bevor eine Zeile Template entsteht.
// integration · 3 systeme
drei systeme · ein muster
Ein Personalwirtschaftssystem liefert Daten, ein CMS macht daraus Seiten. Der Weg dazwischen ist systemunabhängig und sieht überall gleich aus: Ein geplanter Job holt die Stellen in festem Takt, legt jede Ausschreibung als eigenen Inhalt im CMS an — mit einer eigenen, indexierbaren URL je Stelle — und das Frontend rendert daraus Liste, Filter und Detailseite. Aus denselben Feldern entsteht beim Rendern das JobPosting-Markup für Google for Jobs.
Unterschiedlich ist nur, wie das jeweilige System Inhalte modelliert und wiederkehrende Aufgaben plant. Im CMS liegt dabei das Datenmodell: Titel, Standort, Bereich, Anstellungsart, Beschreibung, Ablaufdatum und Bewerbungslink als einzelne Felder statt als Textblock — dazu Platz für das, was die Redaktion daneben ergänzt. Die Auslieferung übernimmt der Cache, sodass kein Seitenaufruf auf ein Fremdsystem wartet. Der Bewerbungsweg setzt an der Detailseite an: Der Button führt in das Formular des Herstellers oder in ein eigenes auf deiner Domain. Und genau hier liegt der Unterschied, der weiter oben schon anklang: Liegen die Stellen als echte Seiten deiner Domain, entsteht eigenes Markup aus deinen Feldern und zählt zu deiner Adresse.
// cms-01typo3
Wir bauen eine eigene Extension auf Basis von Extbase: Der Abruf läuft als Scheduler-Task im festen Takt und schreibt die Stellen als eigene Records in einen Ordner im Seitenbaum, mit TCA-definierten Feldern für Standort, Bereich und Anstellungsart. Das Site Handling erzeugt daraus sprechende URLs, Fluid rendert Liste und Detailseite. Die Redaktion ergänzt daneben, was das Personalsystem nicht kennt — Teamfoto, Ansprechpartner, Einstiegstext. Mehr zum System unter TYPO3.
weg: eigene extension · scheduler
// cms-02wordpress
Hier entsteht ein eigenes Plugin statt Code im Theme — damit die Anbindung einen Theme-Wechsel überlebt. Ein geplanter Lauf holt die Stellen und legt jede als Beitrag eines Custom Post Types mit eigenen Meta-Feldern an; Standort und Bereich liegen als Taxonomien daneben. Eine eigene Permalink-Struktur gibt jeder Stelle ihre Adresse, das Markup setzt ein Hook im <head>. Ergänzende Bilder und Textblöcke pflegt die Redaktion im Block-Editor. Mehr zum System unter WordPress.
weg: eigenes plugin · custom post type
// cms-03statamic
Unter Statamic liegt ein vollständiges Laravel — der Abruf ist deshalb ein Artisan-Command im Scheduler, das die Stellen als Entries in eine Collection schreibt. Das Blueprint gibt die Felder vor, die Route der Collection ergibt die eigene URL je Stelle, Antlers oder Blade rendern Liste und Detailseite. Das Static Caching liefert den fertigen Stand aus und wird beim Speichern erneuert; Ergänzungen pflegt die Redaktion im Control Panel. Mehr zum System unter Statamic.
weg: artisan-command · entries
// sichtbarkeit
markup entscheidet, nicht layout
Wer eine Stelle sucht, tippt einen Jobtitel bei Google ein. Damit eine Anzeige in der Job-Box darüber erscheint, verlangt Google zweierlei: Die Seite muss gecrawlt werden können, und sie muss JobPosting als strukturierte Daten enthalten. Pflichtangaben sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort. Empfohlen kommen unter anderem Ablaufdatum, Anstellungsart, eine eigene Kennung und die Gehaltsangabe dazu — und gerade Letztere entscheidet mit, ob eine Anzeige in gefilterten Ergebnissen überhaupt auftaucht.
Wichtig ist die Reihenfolge: Dieses Markup entsteht nicht im Personalwirtschaftssystem, sondern erst im CMS. Liegen die Stellen als eigene Seiten auf deiner Domain, erzeugen wir es beim Rendern aus denselben Feldern, die aus HANSALOG kommen — ein Feld, ein Attribut. Wird ein Stellenportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiterhin zu dieser Adresse; erfasst wird die Stelle dann dort und nicht unter deiner URL. Beides kann nebeneinander bestehen, aber nur der eigene Weg baut Sichtbarkeit auf der eigenen Domain auf.
Dazu gehört auch das Ende: Google nennt drei Wege für besetzte Stellen — Ablaufdatum in der Vergangenheit, Statuscode 404 oder 410, oder das Markup entfernen. Wie wir strukturierte Daten grundsätzlich bauen, steht unter Strukturierte Daten; was speziell für Stellenanzeigen gilt, unter Google for Jobs.
// datenschutz
so wenig wie möglich, so kurz wie möglich
Eine Bewerbung ist kein Kontaktformular. Lebenslauf, Zeugnisse, Geburtsdatum, manchmal ein Foto — das sind personenbezogene Daten der empfindlichsten Sorte, und sie werden ausgerechnet von Menschen übergeben, die dem Unternehmen noch nicht verbunden sind. Deshalb ist die erste Regel bei der Anbindung Datensparsamkeit: Die Website fragt nur ab, was für die Auswahl gebraucht wird, und legt nichts länger ab, als der Weitertransport dauert.
Technisch heißt das: Übertragung ausschließlich verschlüsselt, Zugangsdaten in der Serverkonfiguration statt im Repository, Anhänge direkt weiterreichen statt in einem Upload-Ordner sammeln, Zugriffe protokollieren. Führendes System bleibt HANSALOG — dort greifen Rollen, Protokolle und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Der Hersteller nennt dafür unter anderem Workflows bis hin zur fristgerechten Löschung von Bewerberdaten; wie das in eurer Installation eingestellt ist, gehört ins Vorgespräch.
Steht das System im eigenen Haus, kommt eine Frage dazu, die bei Cloud-Werkzeugen niemand stellt: Wer sichert den Transportweg ab? Der Übergabepunkt zwischen Personalsystem und Website liegt organisatorisch zwischen HR-IT, Hersteller und Agentur — deshalb wird schriftlich festgehalten, wer ihn einrichtet, wie er verschlüsselt ist und wer die Protokolle sieht. Rechtlich gehört ein Auftragsverarbeitungsvertrag dazu, ebenso ein Datenschutzhinweis an genau der Stelle, an der die Daten erhoben werden — kurz, verständlich und ohne vorangekreuzte Einwilligung. Wie siteway das grundsätzlich hält, steht unter Sicherheit & Datenschutz.
Ein Bewerbungsformular ist die engste Stelle der ganzen Strecke: Wer hier scheitert, bewirbt sich nicht. Deshalb bekommt jedes Feld ein sichtbares, dauerhaft verknüpftes Label statt eines Platzhalters, der beim Tippen verschwindet. Pflichtfelder sind im Text benannt, nicht nur durch ein Sternchen. Fehler stehen am Feld, in Worten, und der Fokus springt dorthin — nicht in eine rote Zeile ganz oben, die eine Screenreader-Nutzerin nie erreicht.
Der Datei-Upload nennt erlaubte Formate und Größen, bevor jemand die falsche Datei wählt, und bleibt per Tastatur bedienbar. Nach dem Absenden gibt es eine Rückmeldung, die auch angesagt wird. Das gilt für das eigene Formular ebenso wie für die Entscheidung, in das Formular des Herstellers weiterzuleiten — dann prüfen wir vorher, wie es sich dort verhält. Die Grundlagen dazu stehen unter Barrierefreiheit.
// faq
HANSALOG vision ist die cloudbasierte Personalwirtschaftssoftware der HANSALOG Gruppe mit Sitz in Ankum im Osnabrücker Land. Das Unternehmen ist inhabergeführt, wurde 1973 gegründet und beziffert seinen Bestand auf rund 2.000 Kunden. Die Software deckt laut Hersteller Entgeltabrechnung, Personalmanagement, Zeitwirtschaft, Reisekostenabrechnung und Recruiting ab; der Hersteller schreibt die Produktlinie auch in Versalien als VISION. Daneben steht mit LN UI eine Linie für den Betrieb im eigenen Haus. Für die Website ist genau ein Ausschnitt relevant: das Recruiting-Modul, in dem die Stellenausschreibungen entstehen.
Der Hersteller beschreibt, dass Stellenprofile im Recruiting-Modul angelegt, daraus Stellenanzeigen erzeugt und auf dem eigenen Stellenportal veröffentlicht werden; für die klassische Linie nennt er zusätzlich Bewerbungsformulare mit anpassbarem Layout zur Einbindung auf der eigenen Homepage. siteway geht den datengetriebenen Weg: Die Stellen werden als Daten übernommen, ins CMS übersetzt und dort als eigene Seiten gerendert. Ob das über einen Export in ein definiertes Zielverzeichnis läuft oder über eine freigegebene Schnittstelle, hängt an eurer Installation und wird vorab mit dem Hersteller oder eurer HR-IT geklärt. Eine öffentliche Entwicklerdokumentation dazu ist nicht frei verfügbar.
Etablierte Personalwirtschaftssysteme stehen selten offen im Internet. HANSALOG gibt an, vier eigene Rechenzentren an deutschen Standorten zu betreiben und die Cloud-Linie ausschließlich in Deutschland zu hosten; die Linie LN UI läuft im eigenen Haus. In beiden Fällen ist der Weg zur Website kein offener Zugriff von außen, sondern ein Export in ein definiertes Zielverzeichnis oder eine gezielt freigegebene Schnittstelle. Praktisch heißt das: Die Datei landet auf einem abgesicherten Übergabepunkt, die Website holt sie dort ab, und die Firewall bleibt zu. Wer den Transportweg absichert und wer ihn überwacht, wird vor dem Bauen festgelegt.
Ja. In allen drei Systemen trägt derselbe Aufbau: Ein geplanter Job holt die Stellen, legt jede Ausschreibung als eigenen Inhalt im CMS an, und das Frontend rendert Liste, Filter und Detailseite — jede Stelle mit einer eigenen indexierbaren URL auf deiner Domain. In TYPO3 ist das eine eigene Extension mit Scheduler-Task, eigenen Datensätzen und Fluid-Templates. In WordPress ein eigenes Plugin mit einem Custom Post Type und Taxonomien für Standort und Bereich. In Statamic ein Artisan-Kommando im Scheduler, das Entries in eine Collection schreibt. Weil die Feldnamen je Installation unterschiedlich ausfallen, baut siteway die Abholung als schlanken eigenen Code und stimmt das Feld-Mapping vorab ab.
Google zeigt eine Stelle in der Job-Box nur, wenn die Seite gecrawlt werden kann und JobPosting-Markup als strukturierte Daten enthält. Pflicht sind Titel, Beschreibung, Veröffentlichungsdatum, Arbeitgeber und Arbeitsort; empfohlen sind unter anderem Ablaufdatum, Anstellungsart und Gehalt. Dieses Markup entsteht nicht im Personalwirtschaftssystem, sondern erst im CMS: siteway erzeugt es beim Rendern aus denselben Feldern, die aus HANSALOG kommen. Wird ein Stellenportal dagegen von einer fremden Adresse eingebunden, gehört der Inhalt technisch weiter zu dieser Adresse und wird dort erfasst, nicht unter deiner URL.
Beides trägt. Der direkte Weg ist die Weiterleitung: Der Button auf der Stellenseite führt in das Bewerbungsformular des Herstellers, dort läuft der Upload, und die Bewerbung liegt ohne Umweg im Bewerbermanagement — auf dem Webserver entstehen dabei gar keine Bewerberdaten. Der zweite Weg ist ein eigenes Formular auf deiner Domain, das die Daten über eine freigegebene Schnittstelle übergibt: durchgängig im Design deiner Website, mit voller Kontrolle über Pflichtfelder, Fehlermeldungen und Barrierefreiheit, dafür mit mehr Aufwand und einer Abhängigkeit von dem, was freigeschaltet ist. siteway klärt das vor dem Bauen, weil daran der ganze Bewerbungsweg hängt.
Fällt eine Stelle aus der Quelle, verschwindet sie beim nächsten Abgleich aus der Liste. Für die Detailseite nennt Google drei saubere Wege: das Ablaufdatum in die Vergangenheit setzen, die Seite mit Statuscode 404 oder 410 beantworten oder das JobPosting-Markup entfernen. Welcher Weg gewählt wird, legt siteway je Projekt fest — und leitet abgelaufene Stellen dorthin, wo es weitergeht: auf die Karriereübersicht statt in eine Sackgasse.
Bewerbungsunterlagen gehören zum Sensibelsten, was eine Website verarbeitet. Deshalb gilt: so wenig wie möglich auf dem Webserver. Die Übertragung läuft verschlüsselt, Zugangsdaten liegen in der Serverkonfiguration statt im Repository, Anhänge werden weitergereicht statt dauerhaft abgelegt. Führendes System bleibt HANSALOG — dort greifen Rollen, Protokollierung und die Löschfristen, die das Personalwesen ohnehin einhalten muss. Läuft das System im eigenen Rechenzentrum, kommt die Frage nach dem Transportweg dazu: Wer richtet den Übergabepunkt ein, wie ist er verschlüsselt, wer sieht die Protokolle. Der Auftragsverarbeitungsvertrag gehört ins Projekt, nicht ins Nachspiel.
// womit das zusammenhängt
komponente, leistung & nachbarn
// komponente · buchen
Der Baustein, der auf deiner Website entsteht: Stellenliste, Detailseiten, Bewerbungsformular und Karriere-Übersicht. Hier wird gebucht.
zur komponente →
// leistung · buchen
Die Leistung hinter dieser Seite: Scoping, Feld-Mapping, Entwicklung, Test und Monitoring — für HANSALOG wie für jedes andere Fremdsystem.
zur leistung →
// stack · sichtbarkeit
Was eine Stellenanzeige mitbringen muss, um in der Job-Box zu erscheinen — Pflichtfelder, Ablaufdatum und die häufigsten Stolpersteine.
zur technik →
// stack · schwester
Dieselbe Frage, anderes System: wie Stellen aus dem rexx-Bewerbermanagement auf die eigene Karriereseite kommen.
zur technik →
// stack · schwester
Der Cloud-Gegenpol: wie Stellen aus Personio auf die eigene Karriereseite kommen — und wo sich die Wege unterscheiden.
zur technik →
// stack · schutz
Verschlüsselung, Header, Datensparsamkeit und der Umgang mit Zugangsdaten — die Regeln, nach denen jede Anbindung gebaut wird.
zur technik →
// Stellen aus HANSALOG auf deiner eigenen Karriereseite?
Anbindung anfragen