Diagnostiquer les problèmes de (dé)publication⚓

Il existe une file d'attente propre aux publications, et une file d'attente propre aux dépublications.

Chaque file d'attente classe les fichiers à traiter dans l'ordre de date et heure, qu'elles aient été calculées lors de la publication immédiate ou définies par une publication différée. Quelles que soient les dates et l'heure, le système ne démarre une publication que s'il a achevé ou renoncé à la précédente.

Dans le cas où s'accumule un grand nombre de lancements de publications de nombreux établissements concernant de gros fichiers, ce traitement progressif explique les délais parfois conséquents (plus de 12 h) entre la validation de la demande et l’achèvement du processus de certaines publications [ou dé-publications] .

La file d'attente fonctionne d'un jour sur l'autre : une publication programmée finira donc par être traitée sans avoir à être relancée.

• Inscription dans la file d'attente, ce qui génère le chevron gris sur le fichier dans l'interface professionnelle.

• Quand vient son tour, démarrage du processus proprement dit de publication et écriture du fichier Traces :

  NB : tant que ce processus proprement dit n'a pas démarré, le fichier Traces contient les informations liées à l'opération précédente.

• Eclatement du fichier xml EAD en autant de fichiers qu'il y a de composants <c> + le <archdesc> afin de permettre l'affichage par composant dans l'interface publique

• Indexation avec gestion des héritages de chaque composant dans chaque table : chaque index apparaît dans les Traces ;

  exemple pour l'index Cote

• Récupération des formes d'autorité non retenues d'IdRef pour les index concernés  :

• Copie de l'ensemble des données du serveur de production au serveur de consultation dédié à l'interface publique :

• Suppression de la base de consultation : le fichier disparait de l'arborescence dans l'interface publique

• Suppression des unités par composants : ce qui autorise d'en supprimer, d'en rajouter ou d'en déplacer sans risque de conflit avec la version antérieure du fichier lors de la republication

  C'est l'importance de cette étape qui rend indispensable la dépublication pour republication des fichiers dont la structure est modifiée :

• Suppression de tous les index spécifiques

Le système détecte que le document XML n'est pas valide : il ne respecte pas les règles de xml ou n'est pas conforme : il viole la DTD EAD. Le message peut éventuellement pointer un détail de non conformité ou non validité.

Attention il ne peut mentionner que la première cause rencontrée qui bloque le processus de publication, mais le fichier peut contenir plusieurs problèmes XML ou EAD.

1. Exporter le fichier au format Natif-Déclaration avec l'extension .xml

2. Ouvrir ce fichier exporté dans NotePad++ ou un éditeur XML type Oxygen et lancer un processus de validation pour avoir la liste exhaustive des violations de la DTD ou de l'XML

3. Corriger les erreurs directement dans cet éditeur XML extérieur à Calames, enregistrer le fichier corrigé et relancer un processus de validation pour vérifier qu'il est désormais valide et conforme

4. Réimporter le fichier xml corrigé dans Calames

Une erreur présente dans l’xml du fichier EAD peut très bien n’avoir eu aucune conséquence au moment de l’import de ce fichier dans Calames, mais bloquer ensuite la publication de ce fichier.

Le problème se situe ici dans l’encodage xml du fichier EAD.

Les traces indiquent après « ErrMessage Analyse XML » la ligne et l'ordre du caractère à corriger dans l'xml.

1. Exporter le fichier au format Natif-Déclaration avec l'extension .xml

2. Ouvrir ce fichier exporté dans NotePad++ ou un éditeur XML type Oxygen et lancer un processus de validation pour avoir la liste exhaustive des violations de la DTD ou de l'XML

3. Corriger les erreurs directement dans cet éditeur XML extérieur à Calames, enregistrer le fichier corrigé et relancer un processus de validation pour vérifier qu'il est désormais valide et conforme

4. Réimporter le fichier xml corrigé dans Calames

L'attribut URL d'<eadid> dans l'<eadheader> est considéré comme en double dans le fichier EAD alors que sa répétition est invalide car la valeur saisie manuellement dans le document EAD entre en conflit avec la valeur automatiquement calculée par le système lors de la publication.

Dans l'interface professionnelle, effacer la valeur présente dans l'attribut URL d'<eadid>, puis relancer la publication.

ERROR GRAVE: pas de rcr valide dans le fichier ead,...

1. Ajouter le RCR Calames de l'établissement dans l'attribut AUTHFILENUMBER du<corpname> du <repository>

2. Relancer la publication

Dans ce cas, au maximum 12 heures après la publication, Calames affiche un message dans les traces du fichier EAD à publier qui témoigne de l'échec de la publication en raison d'une trop grande sollicitation du serveur Abes hébergeant la base de production Calames ("bloqué sur les ressources verrous").

• Relancer le processus de publication, de préférence en différé et en-dehors des heures de bureau

Message 9002, gravité 17, état 2, ligne 1 : Le journal des transactions de la base de données « Calames » est plein en raison de « LOG_BACKUP ».

Même après plusieurs heures, le fichier n'apparaît pas dans l'interface publique de Calames.

• Relancer le processus de publication, de préférence en différé et en-dehors des heures de bureau

  Si 24h après cette relance, vous constatez que la publication échoue à nouveau, ouvrir un ticket sur le guichet ABESstp Calames Pro, domaine Dysfonctionnement technique.

Le serveur qui sert au fonctionnement de la recherche publique n'était pas joignable : les données de la base de production n'ont donc pas pu être copiées sur la base de consultation. Dans ce cas, pour éviter toute confusion, le processus de publication est entièrement annulé.

• Relancer le processus de publication, de préférence en différé et en-dehors des heures de bureau.

Travail « Despublication de :1623 » : étape 1, « Premiere étape » : début d'exécution de 2019-12-02 15:11:24

debut depublication [SQLSTATE 01000]

debut depublication [SQLSTATE 01000]

fin depublication [SQLSTATE 01000]

appel depublie sur :CGM-READ [SQLSTATE 01000]

execution de :execute [CGM-READ].[Formation].[dbo].[sp_DesPublie] 1623 [SQLSTATE 01000]

debut depublication [SQLSTATE 01000]

Message 1205, gravité 13, état 52, ligne 16 : La transaction (ID de processus 61) a été bloquée sur les ressources verrou | tampon de communication par un autre processus et a été choisie comme victime. Réexécutez la transaction. [SQLSTATE 40001]

fin depublication [SQLSTATE 01000]

Quand le système de publication est sursollicité ("bloqué sur les ressources verrous"), il decide de sacrifier certaines dépublications ("choisie comme victime") pour être sûr de mener les autres à leur terme. C'est surtout le cas quand un même établissement lance successivement et sans pause plus de 4 ou 5 dépublications quasi simultanées

• Relancer les dépublications en veillant à attendre que la précédente ait abouti pour lancer la suivante

  En cas de besoin de dépublications massives (plus de 10 fichiers), il est possible de demander à l'Abes de les programmer pour la nuit suivante en lui envoyant par AbesSTP la liste des clés concernées

Le fichier que vous pensez avoir dépublié est toujours visible dans l'interface publique à son ancienne place dans l'arborescence, mais le fichier a disparu de l'interface professionnelle.

Il s'agit d'une suppression sans dépublication : les données sont donc restées sur le serveur de consultation et ont été supprimées du serveur de production.

1. Relever la clé du fichier concerné, grâce à l'url dans l'interface publique

2. Faire un ticket AbesSTP pour demander à l'Abes :

• soit de mener la suppression à son terme en procédant à la dépublication oubliée : seul un administrateur peut le faire

• soit de réimporter le fichier qui n'aurait pas dû être supprimé dans la base de production à partir des sauvegardes