Imagine un requisito hipotético de control de pedidos ya aprobado para una migración SAP. Su implementación actual lee datos de SAP, aplica una validación y bloquea una contabilización no válida. Trasladar ese código a una aplicación externa podría satisfacer una preferencia arquitectónica y dejar sin resolver la cuestión esencial: si el diseño propuesto puede seguir aplicando el control dentro del límite transaccional requerido.
Una estrategia de extensiones clean core en SAP debe preservar el comportamiento de negocio necesario mediante mecanismos admitidos, no asignar todas las extensiones a un entorno de ejecución independiente. Las directrices de extensibilidad de SAP distinguen entre extensiones estrechamente acopladas y aplicaciones débilmente acopladas, y las orientan hacia distintas opciones de implementación. Para arquitectos y responsables de la migración, el entregable práctico es un registro de decisión por capacidad: qué se hará con la implementación existente, por qué encaja esa ubicación y qué dependencias pendientes impiden aprobarla.
Separe la capacidad que se conserva de su código actual
Aprobar una capacidad de negocio no equivale a aprobar la migración de su implementación actual sin cambios. La ficha para aprobar personalizaciones del ERP establece la decisión previa: aprobar el requisito antes de elegir la implementación y tener en cuenta las obligaciones continuas de responsabilidad, interfaces, pruebas y soporte. Aquí damos por hecho que el requisito ha superado esa evaluación. La tarea consiste en determinar cómo debe funcionar en el entorno SAP de destino.
Comience el registro de decisión con una descripción de negocio, no con una lista de objetos. Identifique al responsable del proceso, el resultado requerido y la condición de aceptación. Después, incorpore las dependencias técnicas actuales: objetos personalizados, modificaciones, implementaciones de ampliaciones, lecturas y escrituras de datos, procesamiento programado, interfaces y consumidores posteriores. Pida al equipo técnico que demuestre cómo contribuyen esas dependencias al resultado aprobado.
Asigne una decisión explícita a la implementación:
- Retirar: eliminar una implementación redundante conservando la capacidad aprobada en otro lugar. Si la propia capacidad ha dejado de ser necesaria, devuelva esa decisión al responsable de negocio.
- Sustituir por funcionalidad estándar: demostrar que la funcionalidad y la configuración de destino satisfacen la condición de aceptación y, después, eliminar la implementación a medida.
- Adaptar dentro del núcleo SAP: identificar un mecanismo de extensión admitido que encaje con la proximidad requerida a los datos, las transacciones o el comportamiento de la aplicación.
- Trasladar a una extensión side-by-side: establecer que el acceso remoto admitido y un ciclo de vida operativo independiente encajan con el requisito.
- Bloqueada: mantener una elección provisional con un responsable del asunto pendiente, en lugar de presentar una preferencia arquitectónica como un diseño aprobado.
Mantenga separados los hallazgos técnicos y la decisión sobre la implementación. Para cualquier informe de análisis utilizado en la migración de código personalizado SAP, registre su alcance, sus supuestos sobre el destino y sus limitaciones documentadas. Exija al equipo que explique la consecuencia de negocio de cada hallazgo. Un hallazgo técnico debe informar la decisión, no sustituir la aceptación del responsable del proceso ni demostrar por sí solo que una sustitución conserva el comportamiento requerido.
Condicione la aprobación al despliegue, la versión y las interfaces admitidas
El nombre del producto de destino, por sí solo, es demasiado impreciso para el registro de una extensión. Especifique si el despliegue propuesto es Public Edition, Private Edition u on-premises, junto con su versión y los componentes pertinentes. Después, exija documentación vigente y específica del destino para el mecanismo propuesto. No dé por válida la aprobación de un mecanismo en otro despliegue o versión sin comprobar que resulta aplicable a esta decisión.
La guía de extensibilidad ABAP de SAP orienta los escenarios estrechamente acoplados hacia la extensibilidad de usuario clave o de desarrollador on-stack. Sus ejemplos incluyen modificar conjuntamente datos del cliente y de SAP con consistencia transaccional, ampliar la interfaz de usuario o el modelo de datos de una aplicación e implementar un punto de extensión de una aplicación. Esto justifica considerar una solución on-stack. No demuestra que exista el punto de extensión requerido para su aplicación y destino concretos.
Para una opción on-stack, pregunte si el requisito encaja en un mecanismo disponible de usuario clave o requiere una implementación profesional de desarrollador. Haga que el equipo identifique el punto de extensión concreto y todos los objetos SAP que consume el diseño. Si propone ABAP Cloud, exija evidencia de las restricciones del lenguaje aplicables, las dependencias permitidas y los requisitos relativos a objetos liberados en el entorno de destino. Evite aprobar un diseño solo porque la propuesta emplea la terminología adecuada.
Aplique el mismo rigor a las API liberadas de SAP. Registre la interfaz exacta, las operaciones necesarias, el modelo de consumo permitido, su estado de liberación, el contrato de compatibilidad aplicable y las restricciones documentadas. Una interfaz de lectura no demuestra que exista una operación de escritura admitida. Cuando el diseño dependa de un evento, verifique su significado y el acceso posterior necesario, en lugar de tratar la notificación como una integración de negocio completa.
Resuelva estas dependencias en paralelo al calendario de migración. Utilice el registro del horizonte de mantenimiento de SAP ECC para vincular las decisiones sobre el destino y las interfaces con el plan general de transición. Mantenga visible cualquier dependencia pendiente de una API o un punto de extensión como un bloqueo de la entrega, con un responsable de la decisión, en lugar de ocultarla dentro de una estimación general de desarrollo.
Deje que el límite transaccional determine la hipótesis inicial de ubicación
La ubicación resulta más clara cuando el responsable del proceso especifica qué debe completarse o fallar de forma conjunta. SAP identifica la extensibilidad side-by-side en SAP BTP como la opción predeterminada para aplicaciones débilmente acopladas que utilizan datos replicados o API remotas y no requieren que los datos personalizados y los del núcleo se modifiquen juntos dentro de una misma transacción. Esa distinción es más útil que una instrucción general de sacar el código personalizado del núcleo.
Ejemplo hipotético: validación antes de una contabilización
Suponga que un control obligatorio debe rechazar una transacción de negocio no válida antes de su contabilización, utilizando los valores actuales de la transacción. Considere una implementación on-stack como opción inicial, porque el requisito exige un acoplamiento transaccional estrecho. La aprobación sigue dependiendo de encontrar un punto de extensión admitido con los datos y el momento de ejecución necesarios. Ni este escenario ni las directrices generales de ubicación confirman que exista tal punto.
Pida al equipo que demuestre una contabilización aceptada, otra rechazada y el estado de negocio resultante. Si propone una validación remota, exija una explicación precisa de lo que sucede cuando la respuesta se retrasa o no está disponible. El responsable del proceso debe aceptar el comportamiento durante la espera, la política ante fallos y la cobertura del control en todas las vías de contabilización pertinentes. Una llamada remota correcta, por sí sola, no es una prueba de aceptación suficiente.
Ejemplo hipotético: flujo externo de revisión documental
Suponga ahora que un equipo externo revisa documentos justificativos después de crear un registro y que el negocio acepta un estado pendiente mientras continúa la revisión. Una ubicación side-by-side es una opción inicial razonable si la revisión no necesita confirmarse de forma atómica con la transacción SAP original. Antes de aprobarla, verifique el acceso admitido al registro, la operación de actualización necesaria y el patrón de comunicación permitido en el destino exacto.
Pruebe qué sucede si la revisión termina después de una cancelación, se rechaza una actualización, se pierde una respuesta o se envía de nuevo la misma confirmación de finalización. Exija que el diseño explique el tratamiento de duplicados, la conciliación y la recuperación autorizada. Si el requisito cambia y la revisión debe impedir la contabilización original, reabra la decisión sobre la ubicación. Lo que ha cambiado es el requisito transaccional, no solo un detalle de integración.
Complete la matriz de decisión con evidencias operativas
Un diagrama de arquitectura no basta para asignar la responsabilidad continua. La guía de SAP para elegir una opción de extensibilidad distingue entre la gestión del ciclo de vida integrada con el núcleo para el desarrollo ABAP personalizado y las extensiones de usuario clave, y la gestión independiente del ciclo de vida de las extensiones side-by-side. Atribuye la estabilidad del ciclo de vida de estas últimas a API y eventos estables, no simplemente a la separación del núcleo.
Traduzca esa distinción en tareas con responsables. Pregunte quién publica la extensión, quién comprueba su compatibilidad con el destino SAP y quién acepta el flujo de negocio completo después de que cambie cualquiera de las partes. No apruebe una supuesta reducción del trabajo de actualización o del coste solo porque la implementación se traslade a otro lugar.
| Campo del registro | Evidencia o decisión requerida |
|---|---|
| Capacidad y responsable de negocio | Resultado aprobado, condición de aceptación y responsable autorizado para aceptar cambios de comportamiento. |
| Dependencias actuales | Inventario técnico vinculado a las vías reales del proceso, el acceso a datos y los consumidores posteriores. |
| Destino y decisión | Despliegue, versión, componentes pertinentes y decisión de retirar, sustituir, adaptar, trasladar o mantener bloqueada. |
| Mecanismos admitidos | Documentación específica del destino sobre puntos de extensión, API, eventos, contratos de liberación y restricciones. |
| Transacción y latencia | Qué debe confirmarse conjuntamente, comportamiento de espera permitido, actualidad de los datos y resultados medidos de aceptación. |
| Fallos y autorización | Modelo de identidad, permisos de negocio, operaciones rechazadas, tratamiento de duplicados y autoridad para la recuperación. |
| Monitorización y ciclo de vida | Detección de excepciones, responsable de conciliación, responsabilidad del despliegue, pruebas de actualización y responsable de correcciones. |
| Prerrequisitos y bloqueos | Comprobaciones del entorno de ejecución, conectividad, derechos de uso y condiciones comerciales; asuntos pendientes con responsables de decisión. |
En materia de autorización, exija pruebas de acciones permitidas y denegadas, incluida la ejecución en segundo plano cuando corresponda. Para la monitorización, pida al equipo que muestre cómo distingue un operador entre la transferencia correcta de un mensaje y la finalización correcta de la operación de negocio. Identifique quién concilia una discrepancia y quién puede autorizar una acción correctiva.
Para una propuesta side-by-side, confirme el entorno de ejecución y los servicios seleccionados, sus prerrequisitos, la responsabilidad operativa y los derechos de uso aplicables antes de autorizar la implementación. Mantenga esas comprobaciones adjuntas al registro de decisión. Una ubicación técnicamente plausible debe seguir siendo provisional hasta que la organización pueda mantenerla y operarla.
Apruebe el trabajo de migración solo cuando los bloqueos sean explícitos
Convierta cada decisión aprobada en un paquete de trabajo de migración: eliminar dependencias obsoletas, configurar la sustitución, adaptar la extensión admitida o construir y conectar la aplicación externa. Incluya en ese paquete el tratamiento de datos, los cambios de autorización, los procedimientos de excepción y la aceptación del negocio. No lo cierre únicamente porque el código compile o una interfaz devuelva una respuesta correcta.
Registre qué haría cambiar la recomendación. Una capacidad estándar demostrada puede eliminar el trabajo a medida; la ausencia de una operación de escritura admitida puede bloquear una ubicación side-by-side; un requisito de atomicidad puede favorecer una opción on-stack; y un proceso de recuperación sin responsable debe impedir la aprobación operativa. Mantenga accesible la justificación de la decisión para que un cambio en los supuestos active su revisión.
Antes de aprobar el siguiente paquete de trabajo de una extensión, complete su registro de decisión con el responsable del proceso y el responsable del mantenimiento técnico. Después, resuelva el bloqueo con más probabilidades de cambiar su ubicación. Si necesita ayuda para evaluar el trabajo de migración de código personalizado SAP o implementar el enfoque elegido, comente sus requisitos con los especialistas funcionales y técnicos SAP de Digiventi.
