I'm developing a web application which processes invoices(the functionality is not limited to invoices, but it doesn't matter). One of the parts of the workflow is to print invoice after it was published. This means that the website user is able to select 10-20(and more) invoices and print it at once. Also there may be several invoice templates which may be customizable(this is one of the key requirements).
I should also mention that we decide to generate PDFs from the html code and then print it. So as the PDF creation process may take some time to complete we decided to use a windows service for invoices printing.
So, summarizing we have the following requirements:
There should be customizable invoice
templates;
The website user should be
able to specify which template he
want to use with the invoice item
specified;
There should be a possibility to
print one or several selected
invoices in one click.
Our first idea was to use user controls as invoice templates. The user control will be responsible for invoice layout. This also means there will be a base class for these user controls through which we will be able to define a data source for the controls.
In this case we may even allow users to modify ascx file (or something similar) to edit basic captions if necessary.
The problem begins in the windows service where we are unable to generate output for user controls. So the other solution is to use http handler or web service to generate user controls output and transfer this to the windows service. But this complicates the solution (e.g. we need to use authentication for this and similar problems).
Maybe there is a much more simpler way to do it?
Thanks in advance.
In response to your comment, I suggest you have the website generate the HTML and save it into a 'GeneratedInvoice' field in your DB, which the service then processes (i.e. converts to PDF however your pdf conversion software does it). It's appropriate because you have a 'saved' copy of the generated invoice; i.e. if your invoice processing routine changes (different styles, etc) your old invoices aren't affected, and yet you can regenerate a given bunch in a possibly 'new' format if required.
Related
Recently, I've add the user agent string when the guests submit the form to the database. There is a report that is generated weekly containing various statistics. I want to add the device and maybe the browser information to the report.
I was pondering that I would create a new database table that would hold all the know user agent strings and have two extra fields, one for the device info, and maybe the browser in the other one. However, I cannot find a site that you can download the strings. Would any one know of a place?
If that can not be done, I was thinking of a .net alternative. How would I go into doing that in .net?
2 ways to do it:
If you are using ASPNET MVC, you could use the default this.Request.Browser within the controller method call (contains quite a lot of info, example here),
You can also use 51Degrees, which has a light and a complete device db to match devices capabilities
Recently, I was troubleshooting an issue related to user settings. There was a requirement to migrate the user settings from one environment to another.
There is an AX 2009 form which users make their own personalisations to, moving some of the fields around, or perhaps adding other fields (via the right click->setup functions) , so that unnecessary fields are hidden.
I have saved that form , so that it is available for me , but when i migrate the form to another environment i notice that the new user don't have any change on the form.
As we all know, User related setups for queries, forms, reports etc are stored in SysLastValue table. This is a system table and can't be accessed directly through AOT.
I think here is what you are trying to achieve:
http://axaptian.blogspot.md/2010/01/savecopy-filtersqueriesinquires-to.html
Basically, it allows to save custom filters and queries and pass it to other users. Although it copies only queries, I am sure it can be modified to copy any usage data.
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.
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 made an access vba application where all my architecting was simply creating a one-to-many relationship between a "status" table and a "data" table that contained all the other details of my record. Created a form with the single click of a button with my "status" table open, and wallah,,, I got a form for my open or closed records that had dropdowns for each field where theres a related table. For activity tracking, I had to make a many-to-many table , and made a one-to-many for the status of those activities and again, clicked the create form and I was in business. To finish things off all I did was integrate a checkbox in my data fields and put buttons on my status forms that act on the record that got checked, and I was done, fast & painlessly, kinda.
Is there any ASP.net code generation of a data control in where I can just structure my MYSQL database, make the relationship and generate code of the RELATED "status" table and get my form w its related subform with text fields & DDL's automatically generated, fast? If not, what would you consider is the next best approach (i.e. using excel for replicating repetitive code)?
Take a look at http://www.asp.net/dynamicdata
As far as I know (having not used it myself) it will do what you need, ie quickly generating data entry pages from an existing sql schema.
Access can actually create .net forms when you use access 2010. (the forms are real xaml or so called zammel forms). The beauty of this system is you get to keep the same point and click approach that allows you to build master forms with child sub-forms. You not have to write one line of code and you not ever see one connection string. Only downside of this great new system called "Access Web Services" is it requires SharePoint (enterprise).
So, this is a true access development for the web, but you continue to use the Access client to build those forms. Those forms scale out to many users since you using xaml forms and SharePoint. Here is a video of this in action:
http://www.youtube.com/watch?v=AU4mH0jPntI
At the half way in above, note how I switch to running the access application 100% in the browser.