Architecture Decision Record · Projektpartnerportal

RSM-Fallback-Architektur für Projektangebote

accepted 2026-05-30
TL;DR: Salesforce geht nicht rechtzeitig zum Go-Live live. Für 2–3 Monate übernimmt ein neues solcom_rsm_import-Modul die Datenquelle aus einer täglich per SFTP gelieferten RSM-XML-Datei. Ein State Flag steuert sowohl Import-Quelle als auch Bewerbungsweg. lfdNr ist der primäre Migrations-Key; Drupal-Webform + Minggo-Link sind parallele Apply-Optionen.

Kontext

Salesforce (SF) wird nicht parallel zum SOLCOM-Site-Go-Live (08.07.2026) produktionsbereit sein. Die bisherige Architektur (ADR-0034) sieht den SF-REST-Pull als einzige Datenquelle für Projektangebote vor.

Das RSM-Altsystem (internes CRM) exportiert täglich eine UTF-16-kodierte XML-Datei (OpenPos_YYYYMMDD_HHmmss.xml) mit allen aktiven Projektangeboten. Diese Datei wird per SFTP automatisch in ein Verzeichnis auf dem Drupal-Server gepusht. Struktur je <Datensatz>: lfdNr, Titel, Beschreibung, Ort, Start, Dauer, Bearbeiter (zuständige E-Mail), Aktiv, FreelancerLink (enthält für einige Records eine Minggo-URL mit SF-Record-ID).

Bewerbungen auf Projektangebote müssen in einem exakten Format per E-Mail an bewerbung@solcom.de gesendet werden. Eine Microsoft Power App liest diesen Postfach automatisch aus und parst den Body Zeile für Zeile. Das Format ist nicht verhandelbar.

Das Projektpartnerportal (PPP) speichert pro Freelancer eine numerische PPP-ID. Diese ID muss auf dem neuen Drupal-User-Entity abgelegt werden. Bestehende PPP-Nutzer werden in einem späteren Schritt migriert.

Die Übergangsphase beträgt voraussichtlich 2–3 Monate.

Entscheidung

1. State Flag steuert Datenquelle und Apply-Mechanismus gemeinsam

Ein Drupal State Flag solcom_project_offer.rsm_fallback_enabled (Boolean) steuert sowohl den Import-Cron (RSM-XML vs. SF-API) als auch den Bewerbungsweg (Email-Webform-Sichtbarkeit). Flip via Drush: drush state:set solcom_project_offer.rsm_fallback_enabled 1. Kein Admin-UI nötig für den temporären Zeitraum.

2. lfdNr als primärer Migrations-Key

Die RSM-interne laufende Nummer (lfdNr) dient als Drupal-Migrations-Key. Zusätzlich wird field_sf_id auf dem project_offer-Node gepflegt (aus FreelancerLink extrahiert, wo vorhanden). Beim späteren SF-Go-Live matcht die SF-Migration über field_rsm_lfd_nr → SF-Record-ID anhand einer von SOLCOM zu liefernden Mapping-Tabelle.

3. Dual Apply: Minggo-Link + Email-Webform

Während des RSM-Fallback sind beide Apply-Optionen gleichzeitig sichtbar:

  • Minggo-Link (wenn FreelancerLink im RSM-XML vorhanden): direkter Link zu solcom.minggo.io/UUID/apply/SF_ID
  • Email-Webform (immer): Drupal-Webform sendet E-Mail im exakten Power-App-Format an bewerbung@solcom.de, CC an Bearbeiter-Adresse aus RSM-XML

4. PPP-ID: field_ppp_id auf Drupal User + UUID für Anonyme

Eingeloggte Bewerber: field_ppp_id des Users geht in die Email-Body-Zeile PPP-ID {id}. Anonyme Bewerber: Eine UUID wird per Webform-Submit generiert (\Drupal::service('uuid')->generate()) und als temporäre PPP-ID verwendet.

5. XML-Ablage in private://rsm/

RSM pusht die Datei per SFTP in das Drupal Private-Filesystem-Verzeichnis private://rsm/. Der Import-Cron wählt die Datei mit dem neuesten filemtime. Alte Dateien werden nach 30 Tagen gelöscht.

Email-Body-Format (nicht verhandelbar)

Betreff:  Bewerbung über Projektportal / Projekt-Nummer: {lfdNr} / {Titel}
An:       bewerbung@solcom.de
Von:      SOLCOM Projektportal <no-reply@solcom.de>
CC:       {Bearbeiter-Email aus RSM-XML}

Projektnummer: {lfdNr}
Projekt: {Titel}
Titel: {Anrede}
Anrede: {Herr/Frau}
Vorname:
Nachname:
Telefon:
E-Mail-Adresse:
Straße:
Postleitzahl:
Ort:
Land:
Bewerbertyp: {Account User | TBD für Anonym}
Datenschutzerklärung akzeptiert true
Gesendet {timestamp}
Session ID {UUID}
PPP-ID {field_ppp_id | UUID-anonym}
Datei 1 von 1 {filename}

Abgelehnte Alternativen

SF-ID als einziger Migrations-Key

Datensätze ohne FreelancerLink (noch kein SF-Record zugewiesen) würden ignoriert. Verlust eines signifikanten Teils der aktiven Projektangebote. Abgelehnt.

Modul-Enable/Disable statt State Flag

Grobgranularer Schalter; kein sanfter Übergang, Deployment-Overhead bei jedem Wechsel, nicht via Drush allein flipbar. Abgelehnt zugunsten des State-Flag-Patterns (analog ADR-0047).

Nur Email-Webform (kein Minggo-Link)

Für Records mit bestehendem Minggo-Link würde die vertraute Benutzerführung entfallen. Dual-Apply bietet mehr Optionen ohne Mehraufwand. Abgelehnt.

Login-Pflicht für Bewerbungen

Schränkt die Conversion-Rate ein. Login hat nur den Vorteil vorausgefüllter Felder. Anonyme Bewerbungen via UUID-PPP-ID sind zulässig. Abgelehnt.

Konsequenzen

  • Neues Sub-Modul solcom_rsm_import unter solcom_project_offer mit einem Drupal Migrate SourcePlugin (RsmXmlSource) für UTF-16-XML-Dateien.
  • Zwei neue Felder auf project_offer-Node: field_rsm_lfd_nr (Integer, unique) und field_sf_id (String, nullable).
  • Neues Feld field_ppp_id (Integer, unique) auf dem Drupal-User-Entity.
  • Drupal Webform mit exaktem Power-App-Format; kein Spielraum bei Feldreihenfolge oder Zeilenformat.
  • User-Migration (bestehende PPP-IDs aus dem alten Projektpartnerportal) ist separater, späterer Task — das Feld wird jetzt angelegt, nicht befüllt.
  • SOLCOM muss die exakten Bewerbertyp-Werte für eingeloggte vs. anonyme Bewerber bestätigen.
  • Beim SF-Go-Live: SOLCOM liefert Mapping-Tabelle lfdNr → SF-Record-ID für den Übergangs-Migrate.

Offene Punkte

Bewerbertyp-Werte: Genaue Strings für eingeloggte vs. anonyme Bewerber noch von SOLCOM zu bestätigen. Placeholder: Account User / Anonymous User.
lfdNr → SF-ID Mapping: SOLCOM muss beim SF-Go-Live eine Mapping-Tabelle liefern, damit der SF-Migrate keine Duplikate erzeugt.
PPP-ID Auto-Assignment: Wie bekommen neue Drupal-Registrierungen eine PPP-ID (Auto-Increment, UUID)? Klärt sich mit dem User-Migrations-Task.
SFTP-Zugangsdaten: Konkreter Server-Pfad und Credentials für die private://rsm/-Ablage noch zu konfigurieren (operativer Schritt).