SAP et ses Daemons

Un besoin fréquent chez nos clients est de pouvoir déclencher des traitements à la création ou la modification de données de base ou de données transactionnelles.

Une solution classique est d’activer les ‘change pointers’ et ensuite, soit de les consommer de façon standard via les IDOCs, soit via des programmes spécifiques. Ces derniers doivent alors être planifiés à une fréquence plus ou moins élevée avec pour conséquence de consommer des processus de background et d’être asynchrone.

ABAP Daemon Framework

Parmi les nouveautés dans la version SAP Netweaver 7.52, on trouve l’ABAP Daemon Framework ou ADF. L’ADF est une API qui permet de créer et gérer des daemons en ABAP.

Un daemon ABAP est une classe qui va pouvoir s’exécuter dans une session ‘ABAP Daemon’ spéciale sur l’application server. L’accès aux daemons d’un application server se fait via l’ABAP Daemon manager.

Le daemon ABAP fonctionne sur évènement et de ce fait doit toujours pouvoir répondre et donc s’exécuter en ‘non-blocking mode’. Cela aura un impact dans les traitements que vous souhaitez faire exécuter au daemon, oubliez CALL TRANSACTION et autres SUBMIT. 

Comment ça fonctionne ?

La création d’un daemon consiste en la création d’une classe qui va hériter de la classe abstraite CL_ABAP_DAEMON_EXT_BASE.

De cette super classe, notre daemon va hériter différentes méthodes de l’interface IF_ABAP_DAEMON_EXTENSION qui vont permettre de répondre aux différents évènements.

Nous ne rentrerons pas dans le détail des évènements ici, ceux-ci sont clairement expliqués dans la documentation standard sur les daemons ABAP.

Pour cet exemple simple, nous allons uniquement implémenter les méthodes ON_ACCEPT et ON_MESSAGE.

La première va nous permettre d’autoriser la création du daemon sur le système et la seconde de traiter les messages que l’on enverra au daemon.

 

C’est une implémentation simplifiée de singleton pour éviter de lancer plusieurs fois le même daemon.

Avant de mettre en place le traitement des messages envoyés au daemon, nous devons prendre en compte le fait que seul le programme qui lance le daemon peut ensuite utiliser ce daemon via le daemon manager. L’idée est donc de faire créer le daemon via la classe du daemon elle-même.

Nous allons donc créer 3 méthodes dans la classe : START, SEND et STOP pour pouvoir gérer le daemon.
 

Nous pouvons maintenant lancer notre daemon via un second programme en exécutant :

zmydaemon=>start( iv_daemon_name = 'my_first_daemon' ).

Le suivi des daemons se fait via la transaction SMDAEMON.
 

Notre daemon tourne sur l’application server et attend de recevoir des évènements.

Pour tester ce daemon, nous avons implémenté une BADI à la sauvegarde de la création d’équipement PM pour notifier un utilisateur de cette création.

Nous avons créé une fonction spécifique qui se charge de l’envoi d’un mail comportant le numéro d’équipement créé.

Ensuite, nous implémentons la méthode ON_MESSAGE pour réceptionner le numéro d’équipement et le passer à la fonction d’envoi de mail.

 

Une mise à jour de la BADI est nécessaire pour appeler la méthode SEND définie précédemment :
 

DATA: lv_text TYPE string.

lv_text = i_data_equi-itob-equnr .

zmydaemon=>send( iv_daemon_name = 'my_first_daemon' iv_text = lv_text ).

A la création de l’équipement, le mail est généré et envoyé à l’utilisateur.
 

Pour aller plus loin

Ces daemons ABAP offrent de nouvelles possibilités au backend SAP S4/HANA.

On parle beaucoup d’entreprise 4.0 et d’entreprise intelligente, cette nouvelle brique technique proposée par SAP, combinée aux ABAP Push Channel, permet toute sorte de communication Machine-to-Machine :

• remontée de capteurs directement dans l’ERP

• connexion à des brokers MTTQ

• connexion à des web sockets

Elle permet aussi comme nous l’avons vu la mise en place de traitements temps réel dans l’ERP.