✒️SAP BASIS / Herramientas de transporte y copia de mandantes Por Fernando Escola

Herramientas de transporte y copia de mandantes

1. Introducción y Uso de Herramientas de Mandantes

SAP proporciona herramientas específicas para realizar la copia de mandantes (client copy) y el transporte de mandantes (client transport). Estas herramientas están diseñadas para reemplazar por completo los datos de un mandante destino con los de un mandante fuente, ya sea que se encuentren dentro del mismo sistema o en un sistema externo. Es importante destacar que estas utilidades no permiten fusionar o combinar datos de diferentes mandantes en uno solo.

La copia de mandantes se utiliza principalmente durante la implementación inicial de un sistema o para el mantenimiento del paisaje de servidores, permitiendo la creación de diversos tipos de entornos:

• Mandantes nuevos: Generados a partir del mandante de referencia por defecto SAP 000.
• Mandantes de formación o capacitación: Destinados al entrenamiento de usuarios (training clients).
• Mandantes de demostración.
• Mandantes de pruebas o control de calidad.
• Mandantes de producción.

Los datos internos de un mandante se categorizan en tres grandes grupos: datos de configuración dependientes del mandante, datos maestros de los usuarios y datos de aplicación (definidos en su respectiva clase de entrega). Existe una regla de consistencia estricta: los datos de aplicación nunca pueden copiarse solos, sino que siempre deben transferirse junto con sus correspondientes datos de configuración.

2. Perfiles de Copia y Construcción de Mandantes

Los perfiles de copia son estructuras que definen exactamente qué tablas se van a transferir, basándose en la clase de entrega de cada tabla. También permiten seleccionar conjuntos de datos específicos según los requerimientos de la operación.

• Datos Maestros de Usuario: Permiten transferir la información de los usuarios mediante perfiles específicos como SAP_USER. Al realizar esta copia, los datos maestros de usuario existentes en el mandante destino se eliminan, a menos que el perfil seleccionado los incluya de manera explícita. Además, los perfiles de autorización y los roles forman parte de la configuración del sistema, por lo que siempre se copian de manera conjunta con los datos de parametrización. Copiar usuarios sin sus respectivos perfiles de autorización suele generar problemas de inconsistencia.
• Configuración o Parametrización (Customizing): La gran mayoría de los perfiles de copia incluyen datos de parametrización. Estos datos de configuración dependientes de mandante se almacenan por lo general en tablas vinculadas a las clases de entrega C, G, E y S.
• Configuración Transmandante (Cross-client Customizing): Al realizar copias remotas o transportes de mandantes, también es posible transferir configuraciones que afectan a la totalidad de los mandantes del sistema. Sin embargo, se debe tener mucha precaución al copiar tablas intermandantes, ya que pueden surgir graves inconsistencias en el sistema destino; de hecho, esta acción puede llegar a corromper los mandantes ya existentes debido a los cambios estructurales. Por ello, la copia de customizing transmandante suele limitarse a la creación de un nuevo servidor de aplicación ABAP.
• Datos de Aplicación y Transaccionales: Se utilizan perfiles orientados a entornos de prueba a partir de datos reales de producción. Dado que estos datos dependen de la configuración, solo pueden coexistir de forma consistente si se transfieren juntos. Los datos de aplicación se almacenan mayormente en tablas de clase de entrega A. Al ejecutar copias con perfiles específicos como SAP_USER o SAP_UCUST, los datos de aplicación previos en el mandante destino se borran por completo.

Un prerequisito obligatorio y fundamental antes de iniciar cualquier proceso de copia es crear el registro del mandante nuevo en la transacción SCC4 (Administración de Mandantes). Para la construcción inicial de un mandante a partir del mandante de referencia SAP 000, se utiliza el perfil SAP_CUST, el cual transfiere únicamente el customizing específico. Esto se debe a que no se puede garantizar la consistencia de los datos de aplicación dentro del mandante SAP 000.

3. Consideraciones Técnicas, Recursos y Rendimiento

La ejecución de una copia de mandante es un proceso crítico que demanda un alto consumo de recursos del sistema. Para evitar cancelaciones prematuras o cuellos de botella en la infraestructura, se deben controlar rigurosamente varios factores:

• Espacio de Almacenamiento: Es indispensable estimar el espacio requerido en la base de datos antes de iniciar. Para ello, se recomienda realizar previamente una ejecución de prueba, la cual genera un archivo de registro (log) con el detalle en megabytes de los datos que serán copiados o eliminados.
• Tiempos de Ejecución y Carga del Sistema: Dependiendo del volumen de los datos de aplicación, el proceso puede demorar varias horas o incluso días. Durante este periodo, la base de datos se utiliza de forma muy intensa y se ocupan múltiples procesos de diálogo, lo que eleva significativamente la carga general del servidor.
• Protección del Sistema y Bloqueos: Se debe garantizar que ningún usuario inicie sesión en el sistema durante la copia. Por razones técnicas, el sistema aplica un bloqueo obligatorio en el mandante destino y uno opcional en el mandante fuente. El bloqueo de inicio de sesión (logon lock) afecta tanto a los accesos por SAP GUI como a las conexiones HTTP. La única vía permitida para acceder a un mandante bloqueado es a través de llamadas de función remota (RFC). Es fundamental verificar que los usuarios activos abandonen el sistema antes de iniciar, ya que la herramienta no los desconecta de forma automática. Adicionalmente, se deben proteger ambos mandantes emitiendo un mensaje de sistema mediante la transacción SM02 y monitorear los accesos activos en la transacción SM04.

4. Post-Procesamiento, Limitaciones y Rangos Numéricos

Una vez finalizada la copia, se deben tener en cuenta ciertas restricciones y pasos posteriores:

• Limpieza: Si se tiene previsto utilizar SAP Query en el nuevo mandante, es obligatorio ejecutar tareas de post-procesamiento.
• Restricciones de Datos Archivados: No es posible acceder a los datos archivados en el mandante destino si el número de este difiere del número que tenía el mandante fuente original.
• Logs y Modificaciones: Ciertos registros administrativos no se transfieren. Los documentos de modificación de la administración de usuarios (alojados en tablas como CDHDR, PCDHDR, CDPOS y PCDPOS) así como los logs del repositorio de log genérico (tablas de aplicación BAL*) se omiten en la copia.
• Rangos Numéricos: Su comportamiento está estrictamente ligado al tipo de perfil. Si se copian la configuración y los datos de aplicación de manera conjunta, los rangos numéricos se transfieren intactos porque los datos transaccionales los requieren. En cambio, si el perfil solo incluye la configuración, los rangos numéricos se reinician debido a que los datos de aplicación asociados se eliminan y se deben volver a construir desde cero.
• Estrategia para Grandes Mandantes Productivos: Debido al enorme volumen de información, no se recomienda copiar los datos de aplicación de forma directa en mandantes muy grandes. En su lugar, se aconseja transferir únicamente la configuración y luego generar los datos de prueba indispensables utilizando herramientas de prueba asistidas por ordenador extendidas (eCATTs).

5. Objetos de Autorización Requeridos

Para poder gestionar y ejecutar los procedimientos de copia o transporte de mandantes, el consultor BASIS debe contar con autorizaciones específicas asignadas en su perfil de usuario:

• S_TABU_CLI: Permite el mantenimiento y modificación de tablas intermandantes (cross-client).
• S_TABU_DIS: Habilita el mantenimiento de las tablas generales del sistema.
• S_CLNT_IMP: Autoriza la importación de datos en los procesos de copia de mandante.
• S_DATASET: Permite interactuar y acceder al sistema de archivos del servidor de aplicaciones.
• S_USER_AGR: Requerido específicamente para la copia de roles de usuario.
• S_USER_PRO: Habilita la transferencia de los perfiles de autorización.
• S_USER_GRP: Autoriza la copia de los datos maestros de los usuarios.
• S_TRANSPRT: Requiere combinarse con valores específicos (TTYPE 'CLCP' y ACTVT '01') para facultar la creación de listas de objetos orientadas a transportes y copias entre mandantes.
• S_TABU_RFC: Otorga los permisos de acceso remoto a las tablas del sistema destino a través de conexiones RFC.

6. Modernización de las Herramientas (A partir de SAP_BASIS 754)

A partir de la versión del componente SAP_BASIS 754, SAP introdujo una renovación completa de las herramientas de copia de mandantes (detallada en la Nota SAP 2962811), incorporando metodologías más eficientes orientadas a bases de datos SAP HANA:

• Arquitectura basada en Listas de Tareas: Los procesos antiguos se sustituyen por nuevos códigos de transacción y APIs de comunicación. La gestión principal se centraliza ahora en la transacción ST01 mediante el uso de listas de tareas (task lists), lo que permite automatizar y estructurar la secuencia de pasos.
• Mejora Crítica del Rendimiento: Gracias al aprovechamiento de las capacidades nativas de la base de datos SAP HANA, las copias locales se ejecutan hasta 10 veces más rápido que con las herramientas anteriores, mientras que las copias de mandantes remotas logran acelerarse hasta 5 veces más.
• Seguridad y Estabilidad: El usuario especial SAP* ya no es un requisito obligatorio para efectuar estas operaciones, reduciendo así la necesidad de reiniciar el sistema con configuraciones de seguridad vulnerables. Asimismo, las rutinas de salida de la aplicación (application exits) se ejecutan ahora en entornos totalmente aislados; si una tabla o una rutina falla, los errores se confinan y se registran en el log sin hacer caer todo el proceso.
• Interfaz de Usuario y Gestión de Logs: El registro de eventos pasó de ser un sistema basado en archivos de texto plano a una interfaz gráfica estructurada en tablas (UI basada en tablas). Esto ofrece una persistencia de datos muy superior y organiza el monitoreo en pestañas dedicadas para Datos de Cabecera, Tablas Procesadas, Mensajes de Application Exits y Mediciones detalladas de los Tiempos de Ejecución.
• Gestión Avanzada de Bloqueos: El bloqueo del mandante fuente ahora se puede gestionar y remover directamente desde la pantalla de selección de la herramienta (o mediante parametrizaciones de experto). SAP recomienda remover este bloqueo únicamente en casos excepcionales, como en la creación de entornos aislados tipo sandbox o sistemas de desarrollo rápido, asumiendo el riesgo de que la escritura concurrente pueda provocar inconsistencias menores en la copia. Para entornos productivos formales, el punto de ejecución recomendado para la herramienta es realizarlo desde un tercer mandante neutral que no se vea afectado directamente por el flujo de transferencia.

7. Conversión de Sistemas Lógicos y Estimación de Tamaño

• Conversión de Sistema Lógico: Cuando se realiza una copia entre mandantes de sistemas distintos, los nombres de los sistemas lógicos vinculados a los datos de aplicación del mandante destino deben actualizarse. Si previamente se ha mantenido la equivalencia en la transacción BD54 y se ha asignado correctamente al mandante en la transacción SCC4, las herramientas modernas convierten de forma automática los nombres de los sistemas lógicos al finalizar la transferencia (utilizando perfiles amplios como SAP_ALL).
• Determinación del Tamaño de Mandante: Antes de iniciar cualquier transferencia de datos masiva, es fundamental conocer con precisión el tamaño y el consumo de memoria del mandante fuente. Para esto se provee la transacción especializada SCC_CLIENT_SIZE (o la herramienta equivalente integrada en las nuevas versiones). El procedimiento estándar requiere llamar a la transacción, especificar el mandante objetivo y definir el número de procesos en paralelo que se van a asignar para el cálculo. La herramienta brinda la flexibilidad de analizar la totalidad de las tablas del mandante o realizar un escaneo sobre una selección específica de las mismas. Al ejecutar la transacción, el sistema procesa la solicitud y devuelve una pantalla con los resultados detallados del tamaño aproximado del mandante expresado en megabytes (MB), desglosado también por clases de entrega e información de la base de datos.

1. Prueba de Órdenes de Transportes de Configuración

Las órdenes de transporte orientadas a la parametrización o configuración del sistema se crean habitualmente en el entorno de desarrollo. El flujo estándar determina que, una vez finalizadas, se liberan en dicho entorno y se importan de forma masiva hacia el sistema de control de calidad (Quality Assurance - QA) para su correspondiente validación.

No obstante, una práctica altamente recomendada es llevar a cabo un proceso de pruebas previas (pre-testing) en un mandante aislado que se encuentre dentro del mismo sistema de desarrollo. Esta verificación debe realizarse obligatoriamente antes de proceder a la liberación definitiva de la orden de transporte.

2. Propósito de la Prueba Unitaria

La ejecución de una prueba unitaria antes de liberar la orden de transporte de configuración cumple con dos objetivos fundamentales:

• Probar la funcionalidad: Asegurar que el comportamiento técnico y operativo de los cambios registrados en la orden sea el correcto.
• Verificar la completitud: Validar que todo el contenido y los objetos requeridos para la parametrización estén incluidos de forma íntegra dentro de la orden.

La ventaja clave de mantener un mandante separado y dedicado exclusivamente a las pruebas es que permite recrear escenarios unitarios reales y realizar el mantenimiento de datos de prueba específicos. Todo esto se logra sin el riesgo latente de generar registros de prueba que queden ligados o dependan de la configuración base del mandante de desarrollo principal.

3. La Transacción Clásica SCC1 (Copia por Cambios)

La transacción SCC1 se utiliza tradicionalmente para copiar modificaciones de configuración específicas de un mandante a otro dentro del mismo sistema SAP. Esta operación se realiza tomando como base estructural:

• Una tarea (task) en particular.
• Una orden de transporte completa.
• Una orden de transporte en conjunto con todas sus tareas asociadas.

Para llevar a cabo este procedimiento, el consultor debe posicionarse y ejecutar la transacción SCC1 estrictamente desde el mandante destino. Una vez allí, la interfaz requiere que se introduzca manualmente el mandante fuente desde donde se tomarán los datos y el número de la orden de transporte que contiene los objetos que se desean replicar.

4. Optimizaciones y Limitaciones en la Gestión de Órdenes (SE09 y Objetos Intermandantes)

• Optimización mediante la transacción SE09: De forma nativa, los objetos contenidos en las órdenes de transporte solo pueden ser transferidos de uno en uno, lo cual representa una inversión considerable de tiempo si se manejan múltiples modificaciones de forma simultánea. Para optimizar este flujo, se puede emplear la función Include Objects (Incluir Objetos) dentro de la transacción SE09. Esta utilidad permite agrupar los componentes de varias órdenes dispersas bajo una única orden de transporte de mayor tamaño. Al procesar esta nueva orden consolidada hacia el mandante destino, se logra reducir drásticamente el tiempo de ejecución.
• Restricción de Objetos Intermandantes: Las herramientas de copia por cambios bajo este esquema técnico están diseñadas para procesar únicamente datos específicos del mandante. Por lo tanto, si la orden de transporte seleccionada incluye objetos de carácter intermandante (cross-client objects), estos componentes serán omitidos y no se copiarán al mandante de pruebas.

5. La Nueva Transacción SCC1N (SAP S/4HANA 2020+)

A partir del Feature Pack 01 (FP01) para SAP S/4HANA 2020 (asociado al componente técnico SAP_BASIS 755 SP01), SAP introduce la transacción SCC1N, la cual se establece como la sucesora directa de la clásica SCC1.

Esta renovación tecnológica amplía significativamente las capacidades operativas del sistema e incorpora ventajas críticas:

• Copia Multidestino Simultánea: A diferencia de su predecesora, la transacción SCC1N permite copiar los objetos de configuración registrados en las órdenes de transporte a múltiples mandantes destino en una única ejecución.
• Flexibilidad de Origen: La orden de transporte utilizada en este contexto puede ser tanto una orden de transporte de carácter local (generada internamente) como una orden de transporte que haya sido importada previamente desde un sistema externo.
• Ubicación de Ejecución Flexible: La principal ventaja técnica de SCC1N frente a SCC1 es que puede ser ejecutada desde cualquier mandante, rompiendo la restricción histórica de tener que iniciar sesión obligatoriamente en el mandante destino para realizar la importación. Adicionalmente, la pantalla de selección abre el acceso a un número considerable de nuevos parámetros de control.

6. Procedimiento para Copiar Órdenes de Transporte No Liberadas con SCC1N

En el caso de requerir la transferencia de objetos pertenecientes a órdenes de transporte que aún permanezcan en estado modificable o no liberadas utilizando la nueva transacción SCC1N, el operador debe seguir un protocolo de parametrización específico en la interfaz:

1. Dirigirse a la sección denominada Export / Import Time of the Transport Request (referente a la Hora de Exportación / Importación de la Orden de Transporte) y marcar activamente el botón de opción Local Import/Update Date (Fecha de Importación/Actualización Local).
2. En caso de que el sistema parametrice el campo Export/Import Date (Fecha de Exportación/Importación) como un requerimiento obligatorio —condición que varía según el release exacto o el nivel de Support Package (SP) instalado—, se debe ingresar de forma manual una fecha que se encuentre situada cronológicamente muy en el pasado. Con este ajuste técnico se salta la validación temporal y se habilita la correcta ejecución de la copia de los cambios al mandante de pruebas.

Copia de mandante local

1. Concepto de Copia de Mandante Local

Una copia de mandante local consiste en la transferencia y réplica de datos entre mandantes que coexisten dentro de un mismo entorno o servidor de aplicación ABAP (es decir, comparten el mismo sistema SAP físico).

Al igual que en los esquemas remotos, el proceso requiere que el mandante destino esté previamente registrado.

2. Metodología Clásica: Transacción SCCL

En el esquema tradicional de SAP, las copias locales se ejecutan a través de la transacción SCCL (y las operaciones complementarias mediante la transacción SCC8). Para realizar este procedimiento clásico, el operador debe seguir una secuencia estricta de pasos técnicos:

• Prerrequisito de Registro: Es obligatorio crear primero la entrada y estructura del mandante destino en la tabla de mantenimiento general mediante la transacción SCC4.
• Punto de Inicio y Acceso del Usuario Especial: El proceso de copia local clásica debe iniciarse obligatoriamente iniciando sesión desde el mandante destino. Dado que el mandante es totalmente nuevo y no cuenta aún con usuarios operativos, se debe ingresar utilizando el usuario estándar del sistema SAP*.
• Contraseña por Defecto y Parámetros de Seguridad: La clave genérica codificada de fábrica (hard coded) para este usuario es pass. Sin embargo, para que el sistema permita el acceso con estas credenciales en un mandante vacío, el parámetro de perfil general del sistema login/no_automatic_user_sapstar debe estar configurado estrictamente con el valor 0.
• Parametrización y Ejecución: Una vez dentro de la transacción SCCL, el consultor asigna el mandante fuente desde el cual se extraerán los datos y selecciona un perfil de copia adecuado. Debido al gran volumen de información y al tiempo requerido, la ejecución de la copia debe programarse obligatoriamente para procesarse en segundo plano (background processing).

3. Consideraciones de Consistencia y Mandantes Estándar (000 y 001)

• Consistencia de Datos: Para blindar la integridad del sistema, está estrictamente prohibido que los usuarios operen o modifiquen información en el mandante destino mientras la copia está en marcha. SAP también aconseja firmemente detener cualquier tipo de actividad laboral en el mandante fuente durante la ventana de ejecución del proceso.
• Manejo del Mandante 000: El software de SAP se entrega nativamente con el mandante estándar 000. No se permite realizar tareas de producción ni parametrizaciones operativas directamente sobre él; su propósito es actuar como la base de referencia pura del sistema. Cuando se inicia un nuevo proyecto de implementación, SAP recomienda generar un nuevo mandante personalizado tomando como origen el mandante 000.
• Manejo del Mandante 001: El mandante 001 constituye una copia exacta del mandante de referencia 000. Si bien históricamente se permitía utilizarlo como un entorno productivo inicial, la recomendación técnica actual es descartar su uso operativo, avanzar con la creación de mandantes propios desde el 000 y, una vez establecidos, eliminar por completo el mandante 001 del sistema para optimizar espacio y seguridad.

4. Opciones de Exclusión y Configuración de Experto

Con el fin de aliviar la carga de la base de datos y acelerar los tiempos de copia, las herramientas clásicas permiten refinar el alcance de la transferencia:

• Exclusión de Tablas: A través de la ruta de configuraciones de experto (Expert Settings), el consultor puede acceder a la pestaña de tablas (Tables) para indicar de forma explícita qué tablas o paquetes específicos no deben transferirse al mandante de pruebas por carecer de relevancia técnica.
• Documentación de Soporte: Para asegurar una correcta depuración sin corromper la integridad del customizing, SAP dispone de documentación interna detallada en la barra de herramientas y centraliza las pautas avanzadas de copia local en la Nota SAP 446485 (CC-ADMIN: Opciones especiales de copia).

5. Metodología Moderna: Transacción SCCLN (SAP_BASIS 754+)

A partir de la versión del componente SAP_BASIS 754, SAP transformó por completo este procedimiento técnico introduciendo la transacción SCCLN como el nuevo estándar de reemplazo para las copias locales. Su flujo operativo se estructura bajo los siguientes pasos:

1. Llamada de la Herramienta: Se accede de forma directa a la transacción modernizada SCCLN.
2. Selección de Entornos: A diferencia del método antiguo, el consultor ya no está obligado a ingresar desde el mandante destino; la nueva interfaz permite designar libremente tanto el mandante fuente como el mandante destino desde cualquier punto de acceso autorizado.
3. Definición del Alcance: Se selecciona el perfil de copia general necesario o, si se requiere un ajuste quirúrgico y excepcional, se especifican las tablas individuales concretas que se van a procesar.
4. Configuración del Procesamiento: La pantalla permite activar el modo de prueba (Test Mode) para realizar simulaciones de espacio, habilitar la opción de bloquear de forma automática el mandante fuente para inicios de sesión y determinar la cantidad de procesos que trabajarán en paralelo.
5. Programación Automatizada: La copia se puede lanzar de manera inmediata, ejecutarse en modo diálogo o estructurarse mediante las nuevas listas de tareas (task lists) del sistema para que corra como un job de fondo automatizado.

6. Optimización Mediante el Uso de Procesos Paralelos

El procesamiento en paralelo es una de las características clave integradas tanto en las copias locales modernas como en las remotas y los borrados de mandantes. Su propósito fundamental es explotar y exprimir al máximo la capacidad de cómputo de la base de datos del servidor.

Para garantizar un rendimiento óptimo bajo la nueva transacción SCCLN, se deben seguir de forma estricta las siguientes directrices técnicas:

• Capacidad de Cómputo Relativa: Una regla de diseño e ingeniería de sistemas altamente eficiente es asignar exactamente dos procesos paralelos por cada unidad de CPU (núcleo) disponible en el servidor de la base de datos. En contraposición, los servidores de aplicación ABAP no representan un cuello de botella restrictivo, ya que su número se considera técnicamente ilimitado para esta función.
• Restricción de Fase: Los procesos paralelos configurados actúan y consumen recursos del sistema únicamente durante la fase de copia real de los datos. Las fases previas de análisis y las tareas posteriores de post-procesamiento se ejecutan de manera lineal y no se ven afectadas por este parámetro.
• Limitación de Recursos: La gobernanza interna de SAP restringe el número máximo de procesos que pueden ser transferidos o confiscados por una sola operación de mandante, evitando así que una copia sature la totalidad de la infraestructura y deje sin recursos al resto de las operaciones del sistema.

Copia de mandante remota

1. Copia de Mandante Remota (Herramientas Clásicas)

La copia de mandante remota consiste en transferir datos entre mandantes que se encuentran en diferentes sistemas SAP (distintos servidores de aplicación). En las versiones clásicas de SAP, este proceso se gestiona mediante la transacción SCC9.

• Prerrequisito de Conectividad: El sistema requiere de manera obligatoria una conexión de función remota (RFC) configurada correctamente. El destino RFC debe apuntar de manera específica al mandante fuente desde el cual se van a extraer los datos.
• Punto de Ejecución y Usuario Especial: Al igual que en la copia local, el consultor debe iniciar sesión en el mandante destino utilizando el usuario estándar SAP* (con la contraseña por defecto pass y el parámetro de seguridad habilitado).
• Manejo del Bloqueo: Durante el proceso, el mandante destino se bloquea de forma obligatoria para evitar accesos de usuarios. El mandante fuente, en cambio, se bloquea de forma opcional; si no se bloquea, se asume el riesgo de que las modificaciones concurrentes de los usuarios provoquen inconsistencias menores en los datos copiados.
• Programación en Fondo: Debido al tráfico de red y al volumen de información, la copia remota clásica debe programarse estrictamente para su ejecución en segundo plano (background job).

2. Transporte de Mandantes (Exportación e Importación)

El transporte de mandantes es una alternativa a la copia remota. En lugar de transferir los datos directamente por red mediante RFC, se utiliza el sistema de transportes de SAP para empaquetar los datos en archivos a nivel de sistema operativo y luego importarlos en el destino.

Este método clásico se divide en dos grandes fases de ejecución:

• Fase de Exportación (Transacción SCC8): Se ejecuta en el mandante fuente. El consultor selecciona un perfil de copia y el sistema genera automáticamente hasta tres órdenes de transporte dedicadas, dependiendo de la naturaleza de los datos. Estas órdenes siguen una nomenclatura estricta donde <sid> es el identificador del sistema y nnnnn es el número correlativo:
  • <sid>KTnnnnn: Contiene los datos de configuración o parametrización (Customizing). Esta orden es obligatoria.
  • <sid>KXnnnnn: Contiene los datos de aplicación transaccionales (opcional, según el perfil).
  • <sid>KUnnnnn: Contiene los datos maestros y de control de los usuarios (opcional).
• Flujo en el Sistema Operativo: Al finalizar la exportación, los archivos de datos (data files) y de control (co-files) se guardan físicamente en el directorio de transportes del servidor de aplicaciones.
• Fase de Importación (Transacción STMS y SCC7): Primero, el administrador BASIS debe utilizar la transacción STMS (System Landscape Directory / Transport Management System) para importar de manera efectiva las órdenes generadas en la cola del sistema destino. Una vez que las órdenes terminan de importarse a nivel de infraestructura, se debe iniciar sesión en el mandante destino y ejecutar obligatoriamente la transacción SCC7 para realizar el post-procesamiento. Este paso final es crítico, ya que se encarga de reajustar los rangos numéricos y adaptar lógicamente las tablas importadas.

3. Copia Remota Moderna: Transacción SCCR_CLIENT_COPY

A partir de las optimizaciones de arquitectura (SAP_BASIS 754+), el procedimiento clásico de la transacción SCC9 es reemplazado por una infraestructura moderna que utiliza herramientas nativas de SAP HANA y una interfaz optimizada.

• Flexibilidad de Ubicación: Ya no existe la restricción técnica de iniciar sesión en el mandante destino. La herramienta puede ser ejecutada desde un tercer mandante neutral o administrativo para evitar conflictos de bloqueo.
• Parametrización Avanzada: La nueva pantalla de selección unifica el control. Permite seleccionar el destino RFC del mandante fuente, definir si se operará en modo de prueba (Test Mode), y determinar de forma explícita si se mantendrán o descartarán los bloqueos preventivos en el origen.
• Integración con SAP HANA: El procesamiento de datos aprovecha la base de datos en memoria, lo que acelera la transferencia de tablas grandes hasta 5 veces en comparación con el esquema analógico de la transacción SCC9.

4. Automatización con Listas de Tareas (Transacción STC01)

Tanto para las copias locales como remotas del nuevo entorno, SAP migró la lógica secuencial hacia un marco de automatización basado en el Task Manager (Gestor de Tareas).

• La Transacción STC01: Es el punto central para buscar, configurar y lanzar listas de tareas estructuradas. El consultor puede buscar las plantillas de listas de tareas utilizando criterios de selección directa o mediante búsqueda avanzada (por nombre, descripción o grupo de listas de tareas).
• Secuencia Operativa: Una vez seleccionada la lista de tareas idónea para el escenario (por ejemplo, para copia local o remota), el sistema presenta una secuencia ordenada de pasos lógicos (inicialización, verificación de prerrequisitos, copia de datos y post-procesamiento). El administrador puede monitorizar el estado de ejecución de cada tarea en tiempo real, identificar cuellos de botella y gestionar los logs de errores de forma centralizada.

Transporte de mandantes

1. Conceptos Generales del Transporte de Mandantes

Un transporte de mandante sirve para copiar datos entre diferentes mandantes, con la diferencia clave respecto a una "copia de mandante" tradicional de que no utiliza conexiones RFC. En su lugar, es un proceso que trabaja a nivel del sistema operativo. Se puede usar tanto para reemplazar una copia de mandante local como una remota.

Cualquier transporte de mandante, en su esencia, consta de dos pasos principales:

• Exportación del Mandante: Se extraen los datos del mandante fuente y se generan archivos físicos a nivel del sistema operativo.
• Importación del Mandante: Se toman esos archivos generados y se importan dentro del mandante destino.

2. El Proceso de Exportación Antiguo (Transacción SCC8)

Para iniciar una exportación con la herramienta clásica, se utiliza la transacción SCC8 en el mandante fuente. El procedimiento consiste en:

• Iniciar sesión en el mandante de origen, ejecutar la SCC8 y seleccionar los datos a copiar mediante un perfil de copia.
• Especificar el sistema destino (que debe estar previamente definido en el Sistema de Gestión de Transportes o TMS).
• Iniciar la exportación. Como este proceso suele demorar, se ejecuta de forma asíncrona mediante procesamiento en fondo programado (scheduled background processing), invocando al programa de transporte tp a nivel de sistema operativo.

Archivos generados en el Sistema Operativo

La exportación clásica genera hasta tres archivos de datos específicos a nivel de sistema operativo dentro del directorio de transporte, nombrados según el tipo de contenido y el ID de sistema (SID):

• Archivo con prefijo RO: Contiene los datos intermandante (cross-client data).
• Archivo con prefijo RT: Contiene los datos específicos del mandante.
• Archivo con prefijo RX: Contiene los textos de SAPscript.

Monitoreo y consideraciones de la SCC8

Al ser un proceso asíncrono, continúa corriendo incluso si el usuario cierra la transacción SCC8. Las pautas clave para el monitoreo son:

• No se debe iniciar ninguna otra herramienta de copia de mandante hasta que la exportación actual finalice.
• El estado se puede verificar de forma habitual mediante la transacción SCC3.
• También se puede controlar desde la transacción SE01 (Organizador de Transportes), revisando los logs de la orden de transporte en la pestaña "Client (Mandante)".
• Nota técnica importante: Dependiendo del release de SAP_BASIS, la transacción SCC3 podría no mostrar información en el área de Client Exports porque la exportación se realiza con R3trans. Incluso es normal que la SCC3 muestre un estado de "Aborted" (Terminada Anormalmente) mientras la exportación sigue realmente en ejecución (en lugar de mostrar "Processing...").
• Antes de exportar, se recomienda hacer una verificación de consistencia del repositorio seleccionando "RFC system check" en la SCC8. Si hay inconsistencias, se generará una lista con las definiciones de tablas faltantes o diferentes en el Diccionario ABAP del sistema destino.

3. El Proceso de Importación y Post-Procesamiento Antiguo (Transacción SCC7)

Una vez que la exportación finaliza y los archivos están listos, se pasa a la fase de importación en el sistema destino utilizando el TMS (Sistema de Gestión de Transportes).

• Ejecución de la Importación: Las órdenes de transporte generadas por la exportación no se importan si se realiza un "Import all". Se debe utilizar la opción import single (importar individualmente) en el TMS. Al seleccionar una de las órdenes de transporte del mandante, las demás órdenes asociadas a ese mismo transporte se añadirán y se importarán automáticamente en el orden correcto.
• Post-Procesamiento (SCC7): Una vez que el TMS termina de importar los archivos, es obligatorio realizar actividades de post-importación para la generación de objetos. Para esto, se debe iniciar sesión en el mandante destino, llamar a la transacción SCC7 y ejecutar el post-procesamiento.
• Verificación: Los logs de todo este proceso se pueden visualizar mediante la Vista Extendida del Organizador de Transportes (SE01), específicamente en la pestaña "Client (Mandante)".

4. El Proceso de Transporte Nuevo (A partir de SAP_BASIS 754)

A partir de la versión SAP_BASIS 754, el procedimiento de transporte de mandante fue modificado y mejorado, introduciendo un flujo de tres pasos mediante nuevas transacciones que automatizan gran parte del trabajo.

Paso 1: Exportación del Mandante (Transacción SCC8N)

Se ejecuta en el mandante fuente y sigue estos pasos:

1. Se accede a la transacción SCC8N.
2. Se selecciona el mandante fuente.
3. Se selecciona la Ruta de Exportación/Importación (por ejemplo, el destino de una orden de transporte).
4. Se define el alcance de la copia seleccionando un perfil de copia predefinido, ingresándolo directamente o eligiendo tablas/paquetes específicos.
5. Se definen las configuraciones de procesamiento. Aquí se incluyen opciones como: Test Mode (Modo de prueba), Tolerate Failed Exits, Automated Import Post Processing (que permite automatizar el paso final), o Release Transport Requests on Exports.
6. Se programa la ejecución, ya sea como un job de fondo (Execute as Tasklist) o de forma inmediata (Direct Execution).

Paso 2: Importación del Mandante (STMS)

Se realiza en el Sistema de Gestión de Transportes (STMS):

1. Se seleccionan las órdenes de transporte correspondientes en la cola de importación (Import Queue Overview). Las órdenes restantes del transporte se indexan de manera automática.
2. Se importan las órdenes hacia el mandante destino (requiere estar conectado al mandante de destino).

Paso 3: Post-Procesamiento de Importación (Transacción SCC7N)

El post-procesamiento sigue siendo estrictamente obligatorio en el mandante destino para habilitar los objetos importados.

1. Se ingresa al mandante destino y se ejecuta la transacción SCC7N.
2. Se selecciona el mandante destino de la importación.
3. Se selecciona la Ruta de Exportación/Importación.
4. Se verifica la información de importación (Transporte específico, transporte intermandante, perfil, sistema fuente y mandante fuente).
5. Se definen configuraciones avanzadas de procesamiento, tales como: Test Mode, Tolerate Failed Exits, Tolerate Failed Tables, Use Exclusive Locks y el número de procesos en paralelo (Number of Parallel Processes).
6. Se programa la ejecución de forma inmediata o como una lista de tareas en fondo.

Automatización y Restricción Operativa del método nuevo

• Post-Procesamiento Automatizado: Si al momento de hacer la exportación en la SCC8N se dejó activa la opción Automated Imp. Postprocessing, el sistema ejecutará el post-procesamiento de forma automática tras la importación de las órdenes, eliminando la necesidad de iniciar manualmente la SCC7N.
• Restricción de uso: Bajo ninguna circunstancia se debe utilizar el mismo mandante como fuente para múltiples copias o transportes de mandante en forma simultánea.

La eliminación de mandantes

1. El Concepto de Eliminación y la Comparación Clave: SCC5 vs. SCC4

El material destaca que existe una diferencia fundamental entre quitar un mandante de la lista de acceso y borrar verdaderamente su contenido físico de la base de datos.

Transacción SCC4 (Mantenimiento de Mandantes - Tabla T000)

Cuando se elimina una entrada de mandante directamente de la tabla T000 usando la transacción SCC4:

• Se bloquea el acceso de manera inmediata: ya no es posible iniciar sesión en ese mandante ni actualizarlo mediante órdenes de transporte.
• No se eliminan los datos: Esta acción no borra la información física que pertenece al mandante. Los datos específicos permanecen alojados en el sistema SAP ocupando espacio innecesario en la base de datos.
• Uso como Bloqueo Temporal: Debido a este comportamiento, eliminar la entrada en la SCC4 sirve en realidad para aplicar un bloqueo temporal. Si en el futuro se desea restaurar el mandante y permitir que los usuarios vuelvan a loguearse, simplemente basta con volver a crear la entrada del mandante utilizando la misma SCC4.

Transacción SCC5 (Herramienta de Borrado Completo)

Para eliminar un mandante SAP por completo y liberar espacio, es estrictamente necesario borrar tanto la definición del mandante como sus datos específicos. Para cumplir con esto, se debe utilizar la función Delete Client mediante la transacción SCC5 (en el método antiguo) o su evolución.

2. El Método de Borrado Antiguo (Transacción SCC5)

En el esquema clásico, la herramienta cuenta con una limitación operativa importante respecto a desde dónde se ejecuta:

• Restricción de sesión: La transacción SCC5 únicamente borra el mandante en el cual el administrador inició la sesión actual.
• Procedimiento: El operador debe conectarse de forma efectiva al mandante específico que se va a eliminar, ejecutar la transacción SCC5 e iniciar el proceso.
• Recomendación de ejecución: Se aconseja firmemente lanzar el borrado utilizando el procesamiento en fondo (background processing) debido al volumen de datos que suele manejar.

3. El Método de Borrado Nuevo (Transacción SCC5N)

A partir de la versión SAP_BASIS 754, el procedimiento de copia local y borrado de mandantes fue modificado y mejorado, introduciendo la nueva transacción SCC5N.

La gran ventaja evolutiva de la SCC5N es que permite borrar cualquier mandante del sistema, eliminando la obligación de loguearse dentro del mandante a eliminar. El paso a paso para su ejecución es el siguiente:

1. Llamar a la transacción: Se ejecuta SCC5N. Ya no es necesario realizar este paso desde el mandante que se quiere destruir.
2. Seleccionar el mandante: Se elige el mandante objetivo directamente desde una lista desplegable. En este paso, aparece una opción clave: se puede especificar de forma opcional si también se desea eliminar de manera automática el registro del mandante en la tabla de administración de mandantes (tabla T000).
3. Definir la configuración de procesamiento: Permite configurar parámetros de control para la ejecución. Entre ellos, el administrador puede activar el Test Mode (Modo de prueba) para simular el borrado o definir el número de procesos paralelos en ejecución (estrategia ideal para reducir drásticamente el tiempo total requerido para la eliminación completa).
4. Programar la ejecución: Se define si se prefiere lanzar como un trabajo de fondo programado (Execute as Tasklist - Ejecutar como Lista de Tareas) o si se desea una ejecución inmediata (Direct Execution).
5. Iniciar el borrado: Se confirma y se da comienzo a la eliminación definitiva de los datos.

Los perfiles de copia de mandantes SAP

Los perfiles de copia simplifican el proceso al agrupar de manera estándar qué objetos se van a transferir.

Nota crítica de eliminación previa

Antes de ejecutar una copia, la configuración y los datos de aplicación del mandante destino se eliminan por completo para garantizar un entorno limpio. Las únicas excepciones técnicas a esta regla son los perfiles SAP_USER y SAP_UONL.

Perfiles Estándar Básicos

• SAP_USER: Copia exclusivamente los datos maestros de usuario, sus roles y perfiles de autorización. Al usarlo, el mandante destino no se reinicializa. Los roles siempre acompañan a los datos maestros de usuario en este perfil.
• SAP_UONL: Transfiere únicamente los datos maestros de usuario, omitiendo por completo sus perfiles de autorización y roles.
• SAP_PROF: Copia única y exclusivamente los perfiles de autorización y los roles.
• SAP_CUST: Copia la configuración específica del mandante (customizing), incluyendo perfiles de autorización. Elimina los datos de aplicación previos en el destino pero conserva los datos maestros de usuario que ya existían allá.
• SAP_CUSV: Incluye el contenido de SAP_CUST sumando las variantes.
• SAP_CUSX: Incluye el contenido de SAP_CUST pero excluye perfiles de autorización y roles.
• SAP_UCUS: Combina el perfil SAP_CUST con los datos maestros de usuario.
• SAP_UCSV: Combina el perfil SAP_UCUS incorporando además las variantes.
• SAP_ALL: Copia absolutamente todos los datos del mandante. Solo excluye los documentos de modificación (según Nota 180499) y los datos locales.
• SAP_APPL: Contiene todo lo de SAP_ALL, pero deja afuera los datos maestros de usuario.
• SAP_APPX: Contiene todo lo de SAP_APPL, pero quita los perfiles de autorización y los roles.

Perfiles Especiales para Copias Remotas (SCC9 / SCC9N)

• SAP_RMBC: Copia el perfil SAP_UCSV sumando la configuración intermandante (cross-client customizing).
• SAP_RMPA: Copia el perfil SAP_ALL sumando la configuración intermandante.
• SAP_RMPC: Copia el perfil SAP_CUSV sumando la configuración intermandante.

Perfiles Especiales para Transportes de Mandante (SCC8 / SCC8N)

• SAP_EXBC: Transfiere el perfil SAP_UCSV junto con la configuración intermandante.
• SAP_EXPA: Transfiere el perfil SAP_ALL junto con la configuración intermandante.
• SAP_EXPC: Transfiere el perfil SAP_CUSV junto con la configuración intermandante.

Perfil Especial de Recuperación

• SAP_RECO: Diseñado únicamente para recuperar un mandante borrado por accidente (Nota SAP 31496). Incluye el contenido de SAP_ALL y fuerza la adición de tablas locales de clases de delivery L y W, junto con los documentos de modificación. Solo se encuentra disponible para SCC8 y SCC9(N).

2. Clases de Entrega de las Tablas en SAP (Delivery Class)

Para saber qué propósito tiene una tabla y cómo debe tratarla la copia de mandante, el sistema analiza su Clase de Entrega. Por defecto, la herramienta asume que todas las tablas son de configuración, a menos que pertenezcan a las categorías L, A o W.

• Clase A (Datos de Aplicación): Tablas que contienen datos maestros y de movimientos. Si usas un perfil como SAP_CUST, la herramienta identifica estas tablas y no copia su contenido, eliminando lo que hubiera en el destino.
• Clases C y G (Configuración): Las tablas clase C no pueden recibir entradas nuevas de SAP, mientras que las tablas clase G sí pueden ser modificadas por SAP. Ambas se copian si el perfil incluye Customizing.
• Clases S, E, W (Datos de Control y Sistema): Contienen datos técnicos del sistema (como TADIR o VARI). Las tablas Clase W corresponden al Web Application Server o datos del sistema; se llenan de forma interna y la herramienta de copia de mandantes estándar las ignora por completo.
• Clase L (Datos Temporales): Almacenan logs o datos temporales (como spool o background). Estas tablas deben estar vacías en un sistema SAP nuevo y su contenido se elimina en el mandante destino.

Regla de exclusión para clases L y W

Por norma general, las tablas L y W son ignoradas en cualquier proceso de copia. Las dos únicas excepciones donde sí se toman en cuenta son durante el borrado de mandantes (SCC5 / SCC5N) o cuando se utiliza explícitamente el perfil de recuperación SAP_RECO.

3. Compatibilidad de Estructuras entre Sistemas

Cuando se realiza una copia entre diferentes sistemas (Remota o Transporte), las estructuras de las tablas en el sistema fuente y destino deben ser idénticas.

Se consideran incompatibles si:

• El sistema destino tiene un campo clave adicional.
• Tienen diferentes nombres de campo, tipos de datos o campos clave distintos.
• Un campo en el sistema fuente tiene una longitud más corta que en el destino, ya que esto generaría pérdida de datos.

Comportamiento del sistema ante incompatibilidades

• Copia Local: No hay riesgo porque la estructura es físicamente la misma.
• Copia Remota / Transporte: El programa de copia compara las estructuras. Las tablas que resulten incompatibles se excluyen automáticamente de la copia y el proceso continúa con el resto.
• Buenas prácticas de control: En copias remotas se recomienda ejecutar primero el proceso en Modo de Prueba (Test Mode) para evaluar los errores del log. Para transportes de mandante, se puede usar el programa RSCLICHK vía RFC para verificar consistencias, o ejecutarlo directamente desde la transacción SCC8N en Modo de Prueba.

4. Consistencia, Restricciones y Rendimiento

Restricciones de Acceso obligatorias

Para asegurar que los datos no queden corruptos o inconsistentes durante la copia, se deben seguir dos reglas estrictas:

• En el mandante destino, los usuarios no pueden iniciar sesión mientras dure la copia (con la única excepción de los usuarios administradores de sistema SAP* y DDIC).
• En el mandante fuente, nadie debe trabajar durante el tiempo que tome el proceso de copia.

Consideraciones de Espacio en Base de Datos

• Las estimaciones de espacio necesario son solo aproximadas, ya que no contemplan el espacio asignado en las tablas que aún no está siendo utilizado.
• El espacio que se libera en la base de datos tras un borrado o sobreescritura solo estará realmente disponible después de aplicar una reorganización (reorganization) de la base de datos.
• Para calcular el espacio de manera previa con las herramientas clásicas (SCCL / SCC9), se puede lanzar una Simulación o una Verificación de Recursos (Resource Check, que es mucho más rápida). Con las herramientas nuevas (SCCLN / SCC9N), se selecciona directamente el indicador Test Mode combinándolo con el Resource Check.
• Para optimizar el rendimiento ante mandantes de producción muy grandes o configuraciones críticas, el material remite a la consulta de las Notas SAP 489690 y 2163425.

Las herramientas de monitoreo de mandantes

1. El Monitoreo Clásico de Copias de Mandante (Transacción SCC3)

En las versiones tradicionales (hasta SAP_BASIS 753 inclusive), la transacción SCC3 es el eje central para visualizar el estado de las copias (locales o remotas) que ya finalizaron o que están en ejecución.

Información básica provista por el log

Al ingresar a la SCC3 y seleccionar el mandante destino junto con su proceso de copia correspondiente, el sistema entrega tres tipos de datos esenciales:

• Estadísticas de Tablas: Detalles cuantitativos sobre el procesamiento.
• Información de Control: Datos técnicos sobre la ejecución del proceso.
• Detalle por Tabla Copiada: Muestra el progreso individual de cada tabla e incluye un enlace directo al componente del IMG (Implementation Guide) que le corresponde en el entorno de parametrización.

Análisis detallado en versiones clásicas

Al hacer doble clic sobre las entradas resaltadas en la SCC3, el administrador accede a listados específicos que contienen:

• El tiempo de ejecución exacto y la cantidad de entradas copiadas por cada tabla.
• Los programas de exit ejecutados por otros componentes de la aplicación durante la copia.

2. Ubicación Técnica, Nomenclatura y Almacenamiento de los Logs

A nivel de infraestructura y sistema operativo, los registros de copia de mandante siguen reglas estrictas de almacenamiento:

• Directorio Físico: Todos los archivos de log se guardan de forma física en el directorio /log a nivel de sistema operativo.
• Nomenclatura de Archivos: Los archivos se nombran con el patrón cc<número>.. El componente <número> representa el número de serie asignado a esa copia de mandante específica, mientras que <SID> es el ID del sistema fuente.
• Ubicación en Base de Datos: Técnicamente, la información del log de copia se encuentra registrada en la vista de base de datos V_CCCFLOW. Esta vista almacena el tiempo de ejecución (run time), el estado de procesamiento (processing status), la cantidad de tablas copiadas y el nombre exacto de la tabla que se está procesando en tiempo real.
• Logs Complementarios: La Vista Extendida del Organizador de Transportes (transacción SE01, pestaña "Client") refleja los logs cuando se trata de transportes. Además, se pueden revisar los logs de exportación e importación de la orden de transporte principal.
• Descarga local: El sistema permite la descarga directa de estos archivos de log a la interfaz del usuario local (local front end / PC).

3. Diagnóstico de Fallas, Cancelaciones e Incompatibilidades

Cuando una copia de mandante falla o se cancela de forma inexplicable, los apuntes establecen un protocolo de revisión obligatoria a través de cinco herramientas clave:

• Log de Copia (Transacción SCC3): Para ver en qué tabla o fase se interrumpió.
• Log del Sistema SAP (Transacción SM21): Indispensable para determinar si los problemas de la base de datos son los responsables de la caída de la copia.
• Análisis de Dumps (Transacción ST22): Para evaluar errores de tiempo de ejecución ABAP.
• Vista General de Jobs (Transacción SM37): Para chequear el estado de los procesos de fondo asociados.
• Órdenes de Spool (Transacción SP01): Para revisar salidas de datos o reportes técnicos generados.

Errores comunes detectados

• Error de escritura en el Mandante Destino: Generalmente provocado por falta de espacio suficiente en la base de datos o por intentar un procesamiento simultáneo en el mismo mandante de destino. Ante esto, la regla de oro es verificar la SM21 y asegurar que nadie trabaje en el mandante fuente ni en el destino durante la copia.
• Terminación en un Programa Exit: Si ocurre un error de tiempo de ejecución ABAP en un programa exit, se debe ejecutar el programa de visualización de logs RSCCPROT para identificar cuál fue el último exit que causó la terminación. Esto se cataloga como un error de aplicación y no de la herramienta de copia.
• Exclusión por desarrollo local: Las copias de mandante ignoran por completo las tablas asignadas a la clase de desarrollo local $TMP. Si se requiere incluirlas, se debe modificar primero su clase de desarrollo en el Object Directory (Directorio de Objetos).

4. Reinicio del Proceso ante Terminaciones Anormales

Si una copia se interrumpe de manera abrupta (por ejemplo, por una caída de la base de datos o un database shutdown), el sistema SAP retiene el nombre exacto de la tabla que se estaba copiando en ese instante para permitir la recuperación.

• La Opción Restart (Reinicio): Cuando la ejecución termina de forma anormal, la opción de reiniciar se propone por defecto al volver a ingresar a la herramienta. El proceso continuará exactamente desde el punto en el que se interrumpió.
• Estrategia de Selección: Si la caída fue reciente y la línea de estado del sistema lo indica, se debe elegir Restart. Si se prefiere comenzar la ejecución completamente desde el principio, se debe seguir la ruta Restart -> New Start (Reinicio -> Nuevo Inicio).
• Mecánica ante Terminación Técnica: Al reiniciar con la misma configuración, todos los programas exits se vuelven a procesar. Sin embargo, cualquier tabla que ya se haya copiado correctamente en el intento anterior se omite, a menos que haya sufrido modificaciones en el interín.
• Manejo de Tablas Incompletas: La tabla que quedó a medias durante la caída se reinicializa por completo y se vuelve a copiar en su totalidad para evitar datos corruptos.
• Reinicio Automático: Si una copia de mandante o un post-procesamiento de importación no finaliza correctamente, el sistema SAP propone de manera automática el modo de reinicio al volver a llamar a la transacción, utilizando exactamente los mismos parámetros configurados originalmente.

5. El Nuevo Paradigma de Logs (A partir de SAP_BASIS 754)

Con la llegada de la versión SAP_BASIS 754, la visualización de los logs y la información de control sufrió una transformación estructural profunda:

• Cambio de Arquitectura: El registro pasó de ser un sistema basado en archivos de texto (file-based) a una interfaz respaldada en tablas de base de datos (table-based UI). Esto dota a la herramienta de una mayor persistencia y permite extraer información adicional detallada.
• Acceso Integrado: Se unificó el acceso al "Análisis de Logs de Herramientas de Mandante" (Client Tools Log Analysis) a través de la misma transacción SCC3, pero con una interfaz renovada que organiza las tareas realizadas en pestañas de inicio específicas.

Pestañas de la Nueva Interfaz SCC3

• Active Process (Proceso Activo): Monitorea en tiempo real los procesos que se están ejecutando en ese momento para un mandante.
• Client Overview (Vista General de Mandantes): Enumera todos los mandantes configurados en el sistema SAP.
• Client (Mandante): Muestra la vista general de los procesos cuando el mandante actual fue el objetivo de otra operación.
• Timeline View (Vista de Línea de Tiempo): Presenta el historial cronológico y el número total de todas las copias de mandante realizadas.
• Pestañas de Historial Específico: Divisiones dedicadas a cuantificar y registrar los éxitos de: Local Copy (Copias locales), Remote Copy (Copias remotas), Client Deletion (Borrado de mandantes), Client Export (Exportaciones), Client Import (Importaciones) y Copy by Transport (Copias por transporte).
• Comparison (Comparación): Guarda el historial del número total de comparaciones de tablas de mandante que se hayan ejecutado.
• Client Table Snapshot (Snapshot de Tablas de Mandante): Almacena y expone el número total de snapshots o capturas de tablas creadas en el sistema.