1. Geschäftsproblem
Bewerbungen werden häufig unstrukturiert verwaltet. Ziel ist eine klare Pipeline, in der jede Bewerbung einen definierten Status durchläuft.
Ziel dieses Showcases
Dieser Showcase demonstriert, wie ein fachlicher Bewerbungsprozess als standardisierte REST API modelliert werden kann.
Der Fokus liegt darauf zu zeigen, wie Business Analyse strukturiert in technische Schnittstellen überführt wird – nachvollziehbar, validierbar und direkt testbar.
Zweck der API
Die API stellt nicht nur Daten bereit, sondern kapselt die Geschäftslogik des Prozesses.
Dadurch kann der Bewerbungsprozess kontrolliert durch Web-Frontends, mobile Anwendungen oder integrierte Drittsysteme genutzt werden.
Security im Zielbild
In einer produktiven Umsetzung wäre die API durch Authentisierung, Autorisierung und Rollenberechtigungen abgesichert.
Typische Verfahren wären OAuth2, OpenID Connect oder JWT. In diesem Showcase wird Security bewusst nur fachlich erwähnt.
Swagger / OpenAPI
Die OpenAPI-Spezifikation dient als vertragliche Beschreibung der Schnittstelle.
Sie definiert Endpunkte, Datenobjekte, Request- und Response-Strukturen sowie mögliche Fehlerfälle.
Was wird gezeigt?
- Fachlichen Prozess analysieren
- Entscheidungspunkte identifizieren
- Geschäftsobjekt ableiten
- Statusmodell definieren
BA-Ergebnis
Aus BPMN, DMN-Denkweise und API-Design entsteht eine konsistente OpenAPI-Spezifikation.
Damit wird sichtbar, wie fachliche Analyse in technische Schnittstellen übersetzt wird.
BPMN-Prozessmodell als Detailansicht
Doppelklick zum Vergrössern des Prozessmodells
Fachliche und technische Herleitung
2. Prozessmodell BPMN
Der Prozess beschreibt den Lebenszyklus einer Bewerbung vom Erstkontakt bis zur Einstellung oder Absage.
3. Entscheidungslogik DMN
Statuswechsel basieren auf fachlichen Entscheidungen wie Kandidat geeignet, Angebot erstellen oder Angebot akzeptiert.
4. Datenmodell
Zentrales Objekt ist die Application. Ergänzt wird sie durch Interview, Offer und StatusHistory.
5. API Design
Die Endpunkte wurden direkt aus dem Prozess abgeleitet und bilden Pipeline, Detailansicht, Statuswechsel und Historie ab.
6. Ergebnis
Die OpenAPI-Spezifikation zeigt, wie fachliche Anforderungen in eine konsistente und erweiterbare API übersetzt werden.
DMN Decision Table Showcase
Die folgende Tabelle zeigt exemplarisch, wie fachliche Entscheidungen aus dem Bewerbungsprozess in eine Decision Table überführt werden könnten. Sie verbindet BPMN-Prozess, Statuslogik und API-Statuswechsel.
| Entscheidung | Eingangssituation | Fachliche Regel | Ergebnis | API-Auswirkung |
|---|---|---|---|---|
| Interesse vorhanden? | Unternehmen hat Bedarf und Kontakt wurde hergestellt. | Wenn Rolle, Profil und Timing grundsätzlich passen. | INITIAL_CONTACT → INTERVIEW_PHASE | PATCH /applications/{applicationId}/status |
| Kandidat geeignet? | Bewerbung befindet sich in der Interviewphase. | Wenn Fachlichkeit, Erfahrung und Rollenfit positiv bewertet werden. | INTERVIEW_PHASE → OFFER_PHASE | PATCH /applications/{applicationId}/status |
| Kandidat nicht geeignet? | Interview wurde durchgeführt. | Wenn Anforderungen, Verfügbarkeit oder Rollenfit nicht ausreichend passen. | INTERVIEW_PHASE → REJECTED_AFTER_INTERVIEW | PATCH /applications/{applicationId}/status |
| Angebot akzeptiert? | Ein Angebot wurde erstellt. | Wenn Konditionen, Startdatum und gegenseitige Erwartungen bestätigt sind. | OFFER_PHASE → HIRED | PATCH /applications/{applicationId}/status |
| Angebot abgelehnt? | Ein Angebot wurde erstellt. | Wenn Konditionen oder Rahmenbedingungen nicht akzeptiert werden. | OFFER_PHASE → REJECTED_OFFER_DECLINED | PATCH /applications/{applicationId}/status |
BA-Sicht auf die API.
Die Decision Table beschreibt die fachliche Entscheidungslogik. Die API stellt dafür
einen kontrollierten Statuswechsel bereit. Jeder Statuswechsel wird über die History
nachvollziehbar dokumentiert.
OpenAPI / Swagger Spezifikation
Die folgende Spezifikation ist das Ergebnis der fachlichen Analyse und zeigt, wie der Prozess technisch als REST API umgesetzt werden kann.
Security Stufe 1
Diese API implementiert grundlegende Schutzmassnahmen gegen Missbrauch.
Rate Limiting
- Maximal 10 Anfragen pro Minute pro IP-Adresse
- Bei Überschreitung: HTTP
429 Too Many Requests - Automatischer Reset nach 60 Sekunden
Input-Validierung
- Pflichtfelder server-seitig geprüft → HTTP
422bei Fehler - E-Mail-Format wird validiert
- Maximale Feldlängen: 100 Zeichen (Text), 1000 Zeichen (Notizen)
- Statusübergänge gegen erlaubte Werte geprüft
Security-Header
X-Content-Type-Options: nosniffX-Frame-Options: DENY
Stufe 2 (geplant): API-Key Authentifizierung via
X-API-Key Header — in einer Produktivumgebung zwingend.