Consideraciones para programar en GP2013 (Parte I)

Microsoft Dynamics GP
Microsoft Dynamics GP 2013 ha sido liberado en el mes de diciembre para norteamérica y en el mes de abril se estará realizando su lanzamiento en la región. Dentro de las consideraciones que los desarrolladores deben tomar en cuenta se encuentra el de el manejo multitenant que posee la nueva versión. Qué significa eso? Básicamente hasta la version anterior se podia instalar un Microsoft Dynamics GP por instancia de SQL Server, debido a que la base de datos master de la aplicación se llama DYNAMICS y no puede ser modificada. La nueva arquitectura permite tener varias instalaciones del producto sobre una misma instancia debido a que ahora es posible la modificación del nombre de la base de datos master de la aplicación. Esto se realiza en el momento de la instalación. Lo importante de este detalle es que ya no es necesario instalar una nueva instancia de SQL Server para poder realizar una nueva instalación.
Ahora la otra pregunta es: Qué consecuencias trae este modelo para los desarrolladores? En pocas palabras los cambios no son grandes pero si se debe considerar que ahora la base de datos master de la aplicación no necesariamente se va a llamar DYNAMICS.

GP2013 Named db model

Las consideraciones a tomar en el momento de la instalación son:

  • Por defecto el nombre de la base de datos master sigue siendo DYNAMICS, sin embargo puede ser modificado.
  • El nombre de la base de datos debe ser de menos de 10 caracteres.
  • El nombre seleccionado será almacenado en la propiedad del System DB Name del dex.ini de la instacia que se esté instalando.
  • Una vez establecido el nombre de la base de datos master, no puede ser modificado.
  • Si decide instalar la base de datos de ejemplo Fabrikam y no cambia el nombre de la base de datos master, entonces por defecto se llamará TWO. Si TWO ya existe entonces se buscará el siguiente disponible en incrementos con la configuración TWOnn en donde nn es un número. Por ejemplo, TWO01, TWO02, etc…
  • Los usuarios LessonUser1 y LessonUser2 sera creados únicamente para la base de datos TWO.
  • El owner predeterminado para cada base de datos sigue siendo DYNSA.

Ahora entrando a la parte del código… Qué cambios representa para los programadores?

  • Deben reemplazar todas las referencias de código duro a DYNAMICS (strings y constantes) por la función GetSystemDatabaseName().
  • Reemplazar toda referencia a la base de datos TWO (string y constantes) por la función GetLessonDatabaseName().
  • Usar la función GetSystemDatabaseName(false) si se necesita el nombre de la base de datos antes de la conexión (usar con moderación).
  • Usar la función GetSystemDatabaseName(true) desde VSToolAddin (en Application.Dynamics.dll).

Como verán a la mayoría de los programadores estos cambios no les deben afectar debido a que es extraño que se haga referencia directamente al nombre de la base de datos master o al de la compañía de ejemplo. Tampoco es usual el intentar obtener el nombre de la base de datos antes de establecer la conexión (por lo menos en el mundo de los desarrollos Dynamics).

Pero esto no es todo… Mas les cuento en la parte II…

Leave a Reply