RSM-Fallback-Architektur für Projektangebote
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
FreelancerLinkim RSM-XML vorhanden): direkter Link zusolcom.minggo.io/UUID/apply/SF_ID - Email-Webform (immer): Drupal-Webform sendet E-Mail im exakten Power-App-Format an
bewerbung@solcom.de, CC anBearbeiter-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_importuntersolcom_project_offermit einem Drupal Migrate SourcePlugin (RsmXmlSource) für UTF-16-XML-Dateien. - Zwei neue Felder auf
project_offer-Node:field_rsm_lfd_nr(Integer, unique) undfield_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-IDfür den Übergangs-Migrate.
Offene Punkte
Account User / Anonymous User.private://rsm/-Ablage noch zu konfigurieren (operativer Schritt).