Una pregunta habitual entre los desarrolladores de FileMaker que construyen integraciones es: "¿Puedo bloquear un registro a través de la Data API u OData, y hacer que ese bloqueo sea visible para todos los usuarios de la base de datos?"

Este artículo refleja mi comprensión personal a día de hoy, y puede que me falten detalles o capacidades más recientes. Mi esperanza es que abra un debate. El bloqueo de registros es un asunto crítico para las integraciones ricas de FileMaker, especialmente a medida que interfaces de usuario más sofisticadas se trasladan a los WebViewers, donde la coordinación entre la UI y la base de datos se vuelve más difícil de lograr. Agradezco correcciones, experiencias y enfoques alternativos de quienes hayan resuelto esto en la práctica.

Según mi conocimiento actual, la respuesta corta a la pregunta es no. Entender por qué apunta hacia una solución viable.

Por qué los bloqueos nativos no funcionan aquí #

El bloqueo nativo de registros de FileMaker pertenece a un cliente que tiene un registro en modo de edición. El bloqueo dura solo mientras ese cliente está editando, y FileMaker Pro, Go y WebDirect son los únicos clientes que pueden mantenerlo.

La Data API y OData son sin estado. Cada petición es independiente, y un guion ejecutado a través de la Data API termina cuando devuelve su respuesta. Nada permanece bloqueado después, y ninguna de las dos APIs tiene un endpoint de “bloquear este registro”. Tampoco existe una forma integrada de que FileMaker Server difunda un bloqueo a los clientes conectados.

La solución: un bloqueo suave almacenado en los datos #

Un bloqueo suave (soft lock) es un registro ordinario en tu tabla que todos los clientes acuerdan respetar. Tiene tres campos:

• lock_user, la persona que mantiene el bloqueo
• lock_session, un token único para la sesión de ese usuario
• lock_expires, una marca de tiempo que el titular renueva periódicamente

Adquirir el bloqueo en un guion. Expón un guion del lado del servidor a la API. Este busca el registro, comprueba si un bloqueo no expirado pertenece a otra persona, y solo entonces escribe el nuevo bloqueo. La búsqueda, la comprobación y la escritura se ejecutan dentro de un mismo guion, lo que estrecha la ventana de carrera, aunque no la cierra. Dos guiones ejecutándose al mismo tiempo pueden leer “sin bloqueo” antes de que cualquiera de ellos escriba. El guion devuelve JSON, de modo que el cliente API puede saber si el bloqueo fue concedido.

Renovar y liberar. El cliente llama al mismo guion cada 30 a 60 segundos para adelantar lock_expires. Un guion de liberación independiente limpia los campos cuando el usuario guarda o abandona el registro. Si un cliente se cae, su bloqueo simplemente expira, de modo que un registro no puede quedar bloqueado para siempre.

Hacer que los usuarios de FileMaker lo vean. FileMaker Server no envía cambios a los clientes, así que los clientes FileMaker Pro tienen que sondear. Una llamada a Install OnTimer Script en la presentación puede ejecutarse cada 10 a 30 segundos, comprobar si hay un bloqueo activo de otra persona, y convertir los campos editables en de solo lectura con un aviso. El bloqueo nativo sigue protegiendo a los usuarios de Pro que editan al mismo tiempo.

Advertencias #

Un bloqueo suave es consultivo. Cualquier guion o cliente API que ignore los campos de bloqueo aún puede escribir en el registro. Aplica la comprobación dentro de los guiones del lado del servidor que realizan las escrituras, no solo en la interfaz de usuario.

El sondeo añade latencia. Un cambio puede tardar hasta un intervalo del temporizador en aparecer en una pantalla de FileMaker.

El envío instantáneo necesita algo más. Para notificar a una aplicación externa a FileMaker de inmediato, necesitas un mecanismo aparte, como un webhook llamado desde un paso de guion o un pequeño servicio que vigile la tabla de bloqueos.

La expiración requiere cuidado. Elige un tiempo de vida mayor que tu intervalo de renovación, o los bloqueos caducarán durante el uso normal.

¿Puede un guion del lado del servidor bloquear un campo? #

Es tentador pensar que un guion podría poner un campo concreto de un registro concreto en modo de edición, tomando el foco con Ir al campo, y así mantener un bloqueo nativo. En la práctica esto no funciona desde un guion del lado del servidor. Los bloqueos nativos pertenecen a un cliente interactivo con una ventana. Un guion ejecutándose en el servidor no tiene ventana, así que los pasos de UI como Ir al campo no tienen un efecto fiable. Incluso si se estableciera el foco, el guion termina validando o revirtiendo, lo que libera el registro, y la Data API no puede mantener una sesión de edición abierta entre peticiones.

Transacciones #

FileMaker no proporciona un BEGIN y COMMIT explícitos que abarquen varios pasos de guion o varias peticiones. Validar registros/peticiones es atómico para los registros que guarda, pero nada mantiene abierta una transacción multirregistro entre llamadas a la API. Consulta la documentación de tu versión de FileMaker antes de confiar en cualquier comportamiento tipo transacción.

Protección más fuerte con concurrencia optimista #

Un bloqueo suave evita que dos personas empiecen a editar el mismo registro, pero no puede detener una condición de carrera. La concurrencia optimista aborda el problema más común, que es que un usuario sobrescriba el cambio de otro. La Data API devuelve un modId para cada registro. El cliente envía el modId que leyó por última vez junto con su actualización:

PATCH /records/{id}  { "fieldData": {...}, "modId": "42" }

Si el registro ha cambiado desde que se leyó ese modId, la petición falla. El cliente entonces recarga el registro y reintenta. Esto no impide que nadie abra un registro, pero evita sobrescrituras silenciosas. Para una garantía más estricta, serializa las adquisiciones de bloqueo a través de un único registro de bloqueo dedicado o una cola del lado del servidor, aunque eso añade una complejidad que la mayoría de soluciones no necesitan.

Conclusión #

No puedes activar un bloqueo nativo de FileMaker desde la Data API u OData, pero un bloqueo suave construido con unos pocos campos, unos pocos guiones y un temporizador de sondeo te da edición coordinada entre clientes API y clientes FileMaker. Trátalo como una herramienta de coordinación y no como un control de seguridad, y asegúrate de que el servidor lo hace cumplir.