Key User Extensibility: Extensiones sin acceso de desarrollador

Kategorie
ABAP Cloud
Veröffentlicht
Autor
Johannes

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:

AspectoKey User ExtensibilityDeveloper Extensibility
Grupo objetivoUsuarios funcionales, consultoresDesarrolladores ABAP
HerramientasApps Fiori, navegadorADT/Eclipse, BAS
ProgramaciónNinguna (Low-Code/No-Code)ABAP Cloud
FlexibilidadLimitadaControl total
TransporteAutomáticoManual/gCTS
DisponibilidadPublic Cloud, Private CloudTodas 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

  1. Abrir App: App Fiori “Custom Fields and Logic” (F1481)
  2. Elegir Business Context: p. ej. “Sales Order” o “Business Partner”
  3. Agregar campo: Click en botón “New”

Tipos de campo

Tipo de campoEjemploUso
TextCampo de observacionesTexto libre hasta 1333 caracteres
NumberNivel de descuentoEnteros o decimales
AmountMonto de bonificaciónCon moneda
QuantityCantidad adicionalCon unidad
DateFecha de revisiónFecha de calendario
TimeHora de procesamientoHora
CheckboxEstá verificadoSí/No
Code ListPrioridadDropdown con valores fijos

Ejemplo: Custom Field “Customer Priority”

Business Context: Business Partner - Customer
Field Label: Customer Priority
Technical Name: YY1_CUSTOMER_PRIORITY
Field Type: Code List
Values:
- A = Alta prioridad
- B = Prioridad media
- C = Baja prioridad
- D = Sin clasificación

Uso 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áticamente
extend 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

TriggerMomentoUso típico
On ModifyAl cambiar campoValidación de campo, valores predeterminados
On SaveAntes de guardarValidaciones complejas
After SaveDespués de guardarAcciones de seguimiento
DeterminationAutomáticamenteDerivació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 Logic
Business Context: Business Partner - Customer
Logic Type: Determination
Trigger: 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 Logic
Business Context: Business Partner - Customer
Logic Type: Validation
Trigger: 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ón
Campo1 = "Valor"
Campo2 <> "Valor"
Campo3 > 100
Campo4 >= 50
// Conexiones lógicas
Condicion1 Y Condicion2
Condicion1 O Condicion2
NO Condicion1
// Operaciones de campo
Campo1 + Campo2
Campo1 * Factor
LONGITUD(CampoTexto) > 10
HOY()

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 CustomerPriority

CDS View generado

@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

Limitaciones y restricciones

Key User Extensibility tiene límites claros:

Restricciones técnicas

RestricciónDetalles
Número de camposMáx. ~200 Custom Fields por Business Context
Longitud de campoTexto máx. 1333 caracteres
Lógica complejaSin bucles, sin llamadas externas
RendimientoCon muchos campos puede afectarse el rendimiento
DepuraciónAná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 objetos
No soportado: Integración con sistemas de terceros
No soportado: Procesamiento masivo
No soportado: UIs personalizadas (solo integración de campos)
No soportado: Background Jobs
No soportado: Transacciones propias

Comportamiento 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ón

Proceso 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
- Monitoreo

Documentación

Cada extensión debe documentar:

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

Migración de Key User a Developer

Cuando Key User Extensibility ya no es suficiente:

  1. Conservar Custom Field: La base de datos permanece
  2. Reemplazar Custom Logic: Crear implementación ABAP
  3. Implementar BAdI: Funcionalidad ABAP completa
  4. 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 meses
2. YY1_PAYMENT_SCORE (Number) - Score de pago 1-5
3. YY1_COMPLAINT_RATE (Number) - Tasa de reclamaciones %
4. YY1_CUSTOMER_RATING (Code List) - Calificación A/B/C/D

Paso 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 < 2
ENTONCES YY1_CUSTOMER_RATING = "A"
Regla 2:
SI YY1_REVENUE_12M > 50.000
Y YY1_PAYMENT_SCORE >= 3
Y YY1_COMPLAINT_RATE < 5
ENTONCES YY1_CUSTOMER_RATING = "B"
Regla 3:
SI YY1_REVENUE_12M > 10.000
Y YY1_PAYMENT_SCORE >= 2
ENTONCES 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_RATING

Lí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