If this question is deemed inappropriate because it does not have a specific code question and is more "am I barking up the right tree," please advise me on a better venue.
If not, I'm a full stack .NET Web developer with no SSRS experience and my only knowledge comes from the last 3 sleepless nights. The app my team is working on requires end users to be able to create as many custom dashboards as they would like by creating instances of a dozen or so predefined widget types. Some widgets are as simple as a chart or table, and the user configures the widget to display a subset of possible fields selected from a larger set. We have a few widgets that are composites. The Web client is all angular and consumes a restful Web api.
There are two more requirements, that a reasonable facsimile of each widget can be downloaded as a PDF report upon request or at scheduled times. There are several solutions to this requirement, so I am not looking for alternate solutions. If SSRS would work, it would save us from having to build a scheduler and either find a way to leverage the existing angular templates or to create views based off of them, populate them and convert that to a pdf. What I am looking for is he'll in understanding how report generation best practices and how they interact witg .NET assemblies.
My specfic task is to investige if SSRS can create a report based on a composite widget and either download it as a PDF or schedule it as one, and if so create a POC based on a composite widget that contains 2 line graphs and a table. The PDF versions do not need to be displayed the same way as the UI where the graphs are on the same row and the table is below. I can show each graph on its' own as long as the display order is in reading order. ( left to right, then down to the next line)
An example case could be that the first graph shows the sales of x-boxes over the course of last year. The line graph next to it shows the number of new releases for the X-Box over the course of last year. The report in the table below shows the number of X-box accessories sold last year grouped by accessory type (controller, headset, etc,) and by month, ordered by the total sales amount per month.
The example above would take 3 queries. The queries are unique to that users specific instance of that widget on that specific dashboard. The user can group, choose sort columns and anything else that is applicable.
How these queries are created is not my task (at least not yet.) So there is an assumption that a magic query engine creates and stores these sql queries correctly in the database.
My target database is sql 2012 and its' reporting service. I'm disappointed it only supports the 2.0 clr.
OI have the rough outline of a plan, but given my lack of experience any help with this would be appreciated.
It appears I can use the Soap service for scheduling and management. That's straight forward.
The rest of my plan sounds pretty crazy. Any corrections, guidance and better suggestions would be welcome. Or maybe a different methodology. The report server is a big security hole, and if I can accomplish the requirements by only referencing the reporting names paces please point me in the right direction. If not, this is the process I have cobbled together after 3 days of research and a few msdn simple tutorials. Here goes:
To successfully create the report definition, I will need to reference every possible field in the entire superset available. It isn't clear yet if the superset for a table is the same as the superset for a graph , but for this POC I will assume they are. This way, I will only need a single stored procedure with an input parameter that identifies the correct query, which I will select and execute. The result set will be a small subset of the possible fields, but the stored procedure will return every field, with nulls for each row of the omitted fields so that the report knows about every field. Terrible. I will probably be returning 5 columns with data and 500 full of nulls. There has to be a better way. Thinking about the performance hit is making me queasy, but that was pretty easy. Now I have a deployable report. I have no idea how I would handle summaries. Would they be additional queries that I would just append to the result set? Maybe the magic query engine knows.
Now for some additional ugliness. I have to request the report url with a query string that identifies the correct query. I am guessing I can also set the scheduler up with the correct parameter. But man do I have issues. I could call the url using httpWebRequest for my download, but how exactly does the scheduler work? I would imagine it would create the report in a similar fashion, and I should be able to tell it in what format to render. But for the download I would be streaming html. How would I tell the report server to convert it to a pdf and then stream it as such? Can that be set in the reports definition before deploying it? It has no problem with the conversion when I play around on the report server. But at least I've found a way to secure the report server by accessing it through the Web api.
Then there is the issue of cleaning up the null columns. There are extension points, such as data processing extensions. I think these are almost analogous to a step in the Web page life cycle but not sure exactly or else they would be called events. I would need to find the right one so that I can remove the null data column or labels on a pie chart at null percent, if that doesn't break the report. And I need to do it while it is still rdl. And just maybe if I still haven't found a way, transform the rdl to a pdf and change the content type. It appears I can add .net assemblies at the extension points. But is any of this correct? I am thinking like a developer, not like a seasoned SSRS pro. I'm trying, but any help pushing me in the right direction would be greatly appreciated.
I had tried revising that question a dozen times before asking, and it still seems unintelligible. Maybe my own answer will make my own question clear, and hopefully save someone else having to go through what I did, or at least be a quick dive into SSRS from a developer standpoint.
Creating a typical SSRS report involves (quick 40,000 foot overview)
1. Creating your data connection
2. Creating a SQL query or Queries which can be parameterized.
3. Datasets that the query result will fill
4. Mapping Dataset columns to Report Items; charts, tables, etc.
Then you build the report and deploy it to your report server, where the report can be requested by url with any SQL parameters Values added as a querystring:
http://reportserver/reportfolder/myreport?param1=data
How this works is that an RDL file (Report Definition Language) which is just an XML document with a specific schema is generated. The RDL has two elements that were relevant to me, and . As the names infer, the first contains the queries and the latter contains the graphs, charts, tables, etc. in the report and the mappings to the columns in the dataset.
When the report is requested, it goes through a processing pipeline on the report server. By implementing Interfaces in the reporting services namespace, one could create .NET assemblies that could transform the RDL at various stages in the pipeline.
Reporting Services also has two reporting API's. One for managing reports, and another for rendering. There is also the reportserver control which is a .NET Webforms control which is pretty rich in functionality and could be used to create and render reports without even needing a report server instance. The report files the control could generate were RDLC files, with the C standing for client.
Armed with all of this knowledge, I found several solution paths, but all of them were not optimal for my purposes and I have moved on to a solution that did not involve reporting services or RDL at all. But these may be of use to someone else.
I could transform the RDL file as it went through the pipeline. Not very performant, as this involved writing to the actual physical file, and then removing the modifications after rendering. I was also using SQL Server 2012, which only supported the 2.0/3.5 framework.
Then there were the services. Using either service, I could retrieve an RDL template as a byte array from my application. I wasn't limited by the CLR version here. With the management server, I could modify the RDL and deploy that to the Report Server. I would only need to modify the RDL once, but given the number of files I would need and having to manage them on the remote server, creating file structures by client/user/Dashboard/ReportWidget looked pretty ugly.
Alternatively, I instead of deploying the RDL templates, why not just store them in the database in byte array format. When I needed a specific instance, I could fetch the RDL template, add my queries and mappings to the template and then pass them to the execution service which would then render them. I could then save the resulting RDL in the database. It would be much easier for me to manage there. But now the report server would be useless, I would need my own services for management and to create subscriptions and to mail them I would need a queue service and an SMTP mailer, removing all the extras I would get from the report server, need to write a ton of custom code, and still be bound by RDL. So I would be creating RDLM, RDL mess.
It was the wrong tool for the job, but it was an interesting exercise, I learned more about Reporting Services from every angle, and was paid for most of that time. Maybe a blog post would be a better venue, but then I would need to go into much greater detail.
Related
I am new to Google App maker and I don't have a lot of experience with coding either (sorry :/). Since App maker is marked as low-coding app builder tool, I assumed it was not that hard to make a very simple app with it. However, for me it is.
I need to make a simple app for demonstrations purposes only (so Cloud SQL and other complex database solutions are not in my interest here). I want to make it using calculated models (correct me if I am wrong, calculated models are just temporary solutions, since apps need to have like real databases to be fully functional?).
My app is basically made of 2 datas: 1) Employees and 2) Departments
-> Fields for "Employees" are: First name, Last name and Department.
-> Field for "Departments" is just Department name.
My app is supposed to look like this:
1st page: Table with current employees that has a button to add new employee,
2st page: Table with all department names (e.g. marketing, finance...) that has a button to add new department name,
3rd page: Form that opens when I click on add new employee button in which I can insert their first name, last name and from drop down menu choose department,
4th page: Form that opens when I click on add new department button in which I can insert new department name.
5th page: Form (or some other widget, not sure here) that has option to insert first and last name in order to find out what department that employee is assigned to.
I tried to make first 4 pages, but I end up with forms that I cannot insert anything into them. 5th page is still too much for me.
I hope you understand my struggles and if you know how to do it please share your knowledge. Thank you very much!
Calculated models are kind of like SQL views - they are not necessarily for temporary solutions. Every time you load a calculated model the script you write under that model's datasource is ran. That script usually loads data from an external source (I.e. grabbing stock prices from an API, loading data from an external SQL server, or generating random placeholder data).
You could use the cloud SQL models for this application that you are building - your table with all department names that is supposed to be displayed in the second page could just be a cloud SQL table with one single field for a department name.
I suggest you work through the example apps so you can get a better understanding of how the different components work. Here is a link to one for you to get started.
In short, you're going to create a few models to store information (I suggest using cloud SQL as the calculated models will require code whereas cloud SQL is more plug and play through app maker's bindings). Before you create any pages try to lay out how your databases will look as that will dictate how you set bindings or program your scripts.
Asking to completely make what is essentially a combination of the tutorials already provided by Google is pretty counter intuitive - you should ask more specific questions in regards to implementation.
As for App Maker being a low-code environment, that's only partially true. For very, very simple apps (think glorified forms) you will need only a couple lines of code and can probably do everything through drag-and-drop. However, anything more complicated than a simple form will almost certainly require a good chunk of actual code. There are plenty of resources online to learn Javascript.
You might want to try a google partner like AppSynergy for building stuff like this. It might be overkil for what you need (or maybe not if you intend to build a lot more stuff).
I have an asp.net based website and I need to create a designed report, so the customer can watch and print.
The report is a collect list, which contains a table and additional data.
What is the best way to create it? Crystal reports? SSRS? Maybe some other tech?
thanks
SSRS is dead easy and really simple to knock up if you have a reasonable SQL understanding.
I work on a very complex account for contract reporting. We have over 132 contract conditions which the customer is able to view our performance at any given point in time for any period of time.
We also have over 100 reports for Operations etc. We do rarely touch them once created in SSRS and deploy them.
I have recently even began goofing around with making reports that the user can customize themselves (eg: Hiding Adding Columns)
SSRS is by far the best scaled solution.
We have a very large HTML form (> 100 fields) that updates a SQL Server database with user-entered data. It will take the user a long time to fill out the form, but every piece of information they submit is very valuable to the business process. Even if the user gives up on the form, we want to retain everything they have entered.
We plan to attach an onblur event to each field and use jQuery/AJAX to post each piece of data back to the application server immediately. That part is pretty straightforward. The question we have is when and how to best save this application-level information to the database. Again, our priority is data retention as opposed to performance but we also want to do this as efficiently as possible.
Options as I see it are:
Have the web service immediately post each piece of data to the database server.
Store the information in a custom class on the application server, then periodically call an update method to post new data to the database.
Store the information in view or session state, then run a routine to post this information to the database server.
Something else that we haven't thought of.
Option 1 seems the most obviously failsafe, but also the most resource intensive. Option 2 seems the most elegant, but can we be absolutely certain that the custom class instance can't be destroyed without first running its update method?
Thanks for your help!
IMHO, I'd really cut up the form into sections (if possible). Since this is ASP.Net, if you are using Web Forms then look into using wizards (cut up the form into logical Steps)
You can do same without Form Wizard, but still cut up the process into logical steps, client-side. You can probably do this in pure JavaScript, but it would likely be easier if you used a framework (jQuery, Knockout, etc.) - the concept remains the same, cut up the form entry process into sections (aka 'Steps') - e.g. using display toggles, divs for each "step", etc.
"retain everything even if abandoned later": assumed that the steps are "hierarchical" where the "most critical" inputs are at the beginning. This makes the "steps" approach even more important - this is a "logical group" (of inputs you really want) so if you do the Step approach, then you can save this data (of this "step") to DB in whatever fashion you deem appropriate (e.g. Ajax, or ASP.Net Post/postback).
Hth...
I would package everything up in some xml or dataset (.getxml) and pass the xml to a stored procedure....
How to pass XML from C# to a stored procedure in SQL Server 2008?
And maybe put the call on a background thread.
http://code.msdn.microsoft.com/CSASPNETBackgroundWorker-dda8d7b6
The xml will be faster than calling the values row by row (RBAR).
You can save just the xml, or shred the xml into a relational table(s).
I need to create a Microsoft BI Produced Report, that will display Actual Data, retrieved from database. But I also want users to be able to fill Forecast Data for next month in the column beside the reported actual data, and the inputted data will be loaded to Forecast Cube.
Is it possible to do it ? What is the right strategy ?
Thanks for your input :) !
MS BI products are based on reporting, so they don't have any direct ways to interact with the data like you're asking. There are several options that start with an SSRS report though (or a PowerPivot book etc.).
SharePoint Workflow - allows a lot of other control aspects to the input process. Pickup the list with an ETL package.
You could also do a similar thing with a simple web app. Link either through a report action.
ETL - Make the report exportable to excel and leave blank columns for user input. Re-absorb it through an ETL process that reads the modified Excel file. This can be a manually triggered job, not necessarily part of a DM/DW nightly ETL.
You could also just have a manual script. I would think and hope that the forecast data isn't changed that often, so a simpler solution would probably be best.
I am planning to build part of an internal dashboard around SSRS reports. I'm using ASP.net (framework 4), SQL Server 2008 R2, IIS6 and have built all my reports already in Report Builder 3.0.
Now it comes to pulling the reports through from the report server to the dashboard using the ReportViewer control. What I would like to do is to hide the SSRS report parameters and provide them myself from code behind, because the SSRS parameter selection controls are ugly (Windows 95 ugly) and don't fit with the look and feel of the site. Also, I have different end-user reports that are in fact the same report with different parameter selections (and I don't want to show these selection controls).
The issue is that all of my reports are VERY heavily parameterised - the business users want reports that are as flexible as pivots (you can imagine the fun I had building these reports). As a result I use a large number of shared datasets to provide the default and available values for each parameter. Since I intend to present these parameters myself in my web application, I need to know:
What the parameters are for each report (name and type)
What the default values should be for each parameter
What the available options should be for each parameter
I am happy to store the names/types of each parameter in a database table, but there would be far too many values to store to do the same with parameters (plus the data is too dynamic). Can anyone think of a solution?
In fact, it is quite easy to retrieve the Default and Available parameter values used in the report:
Once you have set the report source, ServerReport.GetParameters() returns a collection of ReportParameterInfo which, for each parameter, provides the data type, default/available values ("Values"/"Valid Values" respectively, where "Valid Values" are value/label pairs) and other useful attributes like a list of other parameters that depend on it.
So, just save default/available parameters in the report (using Report Builder / Report Manager) and use this to retrieve them in your code behind.
IS this what you're looking for: http://msdn.microsoft.com/en-us/library/ms155391.aspx ? I'm not quite clear what your issue is from your post, what exactly do you need help with in doing what you're trying to do?