Key User Extensibility : Extensions sans acces developpeur

Key User Extensibility permet aux utilisateurs metier d’etendre les systemes SAP sans connaissances en developpement. Cet article explique le concept, montre des exemples pratiques et distingue Key User de Developer Extensibility.

Key User vs. Developer Extensibility

SAP distingue deux modeles d’extensibilite :

Quand utiliser Key User Extensibility ?

Key User Extensibility convient pour :

• Extensions de champs simples sans logique complexe
• Adaptations rapides en cours d’exploitation
• Prototypage avant implementation par les developpeurs
• Modifications pilotees par le metier sans goulot d’etranglement IT

Quand utiliser Developer Extensibility ?

Developer Extensibility est preferable pour :

• Logique metier complexe avec code ABAP
• Extensions critiques pour la performance
• Integration avec des systemes externes
• Composants reutilisables

Creer des Custom Fields

Les Custom Fields sont le scenario le plus courant pour Key User Extensibility.

Etape par etape : Creer un Custom Field

1. Ouvrir l’application : Application Fiori “Custom Fields and Logic” (F1481)
2. Choisir le contexte metier : ex. “Sales Order” ou “Business Partner”
3. Ajouter un champ : Cliquer sur le bouton “New”

Types de champs

Exemple : 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

Utilisation dans les UIs

Apres la creation, le champ peut etre active pour :

• Applications Fiori Elements : Integration automatique
• Applications transactionnelles : Dans les formulaires et listes
• Applications analytiques : Dans les rapports et tableaux de bord

Contexte technique

Les Custom Fields sont techniquement :

• Extension Include : Integres dans la table standard
• CDS View Extension : Automatiquement disponibles dans les vues
• Service Extension : Exposes dans les services OData

-- CDS View Extension generee automatiquement
extend view I_BusinessPartner with ZE_BusinessPartner_CF {
  YY1_CUSTOMER_PRIORITY as CustomerPriority
}

Custom Logic avec BAdIs

Pour une logique metier simple, Key User Extensibility offre des BAdIs predefinies.

Declencheurs BAdI disponibles

Exemple 1 : Definir une valeur par defaut

Scenario : Pour les nouveaux clients, le champ “Customer Priority” doit etre automatiquement defini a “C”.

App: Custom Fields and Logic
Business Context: Business Partner - Customer
Logic Type: Determination
Trigger: On Create

Condition: Numero client est initial

Action:
  Definir le champ "YY1_CUSTOMER_PRIORITY" = "C"

L’interface graphique genere :

" Code genere (non directement visible)
IF customer-customer_id IS INITIAL.
  customer-yy1_customer_priority = 'C'.
ENDIF.

Exemple 2 : Validation de champ

Scenario : Les clients avec Priority “A” doivent avoir un contact.

App: Custom Fields and Logic
Business Context: Business Partner - Customer
Logic Type: Validation
Trigger: On Save

Condition:
  YY1_CUSTOMER_PRIORITY = "A"
  ET Contact est vide

Action:
  Erreur: "Les clients High-Priority necessitent un contact"

Expressions avancees

Key User Logic supporte :

// Operateurs de comparaison
Champ1 = "Valeur"
Champ2 <> "Valeur"
Champ3 > 100
Champ4 >= 50

// Liaisons logiques
Condition1 ET Condition2
Condition1 OU Condition2
NON Condition1

// Operations sur les champs
Champ1 + Champ2
Champ1 * Facteur
LONGUEUR(ChampTexte) > 10
AUJOURD'HUI()

Custom CDS Views

Les Key Users peuvent egalement creer leurs propres vues analytiques.

Application Custom CDS Views

L’application “Custom CDS Views” (F2170) permet :

• De nouvelles vues basees sur des vues existantes
• D’ajouter des champs calcules
• De definir des filtres et des aggregations

Exemple : Apercu des clients avec Priority

Vue de base : I_BusinessPartner

Custom View: YY1_CustomerOverview

Champs:
- BusinessPartner (de I_BusinessPartner)
- BusinessPartnerName (de I_BusinessPartner)
- CustomerPriority (Custom Field)
- OrderCount (Calcule : Nombre de commandes)
- TotalRevenue (Calcule : Somme du chiffre d'affaires)

Filtre:
- BusinessPartnerCategory = '1' (clients uniquement)

Aggregation:
- Groupement par CustomerPriority

CDS View generee

@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

Restrictions et limites

Key User Extensibility a des limites claires :

Restrictions techniques

Restrictions fonctionnelles

• Pas de logique de table : Pas de traitement de tables internes
• Pas d’appels API : Pas de RFC, HTTP ou appels OData
• Pas de workflows : Uniquement des declencheurs predefinis
• Pas de tests unitaires : Pas de tests automatises

Scenarios non supportes

X Calculs complexes sur plusieurs objets
X Integration avec des systemes tiers
X Traitement de masse
X UIs personnalisees (uniquement integration de champs)
X Jobs d'arriere-plan
X Transactions personnalisees

Comportement lors des mises a jour

• Les Custom Fields sont preserves lors des mises a jour
• La Custom Logic peut etre desactivee en cas de changements majeurs
• Verification reguliere recommandee

Gouvernance et bonnes pratiques

Conventions de nommage

Prefixe pour Custom Objects: YY1_ ou ZZ1_
(attribue automatiquement par le systeme)

Recommandation pour les noms de champs:
- Descriptif: YY1_CUSTOMER_PRIORITY au lieu de YY1_FIELD01
- Coherent: Memes termes pour les memes concepts
- Documente: Maintenir le label et la description

Processus pour Key User Extensibility

1. Documenter l'exigence
   - Qu'est-ce qui doit etre etendu ?
   - Pourquoi le standard ne suffit-il pas ?

2. Analyse de faisabilite
   - Key User Extensibility est-elle suffisante ?
   - Ou faut-il Developer Extensibility ?

3. Implementation
   - Creer dans le systeme de developpement
   - Tester

4. Transport
   - Transporter vers le systeme de qualite
   - Test de recette

5. Go-Live
   - Activer en production
   - Monitoring

Documentation

Chaque extension doit documenter :

Interaction Key User & Developer Extensibility

Souvent, les deux modeles sont combines :

Etape 1: Key User Extensibility
├── Creer Custom Field "Customer Priority"
├── Logique simple de valeur par defaut
└── Rendre disponible dans l'UI

Etape 2: Developer Extensibility (si necessaire)
├── Logique de calcul complexe en ABAP
├── Integration avec CRM externe
└── Rapport personnalise avec ALV

Migration de Key User vers Developer

Quand Key User Extensibility ne suffit plus :

1. Conserver le Custom Field : La base de donnees reste
2. Remplacer la Custom Logic : Creer une implementation ABAP
3. Implementer un BAdI : Fonctionnalite ABAP complete
4. Desactiver la Key User Logic : Eviter les doublons

Exemple pratique : Evaluation des clients

Exigence

Une entreprise souhaite evaluer automatiquement les clients en fonction de :

• Chiffre d’affaires des 12 derniers mois
• Comportement de paiement
• Taux de reclamation

Mise en oeuvre avec Key User Extensibility

Etape 1 : Creer les Custom Fields

Business Context: Business Partner - Customer

Custom Fields:
1. YY1_REVENUE_12M (Amount) - CA 12 mois
2. YY1_PAYMENT_SCORE (Number) - Score de paiement 1-5
3. YY1_COMPLAINT_RATE (Number) - Taux de reclamation %
4. YY1_CUSTOMER_RATING (Code List) - Evaluation A/B/C/D

Etape 2 : Custom Logic pour l’evaluation

Trigger: On Save

Regle 1:
SI YY1_REVENUE_12M > 100.000
  ET YY1_PAYMENT_SCORE >= 4
  ET YY1_COMPLAINT_RATE < 2
ALORS YY1_CUSTOMER_RATING = "A"

Regle 2:
SI YY1_REVENUE_12M > 50.000
  ET YY1_PAYMENT_SCORE >= 3
  ET YY1_COMPLAINT_RATE < 5
ALORS YY1_CUSTOMER_RATING = "B"

Regle 3:
SI YY1_REVENUE_12M > 10.000
  ET YY1_PAYMENT_SCORE >= 2
ALORS YY1_CUSTOMER_RATING = "C"

Regle 4: (Defaut)
ALORS YY1_CUSTOMER_RATING = "D"

Etape 3 : Custom CDS View pour l’analyse

View: YY1_CustomerRatingAnalysis

Champs:
- Nombre de clients par evaluation
- CA moyen par evaluation
- Tendance vs. annee precedente

Groupement: YY1_CUSTOMER_RATING

Limites de cette solution

Cette solution Key User a des limites :

• Les donnees de CA doivent etre maintenues manuellement
• Pas de calcul automatique a partir des documents
• Pas d’historisation des evaluations

Pour une solution complete, Developer Extensibility serait necessaire :

• Determination automatique du CA en ABAP
• Job d’arriere-plan pour recalcul regulier
• Table d’historique pour l’evolution des evaluations

Sujets connexes

• Developer Extensibility - Extensions avec ABAP Cloud
• Custom Fields Deep Dive - Details techniques sur les Custom Fields
• Strategie Clean Core - Extensibilite dans le contexte de Clean Core