Is there an out of the box solution to check the validity of documents? Let's say when a document has been in a document library for 1 year, the author should get a warning, an e-mail for example, to revise the document.
I didn't find this in SharePoint. So I was thinking of creating my own feature for this:
A timer job which runs every night and check all the documents in the site collection
The timer job can be configured through an admin page in the central admin, for example to configure on which site collections in a web application the job should run.
My concern is, when running this in a heavily used environment, doesn't it burden the servers too much? Let's say for example an environment with 100.000 documents spread out over 5 site collections. And how about looping through all those document libraries in various SPWebs, use an SPSiteDataQuery to retrieve all those documents and loop through that collection? Because opening each document library in each SPWeb in 5 SPSites...
Or is there an other option to accomplish this? With workflows? Because in the end, the owner of the document receives a warning and he needs to confirm if the document is still valid. I haven't touched workflows much to be quite honest.
I would like to hear your thoughts about this.
Maarten.
This SO Question may give you some ideas - workflow/timer jobs/3rd party etc as in essence your requirement for email alerts when documents are 1 year old is basically the same as 'a task is overdue'
Dated reminders in sharepoint calendars
Re: Load - well I can't give you specifics as every situation is different but you've got the ability to run this overnight so I can't imagine that it would really be much of a problem.
Also Remember your not actually retrieving/parsing the documents themselves, just the record containing the documents meta-data such as title, location, modified date, assigne to etc.
this sounds like a job for powershell.
write a little script that queries the document lib's for documents that are older than one year.
then send a email alert or create a task for the user to update the document.
also i would not worry about having 1000's or workflow runing. WFF is an enterprise product. i have had over 60000 running without any problems.
Related
I was given a task, a list of 3k+ mailboxes DBs on it. They want me to review the list if it can be deleted and will not affect any DBs/Apps we're supporting(about 20). Any advice on how to do this w/o going through all the 3k+ DBs?
Like if I check this one DB/App, I can see if there are any mailboxes DBs connected to it? Thanks.
You can easily list databases in the mail subdirectory, but that's hardly definitive. (A mail database can be in any subdirectory.) You can also create a list of databases that use the Mail template. That's hardly definitive either (any database can use the Mail template.) You can go through the Names.nsf (and any secondary address books) and look at the databases listed in the various Person documents, but that's about it.
Further, there's no concept of "connected". The code in one database can try to open another, but chances are that "connection" is fleeting and during runtime. And the code can be #Formula, LotusScript, Java, or even a Web service.
So as I see it, you have two options, 1) Comb through all the design synopses of all the databases and find all of them that reference the mail databases, or 2) Perform the "Scream" test. Make the mail unavailable and see who screams.
I am new to share point and still learning all the best practices, but I have a parent site called "Clients" and a sub site for the each of the clients i.e. Walmart, Kmart, Target. Is it a best practice to have a unique document library for each of the sub sites and the parent site. Or to use just one library for all of them. And if I were to use just one how would I set that up?
Thanks
Sites and Pages are not the same!!!
I wish that was more clear. In this case I want a SITE with the customers. Then each customer will have its own page. This way I can use the same apps across all the customers. I will probably need to learn how to create a customer template next.
to start with you need to answer few questions first, and these questions will help you to decide on an approach.
Do you have unique documents per client
will you control access to your users, that is each subsite will have unique permission, users for one client say for instance walmart should not access documents of Kmart
what would be tentative size of each documents and how much will that grow over the year
above are few question which will help you to get started, being said that, I will start creating a site and if the look and feel are the same for my other clients with little changes, then save the site as template.
This template will be my base for other client subsites/ sites.
will also create a global document library, which will store relavant documents which can be sharable across subsites
If required, each client will have their own subsites and own libraries for maintainabilty. this will also help to move subsite to its own site collection if there is hugh growth in data for a particular client.
You can also plan to use search, and webparts like content search query webpart to mashup data from subsites.
Another area to explore is metadata and Information architecture.
When you ask "Is it best practices" for the multiple Libraries or a single Library. From what you have described and Ramakrishnaraja was trying to say, you need to figure out what would work best for the situation. I don't know if you mean to have a different group called "customers" or if that is the same as "Clients" I'm going to respond assuming you mean both parties are the same.
Ramakrishnaraja points out that you have one central log on page "Clients- 'Main'" which leads to the other pages. If you want to the users to be divided into groups that have access only to the documents within their repective page then you should create multiple Document libraries. If you want the users to have access between the sub pages and use/edit files between the sites then best practices would be to have one Library for the Site.
I hope this helps you. Ramakrishnaraja makes a lot of good points and approaches it from a design overview rather than a specific response to your situation so try to use his post from that perspective.
Entity has a custom field based on which, some security roles should have access to records of that type and some should not.
Javascript can be used to close form after checking roles. But I'm looking for back end solution that will disabled access to this records in workflows and searches too.
For example, product should viewable by everyone if manufacturer is our company and only by Competitor Products Specialist if other.
You might be able to write a plugin that would automatically share the record with the appropriate Users/Teams. When somebody updates that field, the plugin would run and share/unshare the record according to your business logic.
Disclaimer: I haven't actually tried this before, and there may be performance issues if you have lots of records (and therefore lots of sharing records).
I ended up writing the plugin that works on pre-Retrieve event and modifies retrieve query by adding additinal filter by field.
I'm looking at designing some core information systems at a new company I'm working at (described one of my ideas here Workflow system)
I've thought a bit more, and am strongly considering using sharepoint for a lot of the heavy lifting seeing as it comes with so much out of the box.
However, I'm not sure how it will handle the high volume of data we'll be throwing at it. I read the MS whitepaper (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409), and it says about 2000 items in a list is about the limit using traditional design methods.
But first a bit of info on my plan and data structures :
We have multiple clients. Each client has multiple applications. Each application will have multiple, ongoing jobs (or process runs).
Each application will store significant correspondence and documentation. Each job represents the processing of a data file on a single run, and stores information about the job such as the postscript file, postal manifests, etc.
Job volume will be about 50 - 100 a day. Each job will have a workflow, triggered by external programs. Then, say on a "job scheduler" page, production staff can schedule the jobs and perform custom actions on the job (written as plugins).
I was thinking the jobs would sit outside and accessed via the BDC, but I would still like them represented in sharepoint lists, to add in sharepoint functionality and reporting, and they'd be accessible in multiple places
e.g.
Application portal - see jobs for application
Production scheduler - see lists of upcoming jobs, assign to resources, trigger other functionality (e.g. copy print file to printer, produce mailing machine file)
Invoicing view - view completed but uninvoiced jobs, export to accounting package
Client view - client portal displays jobs, invoices, stock levels (from external warehouse system), documentation, change register / helpdesk
So basic info about the job would sit in the BDC, but then sharepoint would capture additional metadata about each job. Also, down the line we might put in more advanced workflows using WF or something like K2 blackpoint / blackpearl.
Is this feasible? Any resources you'd recommend to read to get up to speed?
To use SharePoint, you should concentrate on what SharePoint is good at and what it is designed for.
SharePoint is a great collaboration portal, it is not so good as a simple high volume database. So...
You can setup a small site for each client and subsites for each job. The goal of the "job site" is to display (using a webpart perhaps) the relevant upcoming jobs, a list of job errors/exceptions and relevant team documentation on each job.
Separate sites can be created to give a particular "view" of the jobs. E.g an "Invoicing" site can be created to give a view again from BDC webparts of what is requiring invoicing.
https://iwsolve.partners.extranet.microsoft.com/SDPS/ may provide some help.
Don't try and store huge amounts of information in a SharePoint list, just because it may be possible to "tag" it with meta data. A database table is perfectly able to include columns supplying additional information if required.
Think about it this way. If you are creating 50-100 jobs a day, putting that data into a list pre-supposes your sites users are going to want to enter metadata on those jobs manually. I thought not, so create systems you need in order to get the metadata stored correctly at source, or store metadata about the "types" of jobs within a SharePoint list and allow SharePoint to match the job type with jobs in the BDC.
SharePoint will help you to integrate all your systems information together, but unfortunately it looks like you have a lot of work to do just planning what information should go where and how each type of use will view it.
Please take a look at this blog post I wrote on managing large SharePoint lists for better performance- it might offer a bit of an explanation for the 2,000 items issue, which is not actually a hard limit on the number of items in a list, as SharePoint will support up to 5 million items per list. One way around this would be to create and maintain different views that filter by an indexed field to show you different items, up to 2,000 at a time. Hope that helps.
Dina Ayoub
Program Manager
Windows SharePoint Services
SharePoint is probably quite a good fit for the UI side of things, though you'll need to think carefully about which parts are stored and modified in SharePoint lists and which parts are stored elsewhere. That's not so much a SharePoint issue as something you always have to deal with when you have multiple data sources.
I'd probably use a SharePoint list as the primary store for jobs, to avoid any sync issues and make editing easier. The volume of data shouldn't be an issue - just make sure you aren't trying to display 2000 items at once - it's the view, not the list itself that runs into performance issues on large numbers of items.
Tough question Dane... I would like to know a little more about your design / vision before giving an opinion.
Based on what I read in your question I would not use SharePoint 2007 as a development platform for this application.
1) Development experience in SharePoint 2007 can be painful and unproductive at times.
Hard to debug
Steep learning curve
2) Easy to get in trouble with performance
Data Layer is complex and can require expert SQL / SharePoint Admin skills to make platform scale.
Content databases should not exceed 100 GB.
3) Deployment can be extremely difficult depending on what you are doing.
4) New version will be released in the next 12 months.
Just my .02.
I have a departmental maintenance that needs to be done roughly every 3 months. The maintenance itself can't be automated (it involves physically swapping a primary and spare piece of networking hardware to verify the spare is still working correctly).
I could put this as a recurring event in Outlook and give it a two week reminder window, but I don't want it to be tied to an individual's account (if I or one of my coworkers leaves the company, I still want the reminder to go to the department).
We're working on implementing Sharepoint and my group has a maintenance calendar, which seems like a lovely place to put this. However, there don't seem to be dated notifications for the events. You can set up notifications if the event changes, and you can subscribe to the calendar and set up a notification via Outlook, but that notification is still a per-user notification.
At this point I'm probably just going to write a cronjob on a linux server that emails a reminder, but I thought I'd ask if there's a way to do it using all these expensive collab tools we're putting in place.
So, any idea how to get notifications of a dated event that is not tied to individual users? I also welcome being told that my entire take on the problem is false as long as it involves some good alternatives. Thanks!
Expanding on Andy's answer (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) if you just put code to send an email in the Execute method of the timer job this doesn't give you anything more than cron.
What you could do is to write code to iterate through the Calendar (actually an Event List) finding any events due soon and sending email to whomever is in the Assigned To field. This could then be called from the Timer Jobs Execute method or using a normal scheduled task. This will be easier to administer changes than cron and could be used for other types of tasks.
A link to get you started - Iterate through Items in a List
Another option would be to use Workflow to send out emails from the calendar
EDIT - Since SharePoint SP2 this no longer works as is as workflows can no longer start themselves (loop) - explanation and workaround
This CodeProject article shows how to develop a feature to send scheduled reminders
Yet another option would be to use one of the 3rd party tools that do this (disclaimer - I work for the first company)
Pentalogic - SharePoint Reminder
Bamboo - Alert Plus
BoostSolutions - Alert Reminder Boost
Finally - whichever method you choose (custom code/workflow/3rd party) you will likely run into trouble with recurring events as SharePoint doesn't provide a way to get an 'expanded' list of all occurrences.
The best way to do this would be using a Timer Job - see Andrew Connell's blog here: http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx