Présentation rapide de Dynamics AX 2012 SysOperation Framework

Publié : 15 février 2025 à 22:35:18 UTC
Dernière mise à jour : 12 janvier 2026 à 08:38:49 UTC

Cet article fournit un aperçu rapide (ou aide-mémoire) de la manière d'implémenter des classes de traitement et des tâches par lots dans le framework SysOperation de Dynamics AX 2012 et Dynamics 365 for Operations.

Cette page a été traduite de l'anglais afin de la rendre accessible au plus grand nombre. Malheureusement, la traduction automatique n'est pas encore une technologie parfaite, et des erreurs peuvent donc se produire. 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 cet article sont basées sur Dynamics AX 2012 R3. Leur validité pour d'autres versions n'est pas garantie. (Mise à jour : Je confirme que ces informations sont également valables pour Dynamics 365 for Operations.)

Cet article n'est qu'un aperçu rapide et un aide-mémoire. Si vous débutez avec le framework SysOperation, je vous recommande vivement de lire également le livre blanc de Microsoft sur le sujet. Les informations présentées ici peuvent vous être utiles pour une brève révision des différentes classes impliquées dans le développement d'opérations avec ce framework.

Il existe des variantes, mais lorsque j'utilise ce framework, j'implémente généralement trois classes :

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

De plus, je peux également implémenter une classe UIBuilder (qui doit étendre SysOperationUIBuilder), mais cela n'est nécessaire que si la boîte de dialogue doit, pour une raison ou une autre, être plus avancée que celle générée automatiquement par le framework.

Contrat de données

Le contrat de données contient les membres de données nécessaires à votre opération. Il est comparable à la macro CurrentList classique définie dans le framework RunBase, mais implémenté sous forme de classe. Le contrat de données doit hériter de SysOperationDataContractBase, mais fonctionnera même s'il ne l'hérite pas. L'avantage d'hériter de la superclasse est qu'elle fournit des informations de session qui peuvent s'avérer utiles.

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

Dans cet exemple, itemId est un membre de données. Vous devez implémenter une méthode parm pour chaque membre de données et l'étiqueter avec l'attribut DataMemberAttribute afin que le framework puisse l'identifier. Cela lui permettra de générer automatiquement la boîte de dialogue.

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

    itemId = _itemId;
    return itemId;
}

Service

La classe de service contient la logique métier proprement dite. Elle ne gère ni l'affichage des boîtes de dialogue, ni le traitement par lots ; ces tâches incombent à la classe contrôleur. En séparant ces éléments, vous optimiserez la conception de votre code et favoriserez sa réutilisation.

À l'instar de la classe de contrat de données, la classe de service n'a pas besoin d'hériter d'une classe particulière, mais elle doit hériter de la classe SysOperationServiceBase, au moins si vous prévoyez d'exécuter le service en tant que tâche par lots, car la superclasse fournit des informations sur le contexte de traitement par lots. La méthode qui lance l'opération (c'est-à-dire qui exécute la logique métier) doit prendre un objet de votre classe de contrat de données en entrée et être décorée avec l'attribut [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 de contrôleur gère l'exécution et le traitement par lots de votre opération. Elle garantit également que le code est exécuté en CIL pour des performances optimales. La classe de contrôleur hérite généralement de la classe SysOperationServiceController, mais d'autres options existent.

class MyController extends SysOperationServiceController
{
}

Le constructeur de la superclasse prend comme paramètres un nom de classe, un nom de méthode et (facultativement) un mode d'exécution. Le nom de la classe et le nom de la méthode doivent correspondre respectivement au nom de votre classe de service et à la méthode à exécuter. Vous pourriez donc implémenter la méthode `construct` de votre contrôleur comme ceci :

public static MyController construct()
{
    ;

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

La méthode principale de la classe MyController peut alors être aussi simple que :

public static void main(Args _args)
{
    ;

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

Et voilà, c'est presque terminé. L'exemple ci-dessus est évidemment très simple et le framework offre une multitude d'autres options et possibilités, mais il constitue un aperçu rapide si vous avez besoin de vous rafraîchir la mémoire après une longue période d'inutilisation.

Lectures complémentaires

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