Une Action Alfresco est une unité de tâche qui peut être exécutée sur un node comme par exemple transformer le document représenté par le node, envoyer le document représenté par email comme fichier attaché, copier le document, lancer une opération de sauvegarde de tout le Repository par exemple.

Une action est une opération qu'on peut effectuer à partir d'un node. L'opération n'est toujours pas forcement appliquée sur le node courant, elle peut impacter tout ou partie des nodes du Repository ou d'un Workspace.
Les actions Alfresco sont configurées à partir des règles de gestion des contenus.
Lorsqu'on décide d'implémenter une action Alfresco, la première des choses à faire est de décider de ce que l'action Alfresco que vous voulez développer doit permettre de faire.

Développer une Action Alfresco revient à implémenter un certain nombre de classes abstraites au niveau du Server (pour l'implémentation de l'action proprement dite) et au niveau du Front-End web JSF (dans le cas où l'action nécessite l'interaction de l'utilisateur). Nous allons nous intéresser à un cas de figure d'une Action n'ayant aucune interaction avec l'utilisateur, c'est-à-dire n'ayant aucun fichier JSP pour l'entrée de données.

Au niveau du Server on doit implémenter l'interface org.alfresco.repo.action.executer.ActionExecutor du noyau. La classe résultante qui est l'implémentation de votre action Alfresco est appelée dans le jargon d'Alfresco un "Action Executer". L' "Action Executer" contient l'implémentation d'une Action. C'est dans cette classe qu'on doit écrire le code qui va permettre d'effectuer des opérations sur le node.

public interface ActionExecuter
{
   /**
    * Get the action definition for the action
    * 
    * @return  the action definition
    */
   public ActionDefinition getActionDefinition();
	
   /**
    * Execute the action executer
    * 
    * @param action:	the action
    * @param actionedUponNodeRef:	the actioned upon node reference
    */
   public void execute(
     	Action action,
        NodeRef actionedUponNodeRef);
}

Deux méthodes de l'interface ActionExecuter doivent être implémentées : getActionDefinition() et execute().

getActionDefinition(): permet de fournir un objet définissant votre action. Celui-ci donne les détails du nom de l'action (très important : en fait chaque Action Alfresco enregistrée dans la plateforme doit avoir un nom qualificatif différent des autres) et les détails sur les paramètres attendus.

execute(): fournit la méthode d'exécution. Celle-ci prendra une instance de l'action et le node sur lequel l'appliquer et exécutera les opérations spécifiées.

L'interface ActionExecuter peut être implémentée directement, mais le Centre de Compétences Alfresco-jBPM de Koossery Technology conseille au dévéloppeur de plutôt étendre la classe de base des Actions ActionExecuterAbstractBase afin de bénéficier par défaut de l'implémentation de certaines méthodes basiques.

ActionExecuterAbstractBase fournit toutes les opérations additionnelles requises par la plateforme et un couple de méthodes abstraites à implémenter de façon à rendre les choses plus faciles pour un développeur. En étendant cette classe, les deux méthodes abstratites qui restent à implémenter sont: executeImpl (relative à execute() de l'interface) et addParameterDefinitions (relative à getActionDefinition de l'interface).

public class AddAspectActionExecuter extends ActionExecuterAbstractBase
{
   /**
    * @see org.alfresco.repo.action.executer.ActionExecuterAbstractBase#executeImpl(Action, NodeRef)
    */
   @Override
   public void executeImpl(Action action, NodeRef actionedUponNodeRef)
   {
      // TODO fill in implementation
   }

   /**
    * @see org.alfresco.repo.action.ParameterizedItemAbstractBase#addParameterDefinitions(java.util.List)
    */
   @Override
   protected void addParameterDefinitions(List<ParameterDefinition> paramList) 
   {
      // TODO fill in action parameter definitions
   }
}

Dans la figure ci-dessus le développeur crée une classe AddAspectActionExecuter ( son " Action Executer ") qui implémente la classe de base ActionExecuterAbstractBase.
Les "Actions Executors" (pluriel de "Action Executer") doivent être configurées via Spring en injectant au besoin tous les services du repository dont vous aurez besoin dans l'implémentation. Ainsi le développeur devra juste écrire les méthodes setters relatives aux services, méthodes qui seront utilisées par Spring pour injecter les services requis.

Lors de l'implémentation de l' "Action Executer", la première chose à faire c'est de paramétrer l'action afin d'avoir tous les détails nécessaires pour l'exécution. La définition des paramètres requis se fait en ajoutant dans la méthode addParameterDefintions une instruction du genre :

public static final String NAME = "add-aspect";
public static final String PARAM_ASPECT_NAME = "aspect-name";

   
   @Override
   protected void addParameterDefinitions(List<ParameterDefinition> paramList) 
   {
      // Add definitions for action parameters
      paramList.add(
                // Create a new parameter defintion to add to the list
           new ParameterDefinitionImpl( 
                   // The name used to identify the parameter
           PARAM_ASPECT_NAME,                          
                  // The parameter value type
           DataTypeDefinition.QNAME,        
                   // Indicates whether the parameter is mandatory               
                                true,                                           
                          // The parameters display label
          getParamDisplayLabel(PARAM_ASPECT_NAME)));         }

new ParameterDefinitionImpl() crée la définition d'un nouveau paramètre à ajouter à la liste.

Le premier paramètre de ParameterDefinitionImpl (exemple : la constante PARAM_ASPECT_NAME) est le nom qui sera utilisé pour identifier le paramètre. Notons que la méthode addParameterDefitions sera appelée en premier lieu par le Framework des Actions lorsqu'une action sera invoquée depuis le client web. Les paramètres dont on fait allusion ici sont soit les paramètres provenant du client web (nous verrons dans le chapitre sur le Front-End comment les paramètres de l'action sont gérés dans la partie Front-End des Actions Alfresco), soit des objets construits par le Framework par exemple à partir des modèles (exemple : le cas d'une action qui ajoute un aspect à un node, il s'agira d'un paramètre définissant le QName de l'aspect).

Le deuxième paramètre précise le type du paramètre (exemple : DataTypeDefinition.QNAME, ça aurait pu être DataTypeDefinition.TEXT dans le cas d'un String).

Le troisième paramètre précise si le paramètre est obligatoire ou pas. Et enfin le quatrième paramètre est le label (affichable dans le Client Web).

Ainsi lorsqu'une action est invoquée, le Framework des Actions identifie l' "Action Executer" correspondant (l' "action executer" que vous avez développée et installée dans la plateforme), puis il appelle la méthode interne getActionDefinition de la classe de base (ActionExecuterAbstractBase) qui, à l'aide de la méthode addParameterDefinitions, utilisera la liste paramList (paramètre interne) pour retourner une classe définissant l'action et contenant les définitions des paramètres.

L'objet de type Action retourné à l'aide de la méthode getActionDefinition va donc être utilisé par le Framework pour invoquer la méthode executeImpl() afin d'exécuter les opérations de l'action. Intéressons nous à l'implémentation de la méthode executeImpl().

Notons que le corps de la méthode est essentiellement ce que vous souhaitez faire. Donc aucune règle n'est prescrite à ce niveau. Par contre ce que nous pouvons dire c'est que la méthode doit obligatoirement avoir la signature

public void executeImpl(Action action, NodeRef actionedUponNodeRef)

Cette méthode est invoquée par le conteneur Alfresco (le Framework des Actions). Dans l'implémentation, l'argument "action" doit servir à récupérer les paramètres de l'action. Voici un exemple de récupération d'un paramètre de l'action dans l'implémentation de la méthode executeImpl:

QName aspectQName = (QName)action.getParameterValue(PARAM_ASPECT_NAME);

L'argument actionedUponNodeRef de type NodeRef est la référence (NodeRef) du node sur lequel l'action est appliquée. Cet argument, tout comme l'autre, est passé par le Framework lors de l'invocation de la méthode executeImpl.

Chaque Action doit avoir un titre et une description.
Pour ce qui concerne le nom et la description de l'action, on doit avoir les entrées :
-  "action-class-name".title
-  "action-class-name".description
-  "action-class-name".display-label.
dans un bundle chargé.

Dans l'exemple illustratif que nous utilisons, l' "Action Executer" est nommée:

public static final String NAME = "add-aspect";

Ainsi on doit avoir ceci dans le fichier bundle :

# Custom action messages

add-aspect.title=Add aspect to item
add-aspect.description=This will add an aspect to the matched item.

Chaque paramètre de l'Action doit avoir un titre affichable (les labels des paramètres sont ajoutés à travers la méthode getParamDisplayLabel). Tous ces éléments affichables sont retrouvés à partir des bundles I18N permettant ainsi l'internationalisation (I18N) de l'action.

On doit avoir pour chaque paramètre l'entrée suivante dans le bundle :
-  "action-class-name"."param_name". display-label.

Un exemple:

add-aspect.aspect-name.display-label=The name of the aspect to apply to the node.

Afin de rendre la nouvelle action disponible dans la plateforme, on a besoin de configurer l'action comme un Bean Spring. Ceci est possible en ajoutant cette configuration dans le fichier action-services-context.xml dans le noyau d'Alfresco. Mais dans le but de ne pas modifier les fichiers de base du noyau, il faut le faire dans un fichier nommé "action-class-name"-action-context.xml et le placer dans un package alfresco.extension. Ou bien, créer plutôt un fichier custom-action-services-context.xml et le placer toujours dans un package alfresco.extension. Ce dernier devant overrider le fichier de base action-service-context.xml.

Rappelons que tous ces fichiers (*-context.xml) sont chargés dynamiquement et automatiquement par la plateforme Alfresco. Donc, pas besoin de créer un contexte Spring dans le code.
Le contenu du fichier doit ressembler à ceci :

<bean id="add-aspect"   class="org.alfresco.repo.action.executer.AddAspectActionExecuter" parent="action-executer">
      <property name="nodeService">
         <ref bean="nodeService" />
      </property>
</bean>

<bean id="add-aspect-messages"   class="org.alfresco.i18n.ResourceBundleBootstrapComponent">
      <property name="resourceBundles">
        <list>
           <value>org.alfresco.sample.add-aspect-messages<value/>
        </list>
      </property>
</bean>

On peut voir la configuration de deux Beans. Le Bean de l'action exécuter montre bien que c'est une classe de type " Action-Executer ". On peut voir la configuration du bundle de l'action.
Il est possible réaliser une classe de test Junit pour tester son Action Executer. Vous devrez à chaque fois rédiger une classe de test Junit de votre Action Executer.

Il reste à développer la partie Front-End (web JSF) de l'action afin d'écrire les JSP qui permettront à l'utlisateur de saisir les paramètres. L'exemple illustratif que nous utilisons ne nécessite pas de partie Front-End c'est-à-dire ne nécessite pas de données d'entrée et d'interaction avec l'utilisateur. Nous verrons dans la section correspondante du chapitre sur le Front-End Alfresco comment développer un projet Action complet comportant un Front-End et un Back-Eend.

Le Centre de Compétences Alfresco-jBPM de Koossery Technology recommande la documentation ci-dessous:

Il faut s'exercer sur les projets CustomAction et TaggingSample du SDK Alfresco et lire les documentations :

Le Framework Alfresco Aspect est un ensemble de composants qui permettent d'ajouter de façon programmatique et en utilisant les modèles M2, des propriétés supplémentaires ainsi que du comportement aux noeuds (exemple: comme récupérer automatiquement les courriers électroniques sur un serveur distant et les enregistrer dans le noeud courant, ou bien lancer des batch à intervalle de temps régulier pour faire n'importe quoi).

Nous allons voir comment développer un projet permettant d'ajouter non seulement des propriétés à un node, mais aussi du comportement.

L'exemple sur lequel nous allons nous appuyer est le sample "CustomAspect" du SDK Alfresco qui est notre environnement de développement des extensions.
Cet exemple est un projet qui défini un modèle d'aspect qu'on peut greffer aux nodes afin de pouvoir savoir combien de fois le contenu du node a été lu, combien de fois il a été modifié et quand est-ce que le comptage a débuté. Cet aspect ajoute dont 3 propriétés aux propriétés primaires des nodes:
-  Une propriété pour le nombre de fois que le contenu a été modifié
-  Une propriété pour le nombre de fois qu'il a été lu
-  Et une pour la date de début du comptage, c'est-à-dire la date à laquelle l'aspect a été ajouté au node.

En plus de l'ajout des propriétés, il faut développer du comportement implémentant les opérations pour incrémenter les deux propriétés suivantes: celle concernant le nombre de lectures quand le document est lu et celle concernant le nombre de modifications quand le document est modifié.

A présent nous devons définir le modèle de notre aspect. Définir le modèle de l'aspect revient à définir le type de contenu qui représentera l'aspect et aussi définir les propriétés que cet aspect apportera en plus aux nodes. Le comportement (implémentation de l'aspect) utilisera les propriétés de l'aspect lors de la réalisation les opérations associées (initialisation de la date de début des comptes, incrémentation du compteur du nombre de modification, incrémentation du compteur du nombre de consultation).
Le modèle est défini dans le fichier contentHitsModel.xml. Ci-dessous un extrait:

<aspects>
      
      <!-- Definition of new Content Aspects: Content Hits -->
      <aspect name="ch:contentHits">
      	<title>Content Hits</title>
      	<properties>      	
      		<property name="ch:countStartedDate">
      			<type>d:date</type>
      			<mandatory>true</mandatory>
      		</property>
      		<property name="ch:updateCount">
      			<type>d:int</type>
      			<default>0</default>
      		</property>
      		<property name="ch:readCount">
      			<type>d:int</type>
      			<default>0</default>
      		</property>
      	</properties>
      </aspect>
      
   </aspects>

On peut voir 3 propriétés. Ce sont les propriétés qui seront ajoutés aux propriétés des nodes sur lesquels cet aspect sera greffé. La propriété ch:countStartedDate représente la date de début de comptage, ch:updateCount représente le compteur du nombre de modification du contenu et ch:readCount le compteur du nombre de consultation du contenu.

Ceci est une représentation du modèle de l'aspect du projet sous forme de diagramme UML. Mais il est à noté que ceci n'est fait que dans un but illustratif. En réalité la plateforme ne crée pas de classes pour les entités définies dans les modèles M2. Les diagrammes de classes UML sont utilisés pour présenter les modèles M2 juste pour des buts d'illustration: ne surtout pas croire qu'une classe ContentHits sera créée pour ce modèle. Les modèles de données définis dans les fichiers modèles M2 sont juste les définitions de types de contenu de propriétés manipulées par le NamespaceService et le DictionaryService afin de construire une représentation dans le repository.

On pourrait maintenant se poser la question de savoir comment est ce que cet aspect va être enregistré dans la plateforme afin qu'il soit possible de l'utiliser et de le greffer sur des nodes. Et bien cela sera fait par configuration XML à travers le mécanisme de chargement dynamique et automatique des configurations des extensions Alfresco qui demande que le fichier de configuration Spring du projet soit créé dans un package alfresco.extension avec un nom se terminant par "-context". Ainsi notre aspect est configuré dans le fichier "content-hits-context.xml" créé dans un package alfresco.extension du projet. Les modèles sont chargés à partir du bean dictionaryModelBootstrap qui dépend lui même du bean dictionaryBootstrap.

<!-- Registration of new models -->	
    <bean id="contentHits.dictionaryBootstrap" parent="dictionaryModelBootstrap" depends-on="dictionaryBootstrap">
        <property name="models">
            <list>
                <value>org/alfresco/sample/contentHitsModel.xml</value>
            </list>
        </property>
    </bean>

A ce stade c'est suffisant pour l'intégration du nouveau type de contenu aspect de notre projet.
Maintenant il reste l'implémentation du comportement associé, c'est-à-dire les opérations qui vont créer la date de début de compte dès que l'aspect sera ajouté à un node, et les opérations qui réaliseront les incrémentations.

On pourrait se poser la question de savoir quelle interface (ou classe abstraite de base) doit être implémentée (ou étendue) pour réaliser la classe behavior (comportement) de l'aspect. A ce stade du master nous répondons en disant que pour notre projet, rien !! (Pour l'instant). En fait, la classe qui réalise l'implémentation du comportement de notre projet n'implémente aucune interface ou n'étend aucune classe abstraite relative au concept des Aspect Alfresco. Mais ça ne veut pour autant dire que notre classe n'implémente aucune interface du tout, ou bien aucune classe abstraite du tout !!! En fait elle implémente même 3 interfaces. Afin de vous dire quelles interfaces, nous allons essayer de répondre aux questions :
-  Comment est ce que la plateforme fait pour savoir qu'un aspect (l'aspect que nous avons défini dans notre modèle et qui est enregistré et disponible dans le dictionnaire de données) est entrain d'être greffé à un node donné ? Ceci afin de créer un objet de type Date (new Date()) et enrichir la propriété ch:countStartedDate qui vient d'être ajoutée par l'aspect.

-  Comment fait-il pour détecter une modification de noeud ? Ceci afin d'incrémenter sa propriété ch:updateCount.

-  Comment fait-il pour détecter une lecture du noeud ? Ceci afin d'incrémenter sa propriété ch:readCount.

La réponse à ces questions est le mécanisme de source - auditeur du Framework Alfresco. En fait, la plateforme Alfresco dispose d'un Framework de source - auditeur. Ce Framework, qui va être étudié dans une section plus bas, permet de développer des auditeurs à des évènements. En gros voici comment ça marche : le Framework possède un certain nombre d'événements qu'il peut écouter (exemple : lecture de node, suppression d'un node, ajout d'un aspect à un node, ajout d'une association à un node etc. la liste est longue). Ainsi un auditeur de type OnContentReadPolicy sera invoqué par la plateforme lors de la lecture d'un node, un autre de type OnMoveNodePolicy sera invoqué lors du déplacement d'un node. La plateforme permet donc d'implémenter des auditeurs de ces divers types qui seront invoqués lors d'événement associé afin de réaliser ce que vous voulez du node concerné. Pour chaque type d'auditeur une interface est fournit pour être implémentée.

Pour revenir à notre projet, en s'appuyant sur le framework Source-Auditeur, la classe de notre comportement doit implémenter 3 interfaces représentant les trois types d'auditeurs : OnContentReadPolicy, OnContentUpdatePolicy, OnAddAspectPolicy

public class ContentHitsAspect implement 
                            ContentServicePolicies.OnContentReadPolicy,
                            ContentServicePolicies.OnContentUpdatePolicy,
                            NodeServicePolicies.OnAddAspectPolicy

Notre classe tri-auditeur sera enregistrée dans la liste des auditeurs de type ContentReadPolicy, elle sera ajoutée dans la liste des auditeurs de type ContentUpdatePolicy et dans la liste des auditeurs de type AddAspectPolicy et sera managée par le Framework des sources - auditeurs.
La configuration de notre comportement se fait dans le fichier contexte "content-hits-context.xml" dans le package alfresco.extension

<!-- ContentHits Aspect Behaviour Bean -->
    <bean id="contentHitsAspect" class="org.alfresco.sample.ContentHitsAspect" init-method="initialise">
    	<property name="nodeService">
    		<ref bean="nodeService"/>
    	</property>
    	<property name="policyComponent">
    		<ref bean="policyComponent"/>
    	</property>
        <property name="policyFilter">
            <ref bean="policyBehaviourFilter"/>
        </property>
    	<property name="transactionService">
    		<ref bean="transactionService"/>
    	</property>
    	<property name="threadExecuter">
    		<ref bean="threadPoolExecutor"/>
    	</property>
    </bean>

La méthode initialise() permet d'enregistrer les auditeurs implémentant les comportements.

/**
     * Spring initilaise method used to register the policy behaviours
     */
    public void initialise()
    {
        // Register the policy behaviours
        this.policyComponent.bindClassBehaviour(
                                 QName.createQName(NamespaceService.ALFRESCO_URI, "onAddAspect"),
                                 ASPECT_CONTENT_HITS,
                                 new JavaBehaviour(this, "onAddAspect", NotificationFrequency.FIRST_EVENT));
        this.policyComponent.bindClassBehaviour(
                                 ContentServicePolicies.ON_CONTENT_READ,
                                 ASPECT_CONTENT_HITS,
                                 new JavaBehaviour(this, "onContentRead", NotificationFrequency.TRANSACTION_COMMIT));
        this.policyComponent.bindClassBehaviour(
                                 ContentServicePolicies.ON_CONTENT_UPDATE,
                                 ASPECT_CONTENT_HITS,
                                 new JavaBehaviour(this, "onContentUpdate", NotificationFrequency.TRANSACTION_COMMIT));
    }

La première instruction réalise le binding de notre comportement avec l'évènement d'ajout de notre aspect à un node. L'auditeur sera invoqué uniquement la première fois que l'évènement d'ajout de l'aspect se réalisera sur un node.

La deuxième instruction réalise le binding de notre comportement avec l'évènement de lecture d'un contenu. L'auditeur sera invoqué lorsque la transaction sera commit.

La troisième et dernière instruction réalise le binding de notre comportement avec l'évènement de modification d'un contenu. L'auditeur sera invoqué lorsque la transaction sera commit.

Une question plane. Puisque notre classe (l'implémentation du comportement de l'aspect) est à la fois auditeur des trois types, quelle méthode sera invoquée à chaque fois qu'il y'aura un évènement de type parmi les 3 types traités. La question semble évidente n'est ce pas ? En fait chaque interface d'auditeur impose l'implémentation d'une méthode bien précise. C'est cette méthode qui sera invoquée par la plateforme suite à un évènement.

Pour l'ajout d'un aspect c'est-à-dire le behaviour onAddAspect, la méthode à implémenter est onAddAspect(NodeRef nodeRef, QName aspectTypeQName). L'argument NodeRef est le NodeRef du node sur lequel l'aspect est greffé tandis que l'argument aspectTypeQName est le QName (qualificatif) de l'aspect greffé (c'est à dire l'aspect de notre projet).
Notre implémentation de cette méthode se limite à juste ajouter au node une propriété countStartedDate (le QName de cette propriété a été défini dans le modèle de notre aspect) avec une valeur égale à la date de l'instant présent.

- Pour la modification d'un contenu c'est-à-dire le behaviour onContentUpdate la méthode à implémenter est void onContentUpdate(NodeRef nodeRef, boolean newContent)
Comme on peut déjà l'imaginer, l'implémentation de cette méthode permet d'incrémenter le compteur du nombre de modification du contenu du node.

- Pour la lecture d'un contenu c'est-à-dire le behaviour onContentRead la méthode à implémenter est void onContentRead(NodeRef nodeRef)
Comme on peut déjà l'imaginer, l'implémentation de cette méthode permet d'incrémenté le compteur du nombre de consultation du contenu du node.

@Note: Nous n'insisterons pas assez sur le Framework de gestion des behaviour (comportement) et des sources - auditeurs avec le composant PolicyComponent dans cette section car il sera vu en détail dans une section plus en bas et s'argumentera d'un syllabus associé.

Notons qu'un Aspect Alfresco n'est rien dans la plateforme sans une Action Alfresco pour le greffer aux nodes. Ceci dit, il est important de développer une Alfresco Action qui permettrait de greffer votre aspect aux nodes. Ainsi si l'on veut greffer l'aspect que nous venons d'illustrer, il nous suffira de juste lancer l'action en question.

Mais étant donné que nous sommes en environnement de programmation, une bonne classe de test Junit nous permettrait de tester notre aspect. Nous vous invitons à explorer la classe de test Junit qui est fournit avec ce projet. Exécutez le test et voyez de vos yeux l'aspect en action.

Il s'agit de s'intéresser au projet CustomAspect du SDK Alfresco, au projet emailistener disponible sur le forge d'Alfresco. Lire les documentations :

La plateforme Alfresco dispose d'un Framework de "source - auditeur". Ce Framework permet de développer des auditeurs qui sont à l'écoute des évènements. En gros voici comment ça marche : le Framework possède un certain nombre d'événements qu'il peut écouter (exemple : lecture de node, suppression d'un node, ajout d'un aspect à un node, ajout d'une association à un node etc. la liste est longue). Par exemple un auditeur de type OnContentReadPolicy sera invoqué par la plateforme lors de la lecture d'un node, un autre de type OnMoveNodePolicy sera invoqué lors du déplacement d'un node. La plateforme permet donc d'implémenter des auditeurs de ces divers types qui seront invoqués lors d'événement associés. Pour chaque type d'auditeur, une interface est fournie.

Le tableau ci-dessous dresse une liste exhaustive d'interfaces d'auditeurs fournies par Alfresco et utilisable pour développer des auditeurs:

En mettant en oeuvre le design pattern "observer", les auditeurs sont invoqués sur la base de notifications fréquentielles. Le tableau suivant dresse une liste de notifications fréquentielles:

En récapitulatif si je veux créer un comportement, la première des choses est que je dois décider ce que mon comportement doit faire. Après il faut que je sache à quel évènement mon comportement est lié. Et finalement suivant quelle fréquence mon comportement doit être exécuté.
Ainsi quand ces trois points sont clarifiés, j'implémente mon auditeur. Puis je l'encapsule dans un objet de type JavaBehaviour en spécifiant la fréquence de notification.

policyComponent.bindClassBehaviour(
                                 ContentServicePolicies.ON_CONTENT_UPDATE,
                                 monQName,
                                 new JavaBehaviour(monAuditeur, "onContentUpdate",   
                                 NotificationFrequency.TRANSACTION_COMMIT));

Cette instruction permet de placer mon comportement dans une file transactionnelle de comportements à exécuter, ceci en spécifiant le type d'évènement et la fréquence de notification. Dans cette instruction monQName représente le QName de l'entité qui est manipulée, "onContentUpdate" est le nom de la méthode implémenté par l'auditeur et qui sera exécutée par le Framework, ContentServicePolicies.ON_CONTENT_UPDATE représente l'évènement comme on peut le voir et en même temps, il représente le type d'auditeur.

Le projet "CustomAspect" du SDK Alfresco est un excellent exemple de projet utilisant des auditeurs. Le Centre de Compétences Alfresco-jBPM de Koossery Technology vous recommande de vous exercer dessus. De plus lire les documentations :