Microsoft Dynamics AX 2012 utiliza Microsoft SQL Reporting Services para proporcionar capacidades de informes a los usuarios de AX. Aquí hay un par de trucos y consejos que he aprendido a lo largo de los años y para los cuales no pude encontrar ninguna referencia en línea. Tal vez haya alguna documentación por ahí, pero me resultó difícil encontrarla cuando la necesitaba.
Consejo #1: Asegúrese de tener todos los permisos necesarios
Además de los permisos requeridos en AX para implementar informes, la cuenta de dominio del usuario de AX debe tener los permisos adecuados definidos en SSRS. La cuenta de usuario de dominio debe poder acceder al sitio web del Administrador de informes de SSRS y al menos tener asignado el rol de Administrador de contenido en la carpeta de informes de Dynamics AX. Para probar que mi usuario tiene todos los permisos necesarios para implementar informes, suelo abrir un navegador Internet Explorer e ir al sitio web del Administrador de informes de SSRS. Luego intento abrir la carpeta de Dynamics AX. Si eso funciona, entonces temporalmente creo una subcarpeta dentro de la subcarpeta de Dynamics AX. Si tengo éxito, generalmente significa que tengo lo que necesito para publicar informes. Tal vez no sea la forma correcta de hacerlo, pero me ha funcionado cada vez. Nota: No olvide eliminar la carpeta temporal creada.
Consejo #2: Apuntando en la dirección correcta
Como muchos de ustedes saben, un cliente de Dynamics AX puede apuntar a diferentes instancias de AX instaladas en diferentes servidores. Como ejemplo de esto, puede tener un servidor de Terminal Services con el cliente de AX instalado y luego hacer que ese cliente de AX apunte a una instancia de DEV, una instancia de TEST e incluso una instancia de producción de AX. Para hacer que su cliente de AX apunte a una instancia, tiene dos opciones:
- Establezca la configuración activa de AX de la sesión de usuario de su dominio utilizando la Utilidad de configuración de Microsoft Dynamics AX, haga clic en Aplicar u OK, y luego haga clic en el acceso directo estándar “Microsoft Dynamics AX 2012”. Esto utilizará la configuración activa para conectarse al servidor AX AOS.
- La otra opción es exportar una configuración de AX a un archivo. Esto creará un archivo “.axc” en el que puede hacer doble clic y se abrirá AX y lo apuntará al servidor AX AOS especificado para esa configuración. Muy conveniente para evitar los pasos adicionales en la opción #1.
Ahora aquí está el consejo. Al implementar informes, Visual Studio y AX utilizarán la configuración activa de la sesión para determinar los servidores de destino de AOS y SSRS. (Información difícil de encontrar) Si por alguna razón utilizó un acceso directo que apunta a DEV y la configuración activa apunta a TEST, los informes se publicarán en el entorno de TEST, aunque su cliente de AX apunte a DEV. Solo notará que algo está mal después de haber intentado implementar su informe 1, 2 o tal vez 20 veces y sus cambios no aparecen al imprimir el informe. No solo eso, esto también afecta a las capas donde está realizando sus cambios. Si su cliente de AX apunta a la capa VAR y la configuración activa apunta a la capa USR, tendrá algunos de sus cambios en la capa VAR y algunos de ellos en la capa USR. Por lo tanto, el consejo es asegurarse de que su configuración activa coincida con el entorno y la capa a la que apunta el cliente de AX. He aprendido a no crear más accesos directos de AX, ya que crea mucha confusión.
Este artículo fue escrito por Eduardo Sicouret, Consultor Técnico de Dynamics para Tridea Partners. Tridea es un proveedor líder de Microsoft Dynamics.
