SOFFCONT1 y RSIRPIRL: el paso que parece falla y la pérdida que nadie ve

Toda base SAP con algunos años tiene una tabla que creció sin que nadie lo decidiera: la SOFFCONT1. Es donde los adjuntos de GOS — el PDF que alguien arrastró a una orden, el correo que se volvió documento, la planilla adjunta al pedido — quedan guardados dentro de la base, en lugar de en un repositorio propio.

Sacarlos de ahí es un trabajo conocido, con un report propio: el RSIRPIRL. Y ahí empieza la parte que los tutoriales no cuentan — porque el report tiene un modo de operación cuyo comportamiento normal parece una falla, y una trampa que causa pérdida silenciosa de contenido.

En una frase — en el modo delay del RSIRPIRL la categoría del documento sigue apuntando a la base después de la ejecución, y ese es el comportamiento correcto — no la señal de que algo salió mal.

Qué hace el RSIRPIRL, y qué no hace de inmediato

La operación parece directa: se define la categoría de almacenamiento nueva en OACT, se apunta al repositorio de contenido, se corre el RSIRPIRL y los documentos cambian de lugar.

Solo que existe el parámetro P_UPDATE — el «delete later», el modo delay. Con él marcado, el report no borra el contenido del repositorio de origen en el momento. Y aquí es donde casi todos concluyen que la migración falló:

el report termina con éxito;
el documento aparece en la tabla SDOK_PRELIM_CONT;
pero en la SOFFPHIO la categoría sigue siendo SOFFDB, y no la nueva que usted creó.

La expectativa natural es que la SOFFPHIO ya muestre la categoría nueva. No la muestra — y todavía no debería. El documento está en estado preliminar, existiendo en los dos lugares a propósito.

Por qué existe el modo delay

No es un capricho. La propia SAP documenta el motivo en la Nota 2991944 — «Introducing the Delay mode in report RSIRPIRL»: a veces hay problemas al crear el documento en el repositorio de destino. Si el contenido ya fue borrado del origen en ese momento, recuperarlo se vuelve muy difícil.

Es decir: el modo delay es la red de seguridad que falta en la mayoría de los tutoriales publicados. Convierte una operación irreversible en dos etapas, con un punto de verificación en medio.

La finalización la hace otro report: el RSIR_CONTENT_UNMARK_PRELIM, que quita la marca de preliminar. Solo después de él se alcanza el estado final — y recién ahí se puede liberar el origen.

La pérdida silenciosa que nadie busca

Esta es la parte que sale cara y no aparece en ninguna checklist de blog.

Los documentos guardados con tamaño de archivo vacío en las tablas de archivo migran al content server HTTP sin contenido. El registro va, el archivo no. La misma nota de SAP lo dice con todas las letras: eso resulta en pérdida de datos.

Y lo peor es la firma del problema: la migración reporta éxito. Usted lo descubre cuando alguien intenta abrir el adjunto, meses después, y recibe un archivo vacío. A esa altura el origen ya fue limpiado.

El recurso que entrega la nota permite excluir esos documentos de la migración — pero hay que saber que existen para poder excluirlos.

Antes de correr en producción — tres verificaciones que evitan las dos fallas anteriores: contar cuántos documentos tienen tamaño cero en las tablas de archivo, y decidir qué hacer con ellos antes y no durante; confirmar que la nota 2991944 está aplicada, si no el parámetro P_UPDATE ni existe en su versión; y acordar quién ejecuta el RSIR_CONTENT_UNMARK_PRELIM y cuándo — una migración que queda preliminar indefinidamente ocupa los dos lados y no ahorra nada.

Lo que sale mal, con nombre

Concluir que falló porque la SOFFPHIO no cambió. Es el caso más común. El equipo corre, verifica la categoría, ve SOFFDB todavía ahí y revierte todo — deshaciendo una migración que estaba correcta.

Correr sin el modo delay para «simplificar». Funciona hasta el primer documento que el destino rechaza. Ahí el origen ya fue borrado, y la recuperación es un trabajo de arqueología.

Olvidar la etapa de finalización. El RSIR_CONTENT_UNMARK_PRELIM no corre solo. Sin él, el contenido permanece en los dos lugares — y el objetivo era justamente dejar de ocupar la base.

Migrar todo de una vez. Volumen alto en ventana ajustada, sin conteo previo por franja, es como la migración se vuelve incidente en vez de proyecto.

El límite honesto

Sacar los adjuntos de la base reduce su tamaño, y eso es real. Pero no resuelve lo que suele estar detrás del problema: nadie decidió qué debería adjuntarse al SAP en primer lugar. La SOFFCONT1 vuelve a crecer, más despacio, por el mismo motivo de antes.

Y hay un costo que aparece después: con el contenido fuera de la base, la recuperación pasa a depender de que el content server esté en el aire y accesible. Lo que era un problema de espacio se vuelve uno de disponibilidad — mejor, pero distinto, y necesita monitoreo propio.

Si el punto de partida es entender cuánto de su base son adjuntos y qué se puede sacar, empiece por el archiving SAP — la SOFFCONT1 suele ser solo una de las tablas grandes. Y si el objetivo mayor es reducir el ambiente antes de migrar, vea el diagnóstico de TI.