I have been tasked with developing some large ERP applications (some legacy apps being rewritten and some new apps) in Sharepoint. As I've come up to speed in Sharepoint, I see the value and ease of creating team sites, and the examples I've found online and in books are all tailored to intranet department portals, or simple line-of-business apps for companies that don't have large legacy ERP systems. I have begun to believe that if one is going to create a large application that interfaces to several different legacy systems and spans several departments, that building custom webparts in Sharepoint just isn't the way to go.
Is Sharepoint a viable application framework for creating and hosting large ERP applications?
If so, can anyone please point me to references describing the architecture of such a system?
If not, can anyone please point me to references that I can cite as arguments for not using it?
As someone who has spent the last 15 years writing ERP applications I would say Sharepoint would be an extremely bad choice upon which to build an ERP product.
The Sharepoint table structures would be very ineffective for producing reports.
There is very limited capability for validating data.
There is no native support that I am aware of for maintaining the integrity of relation ships between documents.
Sharepoint works well as a portal into existing LOB applications, not as a platform to build a data-rich application on top of.
I'm currently deploying a ERP system written in Sharepoint for a client. I've been working on this for about a year now and from what I've seen, Sharepoint introduced as many obstacles as it made things more complicated.
Things made simpler:
Credentials automatically synced to AD.
Document handling and versioning out of the box.
Great Office integration.
Things that sucked:
You need to learn the Sharepoint way of doing things.
You have another dependency in your ERP.
It's pretty clunky.
I would recommend reading Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs before making a decision
I use SharePoint 2007 (MOSS) at work as part of a larger ERP installation. We heavily use the Business Data Catalog to interface with external systems and make their data visible and searchable within our MOSS portal.
In our architecture, CRUD operations on the ERP data are handled in our ERP line of business systems. MOSS and the BDC then pull the data out of the ERP database and display it as datagrids embedded in various portal pages. For example, the HR site has a MOSS page for tracking the current status of pending performance reports.
Another compelling feature of MOSS and the BDC is the ability to expose BDC datasources to the MOSS search service. For example, when a user searches for John Smith using MOSS search, the public ERP record for John Smith is inlined with the search results. Clicking on the link in the search results redirects the user to the right page in our ERP system, rather than taking them to a MOSS page.
We don't use MOSS exclusively as an ERP system, but we do use it as a presentation and reporting layer on top of our ERP system.
The MS Dynamics AX system utilizes Sharepoint extensively, in fact there are tool kits that allow users to build web parts and so forth that extract data directly out of the base AX objects. Here is a link that talks a little about the Sharepoint integration AX+SP. Currently there is still a significant portion of AX that does not reside within Sharepoint, but their direction appears to Sharepoint enable a significant portion of the application. I do not think that an entire ERP system could reside within the Sharepoint infrastructure, but from an MVC perspective it could certainly become your View infrastructure. It appears to me that this is the very direction MS is heading, but I'm just making hypothesis on their future plans.
Building custom webparts in SharePoint would not be the way to go for complex legacy systems.
SharePoint would still give you a lot of mileage if you created a custom navigation provider for the main navigation (based on an xml file for example). This would allow custom asp.net pages to display "like" they were still part of SharePoint, giving the illusion of one all encompassing app.
I think the only reason people want one huge application has more to do with Information Architecture, look and feel and findability than any technical architecture reasons.
A solution that creates separate websites for appropriate applications that are still skinned and linked into the SharePoint information architecture and still searchable from the main interface could solve the "need" for the "Enterprise" part of ERP, while still creating appropriate solutions for what are really separate applications.
The mental model I use is not so much building the apps "in" SharePoint, but creating a 'window" in SharePoint to expose the app.
Related
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.
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 got an requirement for implementing captial expenditure lotus notes application in sharepoint. It's having nearly five massive forms with all expense calculations and workflows.
What is the suggested approach in sharepoint to implement this?
I would agree that creating a custom ASP.net/SQL server web app would be the way to go if you have some ASP.net programmers available, though I'd recommend against embedding it via a Page Viewer Web Part. You can integrate ASP.net web apps directly in SharePoint, no embedding required.
If you don't have ASP.net programmers available, you can certainly do it in SharePoint and it may not be painful. The key issues are where you need to store your data and how relational the data needs to be. If the requirement is to store data in a relational DB, it becomes complicated to do it in SharePoint.
On the other hand, if you can imagine recreating your application's data as a collection of Excel spreadsheets, then it will be pretty straightforward to do it in SharePoint. In the simplest scenario, you could do all "development" using the SharePoint web interface. You would create a custom list in a SharePoint site for each expense form, then customize the site's default.aspx page to display a link the newform.aspx for each list. If the wokflows are basic notification/approval types, then you can also attach SharePoint built-in workflows to the lists via the web interface.
If you need custom form layouts, custom workflows and dynamic data filtering, then you could use SharePoint Designer to accomplish a great deal of design and development. Without more information about the existing application and workflows, it's impossible to say exactly how you should do it. But make sure you consider what parts of the existing application are requirements and what parts are just legacy functionality. If you can simplify the application, this is a great opportunity to do it.
While you can do it in SharePoint, it will be painful. You may be better off implementing the application as a stock ASP.net/SQL DB application and embedding it into SharePoint with a Page Viewer Web Part.
You can also skin your custom application to look like SharePoint using one of the SharePoint master pages as a template and link to it from your portal.
For added SharePoint integration, you can use Data View Web Parts or the Business Data Catalog (MOSS only) to query your expenditure application database and embed small reports and key performance indicators throughout your portal.
Alternatively to a Custom web app:
Create custom web controls implementing the forms and kicking off the workflows with custom layout pages to host the controls?
A site definition (just feature to add the pages+layouts at a pinch) to host the created pages "just so" in order to rely on "form1.aspx" being available always.
I would not try to "push" OOTB SharePoint functionality envelope to avoid creating custom code. Easier by far to
If you are going to do extensive workflow work in SharePoint be sure to consider buying an add-on like Nintex workflow or Blackpoint. It is almost always worth the expense over creating workflows with Visual Studio or SharePoint designer.
It's not easy to implement a solution for this in SharePoint, but we have a SharePoint App we're releasing in March 2014 which is a great capital expenditure workflow solution. http://budgetworkflow.com
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
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have heard that Microsoft SharePoint was used by many companies. Could someone tell me briefly what is SharePoint and why is it popular?
What is SharePoint?
The latest version of Microsoft SharePoint software is really two different products:
Windows SharePoint Services is a free download for Windows Server. In the latest version, known as WSS v3, collaborative web sites templates include basic blog and wiki services along with list templates for Image Libraries, Document Libraries, Contact lists, Calendars, Tasks and much more.
Microsoft Office SharePoint Server 2007 or MOSS for short is built on Windows SharePoint Services. As a member of the Office Server product platform, it leverages the Microsoft Office client software to provide content on the web. Integration with Word, PowerPoint, Excel, Access and InfoPath provide rich web content from familiar content creation tools.
Why is it so popular
File Sharing
SharePoint originally became popular because it was an easy way to share documents on the web. Many organizations that adopted SharePoint in the 2003 versions capitalized on the ability to upload documents to Document Libaries and share those documents with others.
Company Extranets
One great example of this web based sharing, is a company extranet where users are not all in one location or authentication domain. Using form based authentication, accounts can be created for people across physical and company boundaries. By allowing one place for shared documents around a task rather than a corporate entity, SharePoint goes way beyond the common file share.
Content Management
There are plenty of other Content Management Systems, but MOSS incorporated the functionality of the previously name Microsoft Content Management System which itself often cost more than MOSS alone.
Search Search is greatly improved in SharePoint 2007 technologies. Search results are security trimmed, relevant and performant unlike the previous 2003 version. Bad search in SharePoint 2003 products lead to a lot of dissatisfaction with the product.
what is sharepoint
Sharepoint is really two different technologies: Windows Sharepoint Services (WSS) and Microsoft Office Sharepoint Server (MOSS). WSS is free and it comes with Windows Server 2003. MOSS isn't free.
WSS provides lots of out of the box functionality for managing documents and projects online. It manages documents in "document libraries." These are folders with permissions and different views of your documents. Projects, tasks, issues, or any tabular data, is managed in lists. Lists are similar to document libraries. They have permissions and views as well. It provides some simple search as well.
MOSS provides a better search (it's supposed to at least). It also has more publishing capabilities (WSS doesn't). And you have more control over page layouts. It's meant more for internet style sites while WSS is more for intranet sites.
and why is it popular?
WSS is popular partly because its free and partly because it just does so much out of the box. You can solve many common office requests with WSS. Stuff like issue trackers, project management and document management are trivial in WSS. That said, its a jack of all trades - good at many, master of none.
MOSS is probably less popular because its not free and having used it for a year, I don't see as much value in it as WSS. Search isn't that great. It does do a good job of creating a company directory.
I've been working with SharePoint since v.1 and I could tell you that SharePoint is a:
Document management server
Web content management server
Portal solution
Search engine
List-based repository
Collaboration site
Replacement for file shares
etc etc...
...but if I have to summarize in one sentence what SharePoint is I would say:
Sharepoint is Microsoft's Web OS.
That's real the secret of its success. Many people imagined the Web OS as something like these. A Web OS is not something that is meant to look like a desktop OS. A Web OS should be a WEB PLATFORM in which all sort of applications can be built on and users are able to collaborate with.
Think of SharePoint as the 2.0-era version of Windows :-)
Previous answers describe what sharepoint is, but don't do a good job describing why it's popular. Yes, it gives you all that neat doc-management stuff out of the box. Yes, it integrates tightly with Office.
The OOB features are 1/10th of the whole story. Sharepoint exposes a comprehensive .Net object model that lets you customize the thing to your hearts content. People are coding amazing things with MOSS 2007. With the object model, you can build and customize sites via code, in response to external events. You can write custom "web-parts" (controls hosted on special pages) that consume both internal (sharepoint) and external data.
Check out Sharepoint Blogs to see what people are doing with it.
Very good points so far but I'll try my best to add something. :)
SharePoint is not just 2 technologies. It is a set of products and technologies brought together by Microsoft into one immense product that comes in 2 flavors. The 2 flavors are Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS). MOSS does come in standard and enterprise.
[Some of the technologies used in SharePoint: Windows Workflow Foundation, ASP.NET, Web Parts, XML (included XPath, XSLT, etc), SQL, Web Services - to name a few I can think of off the top of my head]
No matter the version you choose, SharePoint allows for web-based capabilities to allow users to create, organize, distribute, and maintain information. Because of this, the most common uses for SharePoint sites are intranets and project/team sites.
SharePoint also has incredible possibilities as an application platform. Looking at the web part and workflow pieces alone you can begin to realize the potential. For example, automation of authorization processes within an organization can quickly be developed without any code using SharePoint Designer. (FYI: more complex workflows would require Visual Studio but many simple workflows can be designed using the point and click functionality of SharePoint Designer)
While MOSS only extends upon the WSS, it does add a large amount of functionality that can be very important and useful to a business. Some of the more important features available in MOSS and not in WSS are: records management, document retention and auditing policies, browser based forms (InfoPath forms without installing InfoPath on client machine), and some of the business intelligence capabilities. Amazingly we're seeing interest in the social networking features of MOSS too. (easy to read list of features not in WSS that MOSS has)
Why is SharePoint used? I was doing some research not to long ago on this exact subject and I found a research study that cited 5 key benefits:
Ease of information access
Streamlined internal communication
Increased end-user productivity
Optimized document management practices
IT time savings
Sorry if that turned into a bit of a ramble.
It's a collaboration website. All of the members on a team can update a single calendar and upload shared documents to a single repository.
I think in this case Wikipedia have it right
Windows SharePoint Services (WSS) is the basic part of Microsoft SharePoint, offering collaboration and document management functionality by means of web portals, by providing a centralized repository for shared documents, as well as browser-based management and administration of them. It allows creation of Document libraries, which are collections of files that can be shared for collaborative editing. SharePoint provides access control and revision control for documents in a library.
In a nutshell Sharepoint is all about corporative management and collaboration features. Your company have a Windows 2003 server? Here you go. WSS 3.0 is here up and running.
SharePoint is the reason I'm considering taking advantage of a suicide booth.
In all seriousness, the rest of the answers are spot on. The differences between WSS 3.0 and MOSS 2007 commonly trip people up ("why pay for MOSS when WSS is free?" for example). SharePoint is a very complex and rich product that is integrated into other Microsoft applications, like Project Server 2007 and Team Foundation Server.
Why should you care about it? It depends. There are quite a few opportunities out there for experienced SharePoint developers and administrators. It can very quickly become the singular focus of your career if you decide to put a lot of effort into learning it.
Microsoft Office Sharepoint Server (MOSS) is a combination of two previous products, Microsoft SharePoint and Microsoft Content Management System.
It has a large number of features out of the box that are very desirable for any single system, including hosting files with customisable metadata. Page and file publishing that is enabled for end users, excellent search... the list goes on.
Essentially it is designed to enhance and organisations collaboration activities across the entire enterprise, leveraging the organistations existing Office application to create an enterprise system.
Sharepoint, MS OFFICE proxy circa 2003...
remember when you emailed a copy of that word doc out to the whole company, that's what sharepoint is for, but apparently you missed the introductory gotomeeting training course.