Classe et Workflow

Introduction

Dans SAP, les workflows ont depuis longtemps maintenant deux technologies pour représenter les objets workflow :

• les Business Objects (BOR)

• les Classes ABAP OO

Les Business Objets sont aussi connus sous le terme BOR ou BUS, ils sont créés et étendus dans la transaction SWO1.

Les Classes Workflows sont moins connues moins utilisés mais on clairement un net avantage.

Un ABAPEUR se retrouve beaucoup plus à l'aise avec une classe ABAP qu'avec nos bons vieux BOR.

Les BOR étaient là avant même que l'ABAP Objet existent, mais leur langage est basé sur des macro, qui je trouve se comprennent bien mais ne sont pas trop à la mode et pas vraiment réutilisable dans vos programme.

L'avantage des classes workflow, est donc le nombre de développeur qui seront à l'aise avec et qu'elles peuvent se poser au dessus (sous classe) des classes de l'application, ou avoir un BOR ou la classe d'application (ou business) en attribut pour bénéficier de tout le développement déjà fait.

Ce qui distingue les classes workflows des autres

C'est plutôt simple, elles implémentent l'interface IF_WORFLOW

6 méthodes arrivent alors et je vais essayé d'expliquer comment les implémenter.

Une autre particularité, quand vous déclarez l'interface, les attributs ont alors une colonne supplémentaire afin de déclarer la clée

La méthode Refresh

Find By LPOR

Alors cette méthode fait office de factory, afin de s'assurer que la classe garde la même référence tout au long du workflow (singleton principle). Car si la référence changeait alors le worflow ne pourrait plus réagir aux évènements, ni aux conditions.

Comment fait elle cela, et bien un attribut statique (une table interne) est crée elle contient la clée de l'objet et la référence de l'instance.

L'implémentation de cette méthode est obligatoire.

Mais quel ce type TT_INSTANCE ?

Il faut qu'il soit déclaré pour être disponible pour la classe

C'est pour cela que le constructeur est privé, il faut passer par cette méthode pour obtenir une instances, celle-ci sera présente dans la table tant que le workflow en aura besoin.

Mais comment SAP la retire l'entrée de la table ? L'implémentation de cette méthode est obligatoire;

Et bien ce n'est pas SAP, SAP appelle une autre des méthodes quand le workflow n'a plus besoin de la l'objet, la méthode RELEASE

Elle fait le ménage, supprime les attributs, libère les objets liés...

Cette méthode est optionnelle mais je vous conseille de l'implémentée surtout si vous utilisez la table mst_instances

LPOR

DEFAULT_ATTRIBUTE_VALUE

EXECUTE_DEFAULT_METHOD

L'implémentation de cette méthode n'est pas obligatoire.

Mais je la conseille car si vous cliquez sur votre work item c'est cette méthode qui est appelée.

Il suffit pour l'implémenter de mettre dedans me->display( ).

(si votre méthode par défaut est display( )

A quoi ressemble mon constructor ?

Get_Instance

Quels sont les inconvénients des classes dans le workflow ?

Principalement il s'agit des évènements, ils réagissent différemment entre les classes et les workfows.

Ce n'est pas le meilleurs de points mais il peut être facilement contourner.

J'en parlerai peut être une autre fois.