Una pregunta habitual entre els desenvolupadors de FileMaker que construeixen integracions és: “Puc bloquejar un registre a través de la Data API o OData, i fer que aquest bloqueig sigui visible per a tothom que fa servir la base de dades?”

Aquest article reflecteix la meva comprensió personal a dia d’avui, i pot ser que em faltin detalls o capacitats més recents. La meva esperança és que obri un debat. El bloqueig de registres és un assumpte crític per a les integracions riques de FileMaker, especialment a mesura que interfícies d’usuari més sofisticades es traslladen als WebViewers, on la coordinació entre la UI i la base de dades es torna més difícil d’aconseguir. Agraeixo correccions, experiències i enfocaments alternatius de qui hagi resolt això a la pràctica.

Segons el meu coneixement actual, la resposta curta a la pregunta és no. Entendre per què apunta cap a una solució viable.

Per què els bloquejos natius no funcionen aquí #

El bloqueig natiu de registres de FileMaker pertany a un client que té un registre en mode d’edició. El bloqueig dura només mentre aquest client està editant, i FileMaker Pro, Go i WebDirect són els únics clients que en poden mantenir un.

La Data API i OData són sense estat. Cada petició és independent, i un guió executat a través de la Data API acaba quan retorna la resposta. Res no queda bloquejat després, i cap de les dues APIs té un endpoint de “bloqueja aquest registre”. Tampoc no hi ha una forma integrada que FileMaker Server difongui un bloqueig als clients connectats.

La solució: un bloqueig tou emmagatzemat a les dades #

Un bloqueig tou (soft lock) és un registre ordinari a la teva taula que tots els clients acorden respectar. Té tres camps:

• lock_user, la persona que manté el bloqueig
• lock_session, un token únic per a la sessió d’aquest usuari
• lock_expires, una marca de temps que el titular renova periòdicament

Adquirir el bloqueig en un guió. Exposa un guió del costat del servidor a l’API. Aquest cerca el registre, comprova si un bloqueig no expirat pertany a una altra persona, i només llavors escriu el nou bloqueig. La cerca, la comprovació i l’escriptura s’executen dins d’un mateix guió, cosa que estreta la finestra de cursa, tot i que no la tanca. Dos guions executant-se al mateix moment poden llegir “sense bloqueig” abans que cap d’ells escrigui. El guió retorna JSON, de manera que el client API pot saber si el bloqueig ha estat concedit.

Renovar i alliberar. El client crida el mateix guió cada 30 a 60 segons per avançar lock_expires. Un guió d’alliberament independent neteja els camps quan l’usuari desa o abandona el registre. Si un client cau, el seu bloqueig simplement expira, de manera que un registre no pot quedar bloquejat per sempre.

Fer que els usuaris de FileMaker el vegin. FileMaker Server no envia canvis als clients, així que els clients FileMaker Pro han de sondejar. Una crida a Install OnTimer Script a la presentació pot executar-se cada 10 a 30 segons, comprovar si hi ha un bloqueig actiu d’una altra persona, i convertir els camps editables en de només lectura amb un avís. El bloqueig natiu continua protegint els usuaris de Pro que editen al mateix temps.

Advertències #

Un bloqueig tou és consultiu. Qualsevol guió o client API que ignori els camps de bloqueig encara pot escriure al registre. Aplica la comprovació dins dels guions del costat del servidor que fan les escriptures, no només a la interfície d’usuari.

El sondeig afegeix latència. Un canvi pot trigar fins a un interval del temporitzador a aparèixer a una pantalla de FileMaker.

L’enviament instantani necessita alguna cosa més. Per notificar immediatament una aplicació externa a FileMaker, necessites un mecanisme a part, com un webhook cridat des d’un pas de guió o un petit servei que vigili la taula de bloquejos.

L’expiració requereix cura. Tria un temps de vida més gran que el teu interval de renovació, o els bloquejos caducaran durant l’ús normal.

Pot un guió del costat del servidor bloquejar un camp? #

És temptador pensar que un guió podria posar un camp concret d’un registre concret en mode d’edició, prenent el focus amb Vés al camp, i així mantenir un bloqueig natiu. A la pràctica això no funciona des d’un guió del costat del servidor. Els bloquejos natius pertanyen a un client interactiu amb una finestra. Un guió executant-se al servidor no té finestra, així que els passos d’UI com Vés al camp no tenen un efecte fiable. Fins i tot si s’establís el focus, el guió acaba validant o revertint, cosa que allibera el registre, i la Data API no pot mantenir una sessió d’edició oberta entre peticions.

Transaccions #

FileMaker no proporciona un BEGIN i COMMIT explícits que abastin diversos passos de guió o diverses peticions. Validar registres/peticions és atòmic per als registres que desa, però res no manté oberta una transacció multiregistre entre crides a l’API. Consulta la documentació de la teva versió de FileMaker abans de confiar en qualsevol comportament tipus transacció.

Protecció més forta amb concurrència optimista #

Un bloqueig tou evita que dues persones comencin a editar el mateix registre, però no pot aturar una condició de cursa. La concurrència optimista aborda el problema més comú, que és que un usuari sobreescriu el canvi d’un altre. La Data API retorna un modId per a cada registre. El client envia el modId que va llegir per última vegada juntament amb la seva actualització:

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

Si el registre ha canviat des que es va llegir aquell modId, la petició falla. El client llavors recarrega el registre i ho reintenta. Això no impedeix que ningú obri un registre, però evita sobreescriptures silencioses. Per a una garantia més estricta, serialitza les adquisicions de bloqueig a través d’un únic registre de bloqueig dedicat o una cua del costat del servidor, tot i que això afegeix una complexitat que la majoria de solucions no necessiten.

Conclusió #

No pots activar un bloqueig natiu de FileMaker des de la Data API o OData, però un bloqueig tou construït amb uns quants camps, uns quants guions i un temporitzador de sondeig et dona edició coordinada entre clients API i clients FileMaker. Tracta’l com una eina de coordinació i no com un control de seguretat, i assegura’t que el servidor el fa complir.