Miklix

Descripción rápida de Dynamics AX 2012 SysOperation Framework

Publicado: 15 de febrero de 2025, 22:34:47 UTC
Última actualización: 12 de enero de 2026, 8:38:48 UTC

Este artículo proporciona una descripción general rápida (o una hoja de trucos) sobre cómo implementar clases de procesamiento y trabajos por lotes en el marco SysOperation en Dynamics AX 2012 y Dynamics 365 for Operations.


Esta página ha sido traducida automáticamente del inglés para hacerla accesible al mayor número de personas posible. Lamentablemente, la traducción automática no es todavía una tecnología perfeccionada, por lo que pueden producirse errores. Si lo prefiere, puede consultar la versión original en inglés aquí:

Dynamics AX 2012 SysOperation Framework Quick Overview

La información de esta publicación se basa en Dynamics AX 2012 R3. Puede que no sea válida para otras versiones. (Actualización: Confirmo que la información de este artículo también es válida para Dynamics 365 for Operations).


Esta publicación es solo una breve descripción general y una guía práctica. Si no conoce el framework SysOperation, le recomiendo encarecidamente que lea también el informe técnico de Microsoft sobre el tema. Esta información puede ser útil si necesita un repaso rápido de las diferentes clases involucradas en el desarrollo de operaciones con este framework.

Hay variaciones, pero cuando uso el marco normalmente implemento tres clases:

  • Contrato de datos (debe extender SysOperationDataContractBase)
  • Servicio (debe extender SysOperationServiceBase)
  • Controlador (debe extender SysOperationServiceController)

Además, también puedo implementar una clase UIBuilder (debe extender SysOperationUIBuilder), pero eso solo es necesario si el diálogo por alguna razón tiene que ser más avanzado que lo que el marco genera automáticamente.


Contrato de datos

El contrato de datos contiene los miembros de datos necesarios para la operación. Es similar a la macro CurrentList típica definida en el framework RunBase, pero implementada como una clase. El contrato de datos debería extender SysOperationDataContractBase, pero funcionará incluso si no lo hace. La ventaja de extender la superclase es que proporciona información de sesión que puede ser útil.

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

En este ejemplo, itemId es un miembro de datos. Debe implementar un método parm para cada miembro de datos y etiquetarlo con DataMemberAttribute para que el framework lo sepa. Esto permite que el framework cree automáticamente el diálogo.

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

    itemId = _itemId;
    return itemId;
}


Servicio

La clase de servicio contiene la lógica de negocio. No se encarga de mostrar diálogos, procesar por lotes ni nada por el estilo; eso es responsabilidad de la clase del controlador. Al separarla, es más probable que diseñes tu código correctamente y lo vuelvas más reutilizable.

Al igual que la clase de contrato de datos, la clase de servicio no necesita heredar de nada en particular, pero sí de la clase SysOperationServiceBase, al menos si se espera que el servicio se ejecute como un trabajo por lotes, ya que la superclase proporciona información sobre el contexto del lote. El método que inicia la operación (es decir, ejecuta la lógica de negocio) debe tomar un objeto de la clase de contrato de datos como entrada y debe estar decorado con el atributo [SysEntryPointAttribute]. Por ejemplo:

class MyService extends SysOperationServiceBase
{
}

Con un método llamado ejecutar:

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


Controlador

La clase controladora gestiona la ejecución y el procesamiento por lotes de la operación. También garantiza que el código se ejecute en CIL para obtener el máximo rendimiento. La clase controladora suele heredar de la clase SysOperationServiceController, aunque también existen otras opciones.

class MyController extends SysOperationServiceController
{
}

El constructor de la superclase toma como parámetros el nombre de la clase, el nombre del método y (opcionalmente) el modo de ejecución. Los nombres de la clase y del método deben ser el nombre de la clase de servicio y el método que se ejecutará en ella. Por lo tanto, podría implementar el método de construcción de su controlador de la siguiente manera:

public static MyController construct()
{
    ;

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

Entonces el método principal de la clase MyController puede ser tan simple como

public static void main(Args _args)
{
    ;

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

Y ya está prácticamente listo. El ejemplo anterior es, obviamente, muy sencillo, y el framework contiene muchísimas otras opciones y posibilidades, pero sirve como un repaso rápido si necesitas repasar el framework cuando no lo has usado durante un tiempo.

Lectura adicional

Si te ha gustado esta publicación, puede que también te gusten estas sugerencias:


Compartir en BlueskyCompartir en FacebookCompartir en LinkedInCompartir en TumblrCompartir en XCompartir en LinkedInPin en Pinterest

Mikkel Christensen

Sobre el autor

Mikkel Christensen
Mikkel es el creador y propietario de miklix.com. Tiene más de 20 años de experiencia como programador informático profesional y desarrollador de software, y actualmente trabaja a tiempo completo para una gran empresa europea de TI. Cuando no está escribiendo en su blog, dedica su tiempo libre a una gran variedad de intereses, aficiones y actividades, que en cierta medida pueden verse reflejados en la variedad de temas tratados en este sitio web.