Archivo por meses: diciembre 2014

El método INPUT es obsoleto

Cuando estamos realizando una migración, muchas veces nos podemos encontrar que hay varios métodos que han quedado obsoletos. A partir de Dynamics NAV 2013 uno de ellos es el método INPUT, que se utiliza para pedir al usuario que inserte un texto.

input1

Este método se suele ver sobre todo en codeunits, lo cual no es nada recomendable ya que se nos parará el proceso a mitad requiriendo al usuario que nos inserte algo que podría hacer antes. Pero en el caso que queramos utilizarlo y no utilizar ninguna page, podemos hacerlo de la siguiente manera:

  1. Creamos una variable de tipo DotNet. En las propiedades, marcamos que se ejecute en el cliente
  2. Asignamos a la variable el subtipo Microsoft.VisualBasic.Interaction.’Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’input2
  3. Utilizamos el método InputBox de la variable Window que acabamos de crear. Requiere de los siguientes parámetros:
    • Texto a mostrar
    • Título de la ventana
    • Respuesta predefinida
    • Ancho y alto de la ventana

input3

Si ejecutamos la codeunit, nos dará el siguiente resultado:

input4

Es muy importante que pongamos que se ejecute la variable en el cliente, ya que en el caso que no lo hagamos el programa nos dará el siguiente error:

input5

 

 

Patrón de diseño: Métodos de enganche

Este patrón de diseño es uno de los mejores que existen en Dynamics NAV para tener un menor acoplamiento de las personalizaciones en una empresa con respecto a la versión estándar y quitar la lógica de negocio de las tablas y páginas.

Gracias a este patrón, las migraciones de versiones se pueden hacer en un tiempo récord, ya que reduciremos el código personalizado al mínimo imprescindible. Una de las grandes recomendaciones que se hace desde Microsoft es que utilicemos este patrón en cualquier parte que modifiquemos el estándar, además de en todos los objetos que no sea necesario que contengan lógica de negocio.

La idea de este patrón es contar con un método que llame a diferentes funciones que realizan las personalizaciones que queramos hacer en el estándar de Dynamics NAV.

¿Cómo utilizamos este patrón?

Para ver la utilización de este patrón, a continuación se muestra un ejemplo para que entienda mejor. Imaginemos que cada vez que cada vez que creamos un proveedor queremos que se bloquee con el valor Todos. Para conseguir nuestro objetivo vamos a tener que modificar el método OnInsert de la tabla Vendor.

Para seguir el patrón, primero crearemos una nueva codeunit llamada Vendor Hook. Es decir, añadimos el sufijo Hook al nombre del objeto estándar que vamos a modificar.

hook1

Una vez creada la codeunit, crearemos una función que se llame como la función que estemos modificando, e insertamos en ella llamadas a diferentes funciones con nuestro código personalizado.

hook2

Ahora modificaremos el objeto estándar insertando una variable global con la codeunit que acabamos de crear, e insertaremos la llamada a la función.

hook3

hook4

Este ejemplo es muy simple, pero sirve a la perfección para entender el funcionamiento del patrón y ver cómo aplicarlo. Si lo pensamos a fondo, veremos que este patrón no tiene sentido que sea utilizado en el estándar, ya que las ventajas que proporciona no son aplicables al mismo.

Personalmente, me parece uno de los mejores patrones de Dynamics NAV que existen en la actualidad, ya que aunque utilicemos una codeunit por cada objeto del estándar que modifiquemos, la ventaja de tener la lógica de negocio separada y el poder realizar migraciones de versiones mucho más ágiles supera este inconveniente con creces. Eso sin contar con la posibilidad de poder reutilizar funcionalidad en las funciones que vayamos creando.