Key User Extensibility permite a los usuarios clave extender sistemas SAP sin conocimientos de desarrollo. Este artículo explica el concepto, muestra ejemplos prácticos y diferencia Key User de Developer Extensibility.
Key User vs. Developer Extensibility
SAP distingue dos modelos de extensibilidad:
| Aspecto | Key User Extensibility | Developer Extensibility |
|---|---|---|
| Grupo objetivo | Usuarios funcionales, consultores | Desarrolladores ABAP |
| Herramientas | Apps Fiori, navegador | ADT/Eclipse, BAS |
| Programación | Ninguna (Low-Code/No-Code) | ABAP Cloud |
| Flexibilidad | Limitada | Control total |
| Transporte | Automático | Manual/gCTS |
| Disponibilidad | Public Cloud, Private Cloud | Todas las ediciones |
¿Cuándo usar Key User Extensibility?
Key User Extensibility es adecuada para:
- Extensiones de campo simples sin lógica compleja
- Ajustes rápidos en operación productiva
- Prototipos antes de implementación por desarrolladores
- Cambios impulsados por negocio sin cuello de botella de IT
¿Cuándo Developer Extensibility?
Developer Extensibility es mejor para:
- Lógica de negocio compleja con código ABAP
- Extensiones críticas de rendimiento
- Integración con sistemas externos
- Componentes reutilizables
Crear Custom Fields
Custom Fields es el escenario más común para Key User Extensibility.
Paso a paso: Crear Custom Field
- Abrir App: App Fiori “Custom Fields and Logic” (F1481)
- Elegir Business Context: p. ej. “Sales Order” o “Business Partner”
- Agregar campo: Click en botón “New”
Tipos de campo
| Tipo de campo | Ejemplo | Uso |
|---|---|---|
| Text | Campo de observaciones | Texto libre hasta 1333 caracteres |
| Number | Nivel de descuento | Enteros o decimales |
| Amount | Monto de bonificación | Con moneda |
| Quantity | Cantidad adicional | Con unidad |
| Date | Fecha de revisión | Fecha de calendario |
| Time | Hora de procesamiento | Hora |
| Checkbox | Está verificado | Sí/No |
| Code List | Prioridad | Dropdown con valores fijos |
Ejemplo: Custom Field “Customer Priority”
Business Context: Business Partner - CustomerField Label: Customer PriorityTechnical Name: YY1_CUSTOMER_PRIORITYField Type: Code List
Values:- A = Alta prioridad- B = Prioridad media- C = Baja prioridad- D = Sin clasificaciónUso en UIs
Después de crear, el campo puede activarse para:
- Apps Fiori Elements: Integración automática
- Apps transaccionales: En formularios y listas
- Apps analíticas: En reports y dashboards
Trasfondo técnico
Custom Fields se implementan técnicamente como:
- Extension Include: Incorporado en la tabla estándar
- CDS View Extension: Disponible automáticamente en views
- Service Extension: Expuesto en servicios OData
-- Extensión CDS View generada automáticamenteextend view I_BusinessPartner with ZE_BusinessPartner_CF { YY1_CUSTOMER_PRIORITY as CustomerPriority}Custom Logic con BAdIs
Para lógica de negocio simple, Key User Extensibility ofrece BAdIs predefinidos.
Triggers BAdI disponibles
| Trigger | Momento | Uso típico |
|---|---|---|
| On Modify | Al cambiar campo | Validación de campo, valores predeterminados |
| On Save | Antes de guardar | Validaciones complejas |
| After Save | Después de guardar | Acciones de seguimiento |
| Determination | Automáticamente | Derivación de valores |
Ejemplo 1: Establecer valor predeterminado
Escenario: Para nuevos clientes, el campo “Customer Priority” debe establecerse automáticamente en “C”.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: DeterminationTrigger: On Create
Condición: Número de cliente está inicial
Acción: Establecer campo "YY1_CUSTOMER_PRIORITY" = "C"La interfaz gráfica genera:
" Código generado (no visible directamente)IF customer-customer_id IS INITIAL. customer-yy1_customer_priority = 'C'.ENDIF.Ejemplo 2: Validación de campo
Escenario: Clientes con Priority “A” deben tener un contacto.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: ValidationTrigger: On Save
Condición: YY1_CUSTOMER_PRIORITY = "A" Y Contacto está vacío
Acción: Error: "Los clientes de alta prioridad requieren un contacto"Expresiones avanzadas
Key User Logic soporta:
// Operadores de comparaciónCampo1 = "Valor"Campo2 <> "Valor"Campo3 > 100Campo4 >= 50
// Conexiones lógicasCondicion1 Y Condicion2Condicion1 O Condicion2NO Condicion1
// Operaciones de campoCampo1 + Campo2Campo1 * FactorLONGITUD(CampoTexto) > 10HOY()Custom CDS Views
Los Key Users también pueden crear sus propios views analíticos.
App Custom CDS Views
La App “Custom CDS Views” (F2170) permite:
- Nuevos views basados en views existentes
- Agregar campos calculados
- Definir filtros y agregaciones
Ejemplo: Vista general de clientes con Priority
View base: I_BusinessPartner
Custom View: YY1_CustomerOverview
Campos:- BusinessPartner (de I_BusinessPartner)- BusinessPartnerName (de I_BusinessPartner)- CustomerPriority (Custom Field)- OrderCount (Calculado: Cantidad de pedidos)- TotalRevenue (Calculado: Suma de facturación)
Filtro:- BusinessPartnerCategory = '1' (solo clientes)
Agregación:- Agrupación por CustomerPriorityCDS View generado
@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.TransactionCurrencyLimitaciones y restricciones
Key User Extensibility tiene límites claros:
Restricciones técnicas
| Restricción | Detalles |
|---|---|
| Número de campos | Máx. ~200 Custom Fields por Business Context |
| Longitud de campo | Texto máx. 1333 caracteres |
| Lógica compleja | Sin bucles, sin llamadas externas |
| Rendimiento | Con muchos campos puede afectarse el rendimiento |
| Depuración | Análisis de errores limitado |
Restricciones funcionales
- Sin lógica de tablas: Sin procesamiento de tablas internas
- Sin llamadas API: Sin RFC, HTTP o llamadas OData
- Sin workflows: Solo triggers predefinidos
- Sin Unit Testing: Solo pruebas manuales
Escenarios no soportados
No soportado: Cálculos complejos sobre múltiples objetosNo soportado: Integración con sistemas de tercerosNo soportado: Procesamiento masivoNo soportado: UIs personalizadas (solo integración de campos)No soportado: Background JobsNo soportado: Transacciones propiasComportamiento en upgrades
- Custom Fields se conservan en upgrades
- Custom Logic puede desactivarse en Breaking Changes
- Se recomienda revisión regular
Gobernanza y mejores prácticas
Convenciones de nomenclatura
Prefijo para Custom Objects: YY1_ o ZZ1_(asignado automáticamente por el sistema)
Recomendación para nombres de campos:- Descriptivo: YY1_CUSTOMER_PRIORITY en lugar de YY1_FIELD01- Consistente: Mismos términos para mismos conceptos- Documentado: Mantener label y descripciónProceso para Key User Extensibility
1. Documentar requisito - ¿Qué se debe extender? - ¿Por qué no es suficiente el estándar?
2. Evaluación de factibilidad - ¿Es suficiente Key User Extensibility? - ¿O se necesita Developer Extensibility?
3. Implementación - Crear en sistema de desarrollo - Probar
4. Transporte - Transportar a sistema de calidad - Prueba de aceptación
5. Go-Live - Activar en producción - MonitoreoDocumentación
Cada extensión debe documentar:
| Aspecto | Ejemplo |
|---|---|
| Propósito | ”Permite priorización de clientes para ventas” |
| Business Owner | ”Dirección de ventas” |
| Nombre técnico | ”YY1_CUSTOMER_PRIORITY” |
| Dependencias | ”Usado en Report XY, Integración con CRM” |
| Casos de prueba | ”Nuevos clientes: Default ‘C’, Alta prioridad requiere contacto” |
Interacción Key User y Developer Extensibility
A menudo se combinan ambos modelos:
Paso 1: Key User Extensibility├── Crear Custom Field "Customer Priority"├── Lógica simple de valor predeterminado└── Disponibilizar en UI
Paso 2: Developer Extensibility (si es necesario)├── Lógica de cálculo compleja en ABAP├── Integración con CRM externo└── Custom Report con ALVMigración de Key User a Developer
Cuando Key User Extensibility ya no es suficiente:
- Conservar Custom Field: La base de datos permanece
- Reemplazar Custom Logic: Crear implementación ABAP
- Implementar BAdI: Funcionalidad ABAP completa
- Desactivar Key User Logic: Evitar duplicados
Ejemplo práctico: Calificación de clientes
Requisito
Una empresa quiere calificar clientes automáticamente basándose en:
- Facturación de los últimos 12 meses
- Comportamiento de pago
- Tasa de reclamaciones
Implementación con Key User Extensibility
Paso 1: Crear Custom Fields
Business Context: Business Partner - Customer
Custom Fields:1. YY1_REVENUE_12M (Amount) - Facturación 12 meses2. YY1_PAYMENT_SCORE (Number) - Score de pago 1-53. YY1_COMPLAINT_RATE (Number) - Tasa de reclamaciones %4. YY1_CUSTOMER_RATING (Code List) - Calificación A/B/C/DPaso 2: Custom Logic para Rating
Trigger: On Save
Regla 1:SI YY1_REVENUE_12M > 100.000 Y YY1_PAYMENT_SCORE >= 4 Y YY1_COMPLAINT_RATE < 2ENTONCES YY1_CUSTOMER_RATING = "A"
Regla 2:SI YY1_REVENUE_12M > 50.000 Y YY1_PAYMENT_SCORE >= 3 Y YY1_COMPLAINT_RATE < 5ENTONCES YY1_CUSTOMER_RATING = "B"
Regla 3:SI YY1_REVENUE_12M > 10.000 Y YY1_PAYMENT_SCORE >= 2ENTONCES YY1_CUSTOMER_RATING = "C"
Regla 4: (Default)ENTONCES YY1_CUSTOMER_RATING = "D"Paso 3: Custom CDS View para análisis
View: YY1_CustomerRatingAnalysis
Campos:- Cantidad de clientes por Rating- Facturación promedio por Rating- Tendencia vs. año anterior
Agrupación: YY1_CUSTOMER_RATINGLímites de esta solución
Esta solución Key User tiene límites:
- Los datos de facturación deben mantenerse manualmente
- Sin cálculo automático desde documentos
- Sin historización de ratings
Para una solución completa se necesitaría Developer Extensibility:
- Determinación automática de facturación con ABAP
- Background Job para recálculo regular
- Tabla de historial para seguimiento de rating
Temas relacionados
- Developer Extensibility - Extensiones con ABAP Cloud
- Custom Fields Deep Dive - Detalles técnicos de Custom Fields
- Estrategia Clean Core - Extensibilidad en el contexto de Clean Core