Orchestration Multi PlatformHooks

Request description

Bonjour,

j’ai un besoin de clarification sur l’orchestration d’execution des méthodes “hook” dans les classes qui extends PlatformHooksInterface.
Nous avions historiquement une seul classe PlatformHooks dans un module A, j’ai utilisé la possibilité de créer une autre classe PlatformHooks_ModuleB dans un autre module (B) pour y spécifier un besoin métier.

Steps to reproduce

This request concerns an up-to-date Simplicité instance
and these are the steps to reproduce it:

1.Avoir une classe PlatformHooks

public class PlatformHooks extends com.simplicite.util.engine.PlatformHooksInterface {
  @Override
  public String preSearchIndex(Grant g, java.lang.String search) {
  //Stuff happening here 
  return search }
}

2.Avoir une classe PlatformHooks_ModuleB dans un module différent qui surcharge la même méthode.

public class PlatformHooks_ModuleB extends com.simplicite.util.engine.PlatformHooksInterface {
  @Override
  public String preSearchIndex(Grant g, java.lang.String search) {
  //Other Stuff happening here 
  return modifiedSearch }
}

Les 2 méthodes s’executent lors d’une recherche (j’ai l’impression) sans “avoir connaissance” de l’autre implémentation

Pouvons nous prédire que l’ordre de chargement/exécution des classes/méthodes sera toujours le même ? (lié à l’ordre de chargement des modules ?)
Si oui, si on continue avec ma situation, est que la classe PlatformHooks_ModuleB pourrait “recupérer” la requete modifié par la classe PlatformHooks (originel) pour après y appliquer son propre traitement ?

Technical information

Instance /health
[Platform]
Status=OK
Version=5.3.45
BuiltOn=2024-08-18 13:52

[JavaVM]
Version=17.0.12
Vendor=Eclipse Adoptium
VMName=OpenJDK 64-Bit Server VM
VMVersion=17.0.12+7
ScriptEngine=rhino
ScriptEngineVersion=Rhino 1.7.13 2020 09 02

Le PlatformHooks est un singleton donc il ne peut pas y en avoir plusieurs sur une même instance.

Vous devez donc merger vos classes (ou partir sur une implémentation plus complexe/subtile avec un PlatformHook “générique” qui appellerait les méthodes ad hoc de classes partagées de vos modules dans un ordre approprié et en gérant le fait que certains modules peuvent potentiellement ne pas être présents, d’où sans doute le besoin de passer par de la reflection, etc.)

Bonjour, merci pour ta réponse. Désolé j’ai du mal interpreté cette partie de la doc .

Pouvez-vous m’éclairer sur le sens de cet extrait svp ?

  • Multiple PlatformHooks* for a best business isolation:
    • to allow different app/modules to have there own hooks implementation (isMenuEnable, postSearchIndex…)
    • the name of shared code must start with PlatformHooks

On me souffle qu’il y a effectivement une gestion de multiples platform hooks. J’avoue ne jamais avoir fait ça donc je vais laisser la main sur ce point pour clarifier la manière de faire (y compris en termes d’ordre d’appel de hooks)

Oui on peut avoir plusieurs classes suffixées comme on veut.
Ensuite Simplicité n’a pas d’autre intelligence que d’appeler les hooks de chacun, dans l’ordre alphabétique des noms de script.

Par exemple pour

  • PlatformHooks1
  • PlatformHooks2

avec du code

public class PlatformHooks1 extends com.simplicite.util.engine.PlatformHooksInterface {
	@Override
	public void postLoadGrant(Grant g) {
		AppLog.info("PlatformHooks1.postLoadGrant");
	}
}

on aura :

INFO|system|com.simplicite.util.AppLog|info||Evénement: PlatformHooks1.postLoadGrant
INFO|system|com.simplicite.util.AppLog|info||Evénement: PlatformHooks2.postLoadGrant

La logique de “merge” entre les réponses des hooks appelés est la suivante :

  • un hook implémenté une seule fois aura toujours raison
  • des hooks qui retournent un boolean : logique AND (ex checkMFA, isMenuItemEnabled)
  • des listes : “merge distinct” de tous les items (ex validatePassword, postSearchIndex)
  • des string : garde seulement la dernière valeur non null (ex parseAuth)

Donc :

  • Si un même hook est implémentés 2 fois, mais avec des logiques métier contradictoires (le User doit être “ceci” dans le module 1, puis “pas ceci” dans le module 2), c’est qu’ils n’auraient pas dû être livré sur une même instance ou qu’il va falloir prioriser (en testant la présence de l’autre module…)
  • Quant à faire des “ponts” logiques entre métier/hooks, à vous de prévoir ça en passant dans des variables de session via Grant get/setParameter pour déterminer lequel des hooks a raison si un paramètre est déjà là… ou les ordonner de façon maline…
  • Ou enfin “re-centraliser” plusieurs hooks dans un seul d’un module commun

Merci beaucoup pour ton retour.

Ceci… est je pense la solution la plus souple.
Nous allons revoir le pattern de code du PlatformHook preSearchIndex pour réinjecter en tant que query pour chaque instance de preSearchIndex l’état courant fourni par le dernière instance exécutée.