15 raisons de choisir Telerik Reporting

Nous célébrons le 15^e anniversaire de Telerik Reporting avec 15 raisons pour lesquelles c'est votre meilleur pari pour une solution de reporting complète, quelle que soit la technologie que vous utilisez.

En 2006, une petite équipe de développement chez Telerik, une jeune entreprise de logiciels, connue principalement pour la création de contrôles ASP.NET, WPF et WinForms de haute qualité, a décidé d'essayer quelque chose de nouveau.

Ils venaient de terminer le composant Chart, écrit pour la suite de contrôles AJAX, et voulait l'inclure dans un produit séparé avec plus d'outils qui permettraient aux utilisateurs de présenter leurs données quel que soit le type d'application .NET sur laquelle ils travaillaient. Telerik a reconnu la demande pour un tel produit dans l'écosystème .NET et a décidé d'agir, alors ses développeurs ont simplement fait ce qu'ils faisaient le mieux : se sont assis et ont commencé à coder.

C'est ainsi qu'est né Telerik Reporting.

La première version. de ce produit a été expédié en novembre 2006. Il a été étiqueté CTP (Community Technology Preview) parce que l'équipe était curieuse de savoir comment ce logiciel s'intégrerait dans la gamme de produits de l'entreprise et comment il serait accepté par sa base d'utilisateurs croissante. Les clients ont manifesté un réel intérêt pour le nouvel ajout à leur ensemble d'outils préféré, et Telerik Reporting a rapidement pris de l'ampleur.

Avance rapide jusqu'à nos jours: Telerik Reporting est sur le marché depuis 15 ans, et depuis long chemin. Le nombre de fonctionnalités ajoutées, de technologies prises en charge et de clients satisfaits augmente chaque année. Nous avons décidé d'organiser une fête d'anniversaire pour notre produit, car nous en sommes fiers et pensons qu'il convient à pratiquement tous les scénarios d'ajout de fonctionnalités de reporting à une application, qu'il s'agisse d'une solution WinForms ancienne mais digne de confiance ou une application Web Blazor de pointe. Et pour ceux d'entre vous qui se demandent encore ce que notre produit a à offrir, voici 15 raisons pour lesquelles vous devriez choisir Telerik Reporting :

1. Moteur de reporting .NET mature

Au cours de ces 15 années de développement, nous n'ajoutons pas seulement de nouvelles fonctionnalités, nous étendons et améliorons celles existantes afin que nos utilisateurs disposent d'un moteur de reporting plus rapide avec une empreinte mémoire plus légère.

Bien que le moteur de reporting a fait ses preuves au fil des années et a prouvé son efficacité, nous savons qu'il y a encore de la place pour des optimisations et nous sommes impatients de travailler dans cette direction. Une telle amélioration a été introduite il y a quelques versions, lorsque des parties du flux de production de documents ont été remaniées, et maintenant elles sont exécutées en parallèle avec la pagination du rapport, accélérant le processus de rendu jusqu'à 30 % pour les rapports multipages.

2. Au rythme des dernières versions de .NET

Le monde .NET évolue rapidement et nous gardons un œil sur les changements introduits avec chaque nouvelle version de .NET. Une fois que nous avons publié le nouvel ensemble d'assemblys Telerik Reporting, compilés avec .NET Standard et .NET Core, nous suivons la cadence de publication des versions .NET.

Notre moteur fonctionne sur toutes les versions .NET actuellement prises en charge et, grâce à capacités multiplateformes de .NET Core et de ses successeurs, nous sommes en mesure de traiter et de rendre nos rapports même sur les plateformes Linux et MacOS. Nous sommes particulièrement fiers d'avoir réussi à introduire la prise en charge de Day Zero pour .NET 5 et .NET 6 Preview .

Notre version R2 2021 comprend des exemples de projets prêts à l'emploi ciblant .NET 6 Preview afin que nos utilisateurs aient la possibilité de le tester avant même sa sortie officielle.

3. Rich Report Viewers Suite

L'ensemble fourni de contrôles et de widgets de la visionneuse de rapports garantit que nos utilisateurs peuvent prévisualiser leurs rapports dans pratiquement n'importe quelle application, même en dehors de l'écosystème .NET. Nous proposons des visionneuses de rapports pour toutes les technologies de présentation utilisées de nos jours.

Pour les utilisateurs qui s'en tiennent aux applications de bureau, nous avons des visionneuses de rapports WinForms et WPF qui offrent une prise en charge complète au moment de la conception dans Visual Studio et fournissent un contrôle programmatique complet. Le développement d'une visionneuse de rapports pour WinUI est également dans nos plans et nous estimons actuellement les efforts pour sa mise en œuvre.

Pour les développeurs Web, nous avons créé la HTML5 Report Viewer—un widget HTML5/JavaScript polyvalent. qui communique avec un service REST de rapport dédié qui fait le gros du travail de rendu du rapport et de renvoi du document produit à la visionneuse.

La visionneuse de rapport HTML5 est la base sur laquelle tout le reste du Web les visionneuses de rapports sont créées. Que vous ayez une application héritée ASP.NET, Angular moderne ou Blazor de pointe, nous avons ce qu'il vous faut – vous trouverez une visionneuse de rapports pour votre cas. Et si nous n'avons pas de visionneuse dédiée pour un type spécifique d'application Web, nous avons probablement un article de documentation qui montre comment l'intégrer – voyez comment c'est fait pour React et VueJS cadres.

4. Expérience de «mise en route» fluide

Nous savons que la création de votre première application de création de rapports peut être difficile. C'est pourquoi nous avons essayé de simplifier au maximum vos étapes initiales. Notre documentation commence par un article étape par étape qui vous guide à travers toutes les étapes de la conception et de l'affichage d'un rapport lié aux données dans une application Web.

Ce didacticiel met également l'accent sur l'utilisation des modèles d'éléments Telerik Reporting Visual Studio comme moyen le plus rapide de démarrer votre application de création de rapports. Les modèles d'élément et de projet sont des packages installés par notre produit dans la bibliothèque de modèles Visual Studio.

Ils vous aident à configurer une application qui utilise Telerik Reporting en quelques secondes à l'aide d'une interface pratique basée sur un assistant. Comme vous pouvez vous y attendre, nous fournissons des modèles d'éléments pour tous les types d'applications et de frameworks pris en charge, ainsi que des modèles de projet pour la création de projets de bibliothèque de rapports ou de service REST de création de rapports.

Notre documentation contient également une riche collection d'articles de base de connaissances et de procédures qui expliquent comment résoudre un problème particulier ou gérer un problème spécifique. De plus, notre produit est livré avec un bel ensemble d'exemples de projets prêts à être exécutés en C # et VB, démontrant comment notre bibliothèque de rapports peut être affichée dans une variété d'applications. Certaines démos sont accessibles en ligne afin que vous puissiez saisir l'idée même sans installer le produit.

Et ce n'est pas tout : les concepteurs de rapports ont des modèles intégrés pour certains scénarios de rapport classiques comme le catalogue de produits, facturez, étiquetez les rapports et offrez la possibilité de créer vos propres modèles.

Toutes ces choses sont sans aucun doute utiles, et, dans nos efforts pour fournir des conseils encore meilleurs aux débutants, nous avons mis en place une vidéothèque—un ensemble de vidéos d'introduction tournées et racontées par des membres de notre équipe, montrant exactement comment effectuer certaines des tâches de reportage les plus fréquentes.

5. Concepteurs de rapports WYSIWYG

Historiquement, le premier concepteur de rapports fourni par Telerik Reporting était le Concepteur de rapports Visual Studioqui est toujours pris en charge et maintenu. Il offre une expérience de conception à grande échelle : une aire de conception pour positionner les éléments du rapport, des fenêtres d'outils pour examiner la hiérarchie des groupes, la structure du rapport et ses sources de données, et deux modes pour prévisualiser le rapport conçu—rendu sous forme d'image ou de balisage HTML . Ce concepteur utilise le sérialiseur CodeDOM de .NET pour stocker le modèle de rapport dans un fichier .cs ou .vb et c'est toujours l'outil de choix pour les utilisateurs qui préfèrent utiliser une approche programmatique dans leurs rapports.

En 2012, nous avons introduit le Standalone Report Designer—une application WPF autonome qui permet aux utilisateurs de créer des rapports à l'aide d'une approche déclarative. Cela signifie que le modèle de rapport ne décrit que la structure des éléments du rapport et définit les règles pour sa liaison de données, son regroupement, son filtrage, son interactivité et toute autre opération prise en charge par le moteur de rapport. La définition du rapport est stockée au format XML, soit brut (fichiers .trdx) soit compressé (fichiers .tdp).

Le Concepteur de rapport autonome réutilise une grande partie du code déjà écrit pour le Concepteur Visual Studio, ce qui augmente la fiabilité et facilite la maintenance du code. Pour rendre le processus de transition d'un concepteur de rapports à l'autre encore plus fluide, nous avons ajouté une option d'importation dans les deux concepteurs afin que chacun puisse ouvrir et convertir une définition de rapport créée avec l'autre concepteur.

Cependant, ces deux concepteurs ont un défaut important : ils ne peuvent pas être intégrés dans une application cliente. C'est pourquoi, en 2019, nous avons livré l'aperçu de notre Web Report Designerun widget JS qui s'exécute dans un navigateur et, à l'instar de la visionneuse de rapports HTML5, utilise un service WebAPI REST dédié pour communiquer avec le backend. Le concepteur de rapports Web est en cours de développement et notre objectif est de le rendre comparable (et même d'aller au-delà) des capacités offertes par les deux autres concepteurs de rapports. Bien entendu, tout en travaillant sur les fonctionnalités de Web Report Designer, nous suivons de près les tendances actuelles. C'est pourquoi notre dernière version inclut un wrapper Blazor qui permet aux utilisateurs d'ajouter des fonctionnalités de conception de rapports dans leurs applications Web Blazor.[19659031]6. Prise en charge d'une variété de sources de données

Que ce soit vos données est stocké sur un serveur MS SQL ou dans un entrepôt de données Oracle, obtenu à partir d'un service Web ou placé dans une collection d'objets métier, nous pourrons le lire et le traiter. En ce qui concerne les bases de données prises en charge, Telerik Reporting est indépendant des bases de données, c'est-à-dire qu'il n'a pas besoin de savoir à quelle base de données vous vous connectez. Il suffit d'avoir un fournisseur de données ADO.NET, ODBC ou OleDB installé.

J'ai expliqué comment fonctionne le processus de récupération des données dans un autre article de blog donc je ne vais pas vous ennuyer avec ces détails maintenant, mais je préfère me concentrer sur la variété d'options pour alimenter le rapport en données. En plus de la source de données polyvalente SQLDataSource, nous fournissons également les composants de source de données EntityFramework, Cube, OpenAccess et OpenEdge, tous conçus pour faciliter votre travail avec les connexions aux bases de données dès la sortie de la boîte. Pour rendre les choses encore meilleures, nous déployons notre produit avec une collection de plus de 20 pilotes ODBC DataDirect pour augmenter encore plus le nombre de bases de données prises en charge.

Dans certains scénarios, les gens ne conservent pas leurs données dans une base de données ou tout simplement ne veulent pas l'exposer directement à une application tierce. Habituellement, dans de tels cas, les données peuvent être livrées via un service Web dédié qui renvoie des objets sérialisés au format JSON. Bien sûr, nous soutenons cela aussi. Notre WebServiceDataSource fournit de nombreuses options pour configurer l'URI de la demande, le type d'authentification et les données renvoyées.

Et pour les cas où les données sont organisées dans certains fichiers locaux, nous avons les sources de données CSV et JSON, très pratiques lorsque vous besoin de concevoir une solution PoC rapide sans configurer le backend de fourniture de données.

Le dernier mais non le moindre est la source de données qui donne le plus de contrôle sur le processus de récupération des données—le composant ObjectDataSource. Il se connecte à une classe créée par l'utilisateur qui expose une méthode renvoyant une implémentation IEnumerable, IListSource ou IDbDataProvider. Au moment de l'exécution, le composant ObjectDataSource instancie la classe en question et appelle sa méthode de récupération de données. L'ensemble de données renvoyé sera affecté à l'élément de données qui utilise la source de données. L'ObjectDataSource est très puissant mais demande un peu plus d'efforts en termes de développement et de configuration. Néanmoins, il s'agit d'une solution parfaite lorsque les données du rapport ne peuvent être récupérées à l'aide d'aucun des autres composants de la source de données.

La plupart des sources de données ont une collection de paramètres – des entités clé-valeur qui peuvent obtenir leurs valeurs à partir des paramètres du rapport et les transmettre au serveur de base de données ou à la méthode d'extraction de données, selon le type de source de données. Ceci est particulièrement utile lorsque les données doivent être découpées côté serveur plutôt que filtrées par le moteur de génération de rapports, minimisant ainsi la charge sur le serveur de base de données et augmentant les performances de génération de rapports.

7. Ensemble complet d'éléments de rapport pour tous les scénarios

Même si vous disposez de concepteurs de rapports pratiques, d'un moteur de traitement de données rapide et d'un rendu multiplateforme, votre solution de création de rapports ne sera pas attrayante pour les utilisateurs si les éléments de rapport fournis manquent de diversité. Nous le savons et nous faisons constamment évoluer notre boîte à outils, en ajoutant de nouveaux éléments qui élargissent la liste des cas d'utilisation couverts.

Nos derniers ajouts sont l'élément Cross-Section, qui permet de dessiner des primitives graphiques d'une section de rapport à une autre, et Code à barres SwissQR – une implémentation spéciale du code QR utilisé dans les opérations de paiement en Suisse. Pour le cas classique de présentation d'informations textuelles, nous avons Tableau, Tableau croisé et Liste ; notre élément Graph peut créer un grand nombre de graphiques différents ; pour la représentation géospatiale, nous fournissons des éléments de carte et de choroplèthe, etc.

Cependant, l'une des capacités les plus puissantes de Telerik Reporting est la polyvalence de ses éléments – ils peuvent être utilisés dans de nombreuses configurations différentes, produisant des résultats extraordinaires. Un bon exemple est le graphique sparkline — c'est juste un graphique sans axes ni étiquettes visibles, imbriqué dans une cellule de tableau, mais il a certainement l'air sympa :

D'autres exemples de cette polyvalence sont le widget d'évaluation créé à l'aide d'un élément de tableau croisé:

Et un élément graphique configuré pour afficher un comparateur :

Et le meilleur de tous, dans presque tous les cas, il n'est pas nécessaire d'écrire du code pour cela—toutes les propriétés des éléments de rapport peuvent être contrôlées dans les concepteurs de rapports. Les exceptions à cette règle sont les éléments de forme personnalisés ou certaines des équations graphiques définies par l'utilisateurqui nécessitent un peu de programmation. Bien entendu, le codage de la définition de l'élément est entièrement approuvé, ce qui confirme simplement l'extensibilité de l'ensemble d'outils Telerik Reporting.

8. Plein de fonctionnalités de style et d'interactivité

Je pense que nous sommes tous d'accord pour dire que la vie est trop courte pour regarder des choses laides et que, d'une certaine manière, s'applique également au style de rapport. Nous voulons vous permettre de créer de beaux rapports et, pour cela, le style à grain fin est la clé.

Chaque élément de rapport possède une ou plusieurs propriétés de style qui permettent de configurer son apparence dans les moindres détails. Nous avons implémenté un héritage de style de type CSS où le style d'un élément parent est propagé à tous ses enfants. Nous avons également feuilles de style – un mécanisme puissant mais souvent sous-estimé de déclaration des sélecteurs qui permettent de définir le style du groupe d'éléments de rapport en fonction de leur type, d'un attribut ou de leur position dans le rapport hiérarchie.

Presque toutes les propriétés de style sont associées aux propriétés ConditionalFormatting—un ensemble de règles qui définissent comment un style particulier sera modifié en fonction du résultat d'une expression. Cela nous permet, par exemple, de masquer une zone de texte en fonction de sa valeur ou de peindre la colonne la plus haute d'un graphique à colonnes dans une couleur spécifique.

Outre le style, la possibilité d'interagir avec les données prévisualisées est la prochaine fonctionnalité qui peut faire un rapport pour se démarquer. Nous donnons à l'auteur du rapport le contrôle du flux de travail, lui permettant de décider quelles données seront affichées (à l'aide des paramètres de rapport), comment la mise en page du rapport peut être modifiée de manière dynamique (via le ToggleVisibility and Sorting actions), à quoi ressemblera le chemin de navigation (avec les actions NavigateToReport et NavigateToUrl) et quelles informations supplémentaires afficher dans les info-bulles.

Et si cela ne suffit pas, nous avons également une action personnalisée qui peut accepter pratiquement n'importe quel ensemble de paramètres et l'envoyer au visualiseur de rapports. Les visualiseurs de rapports fournissent quelques gestionnaires d'événements qui peuvent être utilisés pour traiter chaque action interactive et modifier son comportement, comme le montre cet article de la base de connaissances.

9. Fast In-Memory Data Engine

La partie traitement des données du cycle de vie du rapport est assez intéressante, et j'aimerais vous en dire plus à ce sujet, mais j'ai promis de faire court, alors voici la conclusion : quand un un élément de données particulier (tableau croisé, graphique, le rapport lui-même, etc.) doit être lié aux données, le moteur crée l'ensemble de données dit multidimensionnel. Cet ensemble de données est une représentation hiérarchique complexe d'objets de données, créés à la volée et stockés en mémoire. Sa structure est définie par les expressions de regroupement, de tri et de filtrage utilisées dans le rapport.

Chaque fois qu'un élément de rapport doit afficher, comparer ou simplement accéder à une valeur de sa source de données, c'est l'ensemble de données multidimensionnel qui fait tout le travail. Et comme il s'agit d'une structure de données hautement optimisée conservée en mémoire, ses performances sont incroyablement rapides. Au cas où vous voudriez en savoir plus, ce blog explique le sujet de manière plus détaillée.

10. Contrôle programmatique étendu sur le cycle de vie du rapport

Le cycle de vie d'un rapport peut être grossièrement divisé en trois phases : a) création de la définition du rapport, b) liaison aux données et traitement de cette définition, c) génération de pages et rendu du document de sortie. Chacune de ces phases peut être contrôlée par programme dans une certaine mesure.

Toutes les classes et interfaces utilisées dans la définition du rapport sont publiques, ce qui signifie que vous pouvez créer vos rapports par code, quelle que soit leur complexité (mais s'il vous plaît ne faites pas ça, nous avons trois concepteurs de rapports à votre disposition). La modification de la définition du rapport doit être effectuée le plus tôt possible dans le cycle de vie du rapport et est particulièrement pratique lorsque les rapports doivent être modifiés en raison de circonstances qui ne peuvent pas être définies dans le modèle lui-même.

Dans la phase suivante, le Le moteur liera le rapport aux données et commencera à traiter la hiérarchie du rapport. Au cours de cette étape, il déclenchera un certain nombre d'événements pouvant être contrôlés via des gestionnaires d'événements dédiés tels que NeedsDataSourceItemDataBinding et ItemDataBound.

Cependant, le fonctionnement avec ces gestionnaires doit être fait avec soin, car le rapport résultant peut ne pas être rendu correctement. En règle générale, ce n'est presque jamais une bonne idée de modifier la définition du rapport dans un tel gestionnaire d'événements, et nous avons même désactivé cette option il y a quelques versions (elle peut toujours être activée via un paramètre de configuration, cependant). En fait, pour un grand pourcentage de scénarios de rapports courants, il ne devrait pas être nécessaire de gérer ces événements et d'écrire du code personnalisé – les règles de mise en forme et de liaison conditionnelles feront le travail la plupart du temps.

Dans la dernière phase, les utilisateurs peut configurer le processus de rendu via une collection de paramètres nommée deviceInfo qui contient des paramètres spécifiques au format actuel du document. Nous avons également fourni un moyen d'implémenter votre propre extension de rendu, ce qui signifie que vous pouvez étendre Telerik Reporting pour rendre le document de sortie exactement comme vous le souhaitez et ainsi s'adapter à un scénario très spécifique.

En plus de fournir un contrôle programmatique détaillé, nous avons s'est toujours efforcé de rendre le codage global aussi minimal que possible. L'extrait de code suivant le prouve : une seule ligne de code est nécessaire pour que votre rapport soit rendu au format PDF et enregistré dans un fichier sur votre ordinateur :

File.WriteAllBytes("awesome.pdf",
     nouveau ReportProcessor()
         .RenderReport(
             "PDF",
             nouveau UriReportSource () {Uri = "awesome.trdp"},
             new Hashtable() { { "ComplianceLevel", "PDF/A-1b" } })
         .DocumentBytes);

11. Variété d'options d'exportation dans plus de 15 formats

La fonctionnalité d'exportation de Telerik Reporting est essentiellement une commande vers une extension de rendu spécifique pour rendre une définition de rapport dans un format spécifique à l'appareil. Les visionneuses de rapports utilisent ces extensions de rendu pour afficher le contenu du rapport à la fois en mode interactif et aperçu avant impression.

Les autres formats d'exportation sont accessibles via le menu Exporter dans les visionneuses ou simplement appelés par leur nom, comme indiqué dans l'extrait de code ci-dessus. . Nous prenons en charge les formats de documents les plus populaires utilisés dans des applications telles que Adobe PDF, MS Word, MS Excel et MS PowerPoint. Avec eux, nous pouvons exporter dans certains formats moins connus mais importants comme Image (l'image produite peut être TIFF, JPEG, PNG ou BMP), MHTML, XPS, CSV et RTF.

Outre la variété des formats d'exportation, c'est à noter que le moteur de rendu essaiera toujours d'utiliser les primitives natives du format lors de la création du document de sortie. Par exemple, lorsque nous prévisualisons un rapport dans une visionneuse de rapports basée sur HTML5, nous examinons en fait la sortie produite par l'extension de rendu HTML5Interactive. Il crée un balisage HTML et déclare des styles CSS afin que le document produit ressemble le plus possible à la mise en page conçue.

En fait, toutes les extensions de rendu font la même chose : elles parcourent essentiellement les éléments de rapport créés pendant la phase de traitement et écrivent primitives natives dans le flux de documents de sortie. La seule exclusion est l'extension de rendu CSV, qui est conçue pour exporter les données plutôt que d'imiter la mise en page du rapport. Il produit une représentation aplatie des données du rapport, traversant les hiérarchies de groupe sans respecter le style, la visibilité ou l'emplacement des éléments.

Chaque extension de rendu possède son propre ensemble de propriétés exposées qui peuvent être configurées via une collection spéciale de valeurs-clés. paires appelées deviceInfo. Les options prises en charge sont répertoriées dans l'article de documentation correspondant pour chaque extension de rendu et l'objet deviceInfo peut être transmis de trois manières : a) via le fichier de configuration de l'application, b) par programmation à l'aide d'une instance HashTable, c) défini directement dans les RuntimeSettings de la définition du rapport propriété. Le dernier a été ajouté récemment dans notre version R2 2021 et confirme encore une fois que nous aimons encore améliorer les choses et ne nous contentons pas de la première solution qui fonctionne.

12. Conformité aux normes d'accessibilité

Lorsque votre entreprise a besoin d'atteindre un public plus large, il est crucial de produire des documents accessibles au plus grand nombre d'utilisateurs possible. Cela inclut les personnes ayant des restrictions de contrôle moteur qui ne peuvent pas utiliser une souris d'ordinateur et celles qui ont besoin d'un logiciel de lecture d'écran spécialisé pour interpréter le contenu d'un document particulier.

Nous avons traité ces cas d'utilisation dans notre logiciel et nos visionneuses de rapports. et les rapports produits sont conformes aux normes d'accessibilité définies dans la section 508 de la loi sur la réadaptation et dans les directives pour l'accessibilité des contenus Web (WCAG) 2.0.

Le mode accessible peut être activé ou désactivé via une option de visionneuse de rapports ou via un deviceInfo clé. Par conséquent, les visualiseurs de rapports permettent une navigation complète au clavier dans les deux zones du visualiseur de rapports et dans le contenu du rapport. De plus, le rapport produit est rendu d'une manière qui inclut des métadonnées explicatives pour tous ses éléments, fournissant à l'utilisateur des détails complets sur l'élément de rapport actuellement ciblé. Les métadonnées d'accessibilité sont également incluses dans les fichiers PDF produits, ce qui rend ce support adapté aux personnes qui ont besoin de telles technologies d'assistance.

Si vous souhaitez en savoir plus, voici un article de blog qui donne des informations plus détaillées sur la prise en charge de l'accessibilité dans notre produit.

13. Gestion des rapports avec Telerik Report Server

Telerik Report Server est une solution clé en main qui offre des fonctionnalités de gestion des rapports ainsi que des fonctionnalités métier. Il s'agit d'une application Web autonome qui utilise un stockage externe pour conserver ses actifs : révisions de rapports, documents rendus et différentes entités spécifiques à l'application. Un service dédié permet aux utilisateurs de configurer la livraison automatique de rapports à intervalles planifiés ou en fonction de règles liées aux données. L'application dispose également d'un système intégré précis de rôles et d'autorisations d'utilisateurs qui déterminent les niveaux d'accès à l'application.

Telerik Report Server peut être intégré de manière transparente dans les applications Web de l'organisation. Son implémentation d'authentification unique prend en charge deux types d'authentification: basée sur ADFS et une personnalisée. L'apparence de l'application peut être configurée via ses options Whitelabeling qui s'appliquent à la fois à l'interface utilisateur de l'application Web et à l'interface utilisateur du concepteur de rapports autonome utilisé pour concevoir les définitions de rapport.

des Telerik Report Server qui préfèrent avoir un contrôle programmatique sur leur application plutôt que d'utiliser une application Web peuvent utiliser l'API étendue qui permet de gérer toutes les ressources de Report Server. Nous fournissons une bibliothèque de rapports dédiée nommée Report Server API Client qui facilite les tâches liées à l'API.

Le package d'installation est également fourni avec des exemples de SDK qui montrent des exemples d'implémentation de Single-Sign-On et des scénarios simples de en utilisant le client API pour lire, ajouter et modifier des actifs dans le stockage du serveur de rapports. Une fonctionnalité particulièrement intéressante est les rappels Webhooks qui permettent à une application tierce d'être notifiée lorsque Report Server exécute une certaine tâche, par exemple, lorsqu'il ajoute une nouvelle révision de rapport ou planifie une tâche à exécuter.

14. Support technique inégalé

Nous comprenons que Telerik Reporting et Telerik Report Server sont des produits avec de nombreuses fonctionnalités et de nombreux scénarios possibles pour leur utilisation. Il est naturel que nos utilisateurs aient besoin d'assistance lorsqu'un cas d'utilisation particulier ne correspond pas à ceux déjà traités dans la documentation et les articles de la base de connaissances.

Notre équipe d'assistance compétente peut répondre aux questions les plus difficiles des utilisateurs et peut déboguer et dépanner la plupart des types de projets qui utiliser Telerik Reporting. Habituellement, la réponse est une explication détaillée de la raison pour laquelle le moteur de génération de rapports se comporte de manière spécifique, ainsi qu'une suggestion sur la manière de l'adapter au scénario actuel. En fonction du problème, l'ingénieur du support peut même filmer une vidéo explicative dédiée au cas de l'utilisateur. Et lorsque les ingénieurs du support ne sont pas sûrs de fournir la meilleure réponse à la question d'un client, ils confirment leur réponse avec un membre de l'équipe de développement.

Le développeur examinera en profondeur le problème du client et, si suffisamment de données sont fournies, décider de le déboguer par rapport à la base de code du produit réel pour confirmer un éventuel bogue. Dans certains cas isolés, l'enquête peut prendre plus de temps que prévu, mais dans tous les cas, le client reçoit une réponse en temps opportun et est au courant des prochaines étapes que l'équipe prendra pour résoudre le problème.

Au cas où la racine serait la cause. du problème reste incertain et la licence du client le permet, nous pouvons suggérer de tenir une session d'assistance Web à distance au cours de laquelle un ou plusieurs développeurs et ingénieurs de support examineront le problème sur la machine du client et essaieront de déterminer la meilleure façon de le résoudre. Si le problème est le résultat d'un bogue que nous avons introduit dans notre code source, nous l'enregistrons dans notre portail public au nom du client et le planifions dans notre backlog. L'enregistrer publiquement permet au client qui l'a signalé d'être automatiquement informé de toute progression de ce problème. Si le problème n'a pas encore été signalé, l'utilisateur reçoit des points Telerik en guise de remerciement pour avoir trouvé un bogue dans notre produit et ainsi contribuer à son amélioration.

Nous prenons les questions des clients très au sérieux et examinons chaque problème avec soin pour fournir un meilleur service d'assistance à nos clients.

15. Les votes des utilisateurs comptent pour le développement de nos produits

Corriger un bogue dans notre code, c'est bien, mais développer de toutes nouvelles fonctionnalités est toujours génial. Nous avons beaucoup d'idées pour étendre les fonctionnalités du produit, et nous devons les prioriser correctement afin que les nouveaux ajouts répondent aux besoins du plus grand nombre de clients.

Pour déterminer leur commande, nous utilisons le portail public mentionné avec les chefs de projet. « recherche sur les sujets. Dans ce document, nous et les clients enregistrons les améliorations et les idées de produits qui pousseront notre produit encore plus loin. Parfois, une fonctionnalité particulière nécessite beaucoup d'efforts, mais son impact ne sera pas aussi important que certains des autres ajouts suggérés. C'est pourquoi nous prenons en compte le vote de la communauté lorsque nous décidons de ce sur quoi nous devrions nous concentrer ensuite.

Nous gardons toujours un œil sur les sujets les plus votés et en discutons lors de nos réunions de planification. Les fonctionnalités qui ajouteraient de la valeur à notre produit et qui peuvent être mises en œuvre dans un délai raisonnable sont envisagées pour une mise en œuvre pour une version ultérieure.

Bien sûr, cela ne signifie pas qu'une fonctionnalité importante qui a moins de votes n'y parviendra jamais. En cours de développement : s'il est lié à un bogue ou s'il s'aligne mieux sur nos plans de développement, nous programmerons sa mise en œuvre avant ceux avec plus de votes.

En d'autres termes, si vous pensez que Telerik Reporting est manquant une fonctionnalité importante, nous vous encourageons fortement à parcourir le portail de commentaires et à voter pour la fonctionnalité si elle est déjà enregistrée. Si ce n'est pas le cas, veuillez prendre quelques minutes pour créer un nouvel élément de rétroaction et laisser la communauté voter pour celui-ci. De cette façon, votre voix est entendue et peut affecter directement le développement du produit, et nous serons extrêmement reconnaissants de nous aider à améliorer Telerik Reporting à chaque version.

En conclusion

Dans cet article étonnamment long, j'ai énuméré les Les 15 principales raisons pour lesquelles Telerik Reporting serait votre meilleur choix pour une solution de reporting, quelle que soit la technologie utilisée. J'espère avoir réussi à vous donner suffisamment d'informations sur chaque sujet, et je serais heureux d'avoir une discussion sur l'un d'entre eux, alors partagez vos réflexions dans les commentaires ci-dessous.