miércoles, octubre 09, 2013

Axapta: Macros en sentencias SQL

Macros en sentencias SQL
Uno de los beneficios de utilizar macros es que permiten especificar sentencias parciales de consultas en código X++, las cuales pueden ser reutilizadas en varias partes a lo largo de cualquier aplicación.

Beneficios:

·         Reutilización de código,

·         Mejora la lectura del código fuente,

·         Mayor flexibilidad a modificaciones,

·         Reducir el tiempo de desarrollo.

 Ejemplo de uso:

Clase con dos métodos que realizan consultas a la base de datos.

Método: custPaymentProcess
 
 
Método: advancesProcess
 
Luego del análisis realizado a estos dos métodos se puede observar que las consultas pueden ser utilizadas dentro de macros, de esta forma, se puede mejorar la visibilidad del código fuente y hacer uso de la reutilización del código.
Para lo cual creamos dos macros:
Todo se simplifica utilizando macros
·         Macro FieldsCustPaymentHeader
 
A continuación la explicación al código.
o   El %1, %2, %n permite pasar argumentos a nuestra macro, esto permite definir desde donde se llama la macro las variables que queremos utilizar dentro de esta.
o   #ifNot.Empty(%n) permite definir un rango condicionante de acuerdo al argumento que se esté enviando a la macro. En este ejemplo comprobamos si el parámetro enviado en la tercera posición no está vacío ejecuta todo el bloque #ifNot.Empty(%3) …#EndIf
o   #EndIf identifica que es el final de la macro condicionante.
o   #if.Empty(%n) permite comprobar si el parámetro enviado en la posición %n es vacía, entonces se ejecuta todo lo que se encuentra en el bloque #If .Empty…#EndIf


·         Macro FieldsCustPaymentLine

 
La explicación expuesta en la primera macro aplica en esta.


Utilización de la macro en consultas SQL en X++

Modificamos nuestro código original para remplazar con las macros creadas anteriormente.


En el segundo método tenemos:



De esta forma la utilización de macros en las sentencias SQL nos permite una gran flexibilidad a la hora de desarrollar aplicaciones en Axapta.

 

jueves, mayo 23, 2013

Dynamics AX Performance Optimization Guide

Hola, he obtenido mi copia impresa del Libro Dynamics AX Performance. Revisaré y compartiré mis comentarios sobre este nuevo libro que no debería faltar en la biblioteca de cualquier desarrollador Dynamics AX.

martes, enero 08, 2013

AX 2012: MAPAS DESDE AOT

 
Mapas

Los mapas son objetos que asocian un campo del mapa con un campo en una o más tablas. Esto permite utilizar el mismo nombre del campo para acceder a campos con diferente nombre en diferentes tablas. Los métodos del mapa le permiten crear o modificar métodos que actúan en los campos del mapa.

Una tabla puede ser accedida a través de más de un mapa. Típicamente, si más de un mapa accede a la misma tabla, cada mapa accede a diferentes subconjuntos de campos en el mapa. Los mapas no definen objetos de base de datos y así los mapas no se sincronizan con la base de datos.   

Beneficios

Simplicidad. Los mapas proporcionan una interfaz simple a los campos en múltiples tablas. Esto quiere decir que cualquier objeto que hace referencia al campo del mapa puede ser utilizado contra múltiples tablas sin cambiar ningún nombre del campo.
Consistencia.- los campos de las tablas con nombres variados pueden ser accedidos en código de una manera consistente. Por ejemplo utilizando un mapa, los campos nombrados Zip en una tabla, ZipCode en otra, y PostalCode en otra tabla pueden todos ser accedidos por el nombre ZipCode.  

Reutilización de código. Un método del mapa permite añadir código que se ejecute contra los campos del mapa. Un método sencillo del mapa previene la duplicidad de métodos y código en cada tabla.

Elementos del Mapa

Fields. El nodo Fields contiene los elementos del campo del mapa. Cada campo debe ser del mismo tipo de dato a la cual es asociado.
Field Group. Contiene grupo de campos asociados lógicamente. Trabajan de la misma forma que en las tablas.

Mappings. Es el lugar donde los campos del mapa son asociados con los campos de las tablas. Aquí están las tablas que el mapa combina. Sobre cada tabla puede ver cual campo de la tabla está asociado con un campo del mapa. Si un campo existente en el mapa no está asociado a un campo particular de la tabla, solo dejar la propiedad MapFieldTo en blanco.

Methods. Despliega todos los métodos disponibles para el mapa. En este nodo puede añadir nuevos métodos o sobrescribir métodos de la clase kernel xRecord y añadir su propio código.
 
EJERCICIO
·         Crear un Mapa utilizando el AOT
 
1.      Crear dos tablas con la siguiente estructura de datos:
 

 
2.      En el AOT expandir el Data Dictionary, click derecho en Maps y luego en Nuevo Mapa. Establecer el nombre del mapa CustVendMyMap
 

3.      Expandir el nuevo mapa, click derecho en Fields, click en Nuevo, luego seleccionar el tipo de dato para añadir un campo al mapa.
 También puede utilizar la funcionalidad de “Arrastrar y Soltar” para añadir los campos del mapa.
 

 
4.      Repetir el paso 2 para añadir más campos al mapa.
5.      Si el campo del mapa está asociado con un campo de la tabla que es un tipo de dato extendido, establecer la propiedad ExtendedDataType.
6.      Organizar los campos relacionados en grupos.
7.      Asociar los campos del mapa con campos específicos de la tabla.
 
a. Click derecho sobre Mappings, luego click en Nuevo Mapping. Un nuevo mapeo es añadido con todos los campos del mapa definidos en el paso 2.

b.Click derecho en el nuevo mapeo, click en Propiedades, luego establecer la tabla en la propiedad MappingTable. Seleccionar como valor de esta propiedad la tabla CustBirthDay

c. Expandir el nuevo mapeo y luego click derecho en nodo campo.
d.                      Click en Propiedades, y luego seleccionar un campo desde la lista de la propiedad MapFieldTo.
 

 
La lista de campos disponibles varía dependiendo del tipo de dato que seleccionado en el paso 2.
e. Repetir el paso 6d para cada nodo de campo que está desplegado abajo del nuevo mapeo.

8.       Grabar los cambios del mapa.
9.      En el nuevo Mapa creado nos ubicamos en el nodo Methods, click derecho y seleccionamos cancelar método y luego validateWrite
 

 
10.  Reemplazamos el código por lo siguiente:

11.  Grabar los cambios del mapa.
12.  En el AOT buscamos la tabla VendBirthDay.
13.  Ubicamos el nodo Methods, click derecho y seleccionamos cancelar método y luego validateWrite

14.  Añadimos desde el editor de código la siguiente línea:

15.  Creamos un nuevo Job para la ejecución de nuestra pruebas
 
 

jueves, enero 03, 2013

Dynamics AX 2012: Patrón de clase de Contrato de Datos

PATRON DE CLASES DE CONTRATO DE DATOS


Contrato de Datos

• Es un acuerdo formal entre un cliente y un servicio que abstractamente describe los datos que se van a intercambiar.
• Para comunicar el cliente y el servicio no tienen que compartir los mismos datos, solo los mismos contratos de datos.
• Un contrato de datos define con precisión para cada parámetro o tipo de valor devuelto que datos se serializarán (se convierte en XML) para su intercambio.
• Clases que se crean para representar una entidad de datos con propiedades que pertenecen a la misma.
• Permite la interoperabilidad más amplio tanto con clientes o no cliente Microsoft.
• Se marca sus tipos con los atributos DataContractAttribute y DataMemberAttribute para crear un contrato de datos (intercambia sus Operaciones de Servicios).
• Los contratos de datos no están relacionados con el ámbito de acceso del código administrado: los miembros de datos privados se pueden señalizar y enviar a otra parte para tener acceso a ellos públicamente.


Clase FormLetterServiceController.

• Reemplaza la clase FormLetter.
• Actúa como controlador para las clases FormLetterService.
• Obtiene toda la información necesaria durante el proceso de registro y pasa estos valores a la clase FormLetterService utilizando el patrón de clases Contrato de Datos.
• Ésta clase invoca la clase FormLetterService cuando el método run es llamado.
• Las variables de clase fueron asignado valores para ser utilizado durante el proceso de registro han sido movidos a las clases de contrato de datos.
• El patrón utilizado para la asignación de valores a las clases de contrato de datos que era utilizado a través de los métodos parm de AX 2009 han sido cambiados para utilizar la clase de contrato de datos en vez de utilizar una variable de clase global.

Clase FormLetterContract

• Es la clase base de las clases de contrato de datos en el framework FormLetter.
• Sigue la misma estructura jerárquica de la clase FormLetterServiceController.
• Cada clase en la jerarquía de FormLetterServiceController tiene una correspondiente clase de contrato de datos.
• Los métodos parm son utilizados para establecer y obtener datos desde una clase Contrato [DataMemberAttribute].

Clase FormLetterService

• Puede ser utilizado para controlar el flujo de registro para un número de Darios.
• La clase está ligada a la capa Servidor y ejecuta en el IL, lo que significa, que no puede haber ninguna llamada de regreso (callbacks) desde ésta clase. Las llamada de regreso resultan en excepción.
• El método run registra documentos.
• También tiene un método de Operación de Servicio para cada tipo de documento que puede ser registrado por este servicio, tal como PostSalesPackingSlip.

Clase FormLetterParmData

• La jerarquía de esta clase puede ser utilizada para crear y mantener registrando datos en las tablas parm tal como SalesParmUpdate, SalesParmTable y SalesParmLine.
• La clase base utiliza utiliza un patrón de plantilla, definiendo una plantilla para cómo crear registros en las tablas parm.
• Hay clases para los módulos específicos tales como SalesFormLetterParmData y una clase para cada tipo de documento soportado, tal como SalesFormLetterParmDataPackingSlip.
• La clase tiene 3 API públicas:
o CreateData – crea los datos necesarios en las tabla parm.
o ReSelect – crea nuevamente los datos basados en el SpectQty.
o ReArrange – vuelve a organizar los datos en las tablas base (actualización resumen)


Clase FormLetterJournalCreate

• La jerarquía de la clase tiene la responsabilidad de crear un Diario con una cabecera. Por ejemplo CustPackingSlipJour y un número de líneas, por ejemplo CustPackingSlipTrans y los datos relacionados del Diario, por ejemplo CustPackingSlipSalesLink.
• La clase base utiliza un patrón de plantilla, definiendo las plantillas para crear un Diario.
• Patrón de plantilla InitJournalHeader().
• Estas clases mantienen la lógica específica para cada documento.
• Estos documentos de clases que soportan tienen múltiple versiones del mismo documento extendiendo la clase FormLetterVersionableJournalCreate.
• La clase FormLetterService instancia ésta jerarquía de clases por cada Diario que necesita crear y llamadas run.

Clase FormLetterJournalPost

• La jerarquía de esta clase puede ser utilizado para registrar un Diario, por ejemplo actualizando inventarios y el libro mayor.
• La clase base utiliza un patrón de plantilla, definiendo la plantilla para registra un diario.
• Existe una clase de documento específico para cada documento que puede ser registrado por el framework. Por ejemplo: SalesPackingSlipJournalPost.
• Estas clases mantienen la lógica específica para cada documento.
• La jerarquía de clases requiere que un Diario ha sido creado y pasado.
• La clase FormLetterService instancia ésta clase por cada Diario que es necesario registrar y llamadas run.

Clase FormLetterJournalPrint

• La jerarquía de esta clase puede ser utilizada para controlar la impresión de uno o mas documentos de Diarios.
• Hay una clase específica para cada documento que puede ser impreso por este framework.
• La clase FormLetterService instancia ésta clase tanto para cada Diario que está siendo registrado o una vez con toda una lista de Diarios registrados.
Clase FormLetterProvieder

• Puede ser utilizado para proporcionar datos específicos al modulo para cada una de las clases de la jerarquía.
• Hay una clase hija por módulo.