5.3Intégration applicative (.NET / Visual Studio)
L'essentiel en 30 secondes
- Le partage des rôles : le concepteur crée le .rpt dans le designer (sans coder), le développeur l'intègre dans l'application via le SDK et le Crystal Reports Viewer — l'utilisateur consomme les états sans ouvrir le designer.
- Le mécanisme côté dev : charger le .rpt par code, fournir la connexion et les paramètres par programme, lier au viewer — avec impression et export par code (PDF, e-mail) en option.
- Ne jamais oublier : déployer le runtime Crystal sur les postes et serveurs cibles — sans lui, aucun rapport ne s'affiche.
Mini-cas filé — Farès fait entrer ses états dans l'ERP
Farès, contrôleur de gestion à Alger, veut que les chefs de service impriment leurs budgets directement depuis l'ERP, avec un bouton « Imprimer le budget » — sans ouvrir le designer. Il conçoit le .rpt (mise en page, paramètres direction et période), puis travaille avec la développeuse : elle place un Crystal Reports Viewer, charge le .rpt par code, passe la connexion et les paramètres (direction connectée, période choisie), et déploie le runtime sur les postes. Suite du cas 5.2 — Farès passe du rapport partagé par fichier au rapport intégré à l'application.
Suite du cas 5.2 — Farès collabore avec la développeuse : lui le .rpt, elle l'intégration.
1. Embarquer des rapports
Au-delà du designer autonome, Crystal Reports s'intègre dans des applications pour diffuser des états à grande échelle. Le cas courant : Crystal Reports for Visual Studio — une version gratuite qui permet aux développeurs .NET d'embarquer des rapports (.rpt) dans leurs applications (Windows ou web ASP.NET). C'est le projet de Farès : ses budgets accessibles depuis l'ERP.
Le concepteur crée le rapport ; le développeur l'intègre via le Crystal Reports Viewer et le SDK ; l'application charge le rapport, lui fournit données et paramètres, et l'affiche. Un logiciel peut alors proposer « Imprimer la facture » sans que l'utilisateur ouvre le designer — c'est ce qui fait de Crystal Reports un moteur d'états intégré à d'innombrables applications métier.
2. Comment ça marche (côté dev)
On référence les assemblies Crystal dans le projet .NET, on place un CrystalReportViewer, on charge le .rpt, on lui passe les informations de connexion (identifiants) et les valeurs des paramètres par code, puis on lie le rapport au viewer. Pour Farès : la développeuse passe la direction de l'utilisateur connecté et la période choisie à l'écran.
Le rapport s'affiche avec impression et export intégrés. On peut aussi exporter par code (générer un PDF automatiquement, l'envoyer par e-mail) — pratique pour les envois mensuels de Farès sans intervention manuelle.
3. Rôles et déploiement
Côté dev : gérer la connexion (identifiants jamais codés en dur), passer les paramètres selon le contexte de l'application, et déployer le runtime Crystal sur les postes et serveurs cibles — étape à ne pas oublier, sinon rien ne s'affiche. Farès et la développeuse se mettent d'accord sur le contrat : noms des paramètres et source de données.
Il existe aussi des SDK Java et la plateforme SAP BusinessObjects (planification, portail, diffusion massive). L'intégration demande des compétences de développement — travail de développeur, pas de concepteur d'états. Bonne nouvelle pour Farès : il peut modifier son .rpt (une colonne, une formule) sans toucher au code de l'application.
🔎 Exemple concret — Un bouton « Imprimer le budget » dans l'ERP
Le rapport vit dans le logiciel.
Le code charge budget.rpt, passe la direction et la période en paramètres,
fournit la connexion, lie au CrystalReportViewer → le budget s'affiche/s'imprime.Lecture : l'utilisateur consomme l'état sans ouvrir le designer.
Leçon : déployer le runtime ; ne pas coder les identifiants en dur.
Vocabulaire de la section
- Intégration applicative
- Embarquer des rapports Crystal dans une application pour diffuser des états à grande échelle.
Exemple simple : Farès rend ses budgets imprimables depuis l'ERP à Alger.
Ce que ce n'est pas : partager le fichier .rpt par e-mail.
Réflexe : l'utilisateur ouvre-t-il encore le designer ?
- Crystal Reports Viewer
- Le composant d'affichage placé dans l'application, avec impression et export intégrés.
Exemple simple : La développeuse place le viewer sur l'écran budget de l'ERP.
Ce que ce n'est pas : le designer complet installé chez chaque utilisateur.
Réflexe : où le rapport s'affiche-t-il dans l'appli ?
- Passage des paramètres
- La transmission par code des valeurs des paramètres selon le contexte applicatif.
Exemple simple : La direction connectée et la période choisie passent en paramètres.
Ce que ce n'est pas : des valeurs figées dans le rapport pour tout le monde.
Réflexe : qui fournit les valeurs, et d'où viennent-elles ?
- Contrat concepteurs-dev
- L'accord sur le fichier .rpt et les paramètres : noms, types, source de données.
Exemple simple : Farès et la développeuse s'accordent sur les paramètres direction et période.
Ce que ce n'est pas : un .rpt modifié sans prévenir qui casse l'appel.
Réflexe : le contrat des paramètres est-il écrit ?
- Runtime
- Les composants d'exécution à déployer sur postes et serveurs pour afficher les rapports.
Exemple simple : Farès vérifie le runtime installé avant la mise en service.
Ce que ce n'est pas : un poste qui affiche les rapports sans rien d'installé.
Réflexe : le runtime est-il déployé partout où il faut ?
En pratique — Comprendre l'intégration applicative
- Situez le rôle : le concepteur crée le rapport (.rpt) dans le designer ; le développeur l'INTÈGRE (.NET via Crystal Reports for Visual Studio, gratuit).
- Notez le mécanisme : un CrystalReportViewer affiche le rapport ; le code charge le .rpt, fournit la connexion et les paramètres, lie au viewer.
- Retenez les responsabilités développeur : gérer la connexion (identifiants non codés en dur), passer les paramètres, exporter par code si besoin (PDF, e-mail).
- N'oubliez pas le DÉPLOIEMENT du runtime Crystal sur les postes/serveurs cibles ; l'entreprise peut aussi utiliser SAP BusinessObjects pour la diffusion massive.
Script prêt à dire — proposer l'intégration à la direction
« Plutôt que de diffuser ce budget par fichier, je vous propose de l'intégrer à l'ERP : je conçois le rapport avec ses paramètres direction et période, notre développeuse l'affiche via le viewer avec la connexion et les paramètres passés par code, et on déploie le runtime sur les postes. Chaque chef de service imprimera son budget depuis l'application, avec ses seules données — et je pourrai faire évoluer le rapport sans toucher au code. »
À dire à la direction et à la développeuse pour cadrer la collaboration avant tout code.
Modèle copier-coller — fiche contrat d'intégration
FICHE CONTRAT D'INTÉGRATION — rapport : ___ (.rpt)
PARAMÈTRES : nom 1 ___ (type ___) · nom 2 ___ (type ___) · source des valeurs : ___
CONNEXION : fournie par code OUI / NON · identifiants en dur ? JAMAIS
VIEWER : écran ___ · impression OUI / NON · export par code (PDF/e-mail) OUI / NON
RUNTIME déployé sur : ___ · testé le : ___Solo / petit budget
Farès seul : il prépare un .rpt aux paramètres bien nommés, prêt pour la développeuse quand elle arrive.
TPE / équipe réduite
Un seul écran avec viewer et bouton d'impression : l'intégration minimale qui change tout.
PME à Alger
Farès cale à Alger une recette sur deux postes pilotes : viewer, connexion, paramètres et runtime vérifiés avant généralisation.
Équipe qui démarre
Binôme concepteur-développeur : contrat de paramètres écrit, puis test d'un premier .rpt de bout en bout.
✓ Bonnes pratiques
- Le concepteur peut créer d'excellents .rpt sans savoir coder.
- S'accorder sur les paramètres et la source (l'interface entre les deux rôles).
- Un .rpt se modifie souvent sans retoucher le code de l'application.
✗ Pièges fréquents
- Oublier de déployer le runtime (les rapports ne s'affichent pas).
- Coder les identifiants de base en dur (sécurité).
- Croire qu'intégrer un rapport ne demande pas de compétences de développement.
Points clés à retenir
- L'INTÉGRATION APPLICATIVE embarque des rapports Crystal dans des APPLICATIONS : l'utilisateur consomme les états (« Imprimer la facture ») sans ouvrir le designer. Un moteur d'états intégré.
- CRYSTAL REPORTS FOR VISUAL STUDIO (gratuit) = la voie .NET : charger le .rpt, un CrystalReportViewer, fournir CONNEXION et PARAMÈTRES par code, afficher. SDK Java et SAP BusinessObjects existent aussi.
- Le concepteur crée le .rpt ; le DÉVELOPPEUR l'intègre — une collaboration. Côté dev : connexion (identifiants non codés en dur), paramètres, export par code (PDF, e-mail).
- Ne pas oublier le DÉPLOIEMENT du RUNTIME sur les postes/serveurs. L'intégration demande des compétences de DÉVELOPPEMENT — travail de développeur, pas de concepteur d'états.
Défi 48h — appliquez demain
Remplissez la fiche contrat d'intégration (modèle ci-dessus) pour 1 rapport réel : les paramètres, la connexion par code et le runtime déployé y figurent-ils ?
- Je peux décrire le trajet du .rpt jusqu'à l'écran de l'application.
- Mon contrat de paramètres concepteur-développeur est écrit.
- Je sais pourquoi le runtime est indispensable sur les postes.
Questions fréquentes
Comment un rapport conçu dans le designer se retrouve-t-il dans une application métier ?
Par une collaboration entre deux rôles. Le CONCEPTEUR crée le rapport dans le designer (mise en page, champs, formules, groupes, paramètres) et sauvegarde un fichier .RPT — sans écrire de code. Le DÉVELOPPEUR l'intègre dans l'application via le SDK (ex. Crystal Reports for Visual Studio, gratuit, pour .NET) : il place un CrystalReportViewer, charge le .rpt par code, fournit la CONNEXION à la base (identifiants, sans les coder en dur), passe les PARAMÈTRES (ex. l'ID de la facture), et lie le rapport au viewer — qui l'affiche avec impression/export. Concrètement, un bouton « Imprimer la facture » exécute ce code : il charge facture.rpt, passe l'ID en paramètre, récupère les données, affiche/imprime. L'utilisateur consomme le rapport sans ouvrir le designer. Ne pas oublier de DÉPLOYER le runtime Crystal sur les machines cibles.
Faut-il être développeur pour intégrer des rapports, et comment se répartissent les rôles ?
Pour CONCEVOIR des rapports (créer les .rpt) → NON : le designer est visuel, accessible à des profils métier, même pour des états complexes ; c'est un métier distinct du développement. Pour INTÉGRER les rapports dans une application → OUI : viewer, connexion par code, paramètres, déploiement du runtime demandent des compétences de développeur. Collaboration : le concepteur crée/maintient les .rpt (métier, présentation, paramètres) et peut les modifier sans toucher au code (les états évoluent sans redéveloppement) ; le développeur intègre les .rpt (chargement, connexion, paramètres, déploiement). L'interface entre les deux : le fichier .rpt et le contrat sur les paramètres. Concevoir des états est donc une compétence autonome et valorisée.
Que doit-on installer sur les postes pour qu'une application affiche des rapports Crystal ?