We currently have a fully developed web forms application, basically its like WordPress using .net for multiple users to publish content. It does more than that but thats the simplest way to describe it. Our "webmasters" (I work in the gov) want everything put inside of SharePoint. We currently have SharePoint 2007. I have no experience developing within SharePoint so I don't know much about it.
My question is how do you decide when to develop your application in SharePoint and when to develop outside of it.
It depends on several things.
Is there any reason to use SharePoint features (lists for data storage, document libraries with versioning, groups for security, etc.) in your application? If you're just hosting ASP.NET pages within SharePoint but aren't using any of its features, it's not really worth the hassle.
However, if you would be adding the application to an existing SharePoint site, it might still be a good idea. Organizing everything in one place might be more convenient for users than setting up a separate web application.
If it is a requirement to re-architect your application to work with SharePoint, that is one very big reason to develop with SharePoint. Beyond that, the people influencing your architecture decisions may have good reasons of their own.
SharePoint provides security management, search and navigation to name a few relevant pieces to your web puzzle. If you are already creating dynamic web applications in .Net, a lot of what you've learned in the process will apply, but you have some learning to do.
Your orginization is not the only one moving most web applications to SharePoint. If you don't learn it now, you risk getting behind the curve.
You could also just 'show' your existing applications inside of a SharePoint web part (Page Viewer?). That way, your application remains the same, and it is 'shown' inside the SharePoint environment. This is somewhat a hokey solution, but in your particular circumstance, it could be viable considering development time, learning time, and control.
Related
We have an ASP.NET website that we use internally to do some project tracking and various work. We would like to integrate some pieces of it to co-exist with Sharepoint2007 WSS.
Basically what we would really need to do is be able to add items to a list in one of the Sharepoint sites.
I'm not sure where to begin. I've looked online a bit but it seems overly complicated. Is there a quick start guide somewhere that can get me rolling with ease?
The SharePoint Web Services would be a logical place to start. In my opinion this would be the easiest way to build interaction between ASP.NET and SharePoint.
A list of available web services can be found on MSDN.
If adding items to a list is the primary goal, then check out the UpdateListItems method of the Lists web service.
With the scope narrowed to Web Services, you can certainly find tutorials/references online. However, this InfoQ post by Trent Swanson is a decent introduction to SP web services. Note that they recommend generating .NET types using XSD files; in practice, for simple projects I have simply parsed the XML myself using LINQ. You can make it as easy or complex as you like, I suppose.
This is an architectural question.
We are in the process of building a document management site with basic workflow which needs to be external facing.The external facing application needs to be branded and should have the capability to upload and download documents and also support versioning.We have decided to use WSS 3.0 as the collaboration tool as it has all the features we need.We are planning to support multiple clients with custom branding for each client.
My question is should we expose WSS to the client for external facing or build a standard ASP.NET application using WSS in the application tier and let the ASP.NET app interact with WSS using the WSS API/Web service.This makes it easy to customize the ASP.NET application without having to make any changes to the WSS.The internal users doesnt need any branding and hence could go to the internal facing WSS site to do workflow activities. Building features and getting to brand has been a challenge since I started WSS development.
Please let me know your thoughts.
SharePoint is big. Really big. As a result, if you plan to develop a home-brewed middle layer between your customers and SharePoint, be prepared to do a lot of work unless you plan only to expose a tiny piece of the SharePoint interface.
I recommend exposing WSS, and building your application within, instead of adjacent to, the WSS framework by creating Web Parts, pages, and lists that meet the requirements SharePoint alone cannot. This should reduce your workload to something manageable.
Take a look at tools such as VSeWSS or WSPBuilder to ease your WSS 3.0 development (should you use Visual Studio), and take advantage of SharePoint Designer where it is appropriate.
If you don't know a lot about SharePoint, creating and exposing a UI is going to be difficult. Can you do it? Absolutely. Should you do it? That depends on your requirements, and your level of expertise with SharePoint. In my opinion, the easiest path would be to create an ASP.NET application and have that interface with SharePoint, but I spend 90% of my day working with ASP.NET and only do SharePoint development about once a year.
In my experience, if you have to ask whether or not you should build a new product etc. with some tool, the answer is generally know. If I can't answer it myself with maybe some looking around on the tool, I try not to use it on a major project, because that means, that I don't know it well enough to get myself out of bind when something unexpected arises.
If you do a custom coat over WSS underneath, you are essentially writing code that already comes with the platform, especially with SharePoint. I assume that price is a factor in your decision making or you would not use WSS alone. In that case it can be tempting to leverage WSS as a code layer, but I would expect that it would be extremely difficult to make that work smoothly.
Depending on your business model I would look at what hosted SharePoint solutions can do, especially if you can host a custom SharePoint site definition on their platform.
It would take a very strong IP or financial requirement to make me consider wrapping asp.net over top of WSS.
I have worked with a solution that does that and it does work for our externally facing site, but it is a maintenance 'mare.
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.
We are currently in the process of drawing up a solution for an existing client, creating a number of eServices. The client currently have MOSS 2007. The proposed solution is to use MOSS as the launching pad for the eServices…
The requirement involves drawing up several online forms which provide registration facilities as well as facilitating a workflow of some sort. I have been told that the proposed solution requires complex web forms.
Most are complex forms with parent child details that have multiple windows. The proposed solution is to do some bespoke development, developing ASP .NET forms. These forms would be deployed under the _layouts folder of the current MOSS portal, inheriting the master page design on the current site.
I have been told that this approach make development and deployment more simple, as well has having ‘complete integration’ with MOSS.
My questions are:
Is this the best way to leverage SharePoint – it seems like the proposed solution is not leveraging MOSS at all..! I thought perhaps utilizing Web Parts would be better, but I have been told that this is more complex and developing more smarter intuitive UI is more difficult. Is this really the case? If not, what should be the recommended approach?
We will be utilizing Ultimus as the workflow engine. However, I have been recommended K2 Workflows. Anyone used both/have any opinions on either?
Many thanks in advance!
Kind Regards,
If they have MOSS 2007 Enterprise, you might consider if web rendered InfoPath forms can meet your needs for "complex web forms". When it comes down to it, probably all of these technologies can meet the neeed it is just a matter of what skill sets you and your customer have and how that will facilitate keeping this solution up to date.
Asim, what they propose is a possible solution. They can however provide the same functionality by making use of webparts. With the details you are giving us that isn't really possible to decide which option would be easier. I used both approaches in the same project depending on the requirements of each functionality.
I can understand that it doesn't seem like they are leveraging MOSS, but they actually are building pages within the context of MOSS.
I haven't really heard about Ultimus, I did use K2 in a proof of concept and I was quite happy with it. Then again, choosing the right workflow solution depends on your requirements.
We have had SharePoint where I work for a little while now, but we've not done a lot with it. We have an intranet with hundreds of ASP/ASP.Net applications and I'm wondering what kind of things can be done to integrate with SharePoint to make a more seamless environment? We put documentation and production move requests and so on in SharePoint now, but it pretty much feels like it's own separate system rather than an integrated tool on our intranet.
I've searched around to see what other people are doing with SharePoint but I've been finding a lot of useless information.
A great idea for you would be move your most used asp.net apps to run within the SharePoint site. Each app can be added either as a control directly on a pagelayout or integrated into a webpart (use the webpart to load child controls).
This would allow you to use the flexible moss interface to move the asp.net app into a unified information architecture so people can find the app easily.
SharePoint is really easy to roll out something that works, but creating a seamless intranet does require a bit of thinking outside of SharePoint itself (i.e. what should go where, which users need to see what, navigation structure...)
That is really a lot of work and requires lots of input from people outside the IT area.
A typical intranet portal segments functionality by department. Each department will probably have some custom web-based apps that you might have historically implemented in ASP.Net, and linked to from the intranet portal. With sharepoint you can start bringing the useful bits of those custom web-apps in as modular parts, so that the business owner of the portal can have more control as to how information is structured and displayed to his/her users.
Think dashboards, populated with custom metrics that only make sense to individual departments. That's one of the most obvious places to start. HR, accounting, IT, they all have metrics they want to track and display. They all have legacy systems that they might want to correlate information from. All this can be done in reusable web-parts. Since Sharepoint gives the end-user the control over layout, display, audience control, etc, you don't end up reinventing wheels all day.
SharePoint was designed to be a collaboration portal and document repository. If you have other business processes wrapped up in other internal web sites, you may not get much benefit from converting these sites into SharePoint sub-sites.
However, if there is signifcant overlap in your applications (contact lists, inventory, specs, etc.) you may want to make the investment to combine.
If you have InfoPath, you can create online forms. You can share your docs and edit them online. You can start an approvement workflow on these docs. You can create polls. You can create work groups.
Basically SharePoint is a giant and robust document store, but you can do anything what you can do in any ASP.NET web application. You can create e.g. custom workflows to automate business processes. We've worked for several customers to create corporate intranets and sometimes internet sites, so it really works. :)
But sometimes it's very hard to implement the requested features (a lot of workarounds).
Really its an intranet in a box. We pretty much run all of our day to day development tasks off of it. We keep documentation, track defects, manage people's time off etc. You can migrate your asp.net and asp applications to run under the sharepoint site. In the adminstration section you can set up web applications to run under the same site, but outside of sharepoint's control. That would probably help with the "feel" of it being completely seperate.
Sharepoint is really a shift in the way people have to think about web development and that's the key. You're no longer developing a standalone application, you're adding on to an existing framework. I would put it akin to having "silos of data" vs. a centralized database system which houses all the company's data. Once people realize that everything is connected, it will feel more like a seemless integration. My advice is to actively try and create applications in sharepoint and think about how to migrate existing apps on to it.
How about BI and reporting from an ERP?
When we know IE is uncapable to handle a page with 10000 table rows (without pagination)
Many don't realize but the success of a reporting tool depends on the performance of the grid object used - Excel and the SpreadSheet obj from the defunct Office Web Components are still the #1 in user's (accountants, managers, ceo) choice.
I think it depends on your environment. In our environment, we setup each department with their own pages and we use it for basic information, surveys, and the employee's homepage. We've built Google/Live Search and Weather.com widgets and roll RSS feeds using Tim Huer's RSS control.
One thing you can do is to create web parts to provide access to data from existing applications. Initially they could simply be read-only views, but depending on your experience they could be fleshed out to allow writes.
Another idea is to add links between SharePoint and your applications (assuming they're web based); that will at least allow a flow between them.
I haven't done it, but you could also theoretically skin SharePoint to look like the rest of your intranet.
Create libraries
Form libraries, documents libraries, slide libraries
Create standard or custom lists
Standard lists - announcements, tasks, contacts
Custom lists - suppliers, contractors, inventories, orders
Setup secure team discussion areas
Build shared team calendars
Create simple workflow processes on documents and lists