Udostępnij za pośrednictwem

I thought I needed a SharePoint Provider Hosted App for that. - Part 2

  • Artykuł

In my previous post I explained how to create a SharePoint Remote Event Receiver (RER) without the need for a Provider Hosted Application (PHA). In this post I’ll go over a few limitations to this approach that may help you determine if it is right for you. I’ll also talk a bit about some other some other really great client side enhancements that you may or may not have know did not require a PHA.

Limitations

Lets assume that based on some of the data that is being changed you’d like to call back to SharePoint to get some other data in another list to do some processing. Or, lets assume you have added say… 20 columns to your list and you are comparing some of them to each other, if the user decided to use the Quick Edit in SharePoint you’d only receive the columns that were actually changed in AfterProperties, so now you’re a bit stuck because if you need to compare the changed data against other data in the list item that was not changed, you’d have to find some way to call back to SharePoint.

The call back to SharePoint would typically be done through a trusted connection in the context of the SharePoint user or an app… and for that you do indeed need an app. Consider the following code that executes in a RER.

ClientContext clientContext = TokenHelper.CreateRemoteEventReceiverClientContext(properties);

clientContext, without an app in place will always return as null.

I’ll digress a bit. This is the context that would typically be used to talk back to SharePoint. If on prem and using high trust with a PHA, the code in the TokenHelper class grabs the path to your pfx file and the pfx password from your web.config, creates a windows identity X509 signing cred using claims passed from SharePoint, then calls back to SharePoint using the cred on behalf of the SharePoint user. Whew!, and that’s paraphrased, there’s plenty of documentation out there about how this works. If o365, an ACS access token is used to create the trusted connection, once again, beyond the scope of this post. The bottom line is that if we don’t have an app then calling back to SharePoint would require creating a cred using through some other means like storing a user name and password, a service account, etc. etc..

Some other pretty cool things you can do without a PHA.

JavaScript Injection – this pattern is a great way for you to make changes to master pages, page layouts, any page that renders in your Site Collection for that matter, without the need for uploading custom versions. You only need to run a bit of server side CSOM through a console app, windows forms app, web application, etc. A custom action is added that tells SharePoint to add your js file as a script link, all you need is a web site to put your file. That’s it, once added the js file will load each time a SharePoint page loads and “Inject” your mods dynamically. No PHA required. Check it out in GitHub. There’s also a sample on how to use this pattern through JSOM here.

I was going to add more but really there are too many to list. Check out all of the OfficePNP samples in GitHub here, you’ll notice that there are a plethora of things you can do to customize your SharePoint site that you may have been thought required a PHA.