Explication IDfQueryProcessor DFC

De EjnTricks
Révision de 2 janvier 2014 à 12:03 par Etienne (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Dans différentes applications Documentum, comme Webtop cf Explication Exécution Recherche Webtop, les requêtes sont exécutées à l'aide d'une instance de l'interface com.documentum.fc.client.search.IDfQueryProcessor. Ceci permet de récupérer les résultats de façon asynchrone en utilisant un mécanisme de listener. Cependant cette implémentation est particulièrement difficile à appréhender à première vue, car beaucoup de classe sont utilisées.

Cet article va décrire différents points importants important pour comprendre cette fonctionnalité.

Hand-icon.png Votre avis

Nobody voted on this yet

 You need to enable JavaScript to vote


Version 5.3 SP2

Rappel d'utilisation depuis Webtop

Cette article a été écrit suite à l'analyse faite sur l'exécution d'une recherche dans Webtop. Au niveau de Webtop, les requêtes sont construites et exécutées à partir d'une instance com.documentum.fc.client.search.IDfSearchService construite à l'aide de l'instruction suivante:

IDfSearchService searchService = getSearchInfo().getSearchService();

La code de la fonction getSearchService() est:

Ensuite, le code suivant est utilisé afin d'exécuter une requête définie par une instance de com.documentum.fc.client.search.IDfQueryDefinition


Construction de IDfClient

Plusieurs implémentations sont disponibles pour cette interface. Après plusieurs expérience, il est facile de savoir quelle est la classe utilisée. Mais il est important de comprendre comment celle ci est construite. L'implémentation est donc retournée par la méthode getLocalClient() d'une instance de com.documentum.com.DfClientX.

La construction de l'instance de DfClient s'effectue donc depuis la fonction statique getLocalClient

Celle ci fait appel à la fonction statique getLocalClientEx() au sein de la même classe qui va permettre d'obtenir enfin l'instance souhaitée:

En conclusion, la variable retournée par la fonction getLocalClient, de DfClientX, est une instance de com.documentum.fc.client.DfClient.


Construction du service de recherche

Après avoir récupérer une instance de IDfClient, la fonction newSearchService(IDfSessionManager idfsessionmanager, String s) est exécutée afin de récupérer le service de recherche. C'est pourquoi il était important de connaître précisément la classe utilisée. L'étude de cette fonction permet d'identifier la classe exacte du service.

Encore une fois, cette analyse n'est pas forcément nécessaire car il y a uniquement deux implémentations de l'interface IDfSearchService:

  • com.documentum.fc.client.search.impl.mockups.DfSearchService
  • com.documentum.fc.client.search.impl.DfSearchService

D'après le package de la première implémentation, il était fort peu probable qu'elle soit utilisée. L'analyse a pu confirmer cette intuition.


Construction du IDfQueryProcessor

C'est cette instance qui est utilisée pour exécuter une définition de recherche. Elle est construite à partir de service de recherche par la fonction newQueryProcessor(IDfQueryDefinition query, boolean removeDuplicate).

La variable retournée est donc une instance de la classe com.documentum.fc.client.search.impl.execution.DfQueryProcessor. Encore une fois, la lecture de ce code n'était pas forcément nécessaire car il n'existe qu'une seule implémentation de l'interface IDfQueryProcessor. Mais il est important de noter le paramètre d'appel au constructeur construit à l'aide de la fonction getBrokerAssembly(), qui sera utilisée plus tard.

Dans le constructeur de la classe DfQueryProcessor, la fonction getQueryBroker() de l'instance BrokerAssembly est exécutée afin de peupler la variable m_receiver.

La variable m_receiver est donc peuplée à l'aide de la fonction getQueryBroker() de l'argument assembly.

Celle ci retourne la variable interne m_queryBroker construite dans le constructeur de la classe.

Tout cela est un peu fastidieux, mais nécessaire pour comprendre la suite.


Exécution de la recherche

La recherche est construite et exécutée depuis la méthode search() de l'instance DfQueryProcessor.

A ce niveau, on peut constater l'utilité de connaître la classe d'instance de m_receiver, pour mémoire QueryBroker, à laquelle a été affectée une instance de com.documentum.fc.client.search.impl.broker.Scheduler dans la variable m_scheduler lors du constructeur de BrokerAssembly. La fonction search(Surrogate sg, ServerQuery query) est la suivante.


Exécution différée de la recherche, classe Scheduler

Jusqu'à présent la requête n'est toujours pas construite ni exécutée. Mais comme le nom de la classe Scheduler l'indique, celle ci va être responsable de l'exécution différée/plannifiée de la requête.

Dans un premier temps, des instances (en fonction du nombre de source) de com.documentum.fc.client.search.impl.broker.Action sont construites et placées dans le vecteur unprocessedActions. Dans un second temps, les actions sont placées dans les variables m_docBasePendings ou m_ecisPendings. Ces variables sont des instances de com.documentum.fc.client.search.impl.broker.ActionQueue, construite dans le constructeur du Scheduler. Dans ce constructeur, des threads sont démarrés, ceux intéressants dans le cas des l'étude sont les instances de DocbaseBroker.


Définition des threads

Dans le constructeur de la classe Scheduler, des threads sont construits (cf paragraphe précédent, en les associant à une instance de ActionQueue. L'association s'effectue dans le constructeur de ces threads.


Déclenchement de la requête

En reprenant la classe Scheduler, les threads sont démarrés dès leur construction. L'analyse de la méthode run permet d'en finir avec l'analyse.

Dans cette méthode run, lorsque la valeur de la variable m_brokerState, représentant son état, est égal à 2 (visiblement actif), la méthode handleProcessingState() est exécutée.

Cette méthode va ensuite appelée la méthode internalProcess, abstraite dans la classe BaseBroker. Dans le cadre de cette explication, l'implémentation dans la classe DocbaseBroker est intéressante.

L'analyse de l'exécution de la recherche est ainsi terminée. Le nombre de classes mises en jeu est assez impressionnant, ce qui explique la difficulté à comprendre le fonctionnement. Toutefois, cela permet également d'identifier un moyen simple de logger les requêtes exécutées.