Key User Extensibility: Erweiterungen ohne Entwicklerzugriff

kategorie
ABAP Cloud
Veröffentlicht
autor
Johannes

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:

AspektKey User ExtensibilityDeveloper Extensibility
ZielgruppeFachanwender, ConsultantsABAP-Entwickler
WerkzeugeFiori Apps, BrowserADT/Eclipse, BAS
ProgrammierungKeine (Low-Code/No-Code)ABAP Cloud
FlexibilitätEingeschränktVolle Kontrolle
TransportAutomatischManuell/gCTS
VerfügbarkeitPublic Cloud, Private CloudAlle 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

  1. App öffnen: Fiori App “Custom Fields and Logic” (F1481)
  2. Business Context wählen: z.B. “Sales Order” oder “Business Partner”
  3. Feld hinzufügen: Button “New” klicken

Feldtypen

FeldtypBeispielVerwendung
TextBemerkungsfeldFreitext bis 1333 Zeichen
NumberRabattstufeGanzzahlen oder Dezimal
AmountBonusbetragMit Währung
QuantityZusatzmengeMit Einheit
DatePrüfdatumKalenderdatum
TimeBearbeitungszeitUhrzeit
CheckboxIst geprüftJa/Nein
Code ListPrioritätDropdown mit festen Werten

Beispiel: Custom Field “Customer Priority”

Business Context: Business Partner - Customer
Field Label: Customer Priority
Technical Name: YY1_CUSTOMER_PRIORITY
Field Type: Code List
Values:
- A = High Priority
- B = Medium Priority
- C = Low Priority
- D = No Classification

Verwendung 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 Extension
extend 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

TriggerZeitpunktTypische Nutzung
On ModifyBei FeldänderungFeldvalidierung, Defaultwerte
On SaveVor dem SpeichernKomplexe Validierungen
After SaveNach dem SpeichernFolgeaktionen
DeterminationAutomatischWertableitung

Beispiel 1: Defaultwert setzen

Szenario: Bei neuen Kunden soll das Feld “Customer Priority” automatisch auf “C” gesetzt werden.

App: Custom Fields and Logic
Business Context: Business Partner - Customer
Logic Type: Determination
Trigger: 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 Logic
Business Context: Business Partner - Customer
Logic Type: Validation
Trigger: 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:

// Vergleichsoperatoren
Feld1 = "Wert"
Feld2 <> "Wert"
Feld3 > 100
Feld4 >= 50
// Logische Verknüpfungen
Bedingung1 UND Bedingung2
Bedingung1 ODER Bedingung2
NICHT Bedingung1
// Feldoperationen
Feld1 + Feld2
Feld1 * Faktor
LÄNGE(Textfeld) > 10
HEUTE()

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 CustomerPriority

Generierte CDS View

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define 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.TransactionCurrency

Einschränkungen und Grenzen

Key User Extensibility hat klare Grenzen:

Technische Einschränkungen

EinschränkungDetails
Anzahl FelderMax. ~200 Custom Fields pro Business Context
FeldlängeText max. 1333 Zeichen
Komplexe LogikKeine Schleifen, keine externen Aufrufe
PerformanceBei vielen Feldern kann Performance leiden
DebuggingEingeschrä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 Transaktionen

Upgrade-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 pflegen

Prozess 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
- Monitoring

Dokumentation

Jede Erweiterung sollte dokumentieren:

AspektBeispiel
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 ALV

Migration von Key User zu Developer

Wenn Key User Extensibility nicht mehr reicht:

  1. Custom Field beibehalten: Datenbasis bleibt
  2. Custom Logic ersetzen: ABAP-Implementierung erstellen
  3. BAdI implementieren: Volle ABAP-Funktionalität
  4. 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 Monate
2. YY1_PAYMENT_SCORE (Number) - Zahlungsscore 1-5
3. YY1_COMPLAINT_RATE (Number) - Reklamationsquote %
4. YY1_CUSTOMER_RATING (Code List) - Bewertung A/B/C/D

Schritt 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 < 2
DANN YY1_CUSTOMER_RATING = "A"
Regel 2:
WENN YY1_REVENUE_12M > 50.000
UND YY1_PAYMENT_SCORE >= 3
UND YY1_COMPLAINT_RATE < 5
DANN YY1_CUSTOMER_RATING = "B"
Regel 3:
WENN YY1_REVENUE_12M > 10.000
UND YY1_PAYMENT_SCORE >= 2
DANN 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_RATING

Grenzen 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