Re: BizTalk Adapter for Sharepoint

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Gregory Van de Wiele (gregory_at_hydor.be)
Date: 09/16/04 

Date: Thu, 16 Sep 2004 09:52:46 GMT

Hi Gilles,

Thanks for your detailed reply.

We use SP document lib for example to see what orders came in (we have nice
infopath form for the order and many other business docs) and these are
created by BTS SP adapter. Key business users check the list/forms to be
informed about what recently came in/went out.
So in a sense SP isn't used as an "collaborative" tool where it was designed
for - but the way we use it makes sense too. It easily fills up a gap of the
out-of-the-box BizTalk tools because HAT isn't intended for the biz user. I
think most of the people that use the SP adapter will use it for this
purpose. We are very happy with the result considering this was the result
of RAD - not being part of the intitial biz requirements.

Your proposed solution makes sense too. I was about to make a custom event
handler (generic with config xml where you can configure daystokeep number /
itemstokeepnumber for every doc lib) but I will drop the idea. An exe is
indeed much easier. But I've checked the SP db and all documents are in a
table named Docs.
Maybe it's easier to just create a purge stored proc that is run by the SQL
agent. I'll ask if this is a good practice in the sharepoint newsgroup...

Thanks,
Greg

"Gilles [MSFT]" <Gilles@online.microsoft.com> wrote in message
news:91Wksu3mEHA.1600@cpmsftngxa06.phx.gbl...
> Hello,
>
> >Thanks to the very nice sharepoint adapter, BTS got the functionality to
> >send docs to SP libraries, great! Now, please enlight me, does anybody
know
> >how those lists can be cleaned/purged? Is there some kind of maintenance
> >guideline - or best practice? Do we have to develop a custom event
handler
> >or is there another way of doing this? Somebody must have thought
> >of/experienced this before...
>
> Sharepoint out of the box does not offer a way to automatically "purge"
lists or document libraries.
> Sharepoint assumes that if you put something in a document library or a
list, you want to keep it until you explicitely delete it.
>
> Best practices depend on many things: the number of users, the number of
documents per hour being dropped, their size, your actual
> application (sometimes you might need to keep things around longer ...) so
it is hard to formulate them without any knowledge of your solution.
> Sharepoint has limitations on the number of files per document library and
the number of document libraries.
> However, I do not remember them. It is better to ask the Sharepoint
specialist in the appropriate newsgroup.
>
> You can maybe find an existing solution that conditionally deletes
sharepoint files. I do not know of any but it is reasonable to assume that
> at least one ISV developped one.
>
> I can think of an obvious while effective best practice: do not store a
document into sharepoint if the document will not be edited/viewed.
> In other words, try to use sharepoint for documents which require user
edition/viewing only.
>
> As far as implementing this solution yourself, it is in fact relatively
easy.
> Sharepoint offers an object model and a few web services that you can use
to manipulate content.
> This allows you to enumerate and delete documents and much more. There is
a catch: the WSS object model can be called only
> from code which runs on the same machine as the server. The web services
can be called from anywhere (provided that the user has
> the adequate privileges) but offer much less methods than the object model
and is slower than the object model.
>
> You have essentially two ways to implement your cleanup:
>
> 1) An event handler (per document library). Every time a document is
dropped, you scan the library and delete it.
> You could be tempted to "filter" adds in the event handler:" decide
if the document should be put or not and delete it if it should not be kept.
> Resist that temptation. Events are fired asynchronously with the
respect of the file being saved to the sharepoint store. As a result, you
will
> slow down the performances of your server. It is better to not add
files to wss instead of filtering the adds.
>
> 2) Write a piece of code that performs the cleaning when it is run.
Package it as an .exe, perhpas taking some parameters to fine tune the
cleanup.
> Then, create a windows scheduled task and run this at appropriate
> time intervals. You could also put the scheduling logic into your
code, but Windows does it, so why re-write it.
>
> I would not recommend 1). First, event handlers are fired only in document
libraries. Not in lists. So you can only clean up doc libs.
> Event handlers are set up per library: you will have to set it up for
every single library and every time one library is created, you
> will ahve to set up the handler as well. From a practical point of view,
event handlers are a little more hard to debug since they run in
> the context of the sharepoint server. An exe is far easier to debug.
>
> The scheduled clean up 2) adopts a batch approach. When the server is not
used much (at night perhaps) you can then perform the clean up and
> when users come in, the site is ready for them.
>
> Thanks,
> -Gilles.
>

Relevant Pages

  • Re: Linking InfoPath to Sharepoint (SBS2003)
    ... It depends on your InfoPath form as to what will work. ... utilize InfoPath with Sharepoint via Form Libraries. ... The way the forms libraries work in Sharepoint is that they are effectively ...
    (microsoft.public.windows.server.sbs)
  • Re: W3WP memory usage
    ... You may be correct regarding the libraries using the lion's share of memory. ... > I am quite aware that Sharepoint files are stored in the database. ... >>> public class SPVersion ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Public Folders and SharePoint 2003
    ... Goto the Virtual Server General Settings/E-Mail Enabled Document Libraries ... > enables to associate an Exchange Public Folder with a SharePoint Document ... This in effect, email enables SharePoint. ...
    (microsoft.public.sharepoint.portalserver)
  • Re: Reading InfoPath document through SharePoint web service interface
    ... If they are in a SharePoint 'Folder Library' (which is where InfoPath forms ... client create a local drive with for the Forms Lib with NET USE X: ... Mike Walsh, Helsinki, Finland ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Event Handlers on lists
    ... As I understand it Event Handlers ... I personally expect to see this functionality available for all lists in V3. ... >> Document Libraries, Form Libraries and Picture Libraries in WSS all ...
    (microsoft.public.sharepoint.windowsservices)