Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros
problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ?
Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros
problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ?
Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros
problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ?
Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
de tous les documents du portail SPS. Quand un document est supprimé
d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
mais le gros problème, c'est l'overhead de la DB (double copie d'un
document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
que les évènements sont asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
de tous les documents du portail SPS. Quand un document est supprimé
d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
mais le gros problème, c'est l'overhead de la DB (double copie d'un
document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
que les évènements sont asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
de tous les documents du portail SPS. Quand un document est supprimé
d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
mais le gros problème, c'est l'overhead de la DB (double copie d'un
document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
que les évènements sont asynchrones sous SPS ?
Merci
Disons que Seattle n'est pas si perdu que cela
Je disais jsute que la copie de fichier est plus rapide et surtout plus riche
d'option en utilisatn le Frontpage RPC
Quels infos vous manquemt il ?
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
> de tous les documents du portail SPS. Quand un document est supprimé
> d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
> bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
> mais le gros problème, c'est l'overhead de la DB (double copie d'un
> document).
>
> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
> que les évènements sont asynchrones sous SPS ?
>
> Merci
>
Disons que Seattle n'est pas si perdu que cela
Je disais jsute que la copie de fichier est plus rapide et surtout plus riche
d'option en utilisatn le Frontpage RPC
Quels infos vous manquemt il ?
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
> de tous les documents du portail SPS. Quand un document est supprimé
> d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
> bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
> mais le gros problème, c'est l'overhead de la DB (double copie d'un
> document).
>
> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
> que les évènements sont asynchrones sous SPS ?
>
> Merci
>
Disons que Seattle n'est pas si perdu que cela
Je disais jsute que la copie de fichier est plus rapide et surtout plus riche
d'option en utilisatn le Frontpage RPC
Quels infos vous manquemt il ?
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie
> de tous les documents du portail SPS. Quand un document est supprimé
> d'une bibliothèque, j'utilise ce mirroir pour faire une copie dans ma
> bibliothèque "corbeille". Bref, cette méthode est connue, ça marche
> mais le gros problème, c'est l'overhead de la DB (double copie d'un
> document).
>
> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
> que les évènements sont asynchrones sous SPS ?
>
> Merci
>
Bonjour,
Tout d'abord méfiance : implanter quoi que ce soit dans la base de données
de SharePoint est risqué (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
même si un trigger peut facilement être supprimé pour revenir en configuration
normale.
Pour ce qui est de votre question CAML, je ne vois pas bien l'utilité. Si
votre librairie d'EventSink réinjecte le document dans une doclib "Archive"
pas besoin de CAML spécifique : une vue standard sur cette doclib suffit
amplement.
Au delà de ça se pose pour vous une grosse problématique de sécurité : qui
va avoir accès à cette doclib archive ? Si ce ne sont que les admins tant
mieux parce que sinon bonjour le casse-tête : n'importe quel lecteur verrait
un document supprimé de la doclib ultraconfidentielle de la direction générale
sauf à créer une docib archive par doclib !!!
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Bah disons que le problème est de pouvoir récupérer le fichier avant
> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
> signalé qu'après. Je ne vois pas comment le faire avec un EventHandler
> du coup, même avec le Frontpage RPC.
>
> Une solution que je vois, est de travailler sur une table "Corbeille",
> structure identique à la table Docs, et de gérer avec un trigger
> "InsteadOf
> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
> bien
> remplie à chaque fois qu'un document est supprimé. ça marche bien au
> sein de
> SQLServer.
> Ma prochaine étape est, vu que la suppression est effective dans la DB
> avant
> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
> enregistrement de cette table et de copier l'engistrement en tant que
> nouveau
> document dans une bibliothèque de document "Archive", et ceci à faire
> sur
> l'EventSink "Delete" de la biblio. source.
> Est-ce que cela vous paraît envisageable par rapport à la
> synchronisation
> des évènements ?
> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
> possible de
> lier par le CAML ou autre, une biblio. sur une table SQLServer de type
> la
> table Docs ?
> Merci
>
> "Renaud COMTE [MVP]" a écrit :
>
>> Disons que Seattle n'est pas si perdu que cela
>>
>> Je disais jsute que la copie de fichier est plus rapide et surtout
>> plus riche d'option en utilisatn le Frontpage RPC
>>
>> Quels infos vous manquemt il ?
>>
>> Renaud COMTE [MVP]
>> ---------------------------------
>> http://blogs.developpeur.org/themit/
>> http://blog.spsclerics.com/
>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>> copie de tous les documents du portail SPS. Quand un document est
>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>> (double copie d'un document).
>>>
>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
>>> que les évènements sont asynchrones sous SPS ?
>>>
>>> Merci
>>>
Bonjour,
Tout d'abord méfiance : implanter quoi que ce soit dans la base de données
de SharePoint est risqué (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
même si un trigger peut facilement être supprimé pour revenir en configuration
normale.
Pour ce qui est de votre question CAML, je ne vois pas bien l'utilité. Si
votre librairie d'EventSink réinjecte le document dans une doclib "Archive"
pas besoin de CAML spécifique : une vue standard sur cette doclib suffit
amplement.
Au delà de ça se pose pour vous une grosse problématique de sécurité : qui
va avoir accès à cette doclib archive ? Si ce ne sont que les admins tant
mieux parce que sinon bonjour le casse-tête : n'importe quel lecteur verrait
un document supprimé de la doclib ultraconfidentielle de la direction générale
sauf à créer une docib archive par doclib !!!
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Bah disons que le problème est de pouvoir récupérer le fichier avant
> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
> signalé qu'après. Je ne vois pas comment le faire avec un EventHandler
> du coup, même avec le Frontpage RPC.
>
> Une solution que je vois, est de travailler sur une table "Corbeille",
> structure identique à la table Docs, et de gérer avec un trigger
> "InsteadOf
> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
> bien
> remplie à chaque fois qu'un document est supprimé. ça marche bien au
> sein de
> SQLServer.
> Ma prochaine étape est, vu que la suppression est effective dans la DB
> avant
> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
> enregistrement de cette table et de copier l'engistrement en tant que
> nouveau
> document dans une bibliothèque de document "Archive", et ceci à faire
> sur
> l'EventSink "Delete" de la biblio. source.
> Est-ce que cela vous paraît envisageable par rapport à la
> synchronisation
> des évènements ?
> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
> possible de
> lier par le CAML ou autre, une biblio. sur une table SQLServer de type
> la
> table Docs ?
> Merci
>
> "Renaud COMTE [MVP]" a écrit :
>
>> Disons que Seattle n'est pas si perdu que cela
>>
>> Je disais jsute que la copie de fichier est plus rapide et surtout
>> plus riche d'option en utilisatn le Frontpage RPC
>>
>> Quels infos vous manquemt il ?
>>
>> Renaud COMTE [MVP]
>> ---------------------------------
>> http://blogs.developpeur.org/themit/
>> http://blog.spsclerics.com/
>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>> copie de tous les documents du portail SPS. Quand un document est
>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>> (double copie d'un document).
>>>
>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
>>> que les évènements sont asynchrones sous SPS ?
>>>
>>> Merci
>>>
Bonjour,
Tout d'abord méfiance : implanter quoi que ce soit dans la base de données
de SharePoint est risqué (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
même si un trigger peut facilement être supprimé pour revenir en configuration
normale.
Pour ce qui est de votre question CAML, je ne vois pas bien l'utilité. Si
votre librairie d'EventSink réinjecte le document dans une doclib "Archive"
pas besoin de CAML spécifique : une vue standard sur cette doclib suffit
amplement.
Au delà de ça se pose pour vous une grosse problématique de sécurité : qui
va avoir accès à cette doclib archive ? Si ce ne sont que les admins tant
mieux parce que sinon bonjour le casse-tête : n'importe quel lecteur verrait
un document supprimé de la doclib ultraconfidentielle de la direction générale
sauf à créer une docib archive par doclib !!!
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Bah disons que le problème est de pouvoir récupérer le fichier avant
> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
> signalé qu'après. Je ne vois pas comment le faire avec un EventHandler
> du coup, même avec le Frontpage RPC.
>
> Une solution que je vois, est de travailler sur une table "Corbeille",
> structure identique à la table Docs, et de gérer avec un trigger
> "InsteadOf
> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
> bien
> remplie à chaque fois qu'un document est supprimé. ça marche bien au
> sein de
> SQLServer.
> Ma prochaine étape est, vu que la suppression est effective dans la DB
> avant
> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
> enregistrement de cette table et de copier l'engistrement en tant que
> nouveau
> document dans une bibliothèque de document "Archive", et ceci à faire
> sur
> l'EventSink "Delete" de la biblio. source.
> Est-ce que cela vous paraît envisageable par rapport à la
> synchronisation
> des évènements ?
> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
> possible de
> lier par le CAML ou autre, une biblio. sur une table SQLServer de type
> la
> table Docs ?
> Merci
>
> "Renaud COMTE [MVP]" a écrit :
>
>> Disons que Seattle n'est pas si perdu que cela
>>
>> Je disais jsute que la copie de fichier est plus rapide et surtout
>> plus riche d'option en utilisatn le Frontpage RPC
>>
>> Quels infos vous manquemt il ?
>>
>> Renaud COMTE [MVP]
>> ---------------------------------
>> http://blogs.developpeur.org/themit/
>> http://blog.spsclerics.com/
>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>> copie de tous les documents du portail SPS. Quand un document est
>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>> (double copie d'un document).
>>>
>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode vu
>>> que les évènements sont asynchrones sous SPS ?
>>>
>>> Merci
>>>
La plus grosse limitation que je vois à ce genre de solutions vient du fait
que SharePoint ne peut implémenter qu'une librairie d'EventSink par doclib.
Si vous implémentez une solution de corbeille par ce biais, impossible d'implémenter
quoi que ce soit d'autre qui fonctionne par événement (workflow, conversion
PDF ou que sais-je).
Pourquoi ne pas dans ce cas mettre un service qui se chargerait de réinjecter
dans la doclib archive les documents "poubellisés" par votre trigger.
Pour répondre à votre question sur les réflexions menées sur cette problématique
: s'il s'agît uniquement de permettre la récupération de documents supprimés,
je vous invite à lire l'excellent article de Stéphane Cordonnier (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.aspx)
et à downloader son outil.
Son idée est de répondre à ce problème grâce aux sauvegardes de la base SQL
de WSS (ou SPS) :
- vous restaurez juste la base sur un serveur SQL (autre que la base de données
active de votre SharePoint)
- son outil vous permet d'explorer la structure du site pour retrouver le
document à récupérer
- vous le sauvegardez en local
- il ne vous reste plus qu'à le réinjecter
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Je comprends la préco MS sur le fait de modifier la structure de la DB
> SPS
> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
> nativement de gérer le recyclage des docs, j'essaie d'étudier une
> solution
> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
> comme
> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
> besoins. Et
> je ne peux attendre SPSV3 pour ça.
> En fait, si je passe par cette méthode, c'est surtout pour éviter
> d'avoir
> une double copie d'un document dans la DB et pour que la corbeille
> puisse
> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
> juste un
> trigger sur la table Docs, qui copie un document supprimé dans une
> autre
> table tampon de même structure que la table Docs. Si seulement cela
> fait
> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
> cette
> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est bon
> signe ;)
> Plus sérieusement, il n'y a que les admins qui ont accès à cette
> biblio
> archive. Mais je voulais aussi avoir votre opinion sur la crédibilité
> de ce
> mécanisme.
> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
> est-ce
> que quelqu'un a déjà travaillé dans ce sens ?
> "Eric Donneger" a écrit :
>
>> Bonjour,
>>
>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>> données de SharePoint est risqué
>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057) même
>> si un trigger peut facilement être supprimé pour revenir en
>> configuration normale.
>>
>> Pour ce qui est de votre question CAML, je ne vois pas bien
>> l'utilité. Si votre librairie d'EventSink réinjecte le document dans
>> une doclib "Archive" pas besoin de CAML spécifique : une vue standard
>> sur cette doclib suffit amplement.
>>
>> Au delà de ça se pose pour vous une grosse problématique de sécurité
>> : qui va avoir accès à cette doclib archive ? Si ce ne sont que les
>> admins tant mieux parce que sinon bonjour le casse-tête : n'importe
>> quel lecteur verrait un document supprimé de la doclib
>> ultraconfidentielle de la direction générale sauf à créer une docib
>> archive par doclib !!!
>>
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Bah disons que le problème est de pouvoir récupérer le fichier avant
>>> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
>>> signalé qu'après. Je ne vois pas comment le faire avec un
>>> EventHandler du coup, même avec le Frontpage RPC.
>>>
>>> Une solution que je vois, est de travailler sur une table
>>> "Corbeille",
>>> structure identique à la table Docs, et de gérer avec un trigger
>>> "InsteadOf
>>> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
>>> bien
>>> remplie à chaque fois qu'un document est supprimé. ça marche bien au
>>> sein de
>>> SQLServer.
>>> Ma prochaine étape est, vu que la suppression est effective dans la
>>> DB
>>> avant
>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>> enregistrement de cette table et de copier l'engistrement en tant
>>> que
>>> nouveau
>>> document dans une bibliothèque de document "Archive", et ceci à
>>> faire
>>> sur
>>> l'EventSink "Delete" de la biblio. source.
>>> Est-ce que cela vous paraît envisageable par rapport à la
>>> synchronisation
>>> des évènements ?
>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>> possible de
>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>> type
>>> la
>>> table Docs ?
>>> Merci
>>> "Renaud COMTE [MVP]" a écrit :
>>>
>>>> Disons que Seattle n'est pas si perdu que cela
>>>>
>>>> Je disais jsute que la copie de fichier est plus rapide et surtout
>>>> plus riche d'option en utilisatn le Frontpage RPC
>>>>
>>>> Quels infos vous manquemt il ?
>>>>
>>>> Renaud COMTE [MVP]
>>>> ---------------------------------
>>>> http://blogs.developpeur.org/themit/
>>>> http://blog.spsclerics.com/
>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>> copie de tous les documents du portail SPS. Quand un document est
>>>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>>>> (double copie d'un document).
>>>>>
>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode
>>>>> vu que les évènements sont asynchrones sous SPS ?
>>>>>
>>>>> Merci
>>>>>
La plus grosse limitation que je vois à ce genre de solutions vient du fait
que SharePoint ne peut implémenter qu'une librairie d'EventSink par doclib.
Si vous implémentez une solution de corbeille par ce biais, impossible d'implémenter
quoi que ce soit d'autre qui fonctionne par événement (workflow, conversion
PDF ou que sais-je).
Pourquoi ne pas dans ce cas mettre un service qui se chargerait de réinjecter
dans la doclib archive les documents "poubellisés" par votre trigger.
Pour répondre à votre question sur les réflexions menées sur cette problématique
: s'il s'agît uniquement de permettre la récupération de documents supprimés,
je vous invite à lire l'excellent article de Stéphane Cordonnier (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.aspx)
et à downloader son outil.
Son idée est de répondre à ce problème grâce aux sauvegardes de la base SQL
de WSS (ou SPS) :
- vous restaurez juste la base sur un serveur SQL (autre que la base de données
active de votre SharePoint)
- son outil vous permet d'explorer la structure du site pour retrouver le
document à récupérer
- vous le sauvegardez en local
- il ne vous reste plus qu'à le réinjecter
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Je comprends la préco MS sur le fait de modifier la structure de la DB
> SPS
> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
> nativement de gérer le recyclage des docs, j'essaie d'étudier une
> solution
> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
> comme
> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
> besoins. Et
> je ne peux attendre SPSV3 pour ça.
> En fait, si je passe par cette méthode, c'est surtout pour éviter
> d'avoir
> une double copie d'un document dans la DB et pour que la corbeille
> puisse
> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
> juste un
> trigger sur la table Docs, qui copie un document supprimé dans une
> autre
> table tampon de même structure que la table Docs. Si seulement cela
> fait
> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
> cette
> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est bon
> signe ;)
> Plus sérieusement, il n'y a que les admins qui ont accès à cette
> biblio
> archive. Mais je voulais aussi avoir votre opinion sur la crédibilité
> de ce
> mécanisme.
> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
> est-ce
> que quelqu'un a déjà travaillé dans ce sens ?
> "Eric Donneger" a écrit :
>
>> Bonjour,
>>
>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>> données de SharePoint est risqué
>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057) même
>> si un trigger peut facilement être supprimé pour revenir en
>> configuration normale.
>>
>> Pour ce qui est de votre question CAML, je ne vois pas bien
>> l'utilité. Si votre librairie d'EventSink réinjecte le document dans
>> une doclib "Archive" pas besoin de CAML spécifique : une vue standard
>> sur cette doclib suffit amplement.
>>
>> Au delà de ça se pose pour vous une grosse problématique de sécurité
>> : qui va avoir accès à cette doclib archive ? Si ce ne sont que les
>> admins tant mieux parce que sinon bonjour le casse-tête : n'importe
>> quel lecteur verrait un document supprimé de la doclib
>> ultraconfidentielle de la direction générale sauf à créer une docib
>> archive par doclib !!!
>>
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Bah disons que le problème est de pouvoir récupérer le fichier avant
>>> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
>>> signalé qu'après. Je ne vois pas comment le faire avec un
>>> EventHandler du coup, même avec le Frontpage RPC.
>>>
>>> Une solution que je vois, est de travailler sur une table
>>> "Corbeille",
>>> structure identique à la table Docs, et de gérer avec un trigger
>>> "InsteadOf
>>> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
>>> bien
>>> remplie à chaque fois qu'un document est supprimé. ça marche bien au
>>> sein de
>>> SQLServer.
>>> Ma prochaine étape est, vu que la suppression est effective dans la
>>> DB
>>> avant
>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>> enregistrement de cette table et de copier l'engistrement en tant
>>> que
>>> nouveau
>>> document dans une bibliothèque de document "Archive", et ceci à
>>> faire
>>> sur
>>> l'EventSink "Delete" de la biblio. source.
>>> Est-ce que cela vous paraît envisageable par rapport à la
>>> synchronisation
>>> des évènements ?
>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>> possible de
>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>> type
>>> la
>>> table Docs ?
>>> Merci
>>> "Renaud COMTE [MVP]" a écrit :
>>>
>>>> Disons que Seattle n'est pas si perdu que cela
>>>>
>>>> Je disais jsute que la copie de fichier est plus rapide et surtout
>>>> plus riche d'option en utilisatn le Frontpage RPC
>>>>
>>>> Quels infos vous manquemt il ?
>>>>
>>>> Renaud COMTE [MVP]
>>>> ---------------------------------
>>>> http://blogs.developpeur.org/themit/
>>>> http://blog.spsclerics.com/
>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>> copie de tous les documents du portail SPS. Quand un document est
>>>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>>>> (double copie d'un document).
>>>>>
>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode
>>>>> vu que les évènements sont asynchrones sous SPS ?
>>>>>
>>>>> Merci
>>>>>
La plus grosse limitation que je vois à ce genre de solutions vient du fait
que SharePoint ne peut implémenter qu'une librairie d'EventSink par doclib.
Si vous implémentez une solution de corbeille par ce biais, impossible d'implémenter
quoi que ce soit d'autre qui fonctionne par événement (workflow, conversion
PDF ou que sais-je).
Pourquoi ne pas dans ce cas mettre un service qui se chargerait de réinjecter
dans la doclib archive les documents "poubellisés" par votre trigger.
Pour répondre à votre question sur les réflexions menées sur cette problématique
: s'il s'agît uniquement de permettre la récupération de documents supprimés,
je vous invite à lire l'excellent article de Stéphane Cordonnier (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.aspx)
et à downloader son outil.
Son idée est de répondre à ce problème grâce aux sauvegardes de la base SQL
de WSS (ou SPS) :
- vous restaurez juste la base sur un serveur SQL (autre que la base de données
active de votre SharePoint)
- son outil vous permet d'explorer la structure du site pour retrouver le
document à récupérer
- vous le sauvegardez en local
- il ne vous reste plus qu'à le réinjecter
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Je comprends la préco MS sur le fait de modifier la structure de la DB
> SPS
> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
> nativement de gérer le recyclage des docs, j'essaie d'étudier une
> solution
> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
> comme
> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
> besoins. Et
> je ne peux attendre SPSV3 pour ça.
> En fait, si je passe par cette méthode, c'est surtout pour éviter
> d'avoir
> une double copie d'un document dans la DB et pour que la corbeille
> puisse
> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
> juste un
> trigger sur la table Docs, qui copie un document supprimé dans une
> autre
> table tampon de même structure que la table Docs. Si seulement cela
> fait
> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
> cette
> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est bon
> signe ;)
> Plus sérieusement, il n'y a que les admins qui ont accès à cette
> biblio
> archive. Mais je voulais aussi avoir votre opinion sur la crédibilité
> de ce
> mécanisme.
> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
> est-ce
> que quelqu'un a déjà travaillé dans ce sens ?
> "Eric Donneger" a écrit :
>
>> Bonjour,
>>
>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>> données de SharePoint est risqué
>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057) même
>> si un trigger peut facilement être supprimé pour revenir en
>> configuration normale.
>>
>> Pour ce qui est de votre question CAML, je ne vois pas bien
>> l'utilité. Si votre librairie d'EventSink réinjecte le document dans
>> une doclib "Archive" pas besoin de CAML spécifique : une vue standard
>> sur cette doclib suffit amplement.
>>
>> Au delà de ça se pose pour vous une grosse problématique de sécurité
>> : qui va avoir accès à cette doclib archive ? Si ce ne sont que les
>> admins tant mieux parce que sinon bonjour le casse-tête : n'importe
>> quel lecteur verrait un document supprimé de la doclib
>> ultraconfidentielle de la direction générale sauf à créer une docib
>> archive par doclib !!!
>>
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Bah disons que le problème est de pouvoir récupérer le fichier avant
>>> qu'il ne soit supprimer de la DB, vu que l'évènement delete n'est
>>> signalé qu'après. Je ne vois pas comment le faire avec un
>>> EventHandler du coup, même avec le Frontpage RPC.
>>>
>>> Une solution que je vois, est de travailler sur une table
>>> "Corbeille",
>>> structure identique à la table Docs, et de gérer avec un trigger
>>> "InsteadOf
>>> delete" l'évènement "Delete" d'un document. La table "Corbeille" est
>>> bien
>>> remplie à chaque fois qu'un document est supprimé. ça marche bien au
>>> sein de
>>> SQLServer.
>>> Ma prochaine étape est, vu que la suppression est effective dans la
>>> DB
>>> avant
>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>> enregistrement de cette table et de copier l'engistrement en tant
>>> que
>>> nouveau
>>> document dans une bibliothèque de document "Archive", et ceci à
>>> faire
>>> sur
>>> l'EventSink "Delete" de la biblio. source.
>>> Est-ce que cela vous paraît envisageable par rapport à la
>>> synchronisation
>>> des évènements ?
>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>> possible de
>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>> type
>>> la
>>> table Docs ?
>>> Merci
>>> "Renaud COMTE [MVP]" a écrit :
>>>
>>>> Disons que Seattle n'est pas si perdu que cela
>>>>
>>>> Je disais jsute que la copie de fichier est plus rapide et surtout
>>>> plus riche d'option en utilisatn le Frontpage RPC
>>>>
>>>> Quels infos vous manquemt il ?
>>>>
>>>> Renaud COMTE [MVP]
>>>> ---------------------------------
>>>> http://blogs.developpeur.org/themit/
>>>> http://blog.spsclerics.com/
>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>> copie de tous les documents du portail SPS. Quand un document est
>>>>> supprimé d'une bibliothèque, j'utilise ce mirroir pour faire une
>>>>> copie dans ma bibliothèque "corbeille". Bref, cette méthode est
>>>>> connue, ça marche mais le gros problème, c'est l'overhead de la DB
>>>>> (double copie d'un document).
>>>>>
>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE
>>>>> avait préconisé l'utilisation du Frontpage RPC. Est-ce que je me
>>>>> trompe ou pas ? Si non, comment mettre en pratique cette méthode
>>>>> vu que les évènements sont asynchrones sous SPS ?
>>>>>
>>>>> Merci
>>>>>
La pour le coup, bonne analyse...
Si vous avez besoin de tracer ce genre d'informations je crois que vous n'avez
effectivement pas le choix
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Merci pour vos réponses.
>
> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà restauré
> un
> document à partir de cet outil. C'est très utile mais les limites de
> ce
> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
> qui a
> supprimé le document, à quelle date il a été supprimé et surtout
> retrouver
> son url d'origine quand on ne se rappelle plus de son nom.
> Très souvent la problématique est ainsi : on s'aperçoit à un moment
> donné
> qu'un document a été supprimé et que le seul moyen de retrouver ce
> document
> est de restaurer celui-ci en s'appuyant sur les backups de la DB
> (encore
> faut-il savoir quand ce document a été supprimé).
> C'est pourquoi, je me lance dans cette aventure qui je l'espère
> apportera cette plus-value tant attendue...
>
> Pour répondre à vos limites :
> - Si j'utilise un flux SinkData suffisamment souple, je peux très bien
> implémenter la même librairie EventSink qui pourrait traiter non
> seulement
> les évènements liés à la gestion de la corbeille mais en plus s'il le
> faut,
> effectuer d'autres taches.
> - Service Windows ou Web ?
> - Mettre en place un service Windows pour réinjecter mes docs
> supprimés dans
> la bib "Archive" ne me parait pas suffisant pour récupérer des
> informations
> en temps réel telles que le nom de l'utilisateur qui a supprimé le
> doc. ou
> son url d'origine (je pourrais ajouté la date de suppression dans mon
> trigger).
> Me trompe-je ?
> "Eric Donneger" a écrit :
>
>> La plus grosse limitation que je vois à ce genre de solutions vient
>> du fait que SharePoint ne peut implémenter qu'une librairie
>> d'EventSink par doclib. Si vous implémentez une solution de corbeille
>> par ce biais, impossible d'implémenter quoi que ce soit d'autre qui
>> fonctionne par événement (workflow, conversion PDF ou que sais-je).
>>
>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>> réinjecter dans la doclib archive les documents "poubellisés" par
>> votre trigger.
>>
>> Pour répondre à votre question sur les réflexions menées sur cette
>> problématique : s'il s'agît uniquement de permettre la récupération
>> de documents supprimés, je vous invite à lire l'excellent article de
>> Stéphane Cordonnier
>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.a
>> spx) et à downloader son outil.
>>
>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>> base SQL
>> de WSS (ou SPS) :
>> - vous restaurez juste la base sur un serveur SQL (autre que la base
>> de données
>> active de votre SharePoint)
>> - son outil vous permet d'explorer la structure du site pour
>> retrouver le
>> document à récupérer
>> - vous le sauvegardez en local
>> - il ne vous reste plus qu'à le réinjecter
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Je comprends la préco MS sur le fait de modifier la structure de la
>>> DB
>>> SPS
>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>> solution
>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>> comme
>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>> besoins. Et
>>> je ne peux attendre SPSV3 pour ça.
>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>> d'avoir
>>> une double copie d'un document dans la DB et pour que la corbeille
>>> puisse
>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>> juste un
>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>> autre
>>> table tampon de même structure que la table Docs. Si seulement cela
>>> fait
>>> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
>>> cette
>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>> bon
>>> signe ;)
>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>> biblio
>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>> crédibilité
>>> de ce
>>> mécanisme.
>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>> est-ce
>>> que quelqu'un a déjà travaillé dans ce sens ?
>>> "Eric Donneger" a écrit :
>>>> Bonjour,
>>>>
>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>>>> données de SharePoint est risqué
>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>> configuration normale.
>>>>
>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>> standard sur cette doclib suffit amplement.
>>>>
>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>> casse-tête : n'importe quel lecteur verrait un document supprimé de
>>>> la doclib ultraconfidentielle de la direction générale sauf à créer
>>>> une docib archive par doclib !!!
>>>>
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement delete
>>>>> n'est signalé qu'après. Je ne vois pas comment le faire avec un
>>>>> EventHandler du coup, même avec le Frontpage RPC.
>>>>>
>>>>> Une solution que je vois, est de travailler sur une table
>>>>> "Corbeille",
>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>> "InsteadOf
>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>> est
>>>>> bien
>>>>> remplie à chaque fois qu'un document est supprimé. ça marche bien
>>>>> au
>>>>> sein de
>>>>> SQLServer.
>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>> la
>>>>> DB
>>>>> avant
>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>>>> enregistrement de cette table et de copier l'engistrement en tant
>>>>> que
>>>>> nouveau
>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>> faire
>>>>> sur
>>>>> l'EventSink "Delete" de la biblio. source.
>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>> synchronisation
>>>>> des évènements ?
>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>> possible de
>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>>>> type
>>>>> la
>>>>> table Docs ?
>>>>> Merci
>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>
>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>
>>>>>> Quels infos vous manquemt il ?
>>>>>>
>>>>>> Renaud COMTE [MVP]
>>>>>> ---------------------------------
>>>>>> http://blogs.developpeur.org/themit/
>>>>>> http://blog.spsclerics.com/
>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>>>> copie de tous les documents du portail SPS. Quand un document
>>>>>>> est supprimé d'une bibliothèque, j'utilise ce mirroir pour faire
>>>>>>> une copie dans ma bibliothèque "corbeille". Bref, cette méthode
>>>>>>> est connue, ça marche mais le gros problème, c'est l'overhead de
>>>>>>> la DB (double copie d'un document).
>>>>>>>
>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce que
>>>>>>> je me trompe ou pas ? Si non, comment mettre en pratique cette
>>>>>>> méthode vu que les évènements sont asynchrones sous SPS ?
>>>>>>>
>>>>>>> Merci
>>>>>>>
La pour le coup, bonne analyse...
Si vous avez besoin de tracer ce genre d'informations je crois que vous n'avez
effectivement pas le choix
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Merci pour vos réponses.
>
> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà restauré
> un
> document à partir de cet outil. C'est très utile mais les limites de
> ce
> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
> qui a
> supprimé le document, à quelle date il a été supprimé et surtout
> retrouver
> son url d'origine quand on ne se rappelle plus de son nom.
> Très souvent la problématique est ainsi : on s'aperçoit à un moment
> donné
> qu'un document a été supprimé et que le seul moyen de retrouver ce
> document
> est de restaurer celui-ci en s'appuyant sur les backups de la DB
> (encore
> faut-il savoir quand ce document a été supprimé).
> C'est pourquoi, je me lance dans cette aventure qui je l'espère
> apportera cette plus-value tant attendue...
>
> Pour répondre à vos limites :
> - Si j'utilise un flux SinkData suffisamment souple, je peux très bien
> implémenter la même librairie EventSink qui pourrait traiter non
> seulement
> les évènements liés à la gestion de la corbeille mais en plus s'il le
> faut,
> effectuer d'autres taches.
> - Service Windows ou Web ?
> - Mettre en place un service Windows pour réinjecter mes docs
> supprimés dans
> la bib "Archive" ne me parait pas suffisant pour récupérer des
> informations
> en temps réel telles que le nom de l'utilisateur qui a supprimé le
> doc. ou
> son url d'origine (je pourrais ajouté la date de suppression dans mon
> trigger).
> Me trompe-je ?
> "Eric Donneger" a écrit :
>
>> La plus grosse limitation que je vois à ce genre de solutions vient
>> du fait que SharePoint ne peut implémenter qu'une librairie
>> d'EventSink par doclib. Si vous implémentez une solution de corbeille
>> par ce biais, impossible d'implémenter quoi que ce soit d'autre qui
>> fonctionne par événement (workflow, conversion PDF ou que sais-je).
>>
>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>> réinjecter dans la doclib archive les documents "poubellisés" par
>> votre trigger.
>>
>> Pour répondre à votre question sur les réflexions menées sur cette
>> problématique : s'il s'agît uniquement de permettre la récupération
>> de documents supprimés, je vous invite à lire l'excellent article de
>> Stéphane Cordonnier
>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.a
>> spx) et à downloader son outil.
>>
>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>> base SQL
>> de WSS (ou SPS) :
>> - vous restaurez juste la base sur un serveur SQL (autre que la base
>> de données
>> active de votre SharePoint)
>> - son outil vous permet d'explorer la structure du site pour
>> retrouver le
>> document à récupérer
>> - vous le sauvegardez en local
>> - il ne vous reste plus qu'à le réinjecter
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Je comprends la préco MS sur le fait de modifier la structure de la
>>> DB
>>> SPS
>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>> solution
>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>> comme
>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>> besoins. Et
>>> je ne peux attendre SPSV3 pour ça.
>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>> d'avoir
>>> une double copie d'un document dans la DB et pour que la corbeille
>>> puisse
>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>> juste un
>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>> autre
>>> table tampon de même structure que la table Docs. Si seulement cela
>>> fait
>>> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
>>> cette
>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>> bon
>>> signe ;)
>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>> biblio
>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>> crédibilité
>>> de ce
>>> mécanisme.
>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>> est-ce
>>> que quelqu'un a déjà travaillé dans ce sens ?
>>> "Eric Donneger" a écrit :
>>>> Bonjour,
>>>>
>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>>>> données de SharePoint est risqué
>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>> configuration normale.
>>>>
>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>> standard sur cette doclib suffit amplement.
>>>>
>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>> casse-tête : n'importe quel lecteur verrait un document supprimé de
>>>> la doclib ultraconfidentielle de la direction générale sauf à créer
>>>> une docib archive par doclib !!!
>>>>
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement delete
>>>>> n'est signalé qu'après. Je ne vois pas comment le faire avec un
>>>>> EventHandler du coup, même avec le Frontpage RPC.
>>>>>
>>>>> Une solution que je vois, est de travailler sur une table
>>>>> "Corbeille",
>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>> "InsteadOf
>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>> est
>>>>> bien
>>>>> remplie à chaque fois qu'un document est supprimé. ça marche bien
>>>>> au
>>>>> sein de
>>>>> SQLServer.
>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>> la
>>>>> DB
>>>>> avant
>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>>>> enregistrement de cette table et de copier l'engistrement en tant
>>>>> que
>>>>> nouveau
>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>> faire
>>>>> sur
>>>>> l'EventSink "Delete" de la biblio. source.
>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>> synchronisation
>>>>> des évènements ?
>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>> possible de
>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>>>> type
>>>>> la
>>>>> table Docs ?
>>>>> Merci
>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>
>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>
>>>>>> Quels infos vous manquemt il ?
>>>>>>
>>>>>> Renaud COMTE [MVP]
>>>>>> ---------------------------------
>>>>>> http://blogs.developpeur.org/themit/
>>>>>> http://blog.spsclerics.com/
>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>>>> copie de tous les documents du portail SPS. Quand un document
>>>>>>> est supprimé d'une bibliothèque, j'utilise ce mirroir pour faire
>>>>>>> une copie dans ma bibliothèque "corbeille". Bref, cette méthode
>>>>>>> est connue, ça marche mais le gros problème, c'est l'overhead de
>>>>>>> la DB (double copie d'un document).
>>>>>>>
>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce que
>>>>>>> je me trompe ou pas ? Si non, comment mettre en pratique cette
>>>>>>> méthode vu que les évènements sont asynchrones sous SPS ?
>>>>>>>
>>>>>>> Merci
>>>>>>>
La pour le coup, bonne analyse...
Si vous avez besoin de tracer ce genre d'informations je crois que vous n'avez
effectivement pas le choix
Eric Donneger
http://blogs.developpeur.org/FatEric
http://www.clubsps.org
> Merci pour vos réponses.
>
> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà restauré
> un
> document à partir de cet outil. C'est très utile mais les limites de
> ce
> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
> qui a
> supprimé le document, à quelle date il a été supprimé et surtout
> retrouver
> son url d'origine quand on ne se rappelle plus de son nom.
> Très souvent la problématique est ainsi : on s'aperçoit à un moment
> donné
> qu'un document a été supprimé et que le seul moyen de retrouver ce
> document
> est de restaurer celui-ci en s'appuyant sur les backups de la DB
> (encore
> faut-il savoir quand ce document a été supprimé).
> C'est pourquoi, je me lance dans cette aventure qui je l'espère
> apportera cette plus-value tant attendue...
>
> Pour répondre à vos limites :
> - Si j'utilise un flux SinkData suffisamment souple, je peux très bien
> implémenter la même librairie EventSink qui pourrait traiter non
> seulement
> les évènements liés à la gestion de la corbeille mais en plus s'il le
> faut,
> effectuer d'autres taches.
> - Service Windows ou Web ?
> - Mettre en place un service Windows pour réinjecter mes docs
> supprimés dans
> la bib "Archive" ne me parait pas suffisant pour récupérer des
> informations
> en temps réel telles que le nom de l'utilisateur qui a supprimé le
> doc. ou
> son url d'origine (je pourrais ajouté la date de suppression dans mon
> trigger).
> Me trompe-je ?
> "Eric Donneger" a écrit :
>
>> La plus grosse limitation que je vois à ce genre de solutions vient
>> du fait que SharePoint ne peut implémenter qu'une librairie
>> d'EventSink par doclib. Si vous implémentez une solution de corbeille
>> par ce biais, impossible d'implémenter quoi que ce soit d'autre qui
>> fonctionne par événement (workflow, conversion PDF ou que sais-je).
>>
>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>> réinjecter dans la doclib archive les documents "poubellisés" par
>> votre trigger.
>>
>> Pour répondre à votre question sur les réflexions menées sur cette
>> problématique : s'il s'agît uniquement de permettre la récupération
>> de documents supprimés, je vous invite à lire l'excellent article de
>> Stéphane Cordonnier
>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default.a
>> spx) et à downloader son outil.
>>
>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>> base SQL
>> de WSS (ou SPS) :
>> - vous restaurez juste la base sur un serveur SQL (autre que la base
>> de données
>> active de votre SharePoint)
>> - son outil vous permet d'explorer la structure du site pour
>> retrouver le
>> document à récupérer
>> - vous le sauvegardez en local
>> - il ne vous reste plus qu'à le réinjecter
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Je comprends la préco MS sur le fait de modifier la structure de la
>>> DB
>>> SPS
>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet pas
>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>> solution
>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>> comme
>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>> besoins. Et
>>> je ne peux attendre SPSV3 pour ça.
>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>> d'avoir
>>> une double copie d'un document dans la DB et pour que la corbeille
>>> puisse
>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>> juste un
>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>> autre
>>> table tampon de même structure que la table Docs. Si seulement cela
>>> fait
>>> planter le portail SPS, ça m'inquiéterait... mais bon, je comprends
>>> cette
>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>> bon
>>> signe ;)
>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>> biblio
>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>> crédibilité
>>> de ce
>>> mécanisme.
>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>> est-ce
>>> que quelqu'un a déjà travaillé dans ce sens ?
>>> "Eric Donneger" a écrit :
>>>> Bonjour,
>>>>
>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base de
>>>> données de SharePoint est risqué
>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>> configuration normale.
>>>>
>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>> standard sur cette doclib suffit amplement.
>>>>
>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>> casse-tête : n'importe quel lecteur verrait un document supprimé de
>>>> la doclib ultraconfidentielle de la direction générale sauf à créer
>>>> une docib archive par doclib !!!
>>>>
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement delete
>>>>> n'est signalé qu'après. Je ne vois pas comment le faire avec un
>>>>> EventHandler du coup, même avec le Frontpage RPC.
>>>>>
>>>>> Une solution que je vois, est de travailler sur une table
>>>>> "Corbeille",
>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>> "InsteadOf
>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>> est
>>>>> bien
>>>>> remplie à chaque fois qu'un document est supprimé. ça marche bien
>>>>> au
>>>>> sein de
>>>>> SQLServer.
>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>> la
>>>>> DB
>>>>> avant
>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du nouvel
>>>>> enregistrement de cette table et de copier l'engistrement en tant
>>>>> que
>>>>> nouveau
>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>> faire
>>>>> sur
>>>>> l'EventSink "Delete" de la biblio. source.
>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>> synchronisation
>>>>> des évènements ?
>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>> possible de
>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer de
>>>>> type
>>>>> la
>>>>> table Docs ?
>>>>> Merci
>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>
>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>
>>>>>> Quels infos vous manquemt il ?
>>>>>>
>>>>>> Renaud COMTE [MVP]
>>>>>> ---------------------------------
>>>>>> http://blogs.developpeur.org/themit/
>>>>>> http://blog.spsclerics.com/
>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une
>>>>>>> copie de tous les documents du portail SPS. Quand un document
>>>>>>> est supprimé d'une bibliothèque, j'utilise ce mirroir pour faire
>>>>>>> une copie dans ma bibliothèque "corbeille". Bref, cette méthode
>>>>>>> est connue, ça marche mais le gros problème, c'est l'overhead de
>>>>>>> la DB (double copie d'un document).
>>>>>>>
>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce que
>>>>>>> je me trompe ou pas ? Si non, comment mettre en pratique cette
>>>>>>> méthode vu que les évènements sont asynchrones sous SPS ?
>>>>>>>
>>>>>>> Merci
>>>>>>>
Je vous souhaite bon courage
Hier soir, j'ai diné avec le team Office 12 et quelque MVPs comme Mads NIssen.
Le soucis du recycle Bin est venue sur la table
Pour l'instant, tout le monde, MS compris, n'encourage la modification de
la BDD
>>> il s'agit de phénoméne de lockage e certaines données par l'agent de
cohérence de sharePoint
Ne m'en demandait pas plus, toute manip en BDD etant interdite, aucune doc
ne vient tracer votre besoin
Mais il y a une astuce pouvant être payante : recoder un sous menu de la
doc lib tel qeu Supprimer fassse une copie avant de supprimer
un peu de JS et une dll de copie
Voila
PS : Je ne continuerais pas la discussion, le sujet des acces en BDD étant
pour moi à proscrire dans tout les cas. essayez de vous tourner vers une
produit comme NINTEX
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> ok merci bien.
>
> Pour rebondir à cela, est-ce que quelqu'un aurait-il déjà implémenter
> l'ajout d'un document SPS dans une bib en récupérant les infos
> directement de la table Docs de SQLServer ? (et non en utilisant le
> MO).
>
> Je sais j'insiste un peu là mais qui ne tente rien n'a rien, c'est
> bien connu ;).
>
> "Eric Donneger" a écrit :
>
>> La pour le coup, bonne analyse...
>> Si vous avez besoin de tracer ce genre d'informations je crois que
>> vous n'avez
>> effectivement pas le choix
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Merci pour vos réponses.
>>>
>>> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà
>>> restauré
>>> un
>>> document à partir de cet outil. C'est très utile mais les limites de
>>> ce
>>> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
>>> qui a
>>> supprimé le document, à quelle date il a été supprimé et surtout
>>> retrouver
>>> son url d'origine quand on ne se rappelle plus de son nom.
>>> Très souvent la problématique est ainsi : on s'aperçoit à un moment
>>> donné
>>> qu'un document a été supprimé et que le seul moyen de retrouver ce
>>> document
>>> est de restaurer celui-ci en s'appuyant sur les backups de la DB
>>> (encore
>>> faut-il savoir quand ce document a été supprimé).
>>> C'est pourquoi, je me lance dans cette aventure qui je l'espère
>>> apportera cette plus-value tant attendue...
>>> Pour répondre à vos limites :
>>> - Si j'utilise un flux SinkData suffisamment souple, je peux très
>>> bien
>>> implémenter la même librairie EventSink qui pourrait traiter non
>>> seulement
>>> les évènements liés à la gestion de la corbeille mais en plus s'il
>>> le
>>> faut,
>>> effectuer d'autres taches.
>>> - Service Windows ou Web ?
>>> - Mettre en place un service Windows pour réinjecter mes docs
>>> supprimés dans
>>> la bib "Archive" ne me parait pas suffisant pour récupérer des
>>> informations
>>> en temps réel telles que le nom de l'utilisateur qui a supprimé le
>>> doc. ou
>>> son url d'origine (je pourrais ajouté la date de suppression dans
>>> mon
>>> trigger).
>>> Me trompe-je ?
>>> "Eric Donneger" a écrit :
>>>> La plus grosse limitation que je vois à ce genre de solutions vient
>>>> du fait que SharePoint ne peut implémenter qu'une librairie
>>>> d'EventSink par doclib. Si vous implémentez une solution de
>>>> corbeille par ce biais, impossible d'implémenter quoi que ce soit
>>>> d'autre qui fonctionne par événement (workflow, conversion PDF ou
>>>> que sais-je).
>>>>
>>>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>>>> réinjecter dans la doclib archive les documents "poubellisés" par
>>>> votre trigger.
>>>>
>>>> Pour répondre à votre question sur les réflexions menées sur cette
>>>> problématique : s'il s'agît uniquement de permettre la récupération
>>>> de documents supprimés, je vous invite à lire l'excellent article
>>>> de Stéphane Cordonnier
>>>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default
>>>> .a spx) et à downloader son outil.
>>>>
>>>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>>>> base SQL
>>>> de WSS (ou SPS) :
>>>> - vous restaurez juste la base sur un serveur SQL (autre que la
>>>> base
>>>> de données
>>>> active de votre SharePoint)
>>>> - son outil vous permet d'explorer la structure du site pour
>>>> retrouver le
>>>> document à récupérer
>>>> - vous le sauvegardez en local
>>>> - il ne vous reste plus qu'à le réinjecter
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Je comprends la préco MS sur le fait de modifier la structure de
>>>>> la
>>>>> DB
>>>>> SPS
>>>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet
>>>>> pas
>>>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>>>> solution
>>>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>>>> comme
>>>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>>>> besoins. Et
>>>>> je ne peux attendre SPSV3 pour ça.
>>>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>>>> d'avoir
>>>>> une double copie d'un document dans la DB et pour que la corbeille
>>>>> puisse
>>>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>>>> juste un
>>>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>>>> autre
>>>>> table tampon de même structure que la table Docs. Si seulement
>>>>> cela
>>>>> fait
>>>>> planter le portail SPS, ça m'inquiéterait... mais bon, je
>>>>> comprends
>>>>> cette
>>>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>>>> bon
>>>>> signe ;)
>>>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>>>> biblio
>>>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>>>> crédibilité
>>>>> de ce
>>>>> mécanisme.
>>>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>>>> est-ce
>>>>> que quelqu'un a déjà travaillé dans ce sens ?
>>>>> "Eric Donneger" a écrit :
>>>>>> Bonjour,
>>>>>>
>>>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base
>>>>>> de données de SharePoint est risqué
>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>>>> configuration normale.
>>>>>>
>>>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>>>> standard sur cette doclib suffit amplement.
>>>>>>
>>>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>>>> casse-tête : n'importe quel lecteur verrait un document supprimé
>>>>>> de la doclib ultraconfidentielle de la direction générale sauf à
>>>>>> créer une docib archive par doclib !!!
>>>>>>
>>>>>> Eric Donneger
>>>>>> http://blogs.developpeur.org/FatEric
>>>>>> http://www.clubsps.org
>>>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement
>>>>>>> delete n'est signalé qu'après. Je ne vois pas comment le faire
>>>>>>> avec un EventHandler du coup, même avec le Frontpage RPC.
>>>>>>>
>>>>>>> Une solution que je vois, est de travailler sur une table
>>>>>>> "Corbeille",
>>>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>>>> "InsteadOf
>>>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>>>> est
>>>>>>> bien
>>>>>>> remplie à chaque fois qu'un document est supprimé. ça marche
>>>>>>> bien
>>>>>>> au
>>>>>>> sein de
>>>>>>> SQLServer.
>>>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>>>> la
>>>>>>> DB
>>>>>>> avant
>>>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du
>>>>>>> nouvel
>>>>>>> enregistrement de cette table et de copier l'engistrement en
>>>>>>> tant
>>>>>>> que
>>>>>>> nouveau
>>>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>>>> faire
>>>>>>> sur
>>>>>>> l'EventSink "Delete" de la biblio. source.
>>>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>>>> synchronisation
>>>>>>> des évènements ?
>>>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>>>> possible de
>>>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer
>>>>>>> de
>>>>>>> type
>>>>>>> la
>>>>>>> table Docs ?
>>>>>>> Merci
>>>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>>>
>>>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>>>
>>>>>>>> Quels infos vous manquemt il ?
>>>>>>>>
>>>>>>>> Renaud COMTE [MVP]
>>>>>>>> ---------------------------------
>>>>>>>> http://blogs.developpeur.org/themit/
>>>>>>>> http://blog.spsclerics.com/
>>>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble
>>>>>>>>> une copie de tous les documents du portail SPS. Quand un
>>>>>>>>> document est supprimé d'une bibliothèque, j'utilise ce mirroir
>>>>>>>>> pour faire une copie dans ma bibliothèque "corbeille". Bref,
>>>>>>>>> cette méthode est connue, ça marche mais le gros problème,
>>>>>>>>> c'est l'overhead de la DB (double copie d'un document).
>>>>>>>>>
>>>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce
>>>>>>>>> que je me trompe ou pas ? Si non, comment mettre en pratique
>>>>>>>>> cette méthode vu que les évènements sont asynchrones sous SPS
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> Merci
>>>>>>>>>
Je vous souhaite bon courage
Hier soir, j'ai diné avec le team Office 12 et quelque MVPs comme Mads NIssen.
Le soucis du recycle Bin est venue sur la table
Pour l'instant, tout le monde, MS compris, n'encourage la modification de
la BDD
>>> il s'agit de phénoméne de lockage e certaines données par l'agent de
cohérence de sharePoint
Ne m'en demandait pas plus, toute manip en BDD etant interdite, aucune doc
ne vient tracer votre besoin
Mais il y a une astuce pouvant être payante : recoder un sous menu de la
doc lib tel qeu Supprimer fassse une copie avant de supprimer
un peu de JS et une dll de copie
Voila
PS : Je ne continuerais pas la discussion, le sujet des acces en BDD étant
pour moi à proscrire dans tout les cas. essayez de vous tourner vers une
produit comme NINTEX
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> ok merci bien.
>
> Pour rebondir à cela, est-ce que quelqu'un aurait-il déjà implémenter
> l'ajout d'un document SPS dans une bib en récupérant les infos
> directement de la table Docs de SQLServer ? (et non en utilisant le
> MO).
>
> Je sais j'insiste un peu là mais qui ne tente rien n'a rien, c'est
> bien connu ;).
>
> "Eric Donneger" a écrit :
>
>> La pour le coup, bonne analyse...
>> Si vous avez besoin de tracer ce genre d'informations je crois que
>> vous n'avez
>> effectivement pas le choix
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Merci pour vos réponses.
>>>
>>> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà
>>> restauré
>>> un
>>> document à partir de cet outil. C'est très utile mais les limites de
>>> ce
>>> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
>>> qui a
>>> supprimé le document, à quelle date il a été supprimé et surtout
>>> retrouver
>>> son url d'origine quand on ne se rappelle plus de son nom.
>>> Très souvent la problématique est ainsi : on s'aperçoit à un moment
>>> donné
>>> qu'un document a été supprimé et que le seul moyen de retrouver ce
>>> document
>>> est de restaurer celui-ci en s'appuyant sur les backups de la DB
>>> (encore
>>> faut-il savoir quand ce document a été supprimé).
>>> C'est pourquoi, je me lance dans cette aventure qui je l'espère
>>> apportera cette plus-value tant attendue...
>>> Pour répondre à vos limites :
>>> - Si j'utilise un flux SinkData suffisamment souple, je peux très
>>> bien
>>> implémenter la même librairie EventSink qui pourrait traiter non
>>> seulement
>>> les évènements liés à la gestion de la corbeille mais en plus s'il
>>> le
>>> faut,
>>> effectuer d'autres taches.
>>> - Service Windows ou Web ?
>>> - Mettre en place un service Windows pour réinjecter mes docs
>>> supprimés dans
>>> la bib "Archive" ne me parait pas suffisant pour récupérer des
>>> informations
>>> en temps réel telles que le nom de l'utilisateur qui a supprimé le
>>> doc. ou
>>> son url d'origine (je pourrais ajouté la date de suppression dans
>>> mon
>>> trigger).
>>> Me trompe-je ?
>>> "Eric Donneger" a écrit :
>>>> La plus grosse limitation que je vois à ce genre de solutions vient
>>>> du fait que SharePoint ne peut implémenter qu'une librairie
>>>> d'EventSink par doclib. Si vous implémentez une solution de
>>>> corbeille par ce biais, impossible d'implémenter quoi que ce soit
>>>> d'autre qui fonctionne par événement (workflow, conversion PDF ou
>>>> que sais-je).
>>>>
>>>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>>>> réinjecter dans la doclib archive les documents "poubellisés" par
>>>> votre trigger.
>>>>
>>>> Pour répondre à votre question sur les réflexions menées sur cette
>>>> problématique : s'il s'agît uniquement de permettre la récupération
>>>> de documents supprimés, je vous invite à lire l'excellent article
>>>> de Stéphane Cordonnier
>>>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default
>>>> .a spx) et à downloader son outil.
>>>>
>>>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>>>> base SQL
>>>> de WSS (ou SPS) :
>>>> - vous restaurez juste la base sur un serveur SQL (autre que la
>>>> base
>>>> de données
>>>> active de votre SharePoint)
>>>> - son outil vous permet d'explorer la structure du site pour
>>>> retrouver le
>>>> document à récupérer
>>>> - vous le sauvegardez en local
>>>> - il ne vous reste plus qu'à le réinjecter
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Je comprends la préco MS sur le fait de modifier la structure de
>>>>> la
>>>>> DB
>>>>> SPS
>>>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet
>>>>> pas
>>>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>>>> solution
>>>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>>>> comme
>>>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>>>> besoins. Et
>>>>> je ne peux attendre SPSV3 pour ça.
>>>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>>>> d'avoir
>>>>> une double copie d'un document dans la DB et pour que la corbeille
>>>>> puisse
>>>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>>>> juste un
>>>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>>>> autre
>>>>> table tampon de même structure que la table Docs. Si seulement
>>>>> cela
>>>>> fait
>>>>> planter le portail SPS, ça m'inquiéterait... mais bon, je
>>>>> comprends
>>>>> cette
>>>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>>>> bon
>>>>> signe ;)
>>>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>>>> biblio
>>>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>>>> crédibilité
>>>>> de ce
>>>>> mécanisme.
>>>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>>>> est-ce
>>>>> que quelqu'un a déjà travaillé dans ce sens ?
>>>>> "Eric Donneger" a écrit :
>>>>>> Bonjour,
>>>>>>
>>>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base
>>>>>> de données de SharePoint est risqué
>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>>>> configuration normale.
>>>>>>
>>>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>>>> standard sur cette doclib suffit amplement.
>>>>>>
>>>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>>>> casse-tête : n'importe quel lecteur verrait un document supprimé
>>>>>> de la doclib ultraconfidentielle de la direction générale sauf à
>>>>>> créer une docib archive par doclib !!!
>>>>>>
>>>>>> Eric Donneger
>>>>>> http://blogs.developpeur.org/FatEric
>>>>>> http://www.clubsps.org
>>>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement
>>>>>>> delete n'est signalé qu'après. Je ne vois pas comment le faire
>>>>>>> avec un EventHandler du coup, même avec le Frontpage RPC.
>>>>>>>
>>>>>>> Une solution que je vois, est de travailler sur une table
>>>>>>> "Corbeille",
>>>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>>>> "InsteadOf
>>>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>>>> est
>>>>>>> bien
>>>>>>> remplie à chaque fois qu'un document est supprimé. ça marche
>>>>>>> bien
>>>>>>> au
>>>>>>> sein de
>>>>>>> SQLServer.
>>>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>>>> la
>>>>>>> DB
>>>>>>> avant
>>>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du
>>>>>>> nouvel
>>>>>>> enregistrement de cette table et de copier l'engistrement en
>>>>>>> tant
>>>>>>> que
>>>>>>> nouveau
>>>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>>>> faire
>>>>>>> sur
>>>>>>> l'EventSink "Delete" de la biblio. source.
>>>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>>>> synchronisation
>>>>>>> des évènements ?
>>>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>>>> possible de
>>>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer
>>>>>>> de
>>>>>>> type
>>>>>>> la
>>>>>>> table Docs ?
>>>>>>> Merci
>>>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>>>
>>>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>>>
>>>>>>>> Quels infos vous manquemt il ?
>>>>>>>>
>>>>>>>> Renaud COMTE [MVP]
>>>>>>>> ---------------------------------
>>>>>>>> http://blogs.developpeur.org/themit/
>>>>>>>> http://blog.spsclerics.com/
>>>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble
>>>>>>>>> une copie de tous les documents du portail SPS. Quand un
>>>>>>>>> document est supprimé d'une bibliothèque, j'utilise ce mirroir
>>>>>>>>> pour faire une copie dans ma bibliothèque "corbeille". Bref,
>>>>>>>>> cette méthode est connue, ça marche mais le gros problème,
>>>>>>>>> c'est l'overhead de la DB (double copie d'un document).
>>>>>>>>>
>>>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce
>>>>>>>>> que je me trompe ou pas ? Si non, comment mettre en pratique
>>>>>>>>> cette méthode vu que les évènements sont asynchrones sous SPS
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> Merci
>>>>>>>>>
Je vous souhaite bon courage
Hier soir, j'ai diné avec le team Office 12 et quelque MVPs comme Mads NIssen.
Le soucis du recycle Bin est venue sur la table
Pour l'instant, tout le monde, MS compris, n'encourage la modification de
la BDD
>>> il s'agit de phénoméne de lockage e certaines données par l'agent de
cohérence de sharePoint
Ne m'en demandait pas plus, toute manip en BDD etant interdite, aucune doc
ne vient tracer votre besoin
Mais il y a une astuce pouvant être payante : recoder un sous menu de la
doc lib tel qeu Supprimer fassse une copie avant de supprimer
un peu de JS et une dll de copie
Voila
PS : Je ne continuerais pas la discussion, le sujet des acces en BDD étant
pour moi à proscrire dans tout les cas. essayez de vous tourner vers une
produit comme NINTEX
Renaud COMTE [MVP]
---------------------------------
http://blogs.developpeur.org/themit/
http://blog.spsclerics.com/
> ok merci bien.
>
> Pour rebondir à cela, est-ce que quelqu'un aurait-il déjà implémenter
> l'ajout d'un document SPS dans une bib en récupérant les infos
> directement de la table Docs de SQLServer ? (et non en utilisant le
> MO).
>
> Je sais j'insiste un peu là mais qui ne tente rien n'a rien, c'est
> bien connu ;).
>
> "Eric Donneger" a écrit :
>
>> La pour le coup, bonne analyse...
>> Si vous avez besoin de tracer ce genre d'informations je crois que
>> vous n'avez
>> effectivement pas le choix
>> Eric Donneger
>> http://blogs.developpeur.org/FatEric
>> http://www.clubsps.org
>>> Merci pour vos réponses.
>>>
>>> J'ai déjà l'appli Document Recovery en fonction et j'ai déjà
>>> restauré
>>> un
>>> document à partir de cet outil. C'est très utile mais les limites de
>>> ce
>>> dernier sont purement d'ordre fonctionnel, càd aucun moyen de savoir
>>> qui a
>>> supprimé le document, à quelle date il a été supprimé et surtout
>>> retrouver
>>> son url d'origine quand on ne se rappelle plus de son nom.
>>> Très souvent la problématique est ainsi : on s'aperçoit à un moment
>>> donné
>>> qu'un document a été supprimé et que le seul moyen de retrouver ce
>>> document
>>> est de restaurer celui-ci en s'appuyant sur les backups de la DB
>>> (encore
>>> faut-il savoir quand ce document a été supprimé).
>>> C'est pourquoi, je me lance dans cette aventure qui je l'espère
>>> apportera cette plus-value tant attendue...
>>> Pour répondre à vos limites :
>>> - Si j'utilise un flux SinkData suffisamment souple, je peux très
>>> bien
>>> implémenter la même librairie EventSink qui pourrait traiter non
>>> seulement
>>> les évènements liés à la gestion de la corbeille mais en plus s'il
>>> le
>>> faut,
>>> effectuer d'autres taches.
>>> - Service Windows ou Web ?
>>> - Mettre en place un service Windows pour réinjecter mes docs
>>> supprimés dans
>>> la bib "Archive" ne me parait pas suffisant pour récupérer des
>>> informations
>>> en temps réel telles que le nom de l'utilisateur qui a supprimé le
>>> doc. ou
>>> son url d'origine (je pourrais ajouté la date de suppression dans
>>> mon
>>> trigger).
>>> Me trompe-je ?
>>> "Eric Donneger" a écrit :
>>>> La plus grosse limitation que je vois à ce genre de solutions vient
>>>> du fait que SharePoint ne peut implémenter qu'une librairie
>>>> d'EventSink par doclib. Si vous implémentez une solution de
>>>> corbeille par ce biais, impossible d'implémenter quoi que ce soit
>>>> d'autre qui fonctionne par événement (workflow, conversion PDF ou
>>>> que sais-je).
>>>>
>>>> Pourquoi ne pas dans ce cas mettre un service qui se chargerait de
>>>> réinjecter dans la doclib archive les documents "poubellisés" par
>>>> votre trigger.
>>>>
>>>> Pour répondre à votre question sur les réflexions menées sur cette
>>>> problématique : s'il s'agît uniquement de permettre la récupération
>>>> de documents supprimés, je vous invite à lire l'excellent article
>>>> de Stéphane Cordonnier
>>>> (http://www.sharepoint-france.com/Products/DocumentRecovery/Default
>>>> .a spx) et à downloader son outil.
>>>>
>>>> Son idée est de répondre à ce problème grâce aux sauvegardes de la
>>>> base SQL
>>>> de WSS (ou SPS) :
>>>> - vous restaurez juste la base sur un serveur SQL (autre que la
>>>> base
>>>> de données
>>>> active de votre SharePoint)
>>>> - son outil vous permet d'explorer la structure du site pour
>>>> retrouver le
>>>> document à récupérer
>>>> - vous le sauvegardez en local
>>>> - il ne vous reste plus qu'à le réinjecter
>>>> Eric Donneger
>>>> http://blogs.developpeur.org/FatEric
>>>> http://www.clubsps.org
>>>>> Je comprends la préco MS sur le fait de modifier la structure de
>>>>> la
>>>>> DB
>>>>> SPS
>>>>> peut causer des dysfonctionnement mais, vu que SPS2003 ne permet
>>>>> pas
>>>>> nativement de gérer le recyclage des docs, j'essaie d'étudier une
>>>>> solution
>>>>> adaptée à mon SI. Surtout que pour l'instant, tout ce que j'ai vu
>>>>> comme
>>>>> travaux effectués sur ce sujet ne sont pas très adaptés pour mes
>>>>> besoins. Et
>>>>> je ne peux attendre SPSV3 pour ça.
>>>>> En fait, si je passe par cette méthode, c'est surtout pour éviter
>>>>> d'avoir
>>>>> une double copie d'un document dans la DB et pour que la corbeille
>>>>> puisse
>>>>> fonctionner pour mes biblios existantes. Là, pour l'instant, j'ai
>>>>> juste un
>>>>> trigger sur la table Docs, qui copie un document supprimé dans une
>>>>> autre
>>>>> table tampon de même structure que la table Docs. Si seulement
>>>>> cela
>>>>> fait
>>>>> planter le portail SPS, ça m'inquiéterait... mais bon, je
>>>>> comprends
>>>>> cette
>>>>> inquiétude. Pour l'instant, le portail SPS tourne toujours, c'est
>>>>> bon
>>>>> signe ;)
>>>>> Plus sérieusement, il n'y a que les admins qui ont accès à cette
>>>>> biblio
>>>>> archive. Mais je voulais aussi avoir votre opinion sur la
>>>>> crédibilité
>>>>> de ce
>>>>> mécanisme.
>>>>> Apparemment, peu de personnes ont déjà songé à ce type de méthode,
>>>>> est-ce
>>>>> que quelqu'un a déjà travaillé dans ce sens ?
>>>>> "Eric Donneger" a écrit :
>>>>>> Bonjour,
>>>>>>
>>>>>> Tout d'abord méfiance : implanter quoi que ce soit dans la base
>>>>>> de données de SharePoint est risqué
>>>>>> (http://support.microsoft.com/default.aspx?scid=kb;EN-US;841057)
>>>>>> même si un trigger peut facilement être supprimé pour revenir en
>>>>>> configuration normale.
>>>>>>
>>>>>> Pour ce qui est de votre question CAML, je ne vois pas bien
>>>>>> l'utilité. Si votre librairie d'EventSink réinjecte le document
>>>>>> dans une doclib "Archive" pas besoin de CAML spécifique : une vue
>>>>>> standard sur cette doclib suffit amplement.
>>>>>>
>>>>>> Au delà de ça se pose pour vous une grosse problématique de
>>>>>> sécurité : qui va avoir accès à cette doclib archive ? Si ce ne
>>>>>> sont que les admins tant mieux parce que sinon bonjour le
>>>>>> casse-tête : n'importe quel lecteur verrait un document supprimé
>>>>>> de la doclib ultraconfidentielle de la direction générale sauf à
>>>>>> créer une docib archive par doclib !!!
>>>>>>
>>>>>> Eric Donneger
>>>>>> http://blogs.developpeur.org/FatEric
>>>>>> http://www.clubsps.org
>>>>>>> Bah disons que le problème est de pouvoir récupérer le fichier
>>>>>>> avant qu'il ne soit supprimer de la DB, vu que l'évènement
>>>>>>> delete n'est signalé qu'après. Je ne vois pas comment le faire
>>>>>>> avec un EventHandler du coup, même avec le Frontpage RPC.
>>>>>>>
>>>>>>> Une solution que je vois, est de travailler sur une table
>>>>>>> "Corbeille",
>>>>>>> structure identique à la table Docs, et de gérer avec un trigger
>>>>>>> "InsteadOf
>>>>>>> delete" l'évènement "Delete" d'un document. La table "Corbeille"
>>>>>>> est
>>>>>>> bien
>>>>>>> remplie à chaque fois qu'un document est supprimé. ça marche
>>>>>>> bien
>>>>>>> au
>>>>>>> sein de
>>>>>>> SQLServer.
>>>>>>> Ma prochaine étape est, vu que la suppression est effective dans
>>>>>>> la
>>>>>>> DB
>>>>>>> avant
>>>>>>> l'appel à l'EventSink, de pouvoir récupérer le "content" du
>>>>>>> nouvel
>>>>>>> enregistrement de cette table et de copier l'engistrement en
>>>>>>> tant
>>>>>>> que
>>>>>>> nouveau
>>>>>>> document dans une bibliothèque de document "Archive", et ceci à
>>>>>>> faire
>>>>>>> sur
>>>>>>> l'EventSink "Delete" de la biblio. source.
>>>>>>> Est-ce que cela vous paraît envisageable par rapport à la
>>>>>>> synchronisation
>>>>>>> des évènements ?
>>>>>>> Et un truc que je n'ai pas eu le temps de voir, est-ce qu'il est
>>>>>>> possible de
>>>>>>> lier par le CAML ou autre, une biblio. sur une table SQLServer
>>>>>>> de
>>>>>>> type
>>>>>>> la
>>>>>>> table Docs ?
>>>>>>> Merci
>>>>>>> "Renaud COMTE [MVP]" a écrit :
>>>>>>>> Disons que Seattle n'est pas si perdu que cela
>>>>>>>>
>>>>>>>> Je disais jsute que la copie de fichier est plus rapide et
>>>>>>>> surtout plus riche d'option en utilisatn le Frontpage RPC
>>>>>>>>
>>>>>>>> Quels infos vous manquemt il ?
>>>>>>>>
>>>>>>>> Renaud COMTE [MVP]
>>>>>>>> ---------------------------------
>>>>>>>> http://blogs.developpeur.org/themit/
>>>>>>>> http://blog.spsclerics.com/
>>>>>>>>> Pour l'instant j'utilise une biblio. "mirroir" qui rassemble
>>>>>>>>> une copie de tous les documents du portail SPS. Quand un
>>>>>>>>> document est supprimé d'une bibliothèque, j'utilise ce mirroir
>>>>>>>>> pour faire une copie dans ma bibliothèque "corbeille". Bref,
>>>>>>>>> cette méthode est connue, ça marche mais le gros problème,
>>>>>>>>> c'est l'overhead de la DB (double copie d'un document).
>>>>>>>>>
>>>>>>>>> Je sais que ce sujet a été plusieurs fois évoqué mais Renaud
>>>>>>>>> COMTE avait préconisé l'utilisation du Frontpage RPC. Est-ce
>>>>>>>>> que je me trompe ou pas ? Si non, comment mettre en pratique
>>>>>>>>> cette méthode vu que les évènements sont asynchrones sous SPS
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>> Merci
>>>>>>>>>
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ? Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ? Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
Pour l'instant j'utilise une biblio. "mirroir" qui rassemble une copie de
tous les documents du portail SPS. Quand un document est supprimé d'une
bibliothèque, j'utilise ce mirroir pour faire une copie dans ma bibliothèque
"corbeille". Bref, cette méthode est connue, ça marche mais le gros problème,
c'est l'overhead de la DB (double copie d'un document).
Je sais que ce sujet a été plusieurs fois évoqué mais Renaud COMTE avait
préconisé l'utilisation du Frontpage RPC. Est-ce que je me trompe ou pas ? Si
non, comment mettre en pratique cette méthode vu que les évènements sont
asynchrones sous SPS ?
Merci
