We have a heavily customised SharePoint publishing (WCM) site that uses no web parts in order to meet with XHTML and (AA) accessibilty guidelines. The trouble is that the search functionality is not generating any usage statistics (Usage reports within Search Administration in the SSP). We know this is down to our customisations because we have a couple of the OOTB team sites in the farm which are generating search statistics. We are not sure where/how we need to fix this. It seems we may need to wire up a call to the search.asmx web service but I'm not sure. Perhaps we need to call something from within the SharePoint API as part of our call to the search service? I'm not sure.
Has anyone out there built a heavily customised SharePoint site (no web parts) and are logging search statistics, can you comment on how you did it? Or can anyoone provide insight into how the staistics are generated?
If it helps we are running a medium sized farm with 2 WFEs, 1 Index server and 1 SQL Server box. All Windows 2003 R2 SP2, 32-Bit. MOSS 2007 SP1 (plus December CU) Enterprise Edition.
Thanks,
James.
have you checked Usage Reports in the CA-->Operations tab ?
Our (intranet) site is heavily customized and the Search Usage Reports are turned on (they should be by default). You do have to enable ALL usage reporting options though, both in the SSP as in CA, the key one being "Enable search query logging.", in the SSP -> Usage reporting. I have also found that disabling / reenabling this option will sometimes help if it is already supposed to be running.
P.S. I will vote to move this question to serverfault as that is where this question belongs.
The SharePoint search statistics is only gathered when you use the standard search webparts (SearchBoxEx, CoreResultsWebPart). This is because they use an internal hidden object to perform the searches, which, in turn, logs to the statistics. AFAIK there is no way (except possibly reflection) to write to these logs when using a custom search webpart.
Related
Our content database for WSS is growing out of control. I'd like to be able to do some reporting that will show which sites are using the most space, as well as what documents or document libraries are using the most storage space. These types of features doesn't appear to be built into Windows Sharepoint Services so I'll need a tool or some way to query for this information.
Thanks for any ideas.
There are multiple ways of getting the information, one of the easiest is most probably via this tool: SharePoint Space Monitor
(the link I had is now dead, but you can still find the software online)
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.
I have a requirement to select some data from a table in a database (SQL Server) and display it on a page in a SharePoint site (MOSS 2007).
I have a little bit of experience of MOSS, so I know I have a couple of options:
BDC
SSRS
or possibily even a custom ASPX page.
I've never really worked with any of these. Can anyone advise on the +/-'s of each?
It all depends on what functionality is required once the table is displayed in SharePoint. Do you need extra bells and whistles or is a dump of the data adequate? (Think about the future as well.) Here's some thoughts...
Business Data Catalog (BDC)
If you want to nicely integrate the SharePoint look and feel with your data as well as get some cool functionality, BDC is a good solution. There is no need to program anything and these are the features you get. However if this data will only be used once in one way then it is probably overkill.
You would need to roll your own XML description of the data so SharePoint knows how to pull it from the database (or use something third party like Lightning Tools). As Colin mentioned it requires the Enterprise license of MOSS.
SQL Server Reporting Services (SSRS)
If Reporting Services is already available for use then this is the quickest and simplest solution. It works well but can get painful as more advanced features are required in your reports.
You should be able to use the Report Designer wizard to point to your table and set everything up for you. There are SSRS web parts that can be used within SharePoint, or indeed you can run SSRS inside SharePoint using SharePoint integration mode.
Application Page
This method Steven mentioned lets you integrate an ASP.NET application into SharePoint (such that it can be accessible by a URL within your SharePoint site). This allows anything that ASP.NET does, and the code-behind will be aware of SharePoint so you can tap into that if needed as well. The cons here are code access security and deployment.
See this webcast for how to do it.
Web Part
Similar to developing an application page but much more integrated with SharePoint. A custom web part is very powerful and allows you to integrate ASP.NET code on a SharePoint page. As you would know web parts can be dragged to whatever location and give a consistent properties pane. Again, code access security and deployment needs to be considered.
If you like designer view in Visual Studio then be aware this isn't the approach that Microsoft push. You can however use something like SmartPart where you would develop your custom app as a user control and the SmartPart wraps it into a web part. I'm used to doing it the MS way now and actually prefer the additional control this gives, however it can take more time.
Page Viewer Web Part
If you don't want to touch your SharePoint installation at all then have a look at this web part. It takes a URL as parameter and displays an IFrame containing the page that would be your report, either in SSRS or standard ASP.NET.
The downside from this lack of integration is problems with sizing the IFrame, and possible security warnings from the browser if accessing the URL in a different domain.
Don't forget the DataView Webpart. It has a pretty small developement footprint and works really well as a first "cut" if you are unsure as to how hardcore you need the final result to be.
It renders using XSLT, giving you full control of the final HTML, so it can do some pretty things with Javascript and co.
For a very simple example of charting.
Have you ever used the .NET Framework do develop webpages?
MOSS 2007 uses this framework for master / template files.
So your best choice would be to create an ASPX template file to display the results on the webpage.
BDC is the way to go if you want to keep it "strictly Sharepoint". The problem is, it is only included in the Enterprise edition of SharePoint. If you have the Standard edition, you could go for SSRS and the SSRS webpart, or, create your own webpart. That way you can use your data display anywhere in your site and it's also ASP.NET compatible.
As Nat said - if all that is needed is to display some data from a database on a page - the DVWP is a great solution. Just open your page in SharePoint Designer, add the database connection, and drop the web part on your page. You can use any of the several pre-formatted layouts, or design/tweak your own so the data is displayed as you need.
Relatively straightforward, lots of HowTos online, and far faster/easier to setup than something like BDC.
i have the sharepoint site , infact it is MOSS site. I want to show the reports on share point site. Is there any facility available for to do so? Or is i need to develop any webpart for same? please guide.....
reply will appreciable....! :)
I suggest you make web user controls and have gridview or any report that you want and upload it as a webpart.
let me know if you need further help.
Since you are running MOSS you have a SQL Server which means you have a license for SQL Reporting Services (SRS). SRS integrates with Sharepoint very nicely, one in standard mode (reports are hosted within SQL) and another mode called "integrated" where the reports are actaully housed within SharePoint and revisioned/versioned as such. If SRS doesn't work for you use a page viewere web part to pass through the reports from the reporting engine of your choice.