Mettre des actions sur les PSD
Il est possible d’ajouter des boutons actions sur les PSD, permettant de lancer différents outils (autre PSD, LPA, TDY, Documents, couplage…).
Ici, on a par exemple 3 boutons d'action différents !
Ces actions se paramètrent et se gèrent différemment entre les PSD simple et les PSD FMO.
Pour une PSD Fiche…
Etape 1: Définir les actions sur le questionnaire
On commence par définir les actions qu’on souhaite lancer depuis la PSD 🙂
Pour les PSD simples, les actions se définissent sur la fiche du questionnaire, dans l’onglet “Actions”, en cliquant sur le bouton:
On peut également définir ici une requête RCT sui sera exécuté lors du lancement et du retour de l’action ! Voir chapitre “Requête RCT” ci-dessous.
On arrive sur une application dans laquelle on va définit chaque action:
Pour chaque action il faut définir :
Un code action
Un type d’objet et une référence objet
Un code action retour
Le mode retour
Numéro d’ordre: Le numéro d’ordre va permettre d’ordonner les actions dans le menu contextuel de l’objet paramétrable, ainsi que dans la barre de commandes. Il doit être unique.
Code action: Ce code est libre et permet de référencer l’action. Il sera ensuite utilisé pour lier l’action à un bouton, et également à réaliser du paramétrage dans les requêtes de la PSD C’est le code identifiant l’action dans le cas où des données supplémentaires sont paramétrées dans la règle de gestion des actions. Ce code action sera représenté par la SCR.RCT_TypeAction.
Typ. Obj. App.: Permet de définir quel objet sera lancé via cette action. Cela implique d’avoir créé l’objet en question avant la définition de l’action. Les types d’objets possibles sont:
ACT = Action RCT. Ce type d’action exécute uniquement la règle RCT rattachée au questionnaire, ce qui nous permet de faire un peu ce que l’on veut 😎 (y compris lancer des objets). Dans ce cas là il faut également saisir une désignation et un libellé court pour l’action.
ADG = Arborescence de documents GED
ADM = Action direct métier
AGE = Agenda
AME = Action métier
ARB = Arbre
COU = Couplage
CSY = Commande système
DOC = Documents
GTT = GANTT
LPA = Liste paramétrée
MCO = Message de confirmation
PER = PERT
PSD = une autre PSD (de type IAP)
TDY = Tableur dynamique
Cette valeur sera reportée dans la variable VBP.IAP_TypFils en entrée de la règle RCT.
Ref. Obj. App.: Référence de l’application lancée. OBLIGATOIRE. Non saisissable pour les types ACT et MCO. Cette valeur sera reportée dans la variable VBP.IAP_RefFils en entrée de la règle RCT.
Message: Texte du message pour les actions de type MCO. Uniquement saisissable pour le type MCO.
Désignation: La désignation de l’action, correspondant au texte dans le menu contextuel.
Libellé Court: Libellé de l’action dans la barre de commandes.
Icône: Icône de l’application lancée par l’action.
Raccourci: Raccourci clavier pour l’action.
Ouv. Nouv. Pan.: Ouverture dans un nouveau panneau. Toujours égal à vrai sauf pour les actions d’un couplage, si cette action lance une application pouvant être représentée comme enfant de couplage.
Code act retour: Code action exécutée dans la règle de gestion des actions lors de la fermeture de l’application lancée par l’action.
Mode retour : Mode de passage de critère entre l’application lancée par l’action, et l’application paramétrée lanceuse de l’action.
S = Sans variable ==> Aucune variable ne transite en retour sur la PSD
U = Variable utile ==> Seules les variables utiles transitent en retour sur le père. Ces “variables utiles” sont choisies à l’aide du bouton en dessous.
V = Toutes les variables ==> Toutes les variables transitent en retour sur l’application père
Astuce: Pour ne pas être embêté, il est préférable de mettre systématiquement ce mode retour à V pour récupérer un maximum d’informations dans les requêtes et pouvoir facilement réaliser le paramétrage.
Var. utiles : Variables utiles transmises par l’application lancée par l’action à sa fermeture. Accès à un drag&drop sur les variables VCR.
Mode Réa. : Mode de réaffichage de l’application après fermeture de l’application lancée par l’action.
0 : Ne rien faire
ACT : Actualiser
RAF : Rafraîchissement
( La description des champs ci-dessus est décrite dans le fiche Remplir l'application de définition des actions ).
Etape 2 (si besoin ! 😉 ): Gérer les actions par requête
Créer la requête RCT de gestion des actions
Si dans l'étape précédente vous souhaitez gérer une action par requête, ou simplement initialiser des infos pour votre action, il faut passer par la requête RCT suivante ! 😉
Cette requête sera exécutée au lancement et au retour de l’action. Elle va nous permettre de choisir et d’initialiser toutes les informations nécessaires au bon fonctionnement de l’objet fils !
➡️ Comment initialiser des informations dans cette requête pour le bon fonctionnement d’une action ?
Dans l'étape précédente nous avons défini l’action “SELCLI”, qui correspond à une PSD. Cette action permet de lancer un outil qui nécessite des données en entrée pour fonctionner ! Il faudra dans cette requête initialiser les variables critères nécessaires au fonctionnement de cet l’outil. Il est possible donc possible d’initialiser des SCR/VCR et VBP à partir des VSD présentes sur votre PSD:
Comment lancer une action directement dans cette requête, via “le moteur RCT” ( quand, dans l'étape précédente, on a mis que notre action était lancée via RCT ) ?
Quand l’utilisateur clique sur l’action…on a le contexte suivant :
la SCR.RCT_TypeAcces = ACT (Mode d’exécution de la règle : ‘ACT’ si elle est appelée par une action directe de l’utilisateur, ‘IAP’ si c’est le retour d’une application liée lors d’une fermeture)
La SCR.RCT_TypeAction = Code action lancé
Et dans notre requête on va initialiser:
La VBP.IAP_TypeFils = Type de l’objet lancé
La VBP.IAP_RefFils = Référence de l’objet lancé
La VBP.IAP_ModeRet = mode de retour défini sur l’action (S/U ou V)
On peut également initialiser…
VBP.IAP_FenSep =Ouverture en fenêtre séparée
VBP.IAP_ValActFils = Code action retour
VBP.IAP_LisVarUti =Liste des variables utiles (séparées par une virgule), pour le mode U
VBP.IAP_ModeRea = Mode de réaffichage à la fermeture de l’objet applicatif lancé
Lancement de l’action
On peut écrire le requête suivante:
1-On commence par récupérer l’accès ( est-ce qu’on lance l’action ou est-ce qu’on revient de l’action ? ), et le référence de l’action dans les SCR.RCT_TypeAcces (=ACT au lancement ou =IAP en mode retour) et SCR.RCT_TypeAction pour savoir ce que fait l’utilisateur !
2-On initialise les VBP IAP_ModeAcc et IAP_ModeDem à la valeur “C” (qui veut dire “Complet”). Cela permet de faire transiter un maximum d’informations vers l’objet fils, de la même manière que la VBP.IAP_ModeRet pilote la transition des informations en retour de l’objet fils sur l’objet père. Vous pouvez également initialiser la VBP.IAP_ModeRet à “C” pour encore améliorer la transition d’informations. Ce n’est pas obligatoire mais fortement conseillé 😉
On lance l’action qui a pour code action “SELPOS”, et qui permet de lancer une PSD dans notre exemple. On vient donc initialiser les VBP IAP_TypeFils et IAP_RefFils afin de piloter dynamiquement l’objet à lancer.
VBP.IAP_TypeFils : Type d’objet à lancer. ADG (Arbre documents GED), AGE (Agenda), AME (Application Métier), ARB (Arbre), COU (Couplage), CSY (Commande Système), DOC (Document), ENT (Entité), LPA (Liste Paramétrée), MCO (Message de Confirmation), PER (Diagramme PERT), PSD (Procédure de Saisie Dynamique), TDY (Tableur Dynamique).
VBP.IAP_RefFils : référence Objet. Doit exister pour le type donné.
VBP.IAP_EvtActFils : action DIALOG en retour de l’objet lancé. CTL (mode RCT = contrôle), vide (pas de DIALOG).
Dans le cas d’une action de type ACT, il est possible de juste faire des MAJ via cette requête sans lancer d’outil, dans ce cas là les VBP IAP_TypeFils et IAP_RefFils restent à vide.
Il est aussi possible de mettre des messages d’erreur afin de bloquer le lancement d’une action en fonction des conditions que vous souhaitez.
Remarque: Comme vous pouvez le constater, ce sont des VBP qui donnent l’objet à lancer. Ce type de variable (VBP = Variables Partagées entre Requêtes) permet de faire transiter des informations d’un objet à un autre, elles vont donc être très importantes dans le cas du lancement d’actions, notamment pour le retour !
Retour de l’action
Comment mettre en place le retour d’action ?
Au retour de l’action on a le contexte suivant :
La SCR.RCT_TypeAcces = IAP
La SCR.RCT_TypeAction = Code de retour de l’action (défini sur l'action)
La SCR.IAP_TypeFils = Type de l’objet fils dont on revient
La SCR.IAP_RefFils = Référence de l’objet fils dont on revient
La SCR.IAP_ParActFIls = VAL ou ABA suivant comment on a quitté l’objet fils
La SCR.IAP_ValActFils = Code de retour de l’action (défini sur l'action)
Les VBP qui auront été initialisées dans l’outil fils
On peut écrire le requête suivante:
Ici, on vient remettre à vide les VBP IAP_TypeFils et IAP_RefFils qu’on a utilisées dans une des actions plus haut, pour ne pas relancer l’outil pour lequel on a initialisé ces VPB !
Dans notre action, on demande des informations à l’utilisateur qu’on souhaite récupérer dans notre outil père, comment faire ?
Par exemple, dans notre action, on lance une autre PSD dans laquelle l’utilisateur doit choisir un client, et on souhaite récupérer dans notre PSD père la référence de ce client pour initialiser des champs.
Afin de faire transiter des informations à l’objet père, il faudra obligatoirement initialiser des variables VBP en validation de l’objet fils. Les SCR et VCR ne transiteront pas !
En cas de sélection multiple, la RCT est exécutée une seule fois, et non une fois pour chaque enregistrement sélectionné.
Enchainer sur un autre outil en retour d’action
A noter que lors du retour du lancement d’un outil, il est possible de lancer un nouvel outil ! Cette mécanique peut être répétée autant de fois que nécessaire !
Il n’est pas possible d’initialiser de VSD depuis cette requête RCT 😕 . C’est la requête de PSD de retour d’action ci-dessous qui va nous permettre de le faire 😀.
Créer la requête PSD de retour d’action
Sur la fiche de définition de la PSD, on peut ajouter une requête de retour d’action:
Cette requête s’exécute lors du retour d’une action sur la PSD père, juste après la requête RCT du questionnaire.
C’est dans cette requête que l’on va pouvoir récupérer les VBP initialisées dans l’objet fils et saisir dynamiquement les VSD de notre questionnaire.
Le contexte de la requête de retour d’action:
SCR.CdeSCCEvt = RAC
La SCR.IAP_ParActFIls = VAL ou ABA suivant comment on a quitté l’objet fils
La SCR.IAP_ValActFils = Code de retour de l’action (défini sur l'action)
puis:
On paramétrera donc la requête sous cette forme:
Etape 3: Création des boutons et liaisons avec les actions
Une fois nos actions créées, il faut les intégrer à notre formulaire afin de pouvoir les lancer en cliquant sur un bouton.
Pour cela nous avons deux solutions:
Soit on ajoute l’action par un bouton sur le formulaire: c’est le plus utilisé 😉
Soit on ajoute l’action sur la zone d’un champs: le bouton est peu visible.. on privilégie donc plutôt la première solution !
On ajoute l’action sur le formulaire
Il est possible d’ajouter un bouton sur le formulaire du questionnaire:
Une fois le bouton paramétré, notre action est fonctionnelle:
On ajoute l’action sur une zone
Il est également possible de définir une action sur un champ en particulier, via un onglet dédié:
Il est également possible de rattacher une icone sur le bouton, mais ça rend pas très bien car le bouton est petit 🔎 (ou sinon il faut que le champ soit très grand sur le formulaire).
Pour une PSD FMO
Pour une PSD FMO la définition des actions se fait sur la fiche de l’ergonomie FMO:
La définition des actions est presque totalement identique à la définition depuis les PSD simples ! Vous pouvez donc vous référer à la partie sur les PSD Fiches, en prenant en compte les quelques différences ci-dessous:
Formulaire des actions: Sur le formulaire de l’action des PSD FMO, on peut remplir le champs “Mode Réa”, qui permet d'actualiser la PSD en retour d’action.
Requêtes: on a vu que sur la PSD Fiche, il fallait utiliser une requête RCT et une requête PSD quand on souhaitait gérer une action par requête. Pour les FMO, c’est plus simple !!!
En effet Ii est possible de renseigner à la place d’une requête RCT le code “*PSD” sur la fiche de l’ergonomie:
Cela permet d’utiliser directement la requête de contrôle local de la PSD pour gérer les actions, sans avoir à écrire la requête RCT. On peut donc initialiser initialiser les VSD directement au retour de l’action (Code IAP) au lieu d’utiliser la règle de retour d’action. Cela permet aussi d’avoir une requête unique pour gérer l’ensemble du fonctionnement de la PSD, actions comprises, et de limiter le nombre de requêtes différentes.