Les builders du BPM

A de nombreuses occasions lors de l’utilisation du BPM Studio, les objets requièrent un script pour effectuer une action (script pur) ou pour vérifier si une condition est réalisée (script Completed if). A chaque fois que l’icône apparaît, vous pouvez cliquer dessus pour ouvrir et éditer un builder. Vous avez également la possibilité de cliquer sur l’icône qui permet d’éditer à la main le script.

Néanmoins, si vous choisissez de cliquer sur Ok, vous ne pourrez plus récupérer le script dans le builder et il faudra le refaire par vous même. Si vous avez cliqué sur Ok, l’icône apparaît et vous permet de supprimer l’intégralité de votre script

Builder completed if

Il permet de construire via une interface graphique une ou un ensemble de conditions qui doivent être satisfaites pour permettre à la tâche utilisateur de passer de son état initial à son état final.

add-expression Cet outil nous permet de venir ajouter un nouveau bloc de condition. Les blocs sont liés par le mot clef ET/OU Il faut choisir un modèle sur lequel tester notre condition, cela se fait via la liste déroulante suivante :

Les modèles proposés seront uniquement ceux qui auront été configurés dans le processus. Si la case suivante est coché , la condition sera vérifiée non pas sur le contexte du processus, mais sur la donnée précédemment créée s’il y en a une. Cette zone est le cœur du builder. C’est ici que l’on peut choisir les vérifications à effectuer sur le modèle.

Le Field Name permet de choisir un champ sur le modèle sélectionné et de vérifier une condition dessus (ici pizza) : Mais Pizza étant un objet à part entière avec ses caractéristiques, il est possible de les interroger en cliquant sur à droite du champ. Cela va rajouter un champ sur la droite, et ainsi permettre de sélectionner une valeur.

Cliquer sur la croix supprime le champ qui a été ajouté sur la droite.

Operator permet de choisir le type de vérification que l’on veut faire sur le champ. Quand ce champ fait référence à un objet, il y a trois types de vérification possibles.

Vérifier si l’objet est nul () ou non (),
vérifier si il est égal () ou non () à une valeur précise ou vérifier si il appartient () ou non () à une liste établie par le concepteur du processus (vous en l’occurrence).

Si le champ fait référence à une date ou à une valeur numérique, il est possible d’avoir d’autres types de vérification, toutes basées sur une vérification du type entre tel et tel date

() ou supérieur/inférieur/égal à une certaine date ou valeur ().

Après avoir choisi une façon de vérifier, si il ne s’agit pas d’un vérification de nullité, il faut expliciter d’où vient cette valeur :

Si on sélectionne None, la valeur sera issue de celle déjà présente dans la base de données.
Si on sélectionne Context, cela permet d’utiliser le modèle de données actuel. Ainsi
Si on sélectionne Self, cela permet de récupérer une valeur obtenue via la vue form. Ainsi il est possible de récupérer une date dans notre vue, et de la comparer avec une autre date pour vérifier une condition.
Si vous souhaitez supprimer une règle, un groupe ou une expression, il vous suffit de cliquer sur l’icône poubelle

Avec toutes ses possibilités disponibles, vous pouvez construire la requête de votre choix aisément

Figure 1. Un exemple qui a permis de créer une requête qui vérifie que la description n’est pas nulle ET que le fournisseur est T0001-APOLLO OU ALORS que la société n’est pas nulle

Query builder

Accessible en cochant la case suivante , elle permet d’ouvrir le Query builder quand vous allez cliquer sur et le builder va s’ouvrir.

Vous pouvez sélectionner n’importe quel modèle dans la liste déroulante suivante, et ainsi l’interroger

Comme pour le builder completed if vous construisez votre requête.

Si vous cochez la case Vous aurez en résultat uniquement le premier de la liste de résultats.

Le résultat obtenu sera stocké dans la variable défini dans le champ suivant event process qui est situé sous le script.

Mapper rédaction script

Il permet de créer facilement un script qui va créer un nouvel enregistrement sur un modèle, modifier un enregistrement déjà existant ou créer une nouvelle variable.

Le mapper se présente sous la forme suivante :

On peut choisir un modèle cible (Target model), c’est sur celle ci que vont s’effectuer les modifications Ensuite il faut choisir un ou plusieurs modèles source qui serviront de base pour récupérer des données. Si nous sommes dans un form A pendant l’utilisation de notre processus, nous pouvons spécifier que le modèle source est issu du context via le champ model from. De la même manière, il est possible de spécifier que le modèle source est issu du processus en cours. Le mapper permet donc d’assigner des valeurs au modèle cible.Ici 4 exemples des assignations possibles.

On peut assigner au modèle cible une valeur obtenue via le modèle source (1ère ligne).
On peut aussi choisir de récupérer le modèle via ceux disponibles dans le processus (2nde ligne). De plus, il est possible de chaîner la récupération de la donnée (Purchase request possède une société, celle-ci possède une devise, je récupère la devise par ce biais).
On peut plus simplement assigner une expression parmi celle disponible dans la base de donnée si le champ est un objet en base (Équipe) ou une valeur numérique si l’objet en accepte une.
On peut également, si l’objet existe déjà (sinon on provoque une NPE), récupérer une valeur directement sur celui-ci puis l’assigner à un autre champ.
Il est également possible d’accéder à des variables d’environnement en sélectionnant le contexte comme origine de la valeur.

Les variables de contexte accessibles sont:

__date__ : date du jour
__datetime__: date et heure du jour
__studiouser__ : utilisateur connecté
__log__ : le logger utilisable dans les scripts du BPM

Variables disponibles pour les scripts

The Axelor script is an extended format of the groovy language, it supports the following inbuilt variables and functions.

__ctx__: It represents the context helper service, and it has the following helper functions. It is used in a similar manner with both custom or real models.
- __ctx__.create(String modelName): It is used to create a new record for the model name passed as a parameter. For example, to create a new product it should be used like __ctx__.create(‘Product’). It returns the context of the new product created, here the context is the extended version of a normal JPA entity. This context allows the update and retrieval of custom field values too.
- __ctx__.filterOne(String modelName, String query, String[] params): This helper function is used to find the record by using a query. For example, to find a product with code ‘COMP-005’, this can be used like __ctx__.filterOne(‘Product’,’self.code = ?1’, ‘COMP-005’) It will return a single result from the executed query.
- __ctx__.filter(String modelName, String query, String[] params): It is a similar function as the previous one, but it will return a list of records from the executed query.
- __ctx__.find(String modleName, Long recordId): It will find the record based on the modelName passed with the given recordId.
- __ctx__.save(Object object): It allows you to save the record created by __ctx__.create or record available within the process instance context.
- __ctx__.createVariable(WkfContext wkfContext, DelegateExecution execution): This function is used when a process variable is required to create from the newly created record from __ctx__.create function, here pass that record as wkfContext and execution (inbuilt variable). For example, to create a new variable for a product that is created on the first function, the variable creation can be done by __ctx__.createVariable(product,execution).
__beans__: It represents com.axelor.inject.Beans, which is used to inject and use services.