I have a Rails application I want to do CRUD operation on user's documents online but I want to render MS Office (OpenXML-based) docs in the browser. I have heard about WOPI/SharePoint. How can I integrate it with my web app?
What you're looking for is indeed called WOPI. To be precise, you want to integrate Office Online Server (WOPI client) with your application (WOPI host). This is how SharePoint's integration works as well (SharePoint plays the role of a WOPI host here).
You need to implement the following flow:
Translated to your app - your Rails app will generate URLs pointing to the WOPI client and providing it with information about the MS Office files, authentication information, etc. Then, the WOPI client reaches for those files to your Rails app which will also need to implement the REST endpoints defined by MS-WOPI protocol (mainly CheckFileInfo, GetFile, and PutFile actions).
If you just want to provide view for the documents, that are publicily available, you could use office live viewer, or google docs viewer. You need to basically provide an URL to your document to those services.
I have found this site that has demos for online viewers currently available, you could check it out: https://xtai-umd.github.io/docs-viewer-demo/
SharePoint also has something called WopiFrame.aspx page (or WopiFrame2.aspx), that allows you to show documents like the site above, but with authentication. Please note that this will work only for the documents that are stored in the SharePoint (in the particular SharePoint where you use that WopiFrame.aspx, that is).
If you are developing SPFx web part, this is the way to go I think. Since in this case both are running in the context of SharePoint site, you don't really need to think much about security, it's all taken care of.
I mean, implementing your own WOPI server is not easy at all, and in addition to that you'll need Office Web Apps server, either installed on-premise in your organization, or the Microsoft's online one. To be able to use Microsoft's one you need to be a member of Cloud Storage program, as far as I know.
I would not recommend implementing custom WOPI server unless it is really needed for whatever reason (in my case, it was quite specific security requirements)
Related
If I have a requirement of displaying the a content on all the pages inside a header, Whats the best way to do that in an SharePoint 2013?
I am working on a master page that will be using the design manager and there is possibility of using the same master page in the SharePoint online too. The reason why I want to know what is the best way, when I use this same master page in SharePoint online I would like avoid redoing that entire coding for getting a dynamic data from the web service.
Several ways that I have been planning is below
- User control method
- Web part method, but requires server side coding which I doubt can used in online version
This is a complete dynamic data that will be retrieved by a web service and no internal SharePoint data be used.
Thanks for reading
Deepak
If its possible to consume web-service using jQuery/Ajax call you can go with that
Or else if you want to use c#, might need to go with provider hosted app feature (sharepoint 2013)
You can create a Visual Web Part for SharePoint 2013 Online.
Your web part will be contained in a Sandbox Solution which you will develop locally. Once development is complete you will upload the Solution Package created by Visual Studio to SharePoint Online.
https://sharepoint.stackexchange.com/questions/80164/create-visual-webpart-for-sharepoint-online
http://sharepoint-community.net/profiles/blogs/sharepoint-online-2013-web-part-deployment
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 need to programatically interface with SharePoint folders, files and lists from outside SharePoint. Most tutorials focus on working within SharePoint itself, or at least on the same server where SharePoint is installed. I need to automate some tasks from completely different servers -- tasks that require reading SharePoint lists, browsing folders, checking files out and in, reading files stored in SharePoint libraries, etc. It used to be easy using UNC folder and file paths. Now many of our SharePoint sites don't allow UNC access (probably for good reasons), but my needs are the same. What languages / libraries / interfaces will allow this? I'd like to be able to do this from server-side .NET code and from PowerShell scripts (not on the SharePoint server). Thanks for any pointers.
SharePoint offers a web services API. I won't claim it's particularly friendly or fun, but it does work. You can get started learning here.
Use Sharepoint Web Services which provides a suite of standard web service endpoints you can use to do most anything you can through the objet model API.
You can use SPServices whichis a jQuery library which abstracts SharePoint's Web Services and makes them easier to use. It also includes functions which use the various Web Service operations to provide more useful (and cool) capabilities. It works entirely client side and requires no server install.
Here's anoth example of SPServices in use Example
if you are using SharePoint 2010 you can use the Client Side Object Model (http://msdn.microsoft.com/en-us/library/ee537247(v=office.14).aspx). It will help you to access sharepoint objects, lists and everything. There are 3 types one for C#, Silverlight and Javascript.
there are more than one methods:
use csom (client side object model)
use rest services
use sharepoint out of the box web services.
If you want to be able to choose the language in which you program, I'd recommend using the Sharepoint REST API. I'm writing my service in Java, requesting data in JSON, and using Jackson to parse it into Java Objects.
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I want to use a CMS that can be accessed by my clients via the internet. All SharePoint usage I have seen is for intranet sites only. What I am looking to do:
Landing page for all clients, with general information.
Client login to client specific portal page with client specific information.
Accessible via the internet. The clients may or may not have SharePoint.
General and client specific wikis.
I won't be hosting this myself. I would be looking for a hosting provider as well.
I am also looking at using DotNetNuke, which has a lower cost of entry. I am open to suggestions of other CMSs, but my skills are built around C# and ASP.NET.
Before going down the SharePoint path, I wanted to make sure these things are possible.
Thanks!
Update:
Thanks to all that have given me some points to ponder. In summary, here is what I have decided to do (given my current skill set):
SharePoint can be used for my needs (my initial question). Many great example sites.
DotNetNuke as my CMS. I realize other good CMSs are available, but I prefer to stick to the Microsoft stack.
Branding will be easier in DotNetNuke.
The site will not be very big and not used by many. SharePoint will be overkill at this point.
Many of the 'modules' I am looking to use (wiki, forum, ...) seem to have more options/maturity using DotNetNuke.
Biggest Deciding Factor
Integrating a CMS solution with my software product and then installing/implementing this solution for individual clients will have a much larger cost with SharePoint. DotNetNuke will allow me to 'leave behind' the solution with the client without having them to invest heavily in SharePoint if they do not already own it.
Thanks to all!
Ed
Everything you require is supported by Windows SharePoint Services 3.0, which is included at no additional cost with a Windows Server license. However, SharePoint does have an administrative and development overhead that you could avoid using a different platform. It doesn't sound like you would really be leveraging any of SharePoint's particular strengths (document management, Office client integration, ad hoc collaboration sites, etc), so it's probably not worth the extra effort.
So in short, the answer to your question is "Yes", but it's probably not your best option with these specific requirements.
Check out the Top 17 case studies for Microsoft Office SharePoint Server 2007 and several new MOSS-based web sites. There are some nice Internet websites too.
there are heaps of SharePoint sites out there facing the internet. There’s a great list of over 1,000 of them on the WSS Demo site here: http://www.wssdemo.com/Pages/websites.aspx
All of the requirements you’ve listed are achievable with the externally facing SharePoint model. There’s an obvious cost impact of going down the SharePoint path versus DotNetNuke but it’s certainly achievable in terms of functionality.
Kentico offers SharePoint Connector which allows to publish SharePoint content to external sites: http://www.kentico.com/cms-asp-net-features/sharepoint.aspx
All the things you mentioned are possible. Note that hosting a SharePoint server can be expensive. Most hosting providers charge you a dedicated server hosting plan.
Also I'm not impressed with the default wiki solution in SharePoint. You might want to consider a 3th party wiki tool and point your SharePoint Search towards it so that the results are shown in your search results. Drawback is that you loose the security trimming.
You might also be interested in the BPOS solution. A (kind of) hosting service for SharePoint that Microsoft is offering.