Key User Extensibility vs. Developer Extensibility : Quand utiliser quoi ?

┌────────────────────────────────────────────────────────┐
│                    Clean Core                          │
├────────────────────────────────────────────────────────┤
│                                                        │
│  ┌────────────────────────────────────────────────┐   │
│  │         In-Stack Extensibility                  │   │
│  │  ┌──────────────────┐  ┌────────────────────┐  │   │
│  │  │   Key User       │  │    Developer       │  │   │
│  │  │   Extensibility  │  │    Extensibility   │  │   │
│  │  │   (No-Code)      │  │    (ABAP Cloud)    │  │   │
│  │  └──────────────────┘  └────────────────────┘  │   │
│  └────────────────────────────────────────────────┘   │
│                                                        │
│  ┌────────────────────────────────────────────────┐   │
│  │         Side-by-Side Extensibility              │   │
│  │         (BTP ABAP Environment, CAP, etc.)       │   │
│  └────────────────────────────────────────────────┘   │
│                                                        │
└────────────────────────────────────────────────────────┘

" Exemple : Determination de prix complexe avec service externe
METHOD calculate_special_pricing.
  " Appeler une API externe
  DATA(lo_http_client) = cl_web_http_client_manager=>create_by_http_destination(
    i_destination = cl_http_destination_provider=>create_by_comm_arrangement(
      comm_scenario = 'Z_PRICING_SERVICE' )
  ).

  " Calcul complexe sur plusieurs tables
  SELECT FROM I_SalesOrderItem AS item
    INNER JOIN I_ProductValuation AS val
      ON item~Product = val~Product
    WHERE item~SalesOrder = @iv_sales_order
    INTO TABLE @DATA(lt_items).

  LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<item>).
    " Algorithme avec plusieurs facteurs
    <item>-custom_price = calculate_tiered_price(
      iv_quantity   = <item>-quantity
      iv_base_price = <item>-net_price
      iv_customer   = <item>-customer
    ).
  ENDLOOP.
ENDMETHOD.

1. L'exigence est-elle un simple Custom Field ?
   → OUI : Key User Extensibility (App Custom Fields)
   → NON : passer a la question 2

2. La logique se limite-t-elle a un seul enregistrement ?
   → OUI : passer a la question 3
   → NON : Developer Extensibility (logique de table)

3. La logique peut-elle etre representee par des regles SI/ALORS ?
   → OUI : Key User Extensibility (Custom Logic)
   → NON : Developer Extensibility (code ABAP)

4. Un systeme externe doit-il etre appele ?
   → OUI : Developer Extensibility (HTTP Client)
   → NON : passer a la question 5

5. Des developpeurs ABAP sont-ils disponibles ?
   → OUI : Developer Extensibility (meilleure maintenabilite)
   → NON : Key User Extensibility (approche pragmatique)

✓ Les deux modeles sont conformes Clean Core
✓ Pas de modification des objets standard
✓ APIs stables garanties par SAP
✓ Tests de mise a jour automatiques par SAP

┌─────────────────────────────────────────────────────────┐
│                 EXIGENCE                                │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           1. EVALUATION (Comite Extensibilite)          │
│  • L'extension est-elle necessaire ? (verifier standard)│
│  • Quel type d'extensibilite convient ?                 │
│  • Ressources et planning                               │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           2. DECISION                                   │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │  Key User   │    │  Developer  │    │ Side-by-Side│  │
│  │Extensibility│    │Extensibility│    │   (BTP)     │  │
│  └─────────────┘    └─────────────┘    └─────────────┘  │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           3. IMPLEMENTATION                             │
│  • Selon standards et conventions de nommage            │
│  • Avec documentation                                   │
│  • Avec tests                                           │
└───────────────────────┬─────────────────────────────────┘
                        ▼
┌─────────────────────────────────────────────────────────┐
│           4. GESTION DU CYCLE DE VIE                    │
│  • Revues regulieres                                    │
│  • Preparation aux mises a jour                         │
│  • Retrait des extensions obsoletes                     │
└─────────────────────────────────────────────────────────┘

Key User Extensibility:
├── Attribue automatiquement: YY1_*, ZZ1_*
└── Pas d'influence manuelle

Developer Extensibility:
├── Namespace: Z* ou /CLIENT/*
├── Extension Structures: ZZ1_<OBJET>_EXT
├── BAdI Classes: ZCL_<DOMAINE>_<FONCTION>
├── CDS Extensions: ZE_<BASE>_<OBJECTIF>
└── Behavior Extensions: ZBP_<ENTITE>_EXT

Verification trimestrielle de toutes les extensions:
├── L'extension est-elle encore utilisee ?
├── Correspond-elle encore aux exigences ?
├── Y a-t-il des problemes de performance ?
├── La documentation est-elle a jour ?
└── SAP prevoit-elle une release affectant l'extension ?

Phase 1: Preparation
├── Documenter les exigences
├── Analyser la Key User Logic
└── Creer le concept Developer

Phase 2: Implementation
├── Creer BAdI ou Behavior Extension
├── Implementer la logique en ABAP Cloud
└── Ecrire les tests unitaires

Phase 3: Migration
├── Fonctionnement parallele (les deux actifs, Key User uniquement logging)
├── Validation des resultats
└── Desactiver la Key User Logic

Phase 4: Cloture
├── Mettre a jour la documentation
├── Former les metiers
└── Supprimer la Key User Logic (optionnel)

Priorisation des clients:

1. Custom Field (Key User)
   └── YY1_CUSTOMER_PRIORITY: Priorite A/B/C/D

2. Logique simple (Key User)
   └── Default a la creation: "C"

3. Calcul complexe (Developer)
   └── Recalcul automatique base sur:
       • CA des 12 derniers mois
       • Comportement de paiement
       • Taux de reclamation

4. Integration (Developer)
   └── Sync avec systeme CRM externe

App: Custom Fields and Logic (F1481)
Business Context: Business Partner - Customer
Field: Industry Classification
Type: Code List (Automotive, Retail, Manufacturing, ...)

CLASS zcl_credit_check_badi IMPLEMENTATION.
  METHOD check_credit.
    " Recuperer le rating de credit externe
    DATA(lo_client) = get_http_client( ).
    DATA(lv_rating) = lo_client->get_credit_rating(
      iv_customer = is_order-sold_to_party
    ).

    IF lv_rating < minimum_rating( is_order-net_amount ).
      RAISE EXCEPTION TYPE zcx_credit_block
        MESSAGE e001(zcredit) WITH is_order-sold_to_party.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

App: Custom CDS Views (F2170)
Base: I_SalesOrder
Champs: Region, Sum(NetAmount), Count(SalesOrder)
Groupement: Par Region
Filtre: Exercice en cours