Les agents responsables sont déterminés au niveau de l’étape ou par une règle par défaut au niveau de la tâche.

Les choix possibles sont au niveau de l’étape sont :

Choisir un utilisateur est évidement uniquement valide pour des tests.

Il ne faut pas utiliser cette option autrement car si un utlisateur change de poste alors il faut changer l’étape du workflow ce qui ne pas être facile … la maitenance va très rapidement poser problème.

Prendre une variable comme %I l’initiateur du workflow ou %V le supérieur hiérarchique de l’initiateur workflow, semble à priori être une bonne idée. Ce sont des méthodes qui vont permettre un calcul dynamique. Donc bien mieux que de prendre un utilisateur.

Cette méthode fonctionnera dans pratiquement tous les cas, sauf, quand le workflow devra pour des raisons de maintenance ou d’erreur être relancé par l’administrateur workflow.

Car à ce moment, c’est lui qui devient l’initiateur du workflow, et par conséquent si l’on prend le responsable hiérarchique par rapport à cette variable cela ne fonctionnera pas non plus.

Je préfère dans ce cas prendre le créateur de l’objet (BOR ou CLASS) et faire un calcul dynamique en utilisant une expression, et ensuite de calculer le manager avec une règle par rapport à cet utilisateur.

Que ce soit un poste de travail (A), une fonction(C) , une unité organisationnelle (O) ou un poste (S) il s’agit d’un objet organisationnel. La structure doit donc être maintenue [PPOM].

Comme pour les rôles, je trouve cela peu adapté dès que l’on doit déterminé les agents responsable par rapport à une variable, la encore je préfère l’utilisation de règle.

Les expressions utilisent des containers (variable) du workflow, elles doivent être compatibles, c’est à dire du type SWHACTOR (ou compatible) et peuvent être multi-ligne.

Cela peut être pratique, surtout si l’on se sert d’attribut de l’objet du workflow (BOR/Class), mais un calcul des agents préalable à l’étape de dialogue que l’on stocke dans un container et utilise plus tard, peu poser des soucis à la maintenance si faut relancer un calcul des agents car les données n’avaient pas été maintenues.

Exemple, un centre de couts contient un champs qui définit l’utilisateur qui est responsable, si ce champ n’a pas été maintenu et que le workflow stocke le responsable dans un container du workflow, la donnée devient alors statique. Alors que si ce responsable était determiné par une règle au niveau de la tâche de dialogue alors il suffirait de relancer le calcul des agents (par exemple avec SWI1_RULE) .

Comme annoncé, il s’agit de ma méthode préférée….

Je ne vais pas rentrer dans un trop grand détail ici et j’espère faire un autre article plus tard.

Il existe plusieurs type de règle :

Ce type permet de prendre tout objet qui a un infotype B22 appartient à..

Je ne l’utilise pratiquement jamais, car j'ai remarqué qu'il était difficile à maintenir pour les utilisateurs

C’est un type très utilisé, il permet avec de trouver avec une interface standard et du code ABAP les agents que nous cherchons

L’interface dont je parle est très simple

* »———————————————————————-

* »* »Local Interface:

* » TABLES

* » ACTOR_TAB STRUCTURE SWHACTOR

* » AC_CONTAINER STRUCTURE SWCONT

* » EXCEPTIONS

* » NOBODY_FOUND

* »———————————————————————

Avec le BRF+ et ses tables de décision les fonctions deviennent très puissantes.

Avec ce type de donnée, dans la transaction PFOM un objet organisationnel est lié à un objet organisationnel (PPOM)

Ex: l’objet T024 qui représente un groupe d’acheteurs

Cela peut être très pratique, mais il faut s’assurer que tout le monde sache comment cela fonctionne. Souvent je suis intervenu chez des clients qui ne savaient plus comment les agents étaient calculés ou comment maintenir les nouvelles entrées, et pratiquement à chaque fois cette méthode avaient été retenue.

Personnellement je suis un fan, j’ai commencé assez vite avec cette méthode qui ne demande aucun code et permet une maintenance simple.

Il suffit de configurer le container, puis d’assigner les responsabilités en s’appuyant sur les objets organisationnels.

Il ne faut pas oublier que la maintenance des responsabilités se fait dans les systèmes de développement par la transaction OOCU_RESP.