Bonjour,
idem
Le 05/01/2011 16:23, Stéphane Loret a écrit :
oui on en parlera en même temps que les questions OAI-PMH
Si vous avez bien supprimé la récolte avant la suppression de la
définition, les fiches ont du être supprimées de l'indexing. Vous
pouvez le voir en consultant l'IHM de l'indexing.
Il faut bien supprimer la récolte avant la définition car il y a un petit soucis dans la version actuelle : si vous supprimez la définition sans supprimer explicitement la récolte dans l'onglet "Récolte", les fiches restent dans la base du harvester et donc aussi dans l'indexing. En effet, la suppression de la définition ne semble pas bien supprimer les fiches récoltées. Ca sera corrigé.
Je vous propose de faire un init de la base du harvester et de l'indexing pour repartir sur une base vierge. Par la suite, pensez à prendre ces précautions et supprimer la récolte avant la définition.
vendredi 9h ? j'ai une contrainte à 10h donc je ne pourrai pas
déborder
vous m'appelez ?
vous dites que ça ne s'ouvre pas ? Mais vous voyez bien l'erreur.
Si je comprends bien, la pop-up pour saisir les métadonnées s'ouvre mais il y a cette erreur dans la page ?
Quelle est l'URL de la pop-up lorsqu'elle s'ouvre ?
Est-ce depuis que je vous ai fait changer la config que ça plante comme ça ?
Si oui, pouvez-vous essayer de vous connecter dans le module workflow avec le même compte que l'utilisateur pour qui ça a planté dans Nuxeo. Est-ce que dans les fiches en cours d'édition dans le workflow, vous voyez la fiche correspondant au référencement que vous avez essayé de lancer depuis Nuxeo ? Si oui, dans le lien "Voir", vous pouvez télécharger la version courante de la fiche de métadonnées, vous pouvez me l'envoyer ? Il faudrait voir si le md-editor plante à cause du champ description qui se serait mal rempli.
Pour rappel, ce n'est pas au moment où on choisit la section que le formulaire de saisie des métadonnées s'ouvre, mais c'est bien quand vous allez dans l'onglet "Référencement" et que vous choisissez la version à référencer et que vous cliquez sur "Référencer en tant que ....". C'est bien ce que vous avez fait ?
Pouvez-vous nous dire si le module md-editor fonctionne bien en standalone ? Pour ça, allez sur MailScanner has detected a possible fraud attempt from "....." claiming to be http://...../ori-oai-md-editor
Vous avez accès à tous les formulaires en édition sans connexion au workflow ou nuxeo ni à aucune base de données. Les fiches saisies ici peuvent être enregistrées directement sur votre poste. Les formulaires fonctionnent-ils ?
Si non, avez-vous la même erreur ?
Enfin, avez vous essayé de vous connecter depuis le module workflow en essayant de lancer un référencement ? Ceci évite de passer par Nuxeo. C'est pour essayer de cerner où se passe le problème.
idem
Yohan COLMANT
Direction des Systèmes d'Information
UVHC - Université de Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAI
Direction des Systèmes d'Information
UVHC - Université de Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAI
Le 05/01/2011 16:23, Stéphane Loret a écrit :
Bonjour Yohan, bonjour à tous,
Je vous souhaite à tous une très agréable année 2011.
Je réponds directement dans le message. Encore merci pour votre aide, nous ne sommes pas au bout de nos peines.
Bien à vous
Stéphane LORET
MSH - Tours
Crévilles.org
PS : Puis-je vous contacter directement pour, entre autres, discuter sur les possibilités de formation ?
Le 03/01/11 11:53, Yohan Colmant a écrit :Bonjour,
Désolé pour le délai, mais j'étais en congés.
Le 21/12/2010 16:18, Stéphane Loret a écrit :MerciBonjour Yohan,
Merci pour votre réponse. J'essaie de vous apporter le maximum d'information ci-après :
>> Pour être sûr, est-ce bien la dernière version que vous utilisez ?
- Version d'ORI-OAI installée : Dans le détail, on a çà :
- module Harvester : 1.6.2
- module Md-Editor : 1.6.3
- module Indexing : 1.6.1
- Version esup-ecm : 1.1.2 avec nuxeo DM 5.2, mais le jboss.dir dans build.properties du module ori-oai-nuxeo indique une version 5.3.1 de nuxeo DM.
- module repository : 1.6.2
- module vocabulary : 1.6.2
- module workflow : 1.6.3
- module search : 1.6.2
Merci pour l'info, c'est noté de notre côté !
>> Là je pense que vous êtes tombés sur un cas malheureux où vous pointiez vers un entrepôt OAI qui n'en était pas un.
Il va falloir que nous regardions de notre côté pour ne plus que ça se passe mieux dans les prochaines versions.
Pouvez-vous nous donner l'URL que vous avez entrée et qui faisait planter ?
Oui, en effet, après vérification, la base url du dépôt pointait une redirection sur une page html. La base url qui a fait planter le module : http://ir.ub.rug.nl/dspace-oai/request?verb=Identify
Mais si vous souhaitez supprimer toutes les fiches provenant d'une moisson, il vous suffit de supprimer la récolte côté moissonneur. Ceci supprimera alors les fiches dans l'index.
>> Ce que vous voulez faire, si je comprends bien, c'est bien de supprimer certaines fiches provenant d'une moisson, et qu'elles ne soient plus jamais remises dans l'index ?
A l'heure actuelle, sans moissonner des sets spécifiques où ces fiches ne sont pas présentes, ce n'est pas possible. En revanche, c'est une tâche qui a déjà été identifiée et qui sera réalisée dans la version 2 de ORI-OAI.
Oui, c'est tout à fait cela, voire même l'ensemble d'un dépôt. Je prends l'exemple de Canal-u : nous avons fait des tests sur le dépôt, mais nous souhaiterions maintenant retirer tout ce qui à trait à Canal-U, idem pour Revues.org, ne prendre en compte que les collections
Oui, c'est ce que nous avons fait, mais les fiches sont toujours bien présentes dans l'indexing et dans le module search. Et en supprimant l'index et en réindexant à la suite, on retrouve encore toutes les fiches précédemment supprimées alors que les moissons (définition, récoltes) sont bien supprimées.
Il faut bien supprimer la récolte avant la définition car il y a un petit soucis dans la version actuelle : si vous supprimez la définition sans supprimer explicitement la récolte dans l'onglet "Récolte", les fiches restent dans la base du harvester et donc aussi dans l'indexing. En effet, la suppression de la définition ne semble pas bien supprimer les fiches récoltées. Ca sera corrigé.
Je vous propose de faire un init de la base du harvester et de l'indexing pour repartir sur une base vierge. Par la suite, pensez à prendre ces précautions et supprimer la récolte avant la définition.
Peut-on se contacter directement sur ce point hors liste ? J'ai du mal à voir clairement ce que vous souhaitez et je préfère en discuter directement avec vous pour évoquer les différentes possibilités
>> Là je ne comprends pas bien votre demande.
Voulez-vous modifier des fiches que vous avez moissonnées et les exposer ensuite en OAI ?
Voulez-vous exposer une partie des fiches moissonnées sans les modifiées ?
Ou une partie des fiches que vous produisez ?
Dans ce cas, comment vous identifiez lesquelles exposer et lesquelles ne pas exposer ? Il y a un mécanisme pour ça qui repose sur les métadonnées. Par exemple, que les fiches qui contiennent tel mot dans le titre.
Cette demande est un peu particulière, je le conçois bien. Parmi les questions que vous me posez, celle qui est en rapport direct avec notre souhait est la première : modifier des fiches moissonnées pour les exposer ensuite en OAI. La couche oai actuellement en place pour le site crevilles.org porte sur la totalité du site. Nous souhaitons pouvoir, à la fin de la journée de veille ou le lendemain, ramener ce contenu au niveau du module Harvester et choisir, voire modifier, ce qui sera exposé en OAI. Il est difficile, à l'heure actuelle, de préciser globalement si telle ou telle section du site (en gros ce qui deviendra par la suite des sets au niveau de la couche), doit ou ne doit pas être exposé. Par exemple : nous ne souhaitons pas que l'actualité des études urbaines dans crévilles soit exposée, mais il est possible qu'un item dans cette catégorie de contenu déroge à la règle. Je ne sais donc pas si c'est faisable dans l'état actuel des choses ni si cela correspond ou non aux bonnes pratiques. Mais, dans un premier temps, et à la mesure des possibilités offertes, en tous les cas, nous pourrions procéder de cette manière.
Oui, je vous contacte cette semaine. Avez-vous des disponibilités ?
vous m'appelez ?
Ce qui me semble étrange, c'est que vous avez la description qui est parfois récupérée : en effet, par défaut, la configuration permettant de faire ceci n'existe pas.
>> Vous êtes sur un ESUP-ECM ou alors un Nuxeo que vous avez installé en dehors de ORI-OAI ?
Si c'est bien ESUP-ECM, je ne comprends pas à quel endroit vous avez saisi la description dont vous parlez ? Le titre quant à lui est bien rempli dans la fiche de métadonnées du module md-editor par exemple ?
Pour les droits d'accès, il faudrait voir un peu plus en détail comment fonctionne Nuxeo / ESUP-ECM.
En effet, les documents doivent être publiés dans des sections. Ce sont les droits sur les sections qui définissent les droits d'accès aux documents y étant publiés.
En gros, vous devez créer une section "Documents publics", définir un droit d'accès en lecture à l'utilisateur "invite" et publier les documents dans cette section.
Vous voyez ?
Nous sommes sur un ESUP-ECM. Quand un créateur charge un document, il y a deux champs, titre et description. Une fois que le document est archivé, le lien présent dans l'onglet référencement permet d'ouvrir un formulaire dc_easy pour que nous puissions ensuite reverser ce document dans les ressources locales. QUand le formulaire md-editor s'ouvre, on retrouve bien le titre, le type de document (pdf, etc...), mais dans la partie description (dc.description), celle qui était précisée au niveau d'esup_ecm n'apparaît pas. Cette absence n'est pas systématique car nous avons fait des essais avec des documents de différents formats, différentes tailles pour que nous puissions affinés nos réglages et la partie description dans le formulaire md-editor est parfois remplie, parfois non. Elle l'est pour des documents de type vidéo par exemple, mais elle ne l'est pas pour des pdfs. Et même sur les pdfs, c'est variable. Dans les proportions, on dira que cette partie est incomplète dans 80% des cas sur le peu de tests que nous avons faits (une dizaine de documents pour l'instant).
Vous pouvez tenter ceci et me dire si ça marche à 100% maintenant svp ?
Dans les sources qui ont été chargées du module ori-oai-nuxeo, allez dans src/main/resources/OSGI-INF/orioainuxeo2xml-contrib.xml
Et ajoutez la ligne en rouge dans le bloc suivant :
<extension target="org.orioai.esupecm.nuxeo2xml.service.OriOaiNuxeo2XmlService"
point="nuxeoToxml">
<configuration>
<metadataSchemaNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadataSchemaNamespace>
<ns prefix="dc" namespace=MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "purl.org" MailScanner has detected a possible fraud attempt from "purl.org" claiming to be "http://purl.org/dc/elements/1.1/"/>
<ns prefix="oaidc" namespace=MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "www.openarchives.org" MailScanner has detected a possible fraud attempt from "www.openarchives.org" claiming to be "http://www.openarchives.org/OAI/2.0/oai_dc/"/>
<metadata nuxeoXpath="NUXEO_URL" workflowXpath="/oaidc:dc/dc:identifier"/>
<metadata nuxeoXpath="/document/schema/nx_dc:title" workflowXpath="/oaidc:dc/dc:title"/>
<metadata nuxeoXpath="/document/schema/nx_dc:description" workflowXpath="/oaidc:dc/dc:description"/>
<metadata nuxeoXpath="substring(/document/schema/nx_dc:created, 0, 11)" workflowXpath="/oaidc:dc/dc:date"/>
<metadata nuxeoXpath="/document/nx_file:schema/nx_file:content/nx_file:mime-type" workflowXpath="/oaidc:dc/dc:format"/>
</configuration>
</extension>
Ca donne quoi ?
J'ai fait les modifications sur le fichier :
<!-- dublin core -->
<extension target="org.orioai.esupecm.nuxeo2xml.service.OriOaiNuxeo2XmlService"
point="nuxeoToxml">
<configuration>
<metadataSchemaNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadataSchemaNamespace>
<ns prefix="dc" namespace=MailScanner has detected a possible fraud attempt from "purl.org" claiming to be MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "purl.org" MailScanner has detected a possible fraud attempt from "purl.org" claiming to be "http://purl.org/dc/elements/1.1/"/>
<ns prefix="oaidc" namespace=MailScanner has detected a possible fraud attempt from "www.openarchives.org" claiming to be MailScanner soupçonne le lien suivant d'être une tentative de fraude de la part de "www.openarchives.org" MailScanner has detected a possible fraud attempt from "www.openarchives.org" claiming to be "http://www.openarchives.org/OAI/2.0/oai_dc/"/>
<metadata nuxeoXpath="NUXEO_URL" workflowXpath="/oaidc:dc/dc:identifier"/>
<metadata nuxeoXpath="/document/schema/nx_dc:title" workflowXpath="/oaidc:dc/dc:title"/>
<metadata nuxeoXpath="/document/schema/nx_dc:description" workflowXpath="/oai:dc/dc:description"/>
<metadata nuxeoXpath="substring(/document/schema/nx_dc:created, 0, 11)" workflowXpath="/oaidc:dc/dc:date"/>
<metadata nuxeoXpath="/document/nx_file:schema/nx_file:content/nx_file:mime-type" workflowXpath="/oaidc:dc/dc:format"/>
</configuration>
</extension>
Mais là, j'ai un problème dans le passage de nuxeo au workflow : quand je demande la publication du document, je choisis la section mais le formulaire pour l'édition dans le workflow ne s'ouvre pas...
Si je comprends bien, la pop-up pour saisir les métadonnées s'ouvre mais il y a cette erreur dans la page ?
Quelle est l'URL de la pop-up lorsqu'elle s'ouvre ?
Est-ce depuis que je vous ai fait changer la config que ça plante comme ça ?
Si oui, pouvez-vous essayer de vous connecter dans le module workflow avec le même compte que l'utilisateur pour qui ça a planté dans Nuxeo. Est-ce que dans les fiches en cours d'édition dans le workflow, vous voyez la fiche correspondant au référencement que vous avez essayé de lancer depuis Nuxeo ? Si oui, dans le lien "Voir", vous pouvez télécharger la version courante de la fiche de métadonnées, vous pouvez me l'envoyer ? Il faudrait voir si le md-editor plante à cause du champ description qui se serait mal rempli.
Pour rappel, ce n'est pas au moment où on choisit la section que le formulaire de saisie des métadonnées s'ouvre, mais c'est bien quand vous allez dans l'onglet "Référencement" et que vous choisissez la version à référencer et que vous cliquez sur "Référencer en tant que ....". C'est bien ce que vous avez fait ?
Pouvez-vous nous dire si le module md-editor fonctionne bien en standalone ? Pour ça, allez sur MailScanner has detected a possible fraud attempt from "....." claiming to be http://...../ori-oai-md-editor
Vous avez accès à tous les formulaires en édition sans connexion au workflow ou nuxeo ni à aucune base de données. Les fiches saisies ici peuvent être enregistrées directement sur votre poste. Les formulaires fonctionnent-ils ?
Si non, avez-vous la même erreur ?
Enfin, avez vous essayé de vous connecter depuis le module workflow en essayant de lancer un référencement ? Ceci évite de passer par Nuxeo. C'est pour essayer de cerner où se passe le problème.
Je suis donc allé voir s'il n'y avait pas un problème au niveau du module editor. Et j'ai bien une erreur de ce type :
Unable to retrieve XForms engine state. Please reload the current page. Note that you will lose any unsaved changes. Static state key: 7D0E2D1E-3D2F-82DC-1D3B-A9C495F7DF46, dynamic state key: AAE91060-1271-F3E8-9DDE-D1304BE34259Le rechargement de la page n'arrange rien. Là, j'avoue que je sèche un peu....You may want to try one of the following:
- Close this dialog and continue to use this page.
- Reload this page. Note that you will lose any unsaved changes.
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
- With Firefox and Safari: hold down the
shiftkey and click the Reload button in your browser toolbar.- With Internet Explorer: hold down the
controlkey and click the Reload button in your browser toolbar.- Return home.
Donc tout est bon là ?
Pour ce qui est des droits, j'ai repris la documentation nuxeo et d'esup-ecm pour avancer plus avant dans la configuration. Je pense pouvoir régler le problème.
>> Là je laisse un collègue plus compétent que moi sur ce module répondre.
Pour info, est-ce que l'erreur est aléatoire ou elle se présente toujours pour les mêmes fiches ? En gros, est-ce que lorsque l'erreur se produit, elle se produit toujours sur la fiche ?
Si oui, pouvez-vous nous envoyer une fiche d'exemple ?
Sur quel éditeur ça se passe ? Le dublin core ?
L'erreur était aléatoire sur l'éditeur dublin core. Je dis "était" car le redémarrage de l'application suite à une modification d'un fichier de configuration au niveau de l'éditeur a résolu le problème. Je n'ai plus de fiche exemple à vous montrer, mais l'éditeur apparaissait avec seulement les labels sans les fields.
Pour info, la version 1.6.4 du md-editor est sortie, vous pouvez basculer dessus si vous voulez.
Oui, tout est rentré dans l'ordre.
Yohan COLMANT>> Si j'interprète bien ce que vous dites, les fiches sont toujours bien dans l'index, mais c'est dans le workflow qu'elles sembles disparues ? Elles apparaissent toujours bien dans le module search ? Avant de proposer une explication, pouvez-vous vous placer dans les sources du module workflow et lancer la commande suivante : ant local-reindexall Est-ce que vous revoyez vos fiches dans l'interface du workflow ?
Oui, merci ! Toutes les fiches sont revenues.
Encore merci pour votre aide.
Direction des Systèmes d'Information
UVHC - Université de Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAIBien cordialement
Stéphane Loret
MSH - Tours
Crévilles.org
Le 20/12/10 14:55, Yohan Colmant a écrit :Bonjour Stéphane,
Je réponds dans votre mail.
Le 18/12/2010 19:40, Stéphane Loret a écrit :Pour être sûr, est-ce bien la dernière version que vous utilisez ?Bonjour,
Je suis totalement "newbie" dans la configuration et l'usage de l'application ORI-OAI et tout nouveau aussi sur cette liste que je suis pourtant depuis plus d'un an déjà. Je tiens d'abord à m'excuser de la longueur du message, de ses approximations, voire du caractère peut-être bénin de certaines erreurs ou de certaines questions mais, tout étant relatif, le côté newbie ressort ici puissamment tout cela participe de la prise en main de l'application ORI-OAI.
Avant de vous exposer ces quelques problèmes tels qu'indiqués dans le sujet de ce message, je souhaite vous présenter un peu le projet et le contexte technique dans lequel il s'inscrit. Au sein de la MSH de Tours, le projet crévilles.org vise à recenser la plupart des ressources électroniques couvrant la thématique des études urbaines et à permettre aux utilisateurs du site crevilles.org de pouvoir rechercher sur l'ensemble des ressources indexées qu'elles soient locales ou provenant de dépôts d'archives spécifiquement sélectionnés. Pour ce faire, nous avons choisis de mettre en place l'application ORI-OAI avec l'ensemble de ses modules, esup-ecm compris. Ce choix s'est porté sur cette application car sa modularité permettait de développer un projet de portage du module search vers une application CMS en php/mysql (en cours de développement). Le modèle serait celui de l'Institut de la Montagne. Pour ce qui est de l'installation de ORI-OAI dans le détail, çà donne çà :
- Sur un serveur physique Dell R710 avec 6To d'espace de stockage, 16 Go de RAM tourne un ESXI en version 4.1 dans lequel, pour l'instant, nous avons :
- Une machine virtuelle sous debian 5 lenny dédiée à l'application ORI-OAI en version 1.6.1 et l'ensemble de ses modules. Cette machine présente les caractéristiques suivantes :
- 3Go de RAM et un espace de 200 Go environ pour le tout (système et stockage)
- tous les modules tournent dans un seul tomcat en version 6.0.24. Le lancement et le redémarrage du tomcat est géré par le daemon jsvc.
- esup-ecm tourne dans un jboss.
- Le déploiement des modules s'est opéré via les sources de chaque module
- L'authentification s'effectue via un annuaire LDAP (OpenDS) propre à crévilles.org sous format SUPPANN. Pour l'instant, aucun rôle n'est réellement défini. Les 5 membres de l'équipe sont à la fois modérateur et créateur de chaque notice, dans l'attente d'un passage en production et une redéfinition des roles, si le besoin s'en fait sentir.
L'installation des modules d'ORI-OAI est fonctionnelle depuis pratiquement 15 jours maintenant et nous sommes en phase de test et de configuration pour que les modules répondent à nos besoins, principalement : le harvesting qui représente 90% actuellement des ressources que nous souhaitons proposer à nos utilisateurs et le dépôt, via esup-ecm et le module ori-oai-nuxeo (nuxeo DM en version 5.2) qui nous permet d'indexer les documents locaux (textes, images, sons et vidéos). Nous utilisons essentiellement le formulaire dc_easy pour indexer de la ressource documentaire [simple].
Là je pense que vous êtes tombés sur un cas malheureux où vous pointiez vers un entrepôt OAI qui n'en était pas un.
Ce que nous avons fait et les problèmes que nous rencontrons :
HARVESTER
- La première étape a été de tester le module Harvester en long, en large et en travers. Nous avons lancé des moissons manuellement et via le module de programmation sur des dépôts d'archives tels que Cairn, Revues.org, etc. La première programmation s'est déroulée avec quelques soucis : la base url d'un dépôt pointait une redirection sur une page html. L'erreur est relevée dans les logs mais cela a provoqué le down du module harvester pour toutes les autres programmations de moissonnage qui suivaient (erreur de type :
17 déc. 2010 06:07:16,217 [ WARN] catalina-exec-136 org.orioai.harvesting.dao.HarvestConfigDAO getLastReport - can't find last report for harvest Cairn - Histoire Urbaine.
etc...
Pire, il a fallu redémarré le tomcat pour reprendre la main sur le module et relancer les moissons manuellement. Le tomcat ne stoppait pas, bizarrement, nous avons deux daemon jsvc qui tournent comme s'il y avait deux instances d'un même tomcat alors qu'il n'en existe qu'un seul. Un kill des daemon nous a permis de reprendre la main et de relancer le tout. La question est alors de savoir s'il est normal que le module se plante quand, lors d'une tentative de moisson, il rencontre un problème du genre décrit plus haut. Y a-t-il une configuration spécifique sur un degré d'erreur qui permettrait de passer outre, de reporter sans compromettre la programmation de moisson ni l'activité même du module harvester ?
Il va falloir que nous regardions de notre côté pour ne plus que ça se passe mieux dans les prochaines versions.
Pouvez-vous nous donner l'URL que vous avez entrée et qui faisait planter ?
Ce que vous voulez faire, si je comprends bien, c'est bien de supprimer certaines fiches provenant d'une moisson, et qu'elles ne soient plus jamais remises dans l'index ?
- Toujours sur le plan Harvesting. Nous avions lancé des tests sur des dépôts sans pour autant prendre le soin de sélectionner des sets. On souhaiterait supprimer la totalité des fiches moissonnées sans qu'une réindexation ne puisse les ramener, bref, les supprimer définitivement de l'index, du workflow et de l'harvester. Nous avons essayé via le module indexing -> suppression manuelle des fiches -> suppression de toutes les fiches d'un entrepôt. La suppression se lance, mais elle reste figée. Aucune fiche n'a ensuite été supprimée et on les retrouve toutes dans l'index. La méthode visant à supprimer le dossier index puis de relancer l'indexation via le workflow et le module harvester ne résoud pas le problème. En gros, comment faire pour supprimer définitivement les fiches de ces dépôts ?
A l'heure actuelle, sans moissonner des sets spécifiques où ces fiches ne sont pas présentes, ce n'est pas possible.
En revanche, c'est une tâche qui a déjà été identifiée et qui sera réalisée dans la version 2 de ORI-OAI.
Là je ne comprends pas bien votre demande.
- Pour cette partie, il s'agit d'une demande. J'ai lu dans les messages de la liste qu'une personne souhaitait remonter une fiche issue d'une moisson dans le workflow afin d'obtenir des informations sur les métadonnées d'un champ. Dans le cas qui est le nôtre, nous aurions besoin de pouvoir ré-indexer tout ou partie de la couche oai issue des publications de notre site web crevilles.org et de sélectionner ce qui peut être publier au niveau du module de repository. Est-il possible de le faire et, si tel est le cas, comment procéder ?
Voulez-vous modifier des fiches que vous avez moissonnées et les exposer ensuite en OAI ?
Voulez-vous exposer une partie des fiches moissonnées sans les modifiées ?
Ou une partie des fiches que vous produisez ?
Dans ce cas, comment vous identifiez lesquelles exposer et lesquelles ne pas exposer ? Il y a un mécanisme pour ça qui repose sur les métadonnées. Par exemple, que les fiches qui contiennent tel mot dans le titre.
Vous pouvez expliquer plus en détail svp ?
Vous êtes sur un ESUP-ECM ou alors un Nuxeo que vous avez installé en dehors de ORI-OAI ?
NUXEO - WORKFLOW
- Nous stockons donc nos documents via nuxeo esup-ecm. Le problème est qu'après archivage du document, le formulaire md-editor qui s'ouvre ne récupère pas la description remplie dans une premier temps au niveau de nuxeo, alors que tous les autres champs reprennent bien l'ensemble des données. Une fois que le formulaire est validé, que le document est publié au niveau du workflow et indexé via le module indexing, le lien généré par nuxeo pointe un document qui est inaccessible pour les utilisateurs qui n'ont pas les droits d'accès au module nuxeo. Comment faire pour que le lien généré permette l'accès au document plein texte à l'utilisateur lambda, notamment quand ce dernier utilise le module search sur les documents locaux ?
Si c'est bien ESUP-ECM, je ne comprends pas à quel endroit vous avez saisi la description dont vous parlez ? Le titre quant à lui est bien rempli dans la fiche de métadonnées du module md-editor par exemple ?
Pour les droits d'accès, il faudrait voir un peu plus en détail comment fonctionne Nuxeo / ESUP-ECM.
En effet, les documents doivent être publiés dans des sections. Ce sont les droits sur les sections qui définissent les droits d'accès aux documents y étant publiés.
En gros, vous devez créer une section "Documents publics", définir un droit d'accès en lecture à l'utilisateur "invite" et publier les documents dans cette section.
Vous voyez ?
Là je laisse un collègue plus compétent que moi sur ce module répondre.
- D'autre part, au niveau du workflow, nous avons parfois des erreurs lors du chargement du formulaire : les labels sont bien présents mais les champs ont disparu. L'erreur suivante est générée :
2010-12-18 17:05:48,894 ERROR XFormsServer - xforms-submit-error - setting throwable {throwable: "org.orbeon.oxf.xforms.submission.XFormsSubmissionException: (processing submission response): xforms:submission for submission id: fr-get-document-submission, error code received when submitting instance: 500
null, line -1, column -1: xforms:submission for submission id: fr-get-document-submission, error code received when submitting instance: 500
at org.orbeon.oxf.xforms.submission.XFormsModelSubmission.getReplacer(XFormsModelSubmission.java:599)
at org.orbeon.oxf.xforms.submission.RegularSubmission$1.call(RegularSubmission.java:97)
Pour info, est-ce que l'erreur est aléatoire ou elle se présente toujours pour les mêmes fiches ? En gros, est-ce que lorsque l'erreur se produit, elle se produit toujours sur la fiche ?
Si oui, pouvez-vous nous envoyer une fiche d'exemple ?
Sur quel éditeur ça se passe ? Le dublin core ?
Si j'interprète bien ce que vous dites, les fiches sont toujours bien dans l'index, mais c'est dans le workflow qu'elles sembles disparues ? Elles apparaissent toujours bien dans le module search ?
- Enfin, dernière erreur qui nous préoccupe : nous avions indexé une dizaine de documents et tout se passait à peu près bien (excepté les problèmes de formulaire). Les documents étaient publiés et ils étaient présents dans le module search et le module indexing. Sans comprendre comment, la liste des resssources en traitement ou traitées a disparu et aucun lien n'est présent dans cette partie du workflow. Le problème est que nous n'avons pas d'erreur, du moins pas en rapport avec ce module. Est-il possible que ce problème soit en lien avec les problèmes que l'on rencontre avec le formulaire et Orbeon ? Comment faire pour retrouver les liens et nous permettre de gérer les documents publiés ?
Avant de proposer une explication, pouvez-vous vous placer dans les sources du module workflow et lancer la commande suivante :
ant local-reindexall
Est-ce que vous revoyez vos fiches dans l'interface du workflow ?
Merci.
Bien cordialement et avec toutes mes excuses pour la longueur du message.
Bonnes fêtes également,
Yohan COLMANT
Direction des Systèmes d'Information
UVHC - Université de Valenciennes et du Hainaut Cambrésis
Coordinateur Technique du projet ORI-OAIJe vous souhaite d'agréables fêtes.
Stéphane LORET
MSH - TOURS
Crévilles.org