A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.
Related
I've been tasked to create (or seek something that is already working) a centralized server with an API that has the ability to return a PDF file passing some data, and the name of the template, it has to be a robust solution, enterprise ready. The goal is as follows:
A series of templates for different company things. (Invoices, Orders, Order Plannings, etc)
A way of returning a PDF from external software (Websites, ERP, etc)
Can be an already ready enterprise solution, but they are pressing for a custom one.
Can be any language, but we don't have any dedicated Java programmers in-house. We are PHP / .NET, some of us dabble, but the learning curve could be a little steep.
So, I've been reading. One way we've thought it may be possible is installing a jasper reports server, and creating the templates in Jaspersoft Studio, then using the API to return the PDF files. A colleague stands for this option, because it's mostly done, but 1º is java and 2º I think it's like using a hammer to crack a nut.
Other option we've been toying with is to use C# with iTextSharp to create a server, and create our own API that returns exactly the PDF with the data we need. Doing this we could have some benefits, like using the database connector we have already made and extracting most of the data from the database, instead of having to pass around a big chunk of data, but as it is bare, it doesn't really have a templating system. We'd have create something from with the XMLWorker or with c# classes but it's not really "easy" as drag and drop. For this case I've been reading about XFA too, but documentation on the iText site is misleading and not clear.
I've been also reading about some other alternatives, like PrinceXML, PDFBox, FOP, etc, but the concept will be the same as iText, we'd have to do it ourselves.
My vote, even if it's more work is to go the route of iText and use HTML / CSS for the templates, but my colleagues claim that the templates should be able to be changed every other week (I doubt it), and be easy. HTML / CSS would be too much work.
So the real question is, how do other business approach this? Did I leave anything out on my search? Is there an easier way to achieve this?
PS: I didn't know if SO would be the correct place for this question, but I'm mostly lost and risking a "too broad question" or "off topic" tag doesn't seem that bad.
EDIT:
Input should be sent with the same request. If we decide the C# route, we can get ~70% of the data from the ERP directly, but anyway, it should accept a post request with some data (template, and data needed for that template, like an invoice data, or the invoice ID if we have access to the ERP).
Output should be a PDF (not interested in other formats, just PDF).
Templates will be updated only by IT. (Mostly us, the development team).
Performance wise, I don't know how much muscle we'll need, but right now, without any increase, we are looking at ~500/1000 PDFs daily, mostly printed from 10 to 10.30 and from 12 to 13h. Then maybe 100 more the rest of the day.
TOP performance should not be more than ~10000 daily when the planets align, and is sales season (twice a year). That should be our ceiling for the years to come.
The templates have some requirements:
Have repeating blocks (invoice lines, for example).
Have images as background, as watermark and as blocks.
Have to be multi language (translatable, with the same data).
Have some blocks that are only show on a condition.
Blocks dependent on the page (PDF header / page header / page footer / PDF footer)
Template will maybe have to do calculations over some of the data, I don't think we'll ever need this, but it's something in the future may be asked by the company.
The PDFs don't need to be stored, as we have a document management system, maybe in the future we could link them.
Extra data: Right now we are using "Fast-Reports v2 VCL"
Your question shows you've been considering the problem in detail before asking for help so I'm sure SO will be friendly.
Certainly one thing you haven't detailed much in your description is the broader functional requirements. You mentioned cracking a nut with a hammer, but I think you are focused mostly on the technology/interfacing. If you consider your broader requirements for the documents you need to create, the variables involved, it's might be a bigger nut that you think.
The approach I would suggest is to prototype solutions, assuming you have some room to do so. From your research, pick maybe the best 3 to try which may well include the custom build you have in mind. Put them through some real use-cases end to end - rough as possible but realistic. One or two key documents you need to output should be used across all solutions. Make sure you are covering the most important or most common requirements in terms of:
Input Format(s) - who can/should be updating templates. What is the ideal requirement and what is the minimum requirement?
Output Requirement(s) - who are you delivering to and what formats are essential/desirable
Data Requirement(s) - what are your sources of data and how hard/easy is it to get data from your sources to the reporting system in the format needed?
Template feature(s) - if you are using templates, what features do the templates need? This includes input format(s) but I was mostly thinking of features of the engine like repeating/conditional content, image insertion, table manipulation etc. ie are your invoices, orders and planning documents plain or complex
API requirements - do you have any broader API requirements. You mentioned you use PHP so a PHP library or Web/Web Service is likely to be a good starting point.
Performance - you haven't mentioned any performance characteristics but certainly if you are working at scale (enterprise) it would be worth even rough-measuring the throughput.
iText and Jasper are certainly enterprise grade engines you can rely on. You may wish to look at Docmosis (please note I work for the company) and probably do some searches for PDF libraries that use templates.
A web service interface is possibly a key feature you might want to look at. A REST API is easy to call from PHP and virtually any technology stack. It means you will likely have options about how you can architect a solution, and it's typically easy to prototype against. If you decide to go down the prototyping path and try Docmosis, start with the cloud service since you can prototype/integrate very quickly.
I hope that helps.
From my years of experience in working with PDF I think you should pay attention to the following points:
The performance: You may do the fastest performance with API based pdf files generation in comparision to HTML or XML to PDF generation (because of an additional layer of conversion involved). Considering peaks in the load you may want to calculate the cost of scaling up the generation by adding more servers (and estimate the cost of additional servers or resources required per additional pdf file per day).
Ease of iterations and changes: how often will you need to adjust templates? If you are going to create templates just once (with some iterations) but then no changes required then you should be OK by just coding them using the API. Otherwise you should strongly consider using HTML or XML for templates to simplify changes and to decrease the complexity of making changes in templates;
Search and indexing: If you may need to run search among created documents then you should consider storing indexes of documents generated or maybe store more the source data in XML along with PDF file generated;
Long time preservation: you should better conform to PDF/A sub-format in case you are looking for a long time digital preservation for your documents. See the VeraPDF open source initiative that you may use to validate generated and incoming PDF documents against the conformance to PDF/A requirements;
Preserving source files The PDF format itself was not designed to be edited (though there are some PDF editors already) so you may consider the need of preserving the source data to be able to regenerate PDF documents later and probably introduce additional output formats later.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Are there any options implementing any kind of service that can be consumed by Excel, and user can modify/add data via Excel, and such changes will be communicated back to service?
I read some articles about OData but it seems to be a one way export in excel, no data modification are supported.
There are several ways to expose data from C# to Excel so that you can edit the information in Excel and pass it into the C# world (... and beyond, e.g. to a database server, to an entirely different system, etc etc).
One way -- which happens to be an inherent Excel feature -- is to build an RTD server that wraps a C# dll. You could use a tool like Excel-DNA which will take care of the complexities of writing the RTD wrapper. One nice feature of RTD is that it's quite asynchronous, which can be a performance booster at times. One pain point of RTD is that the asynchronous-ness is managed on a cell-by-cell basis, which means that if the cells relate to each other in any way (e.g. one cell contains the part number, another contains quantity, and yet another the price, and you need all three to get anything done) then you have to write some clever logic to accomodate this. Not impossible, but definitely a pain point. Usually what we would do is create a very hidden sheet that contains the RTD formulas to watch over a different sheet for changes, and handle the changes accordingly.
Another approach would be to write what's called UDF's. Similar challenges to RTD, but you get to have the reference to the entire worksheet rather than one cell at a time, so the pain point is lessened a bit. UDF's are not asynchronous out of the box, but you can definitely make them behave asynchronously. This is pretty important - if you have a long running operation inside the UDF function, and you don't background thread it, Excel will freeze until you complete the function. This could lead to users thinking you broke Excel (LOL). Note this is not an issue with RTD's, since they are already asynchronous. There's several ways you could create a UDF, one of them is again Excel-DNA, but you should explore your options before going headlong into that route. The actual implmentation of handling change is similar to RTD - create a very hidden page, scan the target worksheet.
There is yet another approach, which would be to create a VSTO add-in. This basically integrates your C# dll into Excel. You can create toolbar elements, intercept Excel events -- essentially you can interact with Excel on a very low level. Pretty much anything you can do in Excel VBA, you can do with VSTO, and more. Handling change here is done at the add-in side (i.e. your code-behind .cs files) and the world is your oyster at that point. I usually write a cell changed event handler, but you can capture changes at pretty much any point that you want. You can even defer handling the data change until the user presses the save button - I used to do this, because it was a pretty straightforward paradigm for the end-user.
Those would be the 3 options that come to the top of my mind.
You might take a look at the Microsoft.Office.Interop.Excel namespace.
Here is a good explanation what one could do with it.
Try the Excel-DNA library http://exceldna.codeplex.com/
Better avoid Microsoft.Office.Interop libraries. They are very difficult to handle disposing of references and they require office (in this case Excel) to be installed in your machine (and even worse app servers etc.)
I'm facing a huge challenge with some excel sheets which was written in 90's for some financial calculations. Basically there are around 100 different excel sheets(different in structure, content, formulas,macros etc) and this needs to be integrated into one single application and thus decommission all those excels.
Some of the features of the excel sheet:
Every excel sheet has some defined number of sheets with formulas and macros associated with it. The macros are written in VBA and makes use of extensive addin's in the form of XLL's.
Every excel sheet also has some user defined work sheets, which rely upon the user input data and the predefined sheets to compute instrument prices.The most important thing is that the user inputs data to the user created sheets, which is referenced in the pre defined sheets.The predefined sheets calculates something based on this, and the result is again referenced in the user defined sheets.
We were thinking of various approaches to decommision this as below:
Use Excel Services with Sharepoint 2010, expose the excel sheet as a web service and write a client application which will do the user defined part and then communicate with the excel services for the result.(it will also have to write to the predefined sheets hosted in excel services)
Use excel automation(??)
My question to you is what would be the best feasible approach here to decommission those excels?.All I have to do is to write to excel cells, let the formulas/macros play there part to compute the result, get back the results.We are also very keen not to re create the whole excel set up i.e re create the formula's/addins which is in place, but rather consolidation of them.
Any advice would be much appreciated!!!
Cheers,
-Mike
If we ignore particular technologies, you have three basic options although combinations are possible:
Keep the existing Excel workbooks in the background and provide a new front-end.
Migrate the VBA to some new tool.
Identify with your users, the functionality they need today and tomorrow and implement that.
I would be surprised if Option 1 did not give you the cheapest and quickest integration. The downside is that you remain dependent on those old Excel workbooks. Are they based on early versions of Excel or have they been migrated forward? If not, do they work with the latest hardware and operating systems? Will they work with tomorrow's hardware and operating systems? Microsoft makes enormous efforts to maintain backward compatibility but that does not mean they achieve 100% backward compatibility nor that they can or will maintain backward compatibility in future.
Is Option 2 feasible? Do you know what each workbook does? The VBA can be migrated/converted to a new tool but what about the Add-ins? Do you have the source? Do you have the documentation? The trouble with relying on the documentation is that some bugs become undocumented features that people use.
With Option 3 you need not worry about bringing anything forward. You pick the right tool for today and tomorrow and use it to implement the functionality you need. You have to be slightly careful. If you ask users if they need facility X, they will say yes regardless. The question to ask is: what do you use facility X for?
Each of these options has risks? Do you have the information to access the risks? Can you quantity the work and risks associated with each of these options? Only when you can will you be able to select an approach and then a technology.
I am not familiar with Sharepoint, so can't compare, but with Excel automation it is really possible to open a sheet, enter some values there and read results. It even can be done visually as if somebody opens Excel on the screen and does something in it. I would use some modern .Net language for this if your old sheets are compatible.
I have to compare two Excel files having different number of sheets, different number of columns/rows, merged cells, formulas etc.
The output of the comparison should allow the user to see which rows/columns were added, deleted, modified, re-arranged. This whole thing has to be done using C#,.NET
Can anyone help me out?
You need to define your scope better. As #Brijeesh suggested, there are 3rd party libraries like EPPLus, and also NPOI for reading the files. But this is not about reading the files, but rather performing some "comparison" that you have an idea in your head how you want it to happen.
This question is too broad to be answered in a single thread like this.
Are the spreadsheets in a known format?
Do you only want to check certain sheets / columns ?
You mentioned wanting to see which columns were re-arranged, this implies knowing what order they were in the first place. Again - is the spreadsheet in a known format?
You should start to answer these questions, and trim down the scope of what you're trying to do into manageable tasks.
EDIT:
VSTO has its benefits, and it's downfalls (the user must have excel installed). 3rd party libraries also have their ups and downs. Which method you should use for accessing the spreadsheets was not the question in this thread.
Again - focus on one thing at a time. What do you want to compare, and how do you want to do it? Then you can worry about which library you should use. Though - when you're ready to ask that question, open a separate question so that the posts can stay on topic.
have a looka at epplus if that doesnt fits your requirement use VSTO/office interop
I created a spreadsheet macro that compares two spreadsheets together and highlights differences. You have to login to download it but you can use your Google login.
The VBA code is not locked and it might give you a start to port it to C#
http://www.run8tech.com/tools.aspx
If I built an application that expects the user to use the copy-paste functionality from
a datagridview to excel (as a simple export), do I run a big risk that this will no longer work/give strange behavior in future builds of .net/versions of excel?
Per this MSDN article on copying data from a DataGridView, the control will set onto the clipboard both tab-delimited string data and an HTML table representing the data that was copied. These being relatively standard formats, as well as a relatively standard practice for exchanging data, you should be safe.
Of course, nobody can say with certainty what Microsoft will do in future versions of their products, so there's always a chance that something will break later on. However, Microsoft's pretty good at making things sufficiently backwards-compatible.
There is always a risk relying on clipboard for an export implementation:
I wouldn't say it is big but you are effectively asking for trouble when exporting this way - depending on what's installed on the system (for example some background clipboard watching app) or different versions of Excel or usage of your application in a Terminal Server situation etc. - the list of things that can go wrong is "endless" IMHO.
Using some mechanism to write a real file (XLS or XLSX) is really the way to go.
There are several free and commercial libraries (which don't require Excel to be present) out there to write Excel files (some can even export the content of a DataGridView with less than 10 lines of code!):
OpenXML from MS (free)
ClosedXML (free)
EPPlus (free)
SpreadsheetGear (commercial)
Aspose.Cells (commercial)
LibXL (commercial)
Flexcel (commercial)
You can even export in "Excel-HTML format" (sample source and MS documentation).
Yes, in a way you always run that risk when you assume certain functionality of third party program to stay around. However, Microsoft has a long history of keeping their software backward compatible for a long while, so it may not be in the next year or so that this feature will suddenly be removed.
If you must remain compatible, use another method for exchanging data.