I'm doing an intranet which will not be accessible from outside the company's network and they want to display in Plone some nice statistics about file downloads and pages most viewed.
With the network constrain I can not use google analytics or any sort of external service, so is there any product that allows to count file downloads and pages viewed?
I've seen an idea on uservoice regarding file downloads, and maybe I could extend plone.piwik.now to get page view statistics but I have a hard time thinking that Plone doesn't have any product that (maybe partially) suits this use case.
Any tip?
Essentially, you've two options, you can use one of the existing HTTP log analysis tools and scrape the information you need from those reports, or you can write a custom analytics tool in Plone.
We're currently working on a version which we plan to release as open source later this year. Essentially the patterns we're using is that we have a small javascript which passes parameters to our lightweight logging app. We're than able to show results from the reporting app like "top downloads" in portlets, even filtering by section and keyword.
I don't know about Plone add-ons (nor do I understand why you'd want to use a Plone add-on to do this) but Webalizer and/or http://awstats.sourceforge.net/ are two of the most popular choices.
Related
I'm looking into upgrading a .net 2.0 app. The app is used by the public authorities of a certain city to keep track of expenses and generate reports and forms.
The reports and forms were generated in VS2005 using Crystal report. They follow a well defined layout, like official documents usually do.
I am looking at options to upgrade the application and the main problem I have is in determining how to deal with the crystal report files.
I have successfully upgraded to VS2008, but any version after that doesn't have CR anymore, so my company would have to pruchase CR separately and because the client and my company are both tight, I'm looking at alternatives...
The obvious one is using SSRS. I have never touched it before in my life, but after playing around with it for a bit, I get the impression that it is not very well suited to generating forms with lots of non-tabular content and lots of formatting. Or am I wrong?
It seems that every line has to be drawn separately. There is no (that I can see) accurate way of positioning lines for formatting...
But I'm just a beginner, so I might be getting this all wrong?
If that is the case, are there any other alternatives to CR and SSRS?
I was thinking of maybe having a separate MVC web site project in the solution. Have that generate the layout in html and css with data from my entity model, then view the result in a (built-in or not) web browser. Am I overcomplicating on this?
I really need advice from somebody who's done that kind of thing before.
What SSRS is good for:
Talking to SQL Server, much faster than other products as it in many cases retains the database better when in other programs IMHO they repeat query at times.
Designing collapsable grids and chart objects from datasets. You can have 'groups' that can nest aggregates of collapsed values and can be un collapsed or collapsed on demand based on expressions, parameters, or a recusive parent set.
A web service for deployment ease where you can deploy one or many objects. You can also write add ons for this service with C# and the ReportingService.asmx web service.
You can talk to the web service directly in a 'form' object in HTML and manipulate it's output.
You can schedule reports to send out via email and file saves automatically to clients or internal users.
What SSRS IS NOT GOOD FOR:
It is not event driven hardly at all except for parameters. You cannot click on many things and get other parts on the form itself to update. You may do an 'action' that goes to another location, report, or site. But in essence you are calling a seperate object, not the same instance again.
Multiple layers of reporting. Beyond tweaking tool tips you cannot do 'hover over' reporting without hacking SSRS. You can make javascript windows show other reports but it is not baked in to SSRS. So you are either clicking into new reports or tab stops in a report but not getting hover over quick objects beyond text and expressions that are in tool tips.
What do you want before considering what you need to impement?
I want to input and export things while talking to my database - ASP.NET with potentially HTML 5 or MVC4 if you want to be very new. ASP.NET is made for actively talking to a server and taking commands IN as well as OUT.
I want a form to auto update periodically on a page as a landing site and dashboard - AJAX and Javascript on top of HTML, Java or ASP.NET.
I want to create reports that exist on a Server and can be hosted on a wide variety of platforms in .NET via web service calls - SSRS.
SSRS's biggest selling point to me is it's reusability once you dial a report in. They are pretty easy to create, easy to configure, easy to deploy, and if you get a little advanced in calling the webservice you can get SSRS report objects in other technologies if you want.
There is Crystal reports for VS2010 and VS2012. It is just not shipped with them. You can download the installation from here: http://scn.sap.com/docs/DOC-7824
I am running through the same decision process at this time. There is a .NET product from a company called "Windward" that will allow you to design your reports in Microsoft Office. If you are in the MS ecosystem already or want your users to design reports instead of always calling on you, this might help.
Their template design tool is called AutoTag and you can deploy these template to their .NET based engine in a few lines of code.
I know the question is regarding SSRS vs. Crystal comparison but thought you should know there are other alternatives and some can make life easier
Ryan
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 my sharepoint site to allow a user to search content in a known collection of RSS feeds. I figure conceptually a few ways to do this
crawl the feeds at their source (Yikes!)
Pull the full articles into my sharepoint site, then let my crawler crawl it
Make use of an existing index (like google)
search the full articles, on demand, using something like a google utility (my preference)
So can I somehow, from my sharepoint site, allow a user to search the full articles from a couple dozen, named, rss feeds
thanks
Cary
I don't see why there is a problem with crawling the feeds at their source? That would seem to be reasonable.
It is fairly easy to create a content source to point at the feed and select the correct indexing schedule. If that does not work then you can try a more complicated approach.
Be aware that copying the content of another website to host on your own could have copyright implications (not too mention the risk that any inflammatory content would appear to be published on your own site).
--update--
Try reading the target sites robots.txt to see if (it even has one) it has a desired frequency. Otherwise it depends on the depth of the site you would be crawling.
If you are crawling just the rss feed xml, I suspect you could do that every hour without annoying anyone. Otherwise if you reach into each article, you may want to limit that. It really depends a lot on any relationship you have with the target site and type of site you are hitting.
Checkout this article for a little more info on how SharePoint deals with robots.txt
(p.s. the target site did not put the articles on the web so no one would read them)
The out of the box crawler will respect robots.txt and there are provisions for crawler impact rules that will lessen the chance that SharePoint will perform a beat down on the external site.
We are researching the various options that exist in our environment to create an Employee Directory. We have a SharePoint portal, AD and recently moved from Lotus Notes to Exchange. Our current employee search is a custom Notes DB that has since been retired.
Since moving to SharePoint an year ago, we've used a custom list using SharePoint Profiles that are updated from AD. But the simple list interface isn't very user friendly and is very slow. Sone of the requirements include type-ahead, pictures, and details of skills/certifications and other demographic information etc. We are considering building an ASP.NET or SilverLight application that can consume the information in the SharePoint list. With the introduction of Outlook and the Global Address List, we are now wondering if it might be easier to build something within Outlook.
Has anybody traveled a similar path and what would you advice us to do?
Microsoft has a huge set of offerings for Collaboration and Social Computing in Sharepoint.
See this document, pages 8 and 9 for information about features related to an employee directory, including details of skills/certifications and other demographic information.
A la carte availability of individual features (such as People Profiles and People Search) and pricing may be an issue, but you may want to look into buying something rather than building it (if you can get the pieces you want for a price you can afford).
Sharepoint can connect with Outlook to keep the lists synchronized if you want to use outlook. And there are definitely a lot of different ways to change the way the lists are presented in the Sharepoint portal to make them more user-friendly. Having those details on the portal will certainly be a boon when combined with the powerful search and indexing features in SharePoint so you can identify employees based on their profile details easily.
We use the people search for this pretty effectively. We populate data in AD, then connect profile properties to AD attributes. That's only if you have MOSS, though. If you're working with WSS, you'll have to build something more custom.
One gotcha, though, is that the People Search out of the box doesn't easily do partial searches (i.e. searching for "john" doesn't match "johnson"). That's a big downer in my mind. You can use Ramon Scott's approach of a Content Editor Webpart with a form and some Javascript to work around it, and you can also get there via the advanced search box (albeit indirectly), but it sure would be nice if it were easy to make the default search box do partial name searches.
I recently just discoverd a somewhat easy visual basic script that draws information from the active directory where you can specify which OU to draw from where it displays all user information in a simple .HTM page. it includes a search bar, recognizes patterns (address) (company telephone number) etc... If you would like i can post it for you. you only need to fill in a few sections (display name for directory, OU, OU display, and tags) and you can always change the way things look too.
This should be taken care of by using the My Site feature that's available within SharePoint. You will then be able to search SharePoint users by skills, certifications, projects, and educational qualification.
Please refer to the SharePoint Planning and Deployment material on TechNet for more info.
SH.
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