I have an architectural nightmare lying before me and want to clear some details.
So, the question is as follows:
How can someone build a web application which uses some macros buried deep in the Excel spreadsheet as a back-end for computations?
The background:
My client has an Excel spreadsheet doing some calculation for him (so it's in some ways an Excel application). Now he is willing to have a WEB app using the same Excel spreadsheet as a back-end. Yep, it's as said: to have a web front-end doing queries to the macros in this Excel spreadsheet and getting calculated data back. No, I cannot look at the macros source and translate it to my target language, because the spreadsheet is password-protected from editing.
The main web server which better be left untouched is Apache. The target development language I most proficient with is PHP.
I have read the Microsoft Support article about Excel<->VB interoperability and question here about the Excel<->C# interoperability and concluded that the task is possible with the next dataflow:
Apache -> Some C#.NET / VB.NET app in backend as a relay -> my Excel spreadsheet -> back to relay -> Apache
but of course I think it's just horrible and I want some more sensible solution.
If the macros buried in the spreadsheet are VBA there is no clean way (AFAIK) of running the spreadsheet on a server.
There are some tools available that claim to be able to compile an excel spreadsheet including VBA into an executable that you could run on a server, but I have no experience of them so do not know which, if any, would suit your situation.
Related
I am trying to create a data entry "app" to collect daily readings across our site. Here are the three biggest constraints:
Software - ideally, we would use some software within the Microsoft 365 Suite, mainly because those are the only approved apps on site. It may be possible to use open source software, but that might raise some flags in terms of security. So my thoughts are to use either Excel or Access.
Cost - ideally, we do not want purchase any additional software licenses. I would try and create something with Power Apps, but we do not have the licensing for an Azure or SQL server to store the data. I could be missing something here though.
Mobile-Friendly - finally, it needs to work on an Android tablet. Currently, we collect readings using pen and paper. The whole idea of this is to move towards using a tablet.
The easiest approach would be to create an Excel spreadsheet, save it on OneDrive, and edit the spreadsheet. I don't love this option because we are collecting 100's of data points each day. This would end up with a very wide spreadsheet that will be cumbersome to navigate.
The other option I looked into was creating an Access database and accompanying form and storing it on SharePoint. However, it seems Microsoft has stopped supporting Access databases on SharePoint.
I have created data entry forms using VBA, similar to this, but these do not work on mobile.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
I am engaged in just this kind of project also. I have written an app in PowerApps, built an Excel spreadsheet and stored it in OneDrive, and am running it (the app) on an iPad. The design differs somewhat from your description of directly presenting a spreadsheet to the user (which I think PowerApps could do) because I don't want users having direct access to the data.
Edit: You do not need Azure or SQL, unless you are storing tons of data. Excel can be a satisfactory data storage location for modest uses.
I found the learning curve for PowerApps to be quite steep, as it's a different paradigm than line-by-line coding.
I think this is a more user friendly way to collect data than trying to run an Excel form, and once you get it made and polished, you'll look like a pro :)
I am by no means an expert but if you need some tips I'll do what I can to help. It sounds like we are at similar developmental stages.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
Microsoft Forms does the job when created from OneDrive on mobile browser. Side note: the form I just created and the response I submitted have now disappeared from my OneDrive.
I also saw some people using Power Automate to save responses from a form into an Excel file (every reponse).
I need to give power-users of the web application I am working on the ability to create their own reports, analysis, etc. in Excel. Basically they need to create some Excel sheets, read some data from the web app and than mix the result with further data coming from other data sources.
The web application already exposes data in JSON/XML format through a web api (not fully REST but this doens't matter) and I would use this channel to get data in Excel.
At the moment I have these three options in my mind:
In the past I've solved a request like this with some VBA code and a COM object (that talked with the server/database) but I am not sure if today this is still the best solution to do this kind of job.
I have learned that today Excel has PowerPivot that can read data from a web service. I could develop an oData feed for PowerPivot but I am not sure if PowerPivot is what power-users need
Another solution could bean ad-hoc Excel add-in
How would you solve a request like this?
Power Query would be a better option than Power Pivot here. Power Pivot is a dimensional modeling and analytical database (it is exactly a private instance of SSAS Tabular running behind the Excel process).
Power Query is an end-user friendly ETL tool, developed as an add-in for Excel, and available natively as of Office 2016. It allows loading directly to an Excel worksheet or into a Power Pivot model. It will give more flexibility to your end users. It is a GUI-driven interface that is a front-end to the M query language, developed by Microsoft.
Unfortunately, I am not able to help with Power Query too much, but it fits your use case perfectly.
Edit: An additional feature of Power Query, likely not to meet your needs, but I thought I'd throw in.
Power Query can read directly from HTML tables. If you present data in HTML tables, your end users can simply load directly from a URL.
Power Query definitely the "correct" tool for this within Microsoft world. It can also handle JSON and XML (and Odata) directly. How well it manages your data will depend a bit on how nicely formatted it is, but it can work with most things with a little bit of effort.
It is a free Microsoft authored add-in for pre Excel 2016 and built in to Excel 2016.
There is excel file with complex mathematical model. How to prevent file coping from client machine to other machines? Client have to run Excel and type coefficients into equations, then Excel computes result.
I think about VB extension or macros which checks MAC of network card or value in Windows registry...
There is no way of securely sharing Excel w/o an intermediary application e.g. a WebApp.
If you have SharePoint host it via Excel services.
If you know ASP.NET or another Web language then write a simple calculator or use e.g. https://www.google.pl/search?q=excel+to+asp.net+converter&oq=excel+to&gs_l=serp.3.0.35i39j0l9.84291.85973.0.86694.10.9.0.0.0.0.595.1008.1j1j1j5-1.4.0....0...1c.1.51.serp..6.4.1005.XWeje4bO7mI
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
As for server side:
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/xlwt
As for client side:
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
Example Code
However, as #whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.
I've inherited a large Excel spreadsheet that does some financial calculation magic using any number of simulation tables, and have been asked to write a web application as a front end. Now I could spend endless hours trying to figure out the sheet, or I could call the excel sheet from my web app. I seem to need the Office Primary Interop Assemblies, but do I also need to install office/excel on the web server? How can I handle multiple simultaneous requests to the same sheet? Is this approach even possible?
We have implement a project where we call several Excel spreadsheets from a web app.
We use Sharepoint Excel Services to do this. It has worked very well for us.
In our case our largest spreadsheet has over 300 input parameters, 1000 formuals and 50 results. This takes about 0.5 seconds, where most of that time is moving data in and out of excel services via a web service.
The main draw back in using Sharepoint Excel Services is the cost. However, in our case the saving in development time far out weighed the cost.
Excel is a desktop Application (and a very good one) and not designed for either multiple users or deployment in a web application. You might be able to cobble something together but you are likely to have to write a lot of code to manage the design features of a desktop app which are inadequacies in a web app.
You are better off trying to understand what the Excel workbook is doing and simulating it in code with the desired multi-user features in mind which must have been beneath the request for a web app. If you have access to the current users and/or author you should be able to document the requirement and you have the Excel workbook for you to test your algorithm against once you have understood it.
Best of luck.
Take a look at SpreadsheetGear. Ordinarily it is used to generate new spreadsheets, but it has a calculation engine for existing spreadsheets too. And unlike Excel, it was designed for a server environment.
Spreadsheet Gear
You can try SmartXLS for .net,it has a calculation engine for Excel workbook,it does not depend on Excel.
Not sure if this is appropriate to your task, but could you not import it into Google Spreadsheets to make it multi-user? If it is really complicated then I shouldn't think this will work, but might be worth a try.