We are in the process of moving an on-premise SharePoint installation to SharePoint Online. We have a number of existing C# web parts that we need to convert. These web parts currently access some of our on-premise data... we need to get the web parts working on SharePoint Online; however, we're not certain of the best approach.
We've looked at BCS, but it seems that it is geared more towards synchronizing lists of data via basic CRUD methods. For many of our applications, we are not looking to synchronize lists, we are looking more towards action-oriented methods on a service that can be called on-demand as needed by the web part.
We don't believe the call can be client-side, as the users will often be accessing SharePoint Online from workstations that are not joined to our domain, and we don't want the user to have to separately authenticate to our service (i.e. we want our service to trust only the SharePoint Online backend).
Our ideal setup would be to have our C# code for the web part call into our web service (hosted on our domain, authenticating with a service account from the SPO secure store), passing the current username from the SharePoint context, and getting back a response that the web part can then use for its processing.
But as we understand, the web parts in SharePoint Online are sandboxed in such a way that they cannot make external HTTPS calls via HttpWebRequest.
We've searched for how-to examples or documentation related to our use case, and haven't found anything saying it's possible or that it's not possible. Does anybody know if it's possible for a web part to get data in this way? Is there some other direction we should be taking to achieve this?
In SharePoint online, if you are developing a SharePoint hosted app; You will be able to call external endpoints (EPs) after adding these endpoints in the manifest file.
If you haven't added these endpoint to the manifest file, This means you are not permitting the app to call an external EPs.
You don't need BCS in SharePoint online to call external EPs. Here is a sample on how to do this using JavaScript.
https://msdn.microsoft.com/en-us/library/office/fp179895.aspx
Let me know if you have any other questions.
Related
We're developing a managed app (using ARM templates) that will be deployed to multiple tenants. The solution will, among other things, work with SharePoint sites on the end users' tenant.
We have looked into using a single multi-tenant app registration with the appropriate rights. Because of security restrictions on the SharePoint API when using Azure app-only, a certificate must be added to the app registration and the PFX must be provided in all API calls.
We wish to have as little data at our end as possible, so the we hoped to include the application that connects to SharePoint as part of the deployment. However, this would lead to multiple apps having access to the same PFX, which doesn't seem safe.
I'm hoping there is a better way to go about this. Must the connecting web app instead be hosted on our end? Is there a safe way of storing the PFX in multiple locations, or make it accessible to multiple tenants? It is important to us that we can automate the process as well, preferrably using ARM or an automation job as part of the deployment ... At the very least, I would be thankful for suggestions on making any configurations relatively pain-free for the end user.
PS: We would like to avoid the use of service user accounts.
I need to update data in a sharepoint list remotely via a script that runs on a schedule. We currently are using sharepoint 2013 foundation but will be moving to sharepoint online in 6 months or so. I would like to know how to do this via the REST api for both 2013 on prem and online versions. Im having a hard time wrapping my head around all the different auth models, sharepoint products, available apis, frameworks etc and when reading the documentation on MSDN I cant be sure which is relevant to what version of sharepoint etc.. Anyway, so far im thinking or the 2013 on prem sharepoint I should use the High-trust certificate auth option so my script is authenticated via a certificate. Do I need to create an add-in for script to register it as an app that will talk to the rest api? The reason Im not sure is sharepoint itself never really has to call on my script and its not a webpart or page or antyhing that gets displayed on sharepoint so im a bit lost.
As for how to push data into sharepoint online lists, im assuming I would then have to register the script as a providor hosted Add-in and authenticate using OAuth2 via Azure ACS server.
Does this sound like the best way to acheive my goal? Am I on the right track or is their an eaiser option? Is there anyway I can just use a Active Directory user account in the script to make authenticated requests instead of having to create certificates trusts and create addins etc?
Update:
Heres some more info on what I'm trying to do...
The project Id like to start will be a Node or PHP script that runs on a seperate server and pulls data from a third party source, making calculations on it and then pushes the results into some Sharepoint lists. Then running this on a schedule every night to keep the Sharepoint lists up to date. I know how to do everything except getting started with Sharepoint; how to establish the connection and authentication basically.
What id like to do is access the REST apis for lists and libraries from Node or PHP which would obviously be running externally to Sharepoint. I just don't really understand how to get started. My understanding is there is Sharepoint hosted apps (client side javascript that can access the SP apis), and provider hosted apps (which is essentially an iFrame to another web app). So out of the two I'm looking at provider hosted, but do provider hosted apps only run when called? Do they need to present a front end to show in an iframe? My project only needs to push data into lists overnight. And so do I need to register the project as a provider hosted app?? Or how do I go about getting started? And then I'm lead to believe that the app model is the 2013 way of programming for Sharepoint and the new 2016/online way is Sharepoint framework (SPFX). But then the only examples I'm seeing for this is client side apps. The second project id like to do is to make a client side app which will take the data thats in the lists from project 1 and display that in certain ways dynamically using react. So I'm fairly comfortable knowing where to start for project 2, ill just straight into developing a client side react app that uses SPFX. However I'm totally stuck on starting project 1. Where do I start for project 1? What are my options?
As far as I understand your question, You need to update your on prem list from schedular and later you will update the list in your sharepoint online.
We you can create a Provider hosted app and through configuration you can switch your destination easily.
OR you can think new way to do that. You can use Node JS timer service which insert to your on prem usign rest api later the same code will work for online you just need to change the destination.
Currenlty we are also donig it with Node. Below is the simple code to create timer in nodejs.
what is does, it read the crednentials from file and email to the user.It just a simple code and can be use to insert to SP list usign rest api.
https://github.com/halfice/Node-JS-Timer-SharePoint/blob/master/app.js
furthermore It would be more clarify if you could share picture of what you want to do
Is it possible to create SharePoint web hooks without Azure?
I have a requirement where I need push notifications from a SharePoint list, I read that SharePoint web hooks can be used to achieve it, but customer doesn't have an Azure account and looking into possibilities where it can be achieved without using Azure.
It is absolutely possible. The premise of WebHooks is that SharePoint Online will HTTP POST to a URL you define when the event happens. The only thing that is important is that the WebHook service you create and register with SharePoint Online has to be accessible to the SharePoint Online service. Without getting into specialized networking arrangements with Microsoft this means your service has to be publicly addressable. Azure is used as a common example because it is publicly addressable, it is a Microsoft product and lots of SharePoint Online customers are also Azure customers. There is however nothing that would stop you from using your own hosting solution.
Here is a presentation on WebHooks: https://docs.com/OfficeDevPnP/1223/pnp-web-cast-sharepoint-webhooks
Iam trying to develop webpart for firm website on SharePoint with visual studio, the problem is that there is no solution for SharePoint online - Visual web part. When i try to create SharePoint 2013 - visual web part, I get an
error message.
The only thing there is for Sharepoint online is Apps for Sharepoint and that isn't a web part, or atleast I haven't found a way to use it as such.
When I talk to my supervisor about the error, he tells me that they can't create a virtual server for me to install the SharePoint server on and I have to code it through the Sharepoint online.
Is there any way for me to develop and deploy the webpart with an online Sharepoint server instead of local one or to atleast create it through the apps for Sharepoint?
You can use App Parts, those are Web Parts that display content from an installed App, you can add them at any page of your site as normal Web Parts, App Parts are deployed in the same package as your App, so you can have everything in the same solution.
There are plenty of resources that will help you to develop Apps and to include App Parts also, just look for the right concept in google and you will find it.
There are two kinds of SharePoint Apps (or Add-ins which is the new name), the first one is SharePoint Hosted App and the second one is SharePoint Provider Hosted App, the one you need will depend on the functionality you want to achieve, but as a general reference you can think on the data source that you want to consume in your solution, e.g. if the data to be used by the App is in the SP Site where you are going to install it, then all you need is a SharePoint Hosted App, however if the data is in an external location like databases stored in local servers, then you will need SharePoint Provider Hosted App. Of course this is just a very basic view of this topic, there are other reasons to use one or the other but its pointless to make a full list here. This is a wide topic and you can find tons of articles and guides about this.
If all you need is a simple webpart to display some content with a nice look or roll up some content and provide an output based on it, then you can use a SharePoint Hosted App, which is the easiest to develop and deploy, with this kind of app you can use JavaScript get the data from your site, and then you can display your output in an App Part.
I'm sorry to not provide specific pages to read, but that's just because it's better to look for the guides that be easier for you to understand and that may vary from person to person, all you need to know is the concepts and topics to search for.
If you want me to help you with this please send me a message (my profile).
I have a bit of challenge. Knowing only the basic URL for the sharepoint installation, can I get a list of the site collections that have been created using only the basic web services that are installed?
Using the Webs web service or the SiteData web service I've been able to get information on the default site collection that's at the base URL (http://MySharePointServer/). I can also get a full list of sites below the site collection and a description of the site collection itself but I can't seem to get any info on the other site collections under the same web application.
Any help would be appreciated, I thought it would be a piece of cake to get the info.
Unfortunately, no. That functionality isn't available from the out-of-the-box web services. The only option that might work is using the Search Web Service (I'm not familiar enough with it to know).
This walkthrough describes how to add your own custom web services to the product. I strongly recommend this approach as it's very likely there will be other missing functionality you will need to add - if not now, in the near future.