Approaching to have a third part web application inside SharePoint 2013

Question

I am working on SharePoint enterprise server 2013, and I am trying to find the best approach I can follow to achieve this requirement:-

1. Our customer has a web page which list their employees info.
2. Currently the web page (which is an asp.net mvc application) reads its data from external database.
3. The web page allows users to click on a employee link and a jQuery dialog will be populated showing more details about the associated employee. Also users can search the web page, using employee name.

So currently our customer requested to have this web page shown inside SharePoint site collections. So I am trying to find what are the available approaches I can follow, either to render the web page as-is inside the sharepoint sites OR to build this web page using share-point list

Now I did the following steps:-

1. Inside a team site collection.
2. I added a web page.
3. Then I add a web part of type page viewer, and I specify the external web page url.
4. And seems it worked well. Where the external web page was shown inside the sharepoint web page.

So can anyone advice on this :-

1. Is my approach of using the page viewer web part , a valid approach to follow?

2. Is building a SharePoint list which reads its data from external database, and show a dialog box when click on a employee link ,, something that I can develop easily inside SharePoint?. I mean to have the employees list as a SharePoint list,instead of being an external web page ? but not sure if this is an easy thing to achieve ? also we want the ability to sort the names and extensions based on each dept...

here is a general overview of the list we want to build:-

• where employees are categorized under dept.

• and for each dept, users can sort the names & extension.

• when searching for a name, the web page will show the related branches, with the same categories (per Dept) :-

Answer 1

My own opinion is very clear on such matters: keep your MVC Web app, and display it in SharePoint with the Page Viewer Web part, as you already did. To me, this is a good approach, and very cheap. Pros largely outnumber cons:

Pros

• Cheap solution. While developing something specific in a pure SharePoint style (and with respect to the state-of-the-art) would be several days of work.
• You've already done it, and you understand what happens.
• Accessing external from SharePoint is "complicated" and requires very specific SharePoint dev skills, while finding resources to maintain an ASP.NET MVC app is much easier.
• SharePoint has a lot of limitations when it comes to replace a DB; e.g. the (in)famous "5000 items per view (list)".

Cons

• You have to maintain a third-part server for the only purpose of that external Web app... but you can easily host it on a dedicated Web app/pool of the SharePoint server.
• you have to remove "chrome" from the external page so you don't display logos/menus/navigation/... inside the frame.
• You don't control permissions from SharePoint.

I'm a SharePoint developer, so I should push for a pure SharePoint dev approach. But I'm honest with my customers and I always offer them the "IFrame" solution first! If it fits the needs, and as it is something simple/clear/supported why going with another difficult approach?

EDIT
If I had to do it from scratch, i.e. the external page does not exist yet: it all depends on the complexity/structure of the data.
[remember I'm a SharePoint developer, so creating WSP-solutions is not a problem to me, while it could be complicated even for a very_good_ASP.NET_dev_who_have_never_played_with_SharePoint]

• If it's heavily relational, I'd keep the data inside the DB, and would go to develop a Web part/an applicative (_layouts) page. In that Web part/page, I'd request for teh data with standard ADO.NET, and use as much jQuery/any_other_fancy_client_framework as needed to get to the UI result you need.
• If it can fit into SharePoint lists (including not "too many" rows), I'd store data in lists, and I'd create custom UI (i.e. replacing standard list forms with custom ones) whenever needed.

In all cases the whole thing would take days to develop correctly.

EDIT 2
OK, to try to answer last comment from @john G, let's consider more closely what you'd need to build such a solution completely in SharePoint:

1. You need to store data. I'm not sure I got the big picture, but you could simply use two lists: a list of Departments, and a list of employees. The list of employees has First Name, Ext., etc. columns AND a lookup column to the Departments list. You can even rely on the view capabilities of SharePoint to display the employees list grouped by Department. Also (in SharePoint Server, not in Foundation) you have the "Find an item" box that works great to search directly inline. And when an item is clicked, you view the full details for that employee (could be in a dialog box, if you configure the list to use dialog box, see in Advanced Settings of the list).
2. In addition to the above approach to surface the data, you can build your own UI, either with Web parts and/or with applicative (_layouts) pages. The main difference between these SharePoint artefacts and a standalone ASP.NET application is: you cannot use MVC here, so only old-school ASP.NET. Main advantages are: simplified deployment/updates accross all the servers in the farm, and you can rely on SharePoint groups to check for permissions.

Answer 2

1. This is by far the easiest approach and very valid if you don't run into the technical limitations of using an iframe.
2. You're probably right that indexing the site might no lead to the right results when the page is being built with jQuery. You could check if there's a path on the site where you can index te content by following url's. If so, than indexing would probably be ok.
3. It's probably possible, but if you don't have any experience with this, I would qualify it as rather difficult.

If you're business problem is solved by implementing the page viewer webpart, I would keep it like that. Else try to index the site, ask for an adjustment to make it indexable. I personally wouldn't go the external data route in SharePoint.

Edit

In response to Evariste. If you are not very familiair with SharePoint development, please know that writing full trust code is not the recommended way anymore by Microsoft. It is still very good possible and supported, but the recommend way is building outside SharePoint or using javascript/html/css.

Answer 3

The iFrame approach is perfectly valid, and I agree with Evariste's answer which does a good job of explaining the Pros and Cons.

There is also a pure SharePoint solution which would take only a little longer to implement, and I feel would be the better approach.

You seem to be aware of BCS, since you have mentioned external lists, but are maybe not aware that BCS can also be used in conjunction with the SharePoint User Profile Service. In short, you can set up a BCS connection to your external database, then in the SharePoint UPS you can map fields from the external DB to properties in user's profiles. SharePoint profiles already have properties for Department, Mobile etc, or you can create your own extra properties as needed.

This will then tie in perfectly to the built in SharePoint functionality. If you use the out of the box search centre, then you already have a people search results page, and you can easily customise the refiner web part to prioritise the properties you are interested in. Or, you can easily take any standard page and add a people search box, people search results and refiner web parts.

Then, if someone searches for "Finance" for example, they will typically see a mixture of documents and people in the "Everything" search results, or they could then choose to search People only. The refiner web part will let them filter down the results by whatever properties you include. When they click a persons name, they go to their profile page and see whatever properties you have decided should be on the profile page, along with an org chart browser. And, they can typically click on any of the properties (such as department) to see related users.

And of course, this ties in with the standard functionality, so if you're looking at a document library for example, and see Joe Bloggs modified a document, you can click on his name and see his profile page with all his properties.

If you want to really show off, you can then also encourage users to fill out other profile details such as the "About me" or "Ask me about" sections. In my profile for example I put "SharePoint" in the "Ask me about" section, so if anyone in my organisation searches for SharePoint they find me.

From a technical point of view, this is all very easy to implement. The difficult part is getting agreement on what properties to include, what should be editable by users and what should not, what should be displayed on a profile page and what should not etc.

This is a good guide to planning user profiles: https://technet.microsoft.com/en-us/library/ee721054.aspx

Answer 4

You could try to use a provider hosted app to use the existing MVC application. See the blog Convert MVC application to SharePoint 2013 provider hosted app