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.

Patrones de diseño en Dynamics NAV

Cualquiera que se haya adentrado en el mundo de la programación se ha encontrado con algo muy importante: los patrones de diseño. Pero la pregunta es, ¿tienen cabida estos patrones en Dynamics NAV?

Hay muchos tipos de patrones, y la mayoría se han creado de cara a la programación orientada a objetos (POO), pero hay muchos patrones que existen para Dynamics NAV sin documentar. Esto no quiere decir que no existan, simplemente la mayor parte de ellos no están explicados. Desde hace un tiempo se está documentando un patrón de diseño cada mes en la wiki de Microsoft, para facilitar el diseño de nuestras aplicaciones.

Hay bastantes patrones de diseño que podemos utilizar con Dynamics NAV, y elegir uno de ellos dependerá de las necesidades que tengamos en el momento.

¿Cuál es la importancia de utilizar los patrones en nuestros desarrollos?

  • Haremos de nuestro código más limpio y fácil de mantener. Esto lo agradeceremos en el futuro, ya que cualquier problema con una personalización será más fácil de resolver.
  • Las migraciones de versión serán mucho más sencillas. ¿Cuánto tiempo se ha invertido en cambios de código que no funcionan correctamente en una versión más actualizada? Utilizando alguno de los patrones para Dynamics NAV las migraciones se pueden conseguir en menos tiempo y esfuerzo y mejores resultados.
  • Menor acoplamiento de las personalizaciones.
  • Resolveremos problemas de forma sencilla y sin utilizar métodos extraños.
  • Las personalizaciones las podremos hacer configurables, con lo que un cambio de comportamiento no supondrá un cambio en el código.
  • El código será user-friendly.
  • Separaremos la funcionalidad de la parte visual.

Estas son algunas de las ventajas que nos encontraremos, aunque a veces será necesario sacrificar alguna de ellas para lograr una solución a los problemas que tengamos planteados.

Conforme va pasando el tiempo vamos encontrando una mayor documentación de los patrones que podemos escoger a la hora de personalizar Dynamics NAV. Tendremos que tener en cuenta qué es lo que necesitamos implantar y un análisis profundo de las necesidades, sabiendo que gracias a los patrones de diseño los posteriores mantenimientos serán menores o más fáciles de modificar y entender por otros desarrolladores.