Utilisation des fonctionnalités natives d’analyse de processus

Support
1

Request description

Bonjour,

Suite à la présentation du 6 novembre, nous avons pu mieux expérimenter la création d’un processus métier standard et cela nous a donné plusieurs idées d’implémentation métier ( Merci encore pour l’enregistrement , super utile ! ).

Nous souhaiterions aussi mieux comprendre certaines fonctionnalités natives liées à l’analyse de processus, je n’ai pas pu trouver de docs ou exemple dans la démo avec l’utilisation de ses fonctionnalités.

Existe-t-il une documentation détaillée ou un exemple de configuration complet sur ces modules (graphiques, indicateurs, dossier processus/activité, suivi des activités,alerte…) ?

image
image320×242 8.67 KB

Besoin métier / use case

Je souhaite savoir si les fonctionnalités standards de suivi des processus peuvent m’aider dans un scénario de ce type.

Contexte rapide : nous avons un objet Tags, avec la possibilité d’avoir un tagsParent (relation parent → enfant), ainsi que des tagsLocale par locale possible (fr-FR, en-GB, …), donc une relation 1-N entre Tags et TagsLocale.

et voici pour le moment le processus que l’on a imaginé :

image
image741×745 37.3 KB

L’objectif serait le suivant :

  1. Un utilisateur A démarre un processus
    → Celui-ci selectionne de la data pour crée un objet métier A. ( dans notre exemple selection d’un tagsParent et la creation d’un tags enfant.)

  2. L’utilisateur A peut continuer pour renseigner les locales ou finir le process mais le processus devra rester ouvert le temps qu’un autre utilisateur B complète certaines données si nécessaire. ( dans notre exemple les traductions locale de tags)

  3. Un utilisateur B reprend et termine le processus, en ajoutant les données complémentaires, jusqu’à la complétion totale du parcours.( toute les locales associé au tags)

Résumé, & Questions que l’on se pose :

Idéalement, nous aimerions utiliser les écrans natifs (dossier processus, dossier activité, tableau de bord) pour :

  • suivre l’avancement des différents processus,
  • identifier les tâches en attente,
  • filtrer par utilisateur / rôle,
  • analyser la charge / temps de traitement,
  • obtenir une vue consolidée de tous les processus actifs.

Les écrans “Dossier processus”, “Dossier activité” et le tableau de bord peuvent-ils servir de base à un tel suivi ? Sont-ils configurables et dans quelle mesure ?

Le tableau de bord présent dans la démo semble prendre en compte certains objets (ex. Demande / Order).

  • Comment fonctionne la sélection des objets utilisés dans ces graphiques ? (est-ce lié à l’activation des tables d’historique ?)

  • Peut-on ajouter ou intégrer nos propres objets métiers dans ces statistiques standard ?

J’émets toutes ces hypothèses en voyant le nom de certains attributs liés à ces objets, mais sans certitude. :sweat_smile:
Nous sommes ouverts à toute proposition ; l’idée n’est pas figée. Si le use case nécessite plusieurs processus métiers, aucun problème.

Technical information

Instance /health 
--- [Platform]
Status=OK
Version=6.2.18
BuiltOn=2025-10-31 21:07
Git=6.2/2cc6bf5900a7ae1bba8c53a06751e86976b99eaf
Encoding=UTF-8
EndpointIP=100.88.218.203
EndpointURL=http://lbc-77449-app-58c587c94c-r2b87:8080
TimeZone=Europe/Paris
SystemDate=2025-12-03 10:28:28

[Application]
ApplicationVersion=1.0.0
ContextPath=
ContextURL=https://ldm-app.ext.gke2.dev.gcp.renault.com
ActiveSessions=1
LastLoginDate=2025-12-03 09:43:53

[Server]
ServerActiveSessions=1
ServerSessionTimeout=30
CronStarted=true

[JavaVM]
HeapFree=194045
HeapSize=378880
HeapMaxSize=3045376
TotalFreeSize=2860541

[Cache]
ObjectCache=541
ObjectCacheMax=10000
ObjectCacheRatio=5
ProcessCache=1
ProcessCacheMax=10000
ProcessCacheRatio=0
APIGrantCache=0
APIGrantCacheMax=1000
APIGrantRatio=0

[Healthcheck]
Date=2025-12-03 10:28:28
ElapsedTime=7 ---
Simplicité logs 
---paste the content of the **relevant** server-side logs---
Browser logs 
---paste content of the **relevant** browser-side logs---
Other relevant information

----E.g. type of deployment, browser vendor and version, etc.----

2

Bonjour,

La fonctionnalité de “processus long” avec persistance des activités est très peu utilisées au regard d’un processus court type “screen-flow” d’aide à la saisie d’une opération complexe manipulant plusieurs objets métier.

En général, on préfère modéliser un “processus long” comme un Objet métier central avec un diagramme d’état / cycle de vie surtout lorsque celui-ci est plutôt linéaire ou conditionnel, c’est à dire sans parallélisation (split/join) d’activités à réaliser entre différents acteurs.

Les états permettent de gérer les habilitations des différents acteurs sur l’objet métier ou ses relations. L’objet métier est bien plus paramétrable pour lui créer des bannettes en page d’accueil, des graphiques… et surtout lorsqu’il possède un historique des états de disposer des métriques qui répondent à votre besoin de métrologie (durée des étapes, temps total…) ou d’en ajouter sur cette table d’historique.

Les métriques des worflows de type processus long standards sont comme vous le dites plus génériques. Dossiers Processus/Activité sont les tables de persistances des instances de processus longs pour assurer le suivi (quel processus, dates, états du processus/lock, payload des données métier…). Il n’y a donc pas de “colonnes dépliées” comme dans un objet métier, ces tables ne sont pas très user-friendly à afficher telles quelles, y compris pour le l’analyse fine des données du processus par sql.

Dans votre cas qui parait simple, il faudrait un sreenflow pour initialiser l’objet principal (choisir un tag pour recopie, association de locals…), mais ensuite c’est l’objet métier qui devra gérer son cycle de vie / mise à jour par différents profils / diagramme d’états… Comme la commande de la Démo qui peut être créée par assistance d’un screen-flow puis mise à jour pour son traitement par différents services back-office.

4

Bonjour François,

Merci beaucoup pour ta réponse détaillée, c’est très clair et cela nous conforte dans la bonne approche.

Si jamais vous avez un exemple complet (même simple) montrant la bonne pratique d’un processus court avec persistance en fin d’exécution, cela serait extrêmement bénéfique pour comprendre dans quels types de use cases vous recommandez l’utilisation de cette feature.

Notre use case (processus métier)

De notre côté, nous avons avancé sur notre processus, et j’aurais quelques questions techniques concernant l’ergonomie des activités :

1. Activité CDTT-select-parent-tags

image
image1624×923 60.3 KB

Dans cette activité, nous affichons une liste de Tags existants :

  • Est-il possible, côté processus (hors CSS custom), de masquer le bouton “Créer” afin d’imposer uniquement la sélection ?
    (Idéalement, la contrainte serait limitée à l’activité ou au processus, sans impacter l’objet en standard.)
  • Est-il possible d’utiliser une vue card dans une étape de processus métier ( activité de type selection simple), ou bien seules les vues listes sont supportées ?
    J’ai testé en mettant l’objet Tags en vue card, mais cela ne semble pas pris en compte dans l’activité.

2. Activité CDTT-create-or-select-locale

image
image1618×470 28.3 KB

image
image1539×442 19.6 KB

Dans cette activité, l’utilisateur sélectionne une locale pour modifier l’enregistrement, mais il peut aussi en créer un :

  • Lorsque l’utilisateur clique sur Créer, pouvons-nous pré-remplir automatiquement le parentId dans le formulaire popup (et éventuellement le masquer) ?
    Nous avons réussi à filtrer les locales selon le parent via les données d’activité, mais nous nous demandions s’il est possible d’avoir cette valeur en valeur par défaut lors de la création de locale dans cette activité.

Certaines de ces interrogations sont réalisables via Hook dans le code java du processus ou du front custom, mais nous souhaitons rester au maximum sur du standard / no-code afin de limiter les développements spécifiques. Si ca n’est pas réalisable que par ses hooks pour certaines demandes, nous les utiliserons alors ).

Encore merci pour tes retours, cela nous aident vraiment à tirer le meilleur des fonctionnalités standard des processus métiers :slight_smile:

5

Bonjour,

Beaucoup de questions pour un seul post :

Cela n’existe pas :

  • Un process court est un screen-flow mono-instancié en mémoire de la session utilisateur
  • Si on en commence un, on doit le terminer pour recommencer le modop/parcours
  • Donc si on en sort avant la fin et qu’on le relance, il se repositionnera sur la dernière activité validée.
  • Tout est perdu au logout (sauf les activités New/Upd/Del qui persistent dans un objet métier)

Et en général, un process court redirige à la fin du parcours vers le formulaire qui supporte l’objet métier principal du process (une commande, une demande…) qui reste la persistance des données métier.

Un worklow utilise des instances dédiées pour ne pas se mélanger avec les autres.
Il n’y a pas de modélisation par type d’instance (main, process, panel, ref…), il faut recourir aux hooks. Pour masquer le bouton “créer” on peut sûrement utiliser le hook isCreateEnable :
if (isProcessInstance()) return false;

Ce n’est pas prévu en effet.

Dans un process, l’activité de sélection est une liste particulière pour ne pas proposer toutes les options d’un liste complexe (group-by, minified, actions, row-template…), mais uniquement le filtrage/tri, la pagination et la sélection multiple. Et la création si on ne trouve pas la référence et qu’on a les droits de création pour ne pas sortir du process.

On pourrait revoir cet usage (qui date de la V3) pour utiliser la liste “usuelle” en désactivant certaines choses comme les actions de liste. on pourrait ainsi via hook faire un setMinified(true) sur l’instance.

Je ne vois pas comment on peut faire cela autrement que pas du code dans un hook.

initCreate de l’instance Process :
if (isProcessInstance()) getField("xxx").set(Default)Value("...");

ou dans un hook preLock de l’activité du processus, récupérer l’instance qui sert à la création et lui forcer la valeur par défaut / masquer le champ.

6

Bonjour,

Merci beaucoup pour ces explications détaillées, elles confirment plusieurs points de compréhension de notre côté.

:check_mark: Pré-remplissage / masquage de champs

De notre côté, nous avons bien réussi le pré-remplissage automatique (Avec l’aide de ce post aussi : Valeur par défaut formulaire de création dans un business process - #3 by Alistair )

  • via un postValidate dans le processus métier,
  • et un initCreate dans l’objet associé lorsque l’instance est utilisée dans le process (isProcessInstance()).

:check_mark: Vue “card / minified”

Merci pour la confirmation : nous comprenons que ce n’est pas prévu aujourd’hui dans les activités de sélection BPM, et que celles-ci utilisent volontairement une liste simplifiée. Si ca vient plus tard tant mieux ! :smiley:

:cross_mark: Masquage du bouton “Créer” dans une activité de sélection

C’est le point qui nous pose toujours difficulté.

Nous avons testé plusieurs approches côté objet métier, en partant du principe que le bouton Créer affiché dans l’activité de sélection du processus était piloté par les hooks et droits de l’objet associé :

  • isCreateEnable() avec if (isProcessInstance()) return false;
  • initList
  • contraintes objet dynamiques

Aucune de ces implémentations n’a d’effet sur l’affichage du bouton “Créer” dans l’activité de sélection du process.

Après analyse plus approfondie, nous nous sommes donc posé la question suivante :
ce bouton “Créer” est-il réellement soumis aux mécanismes standards (hooks et droits) de l’objet métier associé ?

Plusieurs éléments semblent indiquer que non :

  • le bouton “Créer” correspond à une action spécifique de l’UI BPM (wkfsel-create),

    image
    image1293×208 16.9 KB

  • il est rendu par le composant de sélection du workflow,

  • il ne semble pas dépendre de l’action create classique de l’objet ni de ses hooks (isCreateEnable, setListAccessNewForm, etc.).

Un test complémentaire vient appuyer cette hypothèse :
:right_arrow: avec un utilisateur ne disposant pas du droit de création sur l’objet métier principal LbcTags, le bouton “Créer” reste malgré tout visible dans l’UI du processus.
Dans ce cas, l’utilisateur ne peut effectivement pas finaliser la création (contrôle back-end OK), mais le bouton reste affiché côté interface.

image
image1886×296 10 KB

image
image2082×351 15.8 KB

image
image2078×447 21.8 KB

Quelle solution serait adapté pour empêcher l’affichage du bouton “Créer” dans une activité de sélection de processus**, lorsque la création n’est pas souhaitée fonctionnellement ?

Merci d’avance pour votre éclairage.

7

Merci pour ton retour détaillé,

Après vérification dans le processus, le bouton “Créer” est simplement soumis à la règle d’accès au niveau des droits globaux du user : $grant.accessCreate("objectName")

On va voir pour améliorer ce point car on doit avoir en front les meta-data qui sont passées par le isCreateEnable côté serveur.

En attendant, le plus simple est de masquer le bouton par CSS.

#wkf_<ProcessName>.activity-<ActivityName> .btn-wkfsel-create {
  display: none !important;
}
8

Le test de droits pour le bouton “Créer” sera remplacé par le flag obj.metadata.create en 6.2.20 afin de respecter les règles back de la liste (dont isCreateEnable).