Domain-Struktur für User Exit & eigene Logik

Partner erweitern reybex oft über User Exit (Transaktion DEV02, Domäne RunnableServiceEvent): Groovy-Skripte vor oder nach Service-Methoden (z. B. SalesHeadService.save). Dafür brauchen Sie das Domänenmodell – nicht jede Tabelle, sondern die Klassen, die der Service tatsächlich lädt und speichert.

Ablauf

1. Fachlich klären – Welcher Prozess? → Business-Flows und Transaktion (z. B. SAL16).
2. Service wählen – In DEV02: GET /api/runnableServiceEvent/runnableServices oder UI „User Exit“.
3. Domäne nachschlagen – Felder, Referenzen, Pflichtwerte in der Domain-Struktur.
4. Skript schreiben & prüfen – POST /api/runnableServiceEvent/analyzeScript, dann aktivieren.

Ausführlich: User Exit (Business) · Runnable Service Event API

Domain-Struktur nutzen

Frage	Wo nachschlagen
Welche Felder hat SalesHead?	SalesHead
Welche Module gibt es?	Domain – Module
Kern-Entitäten pro Modul (kurz)	Kern-Domänen je Modul, z. B. SAL
Entspricht Tabelle X welcher Domain?	Gleicher Pfad unter Datenbank

Generic API vs. User Exit

Die Generic Domain API (Swagger) schreibt direkt auf Domänen – schnell, aber ohne Workflow-Garantie. User Exit hängt an der Fachlogik des Core-Services – besser für Validierung, Anreicherung und side effects im laufenden Beleg.

Typische Partner-Szenarien

Szenario	Domänen (Beispiele)	Business-Doku
Auftrag validieren / anreichern	SalesHead, SalesItem, Customer	Aufträge SAL16
Artikel vor Speichern prüfen	Material, Attribute	Artikelstamm BAS02
Externe API nach Buchung	Hook auf save / afterCode	API

Rechte

User Exit konfigurieren erfordert typisch DEV02 und Entwickler-/Admin-Rollen – siehe Rollen & Transaktionen und Benutzer & Rollen.

Weiterlesen

• Partner-Leitfaden – Technische Integration
• Technische Integration – Übersicht
• Domain-Struktur – alle Klassen