Présentation rapide de Dynamics AX 2012 SysOperation Framework

Publié : 15 février 2025 à 22:35:18 UTC

Cet article fournit un aperçu rapide (ou aide-mémoire) sur la façon d'implémenter des classes de traitement et des tâches par lots dans le framework SysOperation dans 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. Elles peuvent ou non être valables pour d'autres versions. (Mise à jour : je peux confirmer que les informations contenues dans cet article sont également valables pour Dynamics 365 for Operations)

Cet article est simplement destiné à vous donner un aperçu rapide et à vous aider à y voir plus clair. Si vous débutez avec le framework SysOperation, je vous suggère fortement de lire également le livre blanc de Microsoft sur le sujet. Les informations présentées ici peuvent être utiles si vous avez simplement besoin d'une mise à jour rapide sur les différentes classes impliquées dans le développement d'opérations avec ce framework.

Il existe des variantes, mais lorsque j'utilise le 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 ( doit étendre SysOperationUIBuilder), mais cela n'est nécessaire que si la boîte de dialogue, pour une raison quelconque, doit être plus avancée que ce que le framework génère automatiquement.

Contrat de données

Le contrat de données contient les membres de données nécessaires à votre opération. Il peut être comparé à la macro CurrentList typique définie dans le framework RunBase, mais implémentée en tant que classe à la place. Le contrat de données doit étendre SysOperationDataContractBase, mais fonctionnera même si ce n'est pas le cas. L'avantage d'étendre la super classe 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. Vous devez implémenter une méthode parm pour chaque membre de données et l'étiqueter avec le DataMemberAttribute afin que le framework sache de quoi il s'agit. Cela permet au framework de créer automatiquement la boîte de dialogue pour vous.

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

    itemId = _itemId;
    return itemId;
}

Service

La classe de service est la classe qui contient la logique métier proprement dite. Elle ne se préoccupe pas d'afficher des boîtes de dialogue, de traiter des lots ou quoi que ce soit de ce genre : c'est la responsabilité de la classe de contrôleur. En séparant cela, vous avez plus de chances de bien concevoir votre code et de créer un code plus réutilisable.

Comme la classe de contrat de données, la classe de service n'a pas besoin d'hériter de quoi que ce soit en particulier, mais elle doit hériter de la classe SysOperationServiceBase, au moins si vous prévoyez que le service sera exécuté en tant que tâche par lots, car la super classe fournit des informations sur le contexte du lot. La méthode qui démarre 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 doit être décorée avec [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. Elle garantit également que le code est exécuté en CIL pour des performances maximales. La classe contrôleur hérite généralement de la classe SysOperationServiceController, bien qu'il existe également d'autres options.

class MyController extends SysOperationServiceController
{
}

Le constructeur de la super classe prend un nom de classe, un nom de méthode et (éventuellement) un mode d'exécution comme paramètres. Les noms de classe et de méthode doivent être le nom de votre classe de service et la méthode qui doit être exécutée dessus. Vous pouvez donc 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 vous avez pratiquement terminé. Ce qui précède est évidemment un exemple très simple et le framework contient une pléthore d'autres options et possibilités, mais cela sert d'aperçu rapide si vous avez besoin d'un rafraîchissement lorsque vous n'avez pas utilisé le framework depuis un certain temps.