Aperçu rapide de Dynamics AX 2012 SysOperation Framework

Publié : 15 février 2025 à 22 h 41 min 23 s UTC
Dernière mise à jour : 12 janvier 2026 à 08 h 40 min 40 s UTC

Cet article offre un aperçu rapide (ou une fiche de triche) sur la façon d’implémenter des classes de traitement et des tâches batch dans le cadre SysOperation dans Dynamics AX 2012 et Dynamics 365 for Operations.

Cette page a été automatiquement traduite de l'anglais afin de la rendre accessible au plus grand nombre. Malheureusement, la traduction automatique n'est pas encore une technologie au point, des erreurs peuvent donc survenir. Si vous préférez, vous pouvez consulter la version originale en anglais ici :

Dynamics AX 2012 SysOperation Framework Quick Overview

Les informations contenues dans ce billet sont basées sur le Dynamics AX 2012 R3. Cela peut être valide ou non pour d’autres versions. (Mise à jour : Je peux confirmer que les informations de cet article sont également valides pour Dynamics 365 for Operations)

Ce billet est simplement un aperçu rapide et une fiche de triche. Si vous êtes nouveau dans le cadre SysOperation, je vous recommande fortement de lire aussi le livre blanc de Microsoft sur le sujet. Les informations ici peuvent vous être utiles si vous avez simplement besoin d’un rapide aperçu des différentes classes impliquées dans le développement d’opérations avec ce cadre.

Il y a des variantes, mais quand j’utilise le framework, j’implémente généralement trois classes :

Contrat de données (devrait prolonger SysOperationDataContractBase)
Service (devrait étendre SysOperationServiceBase)
Contrôleur (doit étendre SysOperationServiceController)

De plus, je peux aussi implémenter une classe UIBuilder (je dois étendre SysOperationUIBuilder), mais ce n’est nécessaire que si le dialogue doit être plus avancé que ce que le framework génère automatiquement.

Contrat de données

Le contrat de données détient les membres de données nécessaires à votre opération. Elle peut être comparée à la macro typique CurrentList définie dans le cadre RunBase, mais implémentée sous forme de classe. Le contrat de données devrait prolonger SysOperationDataContractBase, mais fonctionnera même si ce n’est pas le cas. L’avantage d’étendre la super classe, c’est qu’elle fournit des informations de session qui peuvent être utiles.

[DataContractAttribute]
class MyDataContract extends SysOperationDataContractBase
{
    ItemId itemId;
}

Dans cet exemple, l’itemId est un membre de données. Tu dois implémenter une méthode parm pour chaque membre de données et la taguer avec le DataMemberAttribute pour que le framework sache ce que c’est. Cela permet au framework de construire automatiquement le dialogue pour vous.

[DataMemberAttribute]
public ItemId parmItemId(ItemId _itemId = itemId)
{
    ;

    itemId = _itemId;
    return itemId;
}

Service

La classe service est celle qui contient la logique métier réelle. Il ne s’agit pas d’afficher des dialogues, du traitement par lots ou quoi que ce soit de ce genre – c’est la responsabilité de la classe contrôleur. En séparant cela, vous avez plus de chances de bien concevoir votre code et de créer plus de code réutilisable.

Comme la classe de contrat de données, la classe de service n’a pas besoin d’hériter de quelque chose en particulier, mais elle devrait hériter de la classe SysOperationServiceBase, du moins si vous vous attendez à ce que le service soit exécuté comme un travail batch, puisque la superclasse fournit certaines informations sur le contexte batch. La méthode qui lance l’opération (c’est-à-dire exécute la logique métier) doit prendre un objet de votre classe de contrat de données en entrée et doit être décorée de l'[SysEntryPointAttribute]. Par exemple:

class MyService extends SysOperationServiceBase
{
}

Avec une méthode appelée run :

[SysEntryPointAttribute]
public void run(MyDataContract _dataContract)
{
    // run business logic here
}

Contrôleur

La classe contrôleur gère l’exécution et le traitement par lots de votre opération. Il s’assure aussi que le code est exécuté en CIL pour une performance maximale. La classe controller hérite généralement de la classe SysOperationServiceController, bien qu’il existe d’autres options également.

class MyController extends SysOperationServiceController
{
}

Le constructeur de la superclasse prend un nom de classe, un nom de méthode et (optionnellement) un mode d’exécution comme paramètres. Les noms de la classe et des méthodes devraient être le nom de votre classe de service et la méthode qui doit être exécutée dessus. Donc, vous pourriez implémenter la méthode de construction de votre contrôleur comme ceci :

public static MyController construct()
{
    ;

    return new MyController(classStr(MyService),
    methodStr(MyService, run));
}

Ensuite, la méthode principale de la classe MyController peut être aussi simple que

public static void main(Args _args)
{
    ;

    MyController::construct().startOperation();
}

Et c’est pratiquement fini. Ce qui précède est évidemment un exemple très simple et le cadre contient une multitude d’autres options et possibilités, mais cela sert de rapide aperçu si vous avez besoin d’un revoir si vous n’avez pas utilisé le cadre depuis un moment.

Lectures complémentaires

Si vous avez apprécié cet article, vous aimerez peut-être aussi ces suggestions :