Aperçu rapide de Dynamics AX 2012 SysOperation Framework

Publié : 15 février 2025 à 22 h 41 min 23 s 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 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 renseignements contenus dans cet article sont basés sur Dynamics AX 2012 R3. Cela peut être valable ou non 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é à servir de bref aperçu et d’aide-mémoire. Si vous êtes nouveau dans le cadre SysOperation, je vous suggère fortement de lire aussi le livre blanc de Microsoft sur le sujet. Les informations ici peuvent être utiles si vous avez juste besoin d'un rappel rapide des différentes classes impliquées dans le développement d'opérations avec ce framework.

Il existe des variantes, mais lorsque j'utilise le cadre, 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 aussi 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 cadre génère automatiquement.

Contrat de données

Le contrat de données contient les données membres nécessaires à votre opération. Il peut être comparé à la macro CurrentList typique définie dans le cadre 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, 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 cadre 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 d'affaires réelle. Il ne s’agit pas d’afficher des boîtes de dialogue, de traiter par lots ou quoi que ce soit du genre – c’est la responsabilité de la classe du 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 travail par lots, car la super classe fournit certaines 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. Il garantit également que le code est exécuté en CIL pour des performances maximales. La classe du contrôleur hérite généralement de la classe SysOperationServiceController, bien qu'il y ait aussi 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 correspondre au 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 cadre 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 cadre depuis un certain temps.