Telerik blogs

This post introduces an infographic that explores what are the possible options for a developer to implement reporting functionality into their web or desktop applications. This decision can impact team productivity and the application quality, among other factors.

We put into the spotlight the two most common ways to solve the need for reporting capabilities into your application: Building a reporting functionality in-house or buying a third-party embedded reporting solution. We will explore the multiple questions you need to ask yourself while following the road and the possible answers to those questions.

Best ways to visualize reporting data within Desktop & Web apps

For convenience, here is the full text of the infographic.

What’s the Best and Easiest Way to Embed Data Reporting into My Application?

…and enable my end-users to create ad-hoc visuals on their own.

This infographic explores what are the possible options for a developer to implement reporting functionality into their Web or Desktop applications. This decision can impact the productivity of the team and the application quality. Read on for more.

We put in the spotlight the two most common ways to solve the need for reporting capabilities into your application: Building a reporting functionality in-house on your own or buying a third-party embedded reporting solution.

Below, the two paths will be represented with either “build” or “buy,” as shorthand for these options:

Build: I’ll build Desktop and Web Reporting tools including Report Viewer from scratch. It shouldn’t be that complicated.

Buy: I’ll explore other options and buy a turn-key embedded reporting solution.

I’ll need to decide which UI technology I’ll support with my reporting solution

Build: I’ll build it with a control suite matching the UI technology of my current project.

Buy: I’ll choose a mature embedded reporting solution that supports multiple UI technologies and comes with a dedicated report viewer control for each framework to embed the reporting functionality into my app. That way, my choice would be future-proof for my next projects as well.

I’ll need to dedicate time and people resources to implement reporting functionality in my app

Build: I’ll start from scratch preparing a specification and dedicate a development team to implement and maintain the desired functionality.

Buy: I’ll step on the prebuilt and maintained mature product and assign one or two developers to become familiar with the intuitive design tools for report creation and to embed the solution into our product with the easy-to-use templates and wizards.

I’ll need a great variety of data visuals like different charts, also barcodes, pivot tables, etc.

Build: I’ll need to research, choose and integrate a control suite to support all of these. Building such visuals from scratch is not feasible at all. But still, I’ll have to crunch the data to data-bind those.

Buy: I’ll use the report items that are built specifically for the purpose of presenting data on-screen and for export. And they are designed from day one to bind to the data engine of the reporting solution.

I’ll need to consider what data sources I should support

Build: I’ll need to implement a data layer into my app to feed the visual controls with data. This will require additional development resources.

Buy: The reporting solution of choice would be able to connect and retrieve data from an extensive list of data sources without writing any code. It is part of the report definition, so each visual can easily retrieve data from different sources.

I’ll need to design, arrange and data-bind my visuals to concrete reports

Build: I’ll use an editor suitable for my UI technology of choice to add the chosen visuals for each report needed. Then I’ll arrange them using numbers. Then I’ll data-bind them using code. Most probably, it will all happen in a text editor. 🙁

Buy: I’ll use the visual designer tools coming with each mature reporting solution to drag-and-drop my visuals of choice, lay them out in a visually-pleasing manner and data-bind them using dedicated editors and tools.

I’ll need to style my visualizations to be appealing and easy to understand for my end-users

Build: I’ll use the stylization tools for my chosen UI technology and control suite.

Buy: I’ll use the reporting solution styling mechanism that would be applied to my visuals no matter the UI technology that I’ll embed it into (build once, deploy everywhere FTW).

I’ll need to support paginated printing with on-screen preview to handle my company’s document flow precisely

Build: I’ll need a complex pagination algorithm so that the content gets split into pages without cutting off or losing content. I’ll also need a complex UI control to navigate between pages for on-screen preview. Oh, lastly, I’ll need to implement the actual printing to a device.

Buy: I’ll use the already available core functionality of the reporting tool. These tools have sophisticated pagination algorithms that split the content precisely without losing data or cutting off content in an unreadable manner. The report viewers for each UI technology support navigation between the report pages for on-screen preview and the actual printing of the report document.

I’ll need flexibility to store and share the report documents in various formats, e.g., PDF

Build: I’ll need to research the desired formats’ specification and implement export functionality for each one of them. This will cost enormous development resources because document formats are extensive and complex to replicate.

Buy: Exporting to various formats is a core capability of all turn-key reporting solutions. I’ll have that implemented with a click of a button.

What if I also need my app to conform to accessibility standards?

Build: Yes, I know. I’ll need to implement that as well. I’ll go through the accessibility standards’ specifications and consider what to be supported and how. Then developers should incorporate accessibility into the app and update features regularly as new criteria are added to the guidelines.

Buy: I’ll choose a reporting solution that already cares about accessibility. It will come with built-in keyboard navigation and screen reader support not only for web, but also for desktop UI technologies. The report content will be narrated when previewed. Even export formats like PDF that already support accessibility would be enhanced.

It would be great to empower my end-users to author their own ad-hoc reports

Build: Well, that would be hard. Basically, my users should become developers and be able to add and configure visualization controls. My other option would be to invest enormous amounts of time and effort to develop a complete visual designer tool.

Buy: I’ll carefully choose a reporting solution that offers visual report designer tools that can be embedded right into my web application. That way, I’ll enable my end-users to create complete reports using drag-and-drop functionality within a dedicated and easy-to-use tool.

How will I handle scenarios that require customizations based on data or user action?

Build: That’s my code. I can do it. I just need more development time.

Buy: Mature solutions offer a plethora of extensibility options like:

  • Bindings and conditional formatting to change behavior and style based on data
  • User functions and custom aggregates to introduce custom calculations
  • Ability to use my domain-specific business objects as a report data source
  • Client-side events and interactivity hooks to trigger application logic
  • Report events as a last resort while the content is being generated
  • And all this is transferrable knowledge for my next report

How will I store and distribute the various report views? And I want my end-users to have granular access to different reports.

Build: My report views would most probably be part of my app. If I need to update those without deploying a new version of the app, I’ll need to figure out some other meta-data format to store and dynamically generate the report views at runtime. That way, I could store my report views in a database, for example, then implement access control functionality on my own, so that a particular user can access different report views. I might also implement scheduling functionality to distribute those report documents on a regular basis to subscribed users. Looks complicated.

Buy: Most reporting solutions come with declarative format, containing a report definition that can easily be stored in the file system or a database. On the other hand, I might hire a ready-to-use Report Server solution. It will come with report storage including full versioning of each report definition. It also has granular access control over single users and user groups providing access to a single report or a whole category of reports. It also offers visual tools to set up a report document delivery with granular control of the schedule and a list of users to receive those. Those deliveries might be smart and only be triggered if a data condition is met.

OK, now I know what functionality I must have and what is good to have. What now?

I’ll need to optimize time and spending

Build: The development team will have to dig deeper to find the best way to implement the reporting they built and start executing.

Buy: I’ll have great resources like a Getting Started guide and product documentation as part of the deal. I’ll also have SDKs and online demos to simplify the development process by at least 40%.

What if I hit a technological roadblock?

Build: I’ll search the net. I’ll have to deal with it.

Buy: I can count on a dedicated support service, which, again, is part of the deal. I’m covered by the developer professionals who build and maintain the product.

I did it! The feeling is great! Now I need to make sure it’s sustainable.

Build: I’ll surely dedicate time and people. Web browsers evolve constantly. Security and optimization are top priorities for me. Also, researching new frameworks and adapting my reporting solution to them sounds like days of fun!

Buy: Major updates and maintenance come with my solution of choice. A dedicated team researches the market plus potential issues and offloads this from my responsibilities. On top of that, when a new UI technology emerges and matures, the product will provide embedding capability for it so that I am covered for my future projects, out of the box.

Ok, let’s now consider the final cost

Build: It’s fairly simple, I guess. My bill will be calculated by the per-hour wage of the dedicated team multiplied by the project estimate. And I have to also account for UX design, testing, learning all those new concepts like the rendering formats, pagination, accessibility. Let’s not forget documentation writing and maintenance. And a lot of pizza!

Buy: Commercial solutions cost money. Still, I should consider what part of an in-house reporting solution I could build for the price of a market-ready one. Also, if the vendor is an established developer tools provider, I should consider the even greater value-for-money offer if I go with a product bundle.

Whichever path I choose, it should be fun!

Build: I believe that my team and I will discover and learn lots of new stuff in the process. We’ll become better at our jobs along the way. This should be fun! At least until we need to implement the content paging algorithm, which should factor in countless dimensions, items interdependencies and paging behavior settings all at once.

Buy: I have the power of choice. I can pick whatever phone works for me and I enjoy the most. I’d never think of building one on my own. 😊 Same here. If I don’t try at least two of those solutions, I might miss a lot of opportunities and fun!

Looking for a Mature Embedded .NET Reporting Solution?

Progress Telerik Reporting is a complete, easy-to-use and powerful .NET embedded reporting solution for web and desktop applications that supports Blazor, ASP.NET Core, ASP.NET MVC, ASP.NET AJAX, HTML5/JS, Angular, React, WinUI, WPF and WinForms. Telerik Reporting allows you to create, style, view and export rich, interactive and reusable reports to attractively present analytical and any business data. Add reports to any business application through report viewer controls. Export the ready reports to more than 15 formats. Available for purchase individually or as a part of the Telerik DevCraft bundle.

If you still haven’t tried it, you can start a free trial to take a closer look. It comes complete with industry-leading technical support, documentation, demos and training resources that will help you along the way.

About the Author

Milen Elkin

Milen Elkin is Product Manager of Telerik Reporting & Telerik Report Server. It’s been a while since he joined the company back in 2007. What drives his work is the belief that handling data should be easy. Besides his work, he likes running and cycling in the city of Sofia and enjoys the countless shapes and shades of green color up in the Bulgarian mountains.

Related Posts


Comments are disabled in preview mode.