So, I'm working on developing some business apps for my organization, and I've been trying to implement the usage of the Navision Web Api for external reporting. And Unfortunately, I'm stuck using Excel because of traditional antiquated business practices.
My question - is there any way to drill-down to single values or even access the json payload through excel's web services function. I've tried switching the payload to XML on OData v4, but I can't get that to work. This is driving me insane - I cant even think about another Pivot table via odbc sql, or Odata, because I know there's a better way. I'm pretty good with PowerShell, javascript, html etc.. but Im almost clueless when it comes to VBA, and it just seems like to much suffering. Anywho, if I cant use the OData feed in the web services function - well why? Is Microsoft just trying to screw us? I keep getting a value error - naturally - because I cant drill down to a single value, format to xml, or access the json object within the web services function(if it even exists in there??) here's a link to what im looking to do Excel Services function Demo- except I cant do it - so is there any substitute or solution.
So, stop whining and use power query to fetch data from Nav’s OData endpoint.
Related
I'm trying a Graph endpoint with Graph Explorer, in particular, I'd like to sort by id by using the following URL with ODATA query but it doesn't work (Always the same result without sorting):
/v1.0/sites/root/lists/{id}/items?$select=id&$orderby=id desc
Unfortunately not all ODATA queries are supported on all workloads on #MicrosoftGraph. It is something we're trying to standardize on. It is frustrating I know. The first thing we're doing this quarter is documenting what is actually supported to stop this confusion.
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.
I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.
I'm looking at the architecture for a DW project and there will be the need for some manual collection of [structured] data eg the monthly accounting results from a country manager where they need to complete a form and fill in half a dozen values etc.
I really like the idea of using SP and InfoPath for this as it gives the security, the workflow and the customisability etc that mean it can be easily deployed as the client already has SP rolled out. The bit I am less clear on is how, technically, we might interface to the SP workflows and the forms themselves. Ideally the data would end up dropped into a database and we would use our [their!] standard ETL (DataStage, possibly sat on a linux server) via ODBC and pick it up like any other datasource but I am not sure what this requires on the SP side. The alternative would be to get at the XML of the individual forms and pull the info from there.
Are these appaoches feasible? What would need to be set up on the SP side in order to make this integration as robust and seamless as possible? Can anyone point me at docs/reading matter that might give me some more background info?
Thanks,
Dex
First up, accessing sharepoint's databases is never the answer to any integration question. You should treat it as a black box.
So, how should you get the data? Web Services + HTTP. SharePoint offers a large amount of Web services to get at the data you need. If you're working with IP forms, then ultimately you will need to grab the resultant XML file from the document library and parse it to get the data you need. The Web services can be used to enumerate the IP forms, and you can use straight HTTP to grab to xml file. This is probably the approach that would be offered by most experienced sharpepoint people.
I'm trying to implement an Excel Services reporting solution in SharePoint (MOSS). Since the source data is a SharePoint list, this problem is doubly frustrating. I keep bumping up against permissions problems, even though I've enabled virtually everything in sight.
The first error is about refreshing external data - it's not (really) external data, but that's a semantic point.
The second error is a cryptic "Excel Web Access" problem.
Anyone get this to work??
Could be a couple different problems. The first possibility is that Excel Services doesn't support using SharePoint list data (crazy I know)... although this only applies if you try using the type of embedded data source you get if you choose Export to Excel from a list (again, I know crazy).
However an easy way around this problem is to use the SP webservices to get you list data. I had a macro written by someone at MS a while back that automated this conversion, if I canfind a link I'll post it. If you are using Kerberos then you task is probably finished. If using NTLM then you may need to also configure an SSO application so that the right credentials can be passed to the webservice (or any other data source for that matter). There's a pretty good step by step here.
One kind of "hack" to get this to work via UDF's (which if trusted, custom code can be deployed and made available via Excel Services) can be found here.