Las actualizaciones en SAP R/3 se encargan de gestionar las modificaciones solicitadas por el usuario de la base de datos. Estás se pueden generar por procesos de trabajo tipo diálogo, batch o update.
Puede ser de dos formas, sincrónica y asincrónica.
La mayoría del tiempo es asincrónica, ya que estás actualizaciones se dan en un segundo plano, es decir, un proceso aparte.
El efecto de este tipo de actualizaciones es que el usuario no tiene que estar al pendiente del proceso de actualización para que pueda seguir trabajando. Esto implica una mejora de rendimiento; el proceso de diálogo del usuario no espera a que terminen las actualizaciones para seguir procesando las peticiones del usuario.
Este tipo de actualizaciones presentan como ventaja las LUW, las cuales consisten en bloques auto consistentes de datos, de tal manera que su actualización en la base de datos sea llevada a cabo completamente.
Si llegase a existir un problema en la base de datos, la grabación de los LUW no se realizaria, evitando así las inconsistencias que pudieran surgir al grabar una LUW a medias.
La actualización asincrónica consiste en 2 tipo de actualización: V1 y V2.
R/3 distingue entre componentes de actualización crítica primaria (V1) y secundaria no crítica (V2). La diferencia entre estos, permite al sistema que procese primero los V1 a los V2 asisgnandoles diferentes LUWs (Para asegurar que los datos sean consistentes, las actualizaciones V1 se procesan con la supervisión del gestor de bloqueos de SAP R/3 que impide que varias modificaciones sobre el mismo objeto se realicen concurrentemente)
Por el contrario, la actualización sincrónica, es menos frecuente, ya que la petición del proceso de actualización en la base de datos se genera en el mismo proceso de trabajo que gestiona el resto de peticiones del usuario. Por lo tanto el proceso de diálogo o batch debe esperar a que se realicen las actualizaciones en la base de datos antes de seguir procesando el resto de las peticiones del usuario, por lo que el rendimiento será peor que en el caso de la actualización asincrónica.
La actualización se activa automáticamente cada vez que el sistema SAP R/3 es arrancado en el servidor, por lo que sólo se deberá monitorizar su posible desactivación.
La transacción desde donde podremos gestionar centralmente la actualización es la SM13. En esta se nos muestra si la actualización del sistema está activa o ha sido desactivada por alguna causa.
También contamos con un sistema de gestión de bloqueos de objetos para evitar la modificación concurrente de un objeto, asegurando así la consistencia de los objetos en SAP R/3.
Cuando un usuario accede a modificar un objeto, el sistema genera un registro de bloqueo con la información necesaria. Si un segundo usuario intenta modificar ese mismo objeto mientras el primero lo tiene bloqueado, el sistema le muestra al segundo un mensaje de error indicándole que un usuario ya está tratando el objeto solicitado.
Los bloqueos se establecen al iniciar las transacciones de modificación y no son liberados hasta que el usuario pulsa Grabar, la información es actualizada en la base de datos y la transacción es finalizada. Toda mofdificación de un objeto desde cualquier aplicación estándar de SAP R/3 genera entradas de bloqueo.
La transacción que nos muestra los bloqueos actualmente activos en el sistema es la SM12, la cual se usa para visualizar y remover los bloqueos del sistema SAP.