5.3 · Application integration (.NET / Visual Studio)

Level 5 · Distribution, integration & best practices

5.3Application integration (.NET / Visual Studio)

Goal: Understand integrating an .rpt into an application and designer/developer collaboration.
Estimated time: 10 min · self-paced reading · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

  • Sharing roles: the designer creates the .rpt in the designer (without coding), the developer integrates it into the application via the SDK and the Crystal Reports Viewer — the user consumes statements without opening the designer.
  • The dev-side mechanism: load the .rpt in code, supply the connection and parameters programmatically, bind to the viewer — with printing and export in code (PDF, email) as an option.
  • Never forget: deploy the Crystal runtime on target workstations and servers — without it, no report displays.

Running mini-case — Farès brings his statements into the ERP

Farès, a management controller in Algiers, wants department heads to print their budgets directly from the ERP, with a “Print budget” button — without opening the designer. He designs the .rpt (layout, division and period parameters), then works with the developer: she places a Crystal Reports Viewer, loads the .rpt in code, passes the connection and parameters (connected division, chosen period), and deploys the runtime on workstations. Continued from case 5.2 — Farès moves from a file-shared report to an application-integrated report.

Continued from case 5.2 — Farès collaborates with the developer: he owns the .rpt, she owns integration.

1. Embedding reports

Beyond the standalone designer, Crystal Reports integrates into applications to distribute statements at scale. The common case: Crystal Reports for Visual Studio — a free version that lets .NET developers embed reports (.rpt) into their applications (Windows or ASP.NET web). That is Farès's project: his budgets available from the ERP.

The designer creates the report; the developer integrates it via the Crystal Reports Viewer and the SDK; the application loads the report, supplies data and parameters, and displays it. Software can then offer “Print invoice” without the user opening the designer — what makes Crystal Reports a statement engine built into countless business applications.

2. How it works (dev side)

Reference the Crystal assemblies in the .NET project, place a CrystalReportViewer, load the .rpt, pass it the connection information (credentials) and the parameter values in code, then bind the report to the viewer. For Farès: the developer passes the logged-in user's division and the on-screen chosen period.

The report displays with built-in printing and export. You can also export in code (automatically generate a PDF, send it by email) — handy for Farès's monthly sends without manual action.

3. Roles and deployment

Dev side: manage the connection (never hard-coded credentials), pass parameters according to the application context, and deploy the Crystal runtime on target workstations and servers — a step not to forget, otherwise nothing displays. Farès and the developer agree on the contract: parameter names and data source.

There are also Java SDKs and the SAP BusinessObjects platform (scheduling, portal, mass distribution). Integration requires development skills — developer work, not statement-designer work. Good news for Farès: he can change his .rpt (a column, a formula) without touching the application code.

Common misinterpretation: “Integrating a report into an app is just copying the .rpt file to the server.” No. The .rpt alone displays nowhere: you need code that loads the report, supplies the connection and parameters, binds it to a viewer — and a runtime deployed on each target machine. Without this developer work (cleanly managed connection, parameters passed by context, runtime installed), the “Print” button prints nothing. The right reflex: designer and developer agree on the .rpt and the parameter contract, then the developer integrates, tests and deploys the runtime.
From .rpt to application Designer then developer Design The .rpt inthe designerIntegrate Viewer +connection + parametersDeploy Runtime onworkstations
Designer then developer
Text version of the diagram (SEO / screen readers / translation): 1) Design: Farès creates the budget .rpt in Algiers in the designer — layout, fields, division and period parameters. 2) Integrate: the developer loads the .rpt in code, places a Crystal Reports Viewer, passes the connection and the logged-in user's parameters. 3) Deploy: the Crystal runtime is installed on workstations and servers, otherwise nothing displays. Lesson: the designer makes the .rpt, the developer integrates it — and the .rpt can evolve without redevelopment.

🔎 Concrete example — A “Print budget” button in the ERP

The report lives inside the software.

The code loads budget.rpt, passes division and period as parameters,
supplies the connection, binds to the CrystalReportViewer → the budget displays/prints.

Reading: the user consumes the statement without opening the designer.

Lesson: deploy the runtime; do not hard-code credentials.

Section vocabulary

Application integration
Embedding Crystal reports in an application to distribute statements at scale.

Simple example: Farès makes his budgets printable from the ERP in Algiers.

What it is not: sharing the .rpt file by email.

Reflex: does the user still open the designer?

Crystal Reports Viewer
The display component placed in the application, with built-in printing and export.

Simple example: The developer places the viewer on the ERP budget screen.

What it is not: the full designer installed for each user.

Reflex: where does the report display in the app?

Passing parameters
Passing parameter values in code according to the application context.

Simple example: The connected division and the chosen period are passed as parameters.

What it is not: values frozen in the report for everyone.

Reflex: who supplies the values, and where do they come from?

Designer-dev contract
The agreement on the .rpt file and parameters: names, types, data source.

Simple example: Farès and the developer agree on the division and period parameters.

What it is not: a .rpt changed without warning that breaks the call.

Reflex: is the parameter contract written down?

Runtime
The runtime components to deploy on workstations and servers to display reports.

Simple example: Farès checks the runtime is installed before go-live.

What it is not: a workstation displaying reports with nothing installed.

Reflex: is the runtime deployed everywhere needed?

In practice — Understand application integration

  1. Place the role: the designer creates the report (.rpt) in the designer; the developer INTEGRATES it (.NET via Crystal Reports for Visual Studio, free).
  2. Note the mechanism: a CrystalReportViewer displays the report; code loads the .rpt, supplies the connection and parameters, binds to the viewer.
  3. Remember developer responsibilities: manage the connection (credentials not hard-coded), pass parameters, export in code if needed (PDF, email).
  4. Do not forget DEPLOYING the Crystal runtime on target workstations/servers; the company can also use SAP BusinessObjects for mass distribution.
You understand how Crystal reports integrate into business applications (invoices/statements generated by the app) and how designer and developer collaborate.

Ready-to-say script — propose integration to management

“Rather than distributing this budget by file, I suggest integrating it into the ERP: I design the report with its division and period parameters, our developer displays it via the viewer with connection and parameters passed in code, and we deploy the runtime on workstations. Each department head will print their budget from the application, with only their data — and I will be able to evolve the report without touching code.”

Say to management and the developer to frame collaboration before any code.

Copy-paste template — integration contract sheet

INTEGRATION CONTRACT SHEET — report: ___ (.rpt)
PARAMETERS: name 1 ___ (type ___) · name 2 ___ (type ___) · value source: ___
CONNECTION: supplied in code YES / NO · hard-coded credentials? NEVER
VIEWER: screen ___ · printing YES / NO · export in code (PDF/email) YES / NO
RUNTIME deployed on: ___ · tested on: ___

Solo / tight budget

Farès alone: he prepares an .rpt with well-named parameters, ready for the developer when she arrives.

Very small business / small team

A single screen with viewer and print button: the minimal integration that changes everything.

SME in Algiers

Farès in Algiers schedules acceptance on two pilot workstations: viewer, connection, parameters and runtime verified before rollout.

Starting team

Designer-developer pair: written parameter contract, then end-to-end test of a first .rpt.

Caution: Runtime versions, rights and connection: align the runtime deployed on workstations and servers with the generation used to design the .rpt (a mismatch can prevent display or distort rendering); never hard-code database credentials — supply the connection in code with rights limited to strict need (read-only access to only the needed data); pass parameters according to the logged-in user's context so that no department sees another department's data. Test display, printing and export on a target workstation before rolling out.

✓ Best practices

  • A designer can create excellent .rpt files without knowing how to code.
  • Agree on parameters and source (the interface between both roles).
  • An .rpt often changes without touching the application code.

✗ Common pitfalls

  • Forgetting to deploy the runtime (reports do not display).
  • Hard-coding database credentials (security).
  • Believing that integrating a report requires no development skills.

Key takeaways

  • APPLICATION INTEGRATION embeds Crystal reports in APPLICATIONS: the user consumes statements (“Print invoice”) without opening the designer. An integrated statement engine.
  • CRYSTAL REPORTS FOR VISUAL STUDIO (free) = the .NET path: load the .rpt, a CrystalReportViewer, supply CONNECTION and PARAMETERS in code, display. Java SDK and SAP BusinessObjects also exist.
  • The designer creates the .rpt; the DEVELOPER integrates it — a collaboration. Dev side: connection (credentials not hard-coded), parameters, export in code (PDF, email).
  • Do not forget deploying the RUNTIME on workstations/servers. Integration requires DEVELOPMENT skills — developer work, not statement-designer work.

48h challenge — apply tomorrow

Fill in the integration contract sheet (template above) for 1 real report: are the parameters, the in-code connection and the deployed runtime in it?

Section exit checklist
  • I can describe the .rpt journey to the application screen.
  • My designer-developer parameter contract is written.
  • I know why the runtime is essential on workstations.
Self-rating 1-5: is role-sharing clear for my report?are connection, parameters and runtime all planned?

Frequently asked questions

How does a report designed in the designer end up in a business application?

Through collaboration between two roles. The DESIGNER creates the report in the designer (layout, fields, formulas, groups, parameters) and saves an .RPT file — without writing code. The DEVELOPER integrates it into the application via the SDK (e.g. Crystal Reports for Visual Studio, free, for .NET): they place a CrystalReportViewer, load the .rpt in code, supply the DATABASE connection (credentials, without hard-coding them), pass PARAMETERS (e.g. the invoice ID), and bind the report to the viewer — which displays it with printing/export. Concretely, a “Print invoice” button runs this code: it loads invoice.rpt, passes the ID as a parameter, fetches data, displays/prints. The user consumes the report without opening the designer. Do not forget to DEPLOY the Crystal runtime on target machines.

Do you need to be a developer to integrate reports, and how are roles shared?

To DESIGN reports (create .rpt files) → NO: the designer is visual, accessible to business profiles, even for complex statements; it is a job distinct from development. To INTEGRATE reports into an application → YES: viewer, in-code connection, parameters, runtime deployment require developer skills. Collaboration: the designer creates/maintains .rpt files (business logic, presentation, parameters) and can change them without touching code (statements evolve without redevelopment); the developer integrates .rpt files (loading, connection, parameters, deployment). The interface between them: the .rpt file and the parameter contract. Designing statements is therefore an autonomous, valued skill.

Check your understanding

What must be installed on workstations for an application to display Crystal reports?

Additional resources (optional, to go further)

Level 5 examFresh, harder questions to test what you've learned