5.3Integración aplicativa (.NET / Visual Studio)
Lo esencial en 30 segundos
- El reparto de los roles : el diseñador crea el .rpt en el designer (sin programar), el desarrollador lo integra en la aplicación vía el SDK y el Crystal Reports Viewer — el usuario consume los estados sin abrir el designer.
- El mecanismo del lado dev : cargar el .rpt por código, dar la conexión y los parámetros por programa, enlazar al viewer — con impresión y exportación por código (PDF, correo) en opción.
- No olvidar nunca : desplegar el runtime Crystal en los puestos y servidores destino — sin él, ningún informe se muestra.
Minicaso hilado — Farès hace entrar sus estados en el ERP
Farès, controlador de gestión en Argel, quiere que los jefes de servicio impriman sus presupuestos directamente desde el ERP, con un botón « Imprimir el presupuesto » — sin abrir el designer. Concibe el .rpt (diseño, parámetros dirección y periodo), y luego trabaja con la desarrolladora : ella coloca un Crystal Reports Viewer, carga el .rpt por código, pasa la conexión y los parámetros (dirección conectada, periodo elegido), y despliega el runtime en los puestos. Continuación del caso 5.2 — Farès pasa del informe compartido por archivo al informe integrado en la aplicación.
Continuación del caso 5.2 — Farès colabora con la desarrolladora : él el .rpt, ella la integración.
1. Embarcar informes
Más allá del designer autónomo, Crystal Reports se integra en aplicaciones para difundir estados a gran escala. El caso habitual : Crystal Reports for Visual Studio — una versión gratuita que permite a los desarrolladores .NET embarcar informes (.rpt) en sus aplicaciones (Windows o web ASP.NET). Es el proyecto de Farès : sus presupuestos accesibles desde el ERP.
El diseñador crea el informe ; el desarrollador lo integra vía el Crystal Reports Viewer y el SDK ; la aplicación carga el informe, le da datos y parámetros, y lo muestra. Un programa puede entonces proponer « Imprimir la factura » sin que el usuario abra el designer — eso es lo que hace de Crystal Reports un motor de estados integrado en innumerables aplicaciones de gestión.
2. Cómo funciona (lado dev)
Se referencian los assemblies Crystal en el proyecto .NET, se coloca un CrystalReportViewer, se carga el .rpt, se le pasan las informaciones de conexión (identificadores) y los valores de los parámetros por código, y luego se enlaza el informe al viewer. Para Farès : la desarrolladora pasa la dirección del usuario conectado y el periodo elegido en pantalla.
El informe se muestra con impresión y exportación integradas. También se puede exportar por código (generar un PDF automáticamente, enviarlo por correo) — práctico para los envíos mensuales de Farès sin intervención manual.
3. Roles y despliegue
Lado dev : gestionar la conexión (identificadores nunca programados en duro), pasar los parámetros según el contexto de la aplicación, y desplegar el runtime Crystal en los puestos y servidores destino — paso para no olvidar, si no nada se muestra. Farès y la desarrolladora se ponen de acuerdo sobre el contrato : nombres de los parámetros y fuente de datos.
También existen SDK Java y la plataforma SAP BusinessObjects (planificación, portal, difusión masiva). La integración pide competencias de desarrollo — trabajo de desarrollador, no de diseñador de estados. Buena noticia para Farès : puede modificar su .rpt (una columna, una fórmula) sin tocar el código de la aplicación.
🔎 Ejemplo concreto — Un botón « Imprimir el presupuesto » en el ERP
El informe vive en el programa.
El código carga budget.rpt, pasa la dirección y el periodo en parámetros,
da la conexión, enlaza al CrystalReportViewer → el presupuesto se muestra/se imprime.Lectura : el usuario consume el estado sin abrir el designer.
Lección : desplegar el runtime ; no programar los identificadores en duro.
Vocabulario de la sección
- Integración aplicativa
- Embarcar informes Crystal en una aplicación para difundir estados a gran escala.
Ejemplo sencillo: Farès hace sus presupuestos imprimibles desde el ERP en Argel.
Lo que no es: compartir el archivo .rpt por correo.
Reflejo: ¿el usuario aún abre el designer ?
- Crystal Reports Viewer
- El componente de visualización colocado en la aplicación, con impresión y exportación integradas.
Ejemplo sencillo: La desarrolladora coloca el viewer en la pantalla presupuesto del ERP.
Lo que no es: el designer completo instalado en cada usuario.
Reflejo: ¿dónde se muestra el informe en la apli ?
- Paso de los parámetros
- La transmisión por código de los valores de los parámetros según el contexto aplicativo.
Ejemplo sencillo: La dirección conectada y el periodo elegido pasan en parámetros.
Lo que no es: valores fijados en el informe para todo el mundo.
Reflejo: ¿quién da los valores, y de dónde vienen ?
- Contrato diseñadores-dev
- El acuerdo sobre el archivo .rpt y los parámetros : nombres, tipos, fuente de datos.
Ejemplo sencillo: Farès y la desarrolladora se ponen de acuerdo sobre los parámetros dirección y periodo.
Lo que no es: un .rpt modificado sin avisar que rompe la llamada.
Reflejo: ¿el contrato de los parámetros está escrito ?
- Runtime
- Los componentes de ejecución para desplegar en puestos y servidores para mostrar los informes.
Ejemplo sencillo: Farès verifica el runtime instalado antes de la puesta en servicio.
Lo que no es: un puesto que muestra los informes sin nada instalado.
Reflejo: ¿el runtime está desplegado donde hace falta ?
En la práctica — Entender la integración aplicativa
- Sitúe el rol : el diseñador crea el informe (.rpt) en el designer ; el desarrollador lo INTEGRA (.NET vía Crystal Reports for Visual Studio, gratuito).
- Anote el mecanismo : un CrystalReportViewer muestra el informe ; el código carga el .rpt, da la conexión y los parámetros, enlaza al viewer.
- Retenga las responsabilidades desarrollador : gestionar la conexión (identificadores no programados en duro), pasar los parámetros, exportar por código si hace falta (PDF, correo).
- No olvide el DESPLIEGUE del runtime Crystal en los puestos/servidores destino ; la empresa puede también usar SAP BusinessObjects para la difusión masiva.
Guion listo para decir — proponer la integración a la dirección
« En lugar de difundir este presupuesto por archivo, les propongo integrarlo en el ERP : concibo el informe con sus parámetros dirección y periodo, nuestra desarrolladora lo muestra vía el viewer con la conexión y los parámetros pasados por código, y desplegamos el runtime en los puestos. Cada jefe de servicio imprimirá su presupuesto desde la aplicación, con sus solos datos — y podré hacer evolucionar el informe sin tocar el código. »
Para decir a la dirección y a la desarrolladora para encuadrar la colaboración antes de todo código.
Plantilla copiar-pegar — ficha contrato de integración
FICHA CONTRATO DE INTEGRACIÓN — informe : ___ (.rpt)
PARÁMETROS : nombre 1 ___ (tipo ___) · nombre 2 ___ (tipo ___) · fuente de los valores : ___
CONEXIÓN : dada por código SÍ / NO · ¿identificadores en duro ? JAMÁS
VIEWER : pantalla ___ · impresión SÍ / NO · exportación por código (PDF/correo) SÍ / NO
RUNTIME desplegado en : ___ · probado el : ___Solo / presupuesto pequeño
Farès solo : prepara un .rpt con parámetros bien nombrados, listo para la desarrolladora cuando llegue.
TPE / equipo reducido
Una sola pantalla con viewer y botón de impresión : la integración mínima que lo cambia todo.
PYME en Argel
Farès ajusta en Argel una recepción en dos puestos piloto : viewer, conexión, parámetros y runtime verificados antes de generalizar.
Equipo que empieza
Binomio diseñador-desarrollador : contrato de parámetros escrito, y luego prueba de un primer .rpt de punta a punta.
✓ Buenas prácticas
- El diseñador puede crear excelentes .rpt sin saber programar.
- Ponerse de acuerdo sobre los parámetros y la fuente (la interfaz entre los dos roles).
- Un .rpt se modifica a menudo sin retocar el código de la aplicación.
✗ Errores frecuentes
- Olvidar desplegar el runtime (los informes no se muestran).
- Programar los identificadores de base de datos en duro (seguridad).
- Creer que integrar un informe no pide competencias de desarrollo.
Puntos clave
- La INTEGRACIÓN APLICATIVA embarca informes Crystal en APLICACIONES : el usuario consume los estados (« Imprimir la factura ») sin abrir el designer. Un motor de estados integrado.
- CRYSTAL REPORTS FOR VISUAL STUDIO (gratuito) = la vía .NET : cargar el .rpt, un CrystalReportViewer, dar CONEXIÓN y PARÁMETROS por código, mostrar. SDK Java y SAP BusinessObjects también existen.
- El diseñador crea el .rpt ; el DESARROLLADOR lo integra — una colaboración. Lado dev : conexión (identificadores no programados en duro), parámetros, exportación por código (PDF, correo).
- No olvidar el DESPLIEGUE del RUNTIME en los puestos/servidores. La integración pide competencias de DESARROLLO — trabajo de desarrollador, no de diseñador de estados.
Desafío 48h — aplíquelo mañana
Rellene la ficha contrato de integración (modelo anterior) para 1 informe real : ¿figuran allí los parámetros, la conexión por código y el runtime desplegado ?
- Puedo describir el trayecto del .rpt hasta la pantalla de la aplicación.
- Mi contrato de parámetros diseñador-desarrollador está escrito.
- Sé por qué el runtime es indispensable en los puestos.
Preguntas frecuentes
¿Cómo un informe concebido en el designer acaba en una aplicación de gestión ?
Por una colaboración entre dos roles. El DISEÑADOR crea el informe en el designer (diseño, campos, fórmulas, grupos, parámetros) y guarda un archivo .RPT — sin escribir código. El DESARROLLADOR lo integra en la aplicación vía el SDK (p. ej. Crystal Reports for Visual Studio, gratuito, para .NET) : coloca un CrystalReportViewer, carga el .rpt por código, da la CONEXIÓN a la base de datos (identificadores, sin programarlos en duro), pasa los PARÁMETROS (p. ej. el ID de la factura), y enlaza el informe al viewer — que lo muestra con impresión/exportación. En concreto, un botón « Imprimir la factura » ejecuta ese código : carga factura.rpt, pasa el ID en parámetro, recupera los datos, muestra/imprime. El usuario consume el informe sin abrir el designer. No olvidar DESPLEGAR el runtime Crystal en las máquinas destino.
¿Hay que ser desarrollador para integrar informes, y cómo se reparten los roles ?
Para CONCEBIR informes (crear los .rpt) → NO : el designer es visual, accesible a perfiles de gestión, incluso para estados complejos ; es un oficio distinto del desarrollo. Para INTEGRAR los informes en una aplicación → SÍ : viewer, conexión por código, parámetros, despliegue del runtime piden competencias de desarrollador. Colaboración : el diseñador crea/mantiene los .rpt (gestión, presentación, parámetros) y puede modificarlos sin tocar el código (los estados evolucionan sin redesarrollo) ; el desarrollador integra los .rpt (carga, conexión, parámetros, despliegue). La interfaz entre ambos : el archivo .rpt y el contrato sobre los parámetros. Concebir estados es pues una competencia autónoma y valorada.
¿Qué hay que instalar en los puestos para que una aplicación muestre informes Crystal ?