Je souhaite pouvoir débrayer certaines règles du modèle logique dans le cas particulier des synchronisation par DataLink.
Je n’ai pas trouvé dans la documentation de notion d’instance de type DataLink comme isDataLinkInstance() ou isDataLinkEndpoint().
J’ai essayé de spécifier un user d’exécution pour le job DataLink. Il semble que le user system soit néanmoins invariablement celui utilisé pour opérer la synchronisation.
J’ai essayé en testant le type d’instance via isBatchInstance() et isSystem() mais c’est beaucoup trop incertain car les instance batch sont réutilisées dans d’autres contextes, y-compris via le cron sans pour autant que ce soit dans le contexte DataLink.
Y-a-t-il d’autres moyens de fixer le contexte de synchronisation par DataLink pour le détecter dans le code des objets concernés ?
pour la synchro au fil de l’eau par service API REST/PUT, c’est le user connecté (défini sur le datalink host) et des instances “api” qui travaillent
pour la synchro en masse par cron des DataLink (resync ou fil de l’eau ko…), c’est le user system qui utilise des batch instances (getBatchObject comme pour un import XML)
Bref il y a bien une logique mais rien ne répond effectivement à ton besoin d’isoler du code dans tous les cas simplement. Il faudrait une logique d’instance distincte mais c’est plutôt une information complémentaire de api/batch.
Il parait impossible de préfixer une instance API par autre chose que “api” dans le pool d’objets stateless.
On peut le faire dans le job cron de synchro (du style datalink_<objectname>)
On peut essayer de faire bosser le même user host et pas system pour la cron
Ou alors ajouter un flag dans l’objet instancié obj.setParameter("DataLinkInstance", true)
ou encore ajouter un suffixe _datalink au nom d’instance (pour pas perturber le prefix api ou eai)
C’est ce que j’ai appliqué pour l’instant dans les postLoad de chaque objet :
public void postLoad() {
super.postLoad();
if (isBatchInstance() && getGrant().isSystem()) {
setParameter("IS_DATA_LINK_CONTEXT", true);
Si dans les hooks d’objets je peux tester ce paramètre (d’objet) et le user du grant (isSystem ou pas), ça me laisse les coudées franches.
Si je peux en plus disposer du paramètre d’objet par défaut dans les deux flux c’est encore mieux (pour l’instant, je ne couvre que le cas de la synchro par batch asynchrone et pas le PUT synchrone car c’est uniquement dans le cas du batch global que j’ai mon pb; en effet, si l’objet est opéré dans un slave, les règles doivent pouvoir s’appliquer dans le master comme si l’objet avait été opéré dans le master).
Finalement comme c’est impossible d’ajouter cette information à l’objet avant son instanciation (et entre autre avant l’appel des hooks pre/postLoad qui peuvent en avoir besoin) :
on a ajouté un suffixe __datalink au nom d’instance (clé des caches/pools d’objet)
pour garder le préfix eai_ ou api_ : si on est en pull ou push
On pourra donc par exemple avoir dans les hooks les tests suivants :
// detect a data-link pull from a host (cron job: bulk resync)
if (isDataLinkInstance() && isBatchInstance()) ...
// detect a data-link push to hosts (REST/PUT: single record)
if (isDataLinkInstance() && isWebServiceInstance()) ...
A noter de bien utiliser un user API dédié pour les synchros, car toutes ses instances d’objet de son pool d’API seront des instances DataLink.
