Si estás trabajando con los (ya no tan) nuevos entornos Tier 2 de tipo self-service en Dynamics 365 for Finance and Operations, puede que ya te hayas dado cuenta de esto: los informes en los entornos Tier 2+ y producción no están usando el visor de informes de SSRS, sino que se imprimen en un visor PDF bien bonito.
¿Pero qué pasa en una máquina de desarrollo?
Si quieres saber más sobre los entornos self-service puedes leer estos posts que escribí hace un tiempo:
- Entornos self-service: el futuro que ya está aquí
- Un aviso sobre los entornos self-service: actualizar con cuidado
Visor de informes en tu VM
Si pruebas a imprimir un informe desde tu máquina de desarrollo, todavía verás el viejo visor HTML de SSRS en lugar de la preview en PDF. Esto es normal y está bien documentado.
¿Pero y a mi por qué debría importarme esto?
Para mi hay una razón muy clara: la forma en la que el visor de SSRS y la vista previa en PDF renderizan el informe es distinta, y algunas veces MUY distinta. Y esto puede ser un problema.
Imagínate esto: es lunes, empieza una nueva semana, has descansado y recargado las pilas, y tienes la suerte de que te asignan un maravilloso nuevo informe! «Joder qué suerte! Buena forma de empezar la semana» dice NADIE.
Lo siento, tenía que decirlo. Así que te tiras unas cuantas horas modificando un report, viendo el resultado, comprobando que los 40 malditos campos que tiene cada línea no causarán un salto de página, y listo. Haces el check-in y el día siguiente alguien te dice que, en UAT, los datos están saliendo en 2 páginas separadas. ¿Por quééééééééé?
Bueno, es porque los visores no renderizan el report igual. Debería ser muy parecido pero al final no lo es.
Arreglando tu máquina de desarrollo
Como dije antes esto está bien documentado, pero cuando nos metieron en la preview privada de los self-service no lo estaba. Afortunadamente mi compañero Ferni Tudela encontró que en la clase SrsReportRunUtil había un método que comprobaba si el entorno era de tipo self-service:
/// <summary>
/// Gets if the current environment is a service fabric host environment
/// </summary>
/// <returns>True, if the current environment is a service fabric host environment; otherwise, False.</returns>
public static boolean isServicFabricHostingEnvironment()
{
#define.HostingEnvironmentKey("HostingEnvironment")
var hostingEnvironment = HostingEnvironment::Unknown;
SysGlobalCache globalCache = classfactory.globalCache();
try
{
// Read from global cache first.
if(globalCache.isSet(funcname(), #HostingEnvironmentKey))
{
hostingEnvironment = globalCache.get(funcname(), #HostingEnvironmentKey);
}
else
{
var environment = EnvironmentFactory::GetApplicationEnvironment();
if(environment)
{
// Update global cache.
hostingEnvironment = environment.Common.HostingEnvironment;
globalCache.set(funcname(), #HostingEnvironmentKey, hostingEnvironment);
}
}
}
catch (Exception::CLRError)
{
hostingEnvironment = HostingEnvironment::Unknown;
}
return hostingEnvironment == HostingEnvironment::ServiceFabric;
}
Una alternativa en ese momento fue extender el método y devolver siempre true, así tu VM era un falso entorno service fabric.
Pero ahora tenemos una manera mejor de hacer esto, navegamos a la URL de nuestro entorno y añadimos &mi=SysReportAdministration. Esto abrirá el formulario de opciones de informes, en el que tenemos que marcar el primer checkbox:
Reiniciamos IIS y ya estaremos listos para empezar a usarl el visor de PDF. Espero que esto ayude a alguien que tenga que hacer reports.
1 Comment
Pingback: Aplicar un DP a un entorno self-service usando release pipelines - ariste.info