Key User Extensibility ermöglicht es Fachanwendern, SAP-Systeme ohne Entwicklerkenntnisse zu erweitern. Dieser Artikel erklärt das Konzept, zeigt praktische Beispiele und grenzt Key User von Developer Extensibility ab.
Key User vs. Developer Extensibility
SAP unterscheidet zwei Extensibility-Modelle:
| Aspekt | Key User Extensibility | Developer Extensibility |
|---|---|---|
| Zielgruppe | Fachanwender, Consultants | ABAP-Entwickler |
| Werkzeuge | Fiori Apps, Browser | ADT/Eclipse, BAS |
| Programmierung | Keine (Low-Code/No-Code) | ABAP Cloud |
| Flexibilität | Eingeschränkt | Volle Kontrolle |
| Transport | Automatisch | Manuell/gCTS |
| Verfügbarkeit | Public Cloud, Private Cloud | Alle Editionen |
Wann Key User Extensibility nutzen?
Key User Extensibility eignet sich für:
- Einfache Felderweiterungen ohne komplexe Logik
- Schnelle Anpassungen im laufenden Betrieb
- Prototyping vor Developer-Implementierung
- Business-getriebene Änderungen ohne IT-Engpass
Wann Developer Extensibility?
Developer Extensibility ist besser für:
- Komplexe Geschäftslogik mit ABAP-Code
- Performance-kritische Erweiterungen
- Integration mit externen Systemen
- Wiederverwendbare Komponenten
Custom Fields anlegen
Custom Fields sind das häufigste Szenario für Key User Extensibility.
Schritt-für-Schritt: Custom Field erstellen
- App öffnen: Fiori App “Custom Fields and Logic” (F1481)
- Business Context wählen: z.B. “Sales Order” oder “Business Partner”
- Feld hinzufügen: Button “New” klicken
Feldtypen
| Feldtyp | Beispiel | Verwendung |
|---|---|---|
| Text | Bemerkungsfeld | Freitext bis 1333 Zeichen |
| Number | Rabattstufe | Ganzzahlen oder Dezimal |
| Amount | Bonusbetrag | Mit Währung |
| Quantity | Zusatzmenge | Mit Einheit |
| Date | Prüfdatum | Kalenderdatum |
| Time | Bearbeitungszeit | Uhrzeit |
| Checkbox | Ist geprüft | Ja/Nein |
| Code List | Priorität | Dropdown mit festen Werten |
Beispiel: Custom Field “Customer Priority”
Business Context: Business Partner - CustomerField Label: Customer PriorityTechnical Name: YY1_CUSTOMER_PRIORITYField Type: Code List
Values:- A = High Priority- B = Medium Priority- C = Low Priority- D = No ClassificationVerwendung in UIs
Nach dem Anlegen kann das Feld aktiviert werden für:
- Fiori Elements Apps: Automatische Integration
- Transaktionale Apps: In Formularen und Listen
- Analytische Apps: In Reports und Dashboards
Technische Hintergründe
Custom Fields werden technisch als:
- Extension Include: In die Standard-Tabelle eingebunden
- CDS View Extension: Automatisch in Views verfügbar
- Service Extension: In OData-Services exponiert
-- Automatisch generierte CDS View Extensionextend view I_BusinessPartner with ZE_BusinessPartner_CF { YY1_CUSTOMER_PRIORITY as CustomerPriority}Custom Logic mit BAdIs
Für einfache Geschäftslogik bietet Key User Extensibility vordefinierte BAdIs.
Verfügbare BAdI-Trigger
| Trigger | Zeitpunkt | Typische Nutzung |
|---|---|---|
| On Modify | Bei Feldänderung | Feldvalidierung, Defaultwerte |
| On Save | Vor dem Speichern | Komplexe Validierungen |
| After Save | Nach dem Speichern | Folgeaktionen |
| Determination | Automatisch | Wertableitung |
Beispiel 1: Defaultwert setzen
Szenario: Bei neuen Kunden soll das Feld “Customer Priority” automatisch auf “C” gesetzt werden.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: DeterminationTrigger: On Create
Bedingung: Kundennummer ist initial
Aktion: Setze Feld "YY1_CUSTOMER_PRIORITY" = "C"Die grafische Oberfläche erzeugt daraus:
" Generierter Code (nicht direkt sichtbar)IF customer-customer_id IS INITIAL. customer-yy1_customer_priority = 'C'.ENDIF.Beispiel 2: Feldvalidierung
Szenario: Kunden mit Priority “A” müssen einen Ansprechpartner haben.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: ValidationTrigger: On Save
Bedingung: YY1_CUSTOMER_PRIORITY = "A" UND Ansprechpartner ist leer
Aktion: Fehler: "High-Priority-Kunden benötigen einen Ansprechpartner"Erweiterte Ausdrücke
Key User Logic unterstützt:
// VergleichsoperatorenFeld1 = "Wert"Feld2 <> "Wert"Feld3 > 100Feld4 >= 50
// Logische VerknüpfungenBedingung1 UND Bedingung2Bedingung1 ODER Bedingung2NICHT Bedingung1
// FeldoperationenFeld1 + Feld2Feld1 * FaktorLÄNGE(Textfeld) > 10HEUTE()Custom CDS Views
Key User können auch eigene analytische Views erstellen.
Custom CDS Views App
Die App “Custom CDS Views” (F2170) ermöglicht:
- Neue Views auf Basis bestehender Views
- Berechnete Felder hinzufügen
- Filter und Aggregationen definieren
Beispiel: Kundenübersicht mit Priority
Basis View: I_BusinessPartner
Custom View: YY1_CustomerOverview
Felder:- BusinessPartner (von I_BusinessPartner)- BusinessPartnerName (von I_BusinessPartner)- CustomerPriority (Custom Field)- OrderCount (Berechnet: Anzahl Aufträge)- TotalRevenue (Berechnet: Summe Umsatz)
Filter:- BusinessPartnerCategory = '1' (nur Kunden)
Aggregation:- Gruppierung nach CustomerPriorityGenerierte CDS View
@AbapCatalog.viewEnhancementCategory: [#NONE]@Analytics.query: true@VDM.viewType: #CONSUMPTIONdefine view entity YY1_CustomerOverview as select from I_BusinessPartner as BP association [1..*] to I_SalesOrder as _Orders on $projection.BusinessPartner = _Orders.SoldToParty{ key BusinessPartner, BusinessPartnerName, YY1_CUSTOMER_PRIORITY as CustomerPriority,
@Aggregation.default: #SUM count( distinct _Orders.SalesOrder ) as OrderCount,
@Aggregation.default: #SUM @Semantics.amount.currencyCode: 'Currency' sum( _Orders.TotalNetAmount ) as TotalRevenue,
_Orders.TransactionCurrency as Currency}where BP.BusinessPartnerCategory = '1'group by BusinessPartner, BusinessPartnerName, YY1_CUSTOMER_PRIORITY, _Orders.TransactionCurrencyEinschränkungen und Grenzen
Key User Extensibility hat klare Grenzen:
Technische Einschränkungen
| Einschränkung | Details |
|---|---|
| Anzahl Felder | Max. ~200 Custom Fields pro Business Context |
| Feldlänge | Text max. 1333 Zeichen |
| Komplexe Logik | Keine Schleifen, keine externen Aufrufe |
| Performance | Bei vielen Feldern kann Performance leiden |
| Debugging | Eingeschränkte Fehleranalyse |
Funktionale Einschränkungen
- Keine Tabellenlogik: Keine Verarbeitung von internen Tabellen
- Keine API-Aufrufe: Keine RFC, HTTP oder OData-Aufrufe
- Keine Workflows: Nur vordefinierte Trigger
- Kein Unit Testing: Keine automatisierten Tests
Nicht unterstützte Szenarien
❌ Komplexe Berechnungen über mehrere Objekte❌ Integration mit Drittsystemen❌ Massenverarbeitung❌ Custom UIs (nur Feldintegration)❌ Background Jobs❌ Eigene TransaktionenUpgrade-Verhalten
- Custom Fields bleiben bei Upgrades erhalten
- Custom Logic wird bei Breaking Changes ggf. deaktiviert
- Regelmäßige Überprüfung empfohlen
Governance und Best Practices
Namenskonventionen
Prefix für Custom Objects: YY1_ oder ZZ1_(automatisch vom System vergeben)
Empfehlung für Feldnamen:- Beschreibend: YY1_CUSTOMER_PRIORITY statt YY1_FIELD01- Konsistent: Gleiche Begriffe für gleiche Konzepte- Dokumentiert: Label und Beschreibung pflegenProzess für Key User Extensibility
1. Anforderung dokumentieren - Was soll erweitert werden? - Warum reicht der Standard nicht?
2. Machbarkeitsprüfung - Ist Key User Extensibility ausreichend? - Oder braucht es Developer Extensibility?
3. Implementierung - Im Development-System erstellen - Testen
4. Transport - In Qualitätssystem transportieren - Abnahmetest
5. Go-Live - In Produktion aktivieren - MonitoringDokumentation
Jede Erweiterung sollte dokumentieren:
| Aspekt | Beispiel |
|---|---|
| Zweck | ”Ermöglicht Priorisierung von Kunden für Vertrieb” |
| Business Owner | ”Vertriebsleitung” |
| Technischer Name | ”YY1_CUSTOMER_PRIORITY” |
| Abhängigkeiten | ”Verwendet in Report XY, Integration mit CRM” |
| Testfälle | ”Neue Kunden: Default ‘C’, High Priority benötigt Kontakt” |
Zusammenspiel Key User & Developer Extensibility
Oft werden beide Modelle kombiniert:
Schritt 1: Key User Extensibility├── Custom Field "Customer Priority" anlegen├── Einfache Defaultwert-Logik└── In UI verfügbar machen
Schritt 2: Developer Extensibility (bei Bedarf)├── Komplexe Berechnungslogik in ABAP├── Integration mit externem CRM└── Custom Report mit ALVMigration von Key User zu Developer
Wenn Key User Extensibility nicht mehr reicht:
- Custom Field beibehalten: Datenbasis bleibt
- Custom Logic ersetzen: ABAP-Implementierung erstellen
- BAdI implementieren: Volle ABAP-Funktionalität
- Key User Logic deaktivieren: Duplikate vermeiden
Praktisches Beispiel: Kundenbewertung
Anforderung
Ein Unternehmen möchte Kunden automatisch bewerten basierend auf:
- Umsatz der letzten 12 Monate
- Zahlungsverhalten
- Reklamationsquote
Umsetzung mit Key User Extensibility
Schritt 1: Custom Fields anlegen
Business Context: Business Partner - Customer
Custom Fields:1. YY1_REVENUE_12M (Amount) - Umsatz 12 Monate2. YY1_PAYMENT_SCORE (Number) - Zahlungsscore 1-53. YY1_COMPLAINT_RATE (Number) - Reklamationsquote %4. YY1_CUSTOMER_RATING (Code List) - Bewertung A/B/C/DSchritt 2: Custom Logic für Rating
Trigger: On Save
Regel 1:WENN YY1_REVENUE_12M > 100.000 UND YY1_PAYMENT_SCORE >= 4 UND YY1_COMPLAINT_RATE < 2DANN YY1_CUSTOMER_RATING = "A"
Regel 2:WENN YY1_REVENUE_12M > 50.000 UND YY1_PAYMENT_SCORE >= 3 UND YY1_COMPLAINT_RATE < 5DANN YY1_CUSTOMER_RATING = "B"
Regel 3:WENN YY1_REVENUE_12M > 10.000 UND YY1_PAYMENT_SCORE >= 2DANN YY1_CUSTOMER_RATING = "C"
Regel 4: (Default)DANN YY1_CUSTOMER_RATING = "D"Schritt 3: Custom CDS View für Analyse
View: YY1_CustomerRatingAnalysis
Felder:- Anzahl Kunden pro Rating- Durchschnittlicher Umsatz pro Rating- Trend vs. Vorjahr
Gruppierung: YY1_CUSTOMER_RATINGGrenzen dieser Lösung
Diese Key User-Lösung hat Grenzen:
- Umsatzdaten müssen manuell gepflegt werden
- Keine automatische Berechnung aus Belegen
- Keine Historisierung der Ratings
Für eine vollständige Lösung wäre Developer Extensibility nötig:
- Automatische Umsatzermittlung per ABAP
- Background Job für regelmäßige Neuberechnung
- Historientabelle für Ratingverlauf
Weiterführende Themen
- Developer Extensibility - Erweiterungen mit ABAP Cloud
- Custom Fields Deep Dive - Technische Details zu Custom Fields
- Clean Core Strategie - Extensibility im Kontext von Clean Core