Offline en SAP MDK: por qué falla en campo
Una app móvil SAP se juzga el día que el técnico entra en una subestación sin cobertura. Estos son los tres puntos donde la sincronización se rompe casi siempre, y cómo se evitan antes de escribir la primera pantalla.
El offline no es un modo, es el diseño
En MDK el dispositivo trabaja contra una base de datos local que se sincroniza con OData. Todo lo que la app necesite ver o validar sin cobertura tiene que estar decidido en el modelo de datos, no resuelto luego con parches. Si esa decisión se pospone, el rediseño llega en pruebas de usuario, que es el momento más caro.
Punto de rotura 1: qué se baja al dispositivo
La tentación es replicar el maestro entero. El resultado es una primera sincronización de veinte minutos y un móvil que se queda sin espacio. La regla es baja lo que el técnico va a necesitar en su turno, y nada más.
- Filtrar por planta, centro de trabajo o brigada, no por sociedad
- Ventana temporal en órdenes y avisos, no histórico completo
- Catálogos y materiales acotados al ámbito real de trabajo
- Adjuntos bajo demanda, nunca en la sincronización inicial
Punto de rotura 2: el tamaño del delta
El delta —lo que cambia entre sincronizaciones— determina la experiencia diaria. Un modelo mal definido obliga a recargar entidades enteras cada vez y convierte una sincronización de segundos en minutos con la app bloqueada.
- Definir claves y deltas por entidad desde el primer diseño
- Evitar entidades sin cambios que se recargan igualmente
- Medir la sincronización con volumen de producción, no de demo
- Sincronizar en segundo plano y no bloquear la interfaz
Punto de rotura 3: los conflictos
Dos técnicos tocan la misma orden. O el planificador la reasigna mientras uno está sin cobertura. Si no hay una política decidida, gana el último que sincroniza y alguien pierde su trabajo, normalmente en silencio.
- Decidir por entidad quién gana: campo, backend o revisión manual
- Bloqueo lógico de la orden asignada mientras está en el dispositivo
- Cola de errores visible para el técnico, no solo en el log
- Nunca descartar un registro fallido sin avisar a nadie
Cómo se prueba de verdad
En laboratorio el offline siempre funciona. Las pruebas que sirven son las incómodas: modo avión durante horas, cobertura intermitente en el trayecto, batería al diez por ciento, la app matada por el sistema operativo a media sincronización y el turno completo sin cerrar sesión.
¿Su app falla justo donde no hay cobertura?
Cuéntenos el caso