Le dossier AKTemp

Dès que vous lancez Kentika, un dossier temporaire est créé : le dossier AKTemp. Par défaut, il est créé dans le dossier temporaire de l'administrateur mais vous pouvez choisir de la placer à la racine de l'un des disques de votre machine .

Attention : vous devez impérativement avoir des droits en lecture / écriture sur ce dossier et ce sans aucune restriction.

Choix du disque contenant le dossier temporaire

Structuration du dossier ALTemp

A l'intérieur du dossier ALTemp est automatiquement créé un sous-dossier dont le nom est égal à la signature de la base de données :

Sous-dossiers créés dans le dossier ALTemp

La signature de la base est visible dans le paramétrage de l'archivage.

• ATOMIC : dossier temporaire de la base dont la signature est "ATOMIC" quand cette dernière est exploitée en mono-poste
• ATOMIC_C : idem, quand c'est un client qui se connecte au serveur
• ATOMIC_S : idem, quand la base est exploitée en version serveur

Les fichiers à la racine de AKTemp

Certains paramètres sont indépendants de la base de données et doivent donc être les mêmes quelque soit la base à laquelle on accède. Ces paramètres sont contenus dans des fichiers placés directement à la racine de AKTemp.

ListVol.txt

Lorsque l'application Kentika démarre, elle demande au système d'exploitation quels sont les volumes disponibles. Ce dernier fournit la liste, y compris les lecteurs (ex. CD ou DVD) pour lesquels aucun disque n'est inséré. La recherche d'un fichier sur un tel lecteur n'est pas interdite mais le temps de vérification est long avant que le système n'indique qu'un tel fichier n'existe pas. Afin d'éviter ce désagrément, on indique dans un fichier ListVol.txt la liste des volumes disponibles à considérer en remplacement de ce qu'indique le système d'exploitation.

Exemple de contenu :

C:\

J:\

IP.txt

Une machine peut avoir plusieurs adresses IP et un serveur web est supposé écouter une adresse unique. De plus, une application pouvant être exécutée en mono-poste, en client ou en serveur, on peut vouloir à ce que seule la version serveur lance automatiquement le serveur WEB.

Ce fichier, s'il est créé doit contenir deux lignes : la première avec l'adresse IP d'écoute ; la deuxième avec les configurations devant lancer le serveur WEB (M : mono poste ; S : serveur ; C : client, ce cas étant plus rare).

NB : par défaut, le serveur web n'est pas lancé en configuration client.

Exemple de contenu :

192.168.0.20

MS

NoSynchrString.txt

Lorsque Kentika se lance, il synchronise les chaînes de caractères qui sont résidentes dans ses ressources propres avec les personnalisations de traduction effectuées dans l'application. Afin de bloquer cette synchronisation, il suffit qu'un fichier nommé "NoSynchrString.txt" existe dans AKTemp.

Signature.txt

Lorsque l'application Kentika quitte (version mono poste uniquement), elle écrit dans son dossier temporaire un fichier de signature permettant ensuite à la fonction "Ouvrir un fichier de données" de proposer les bases de données présentes sur la machine.

Les sous-dossiers du dossier temporaire d'une application

AcroTemp\IN et AcroTemp\OUT

Lorsque vous utilisez un programme effectuant un traitement en batch sur des archives, les documents à traiter sont archivés et également copiés dans le sous-dossier "IN" du dossier "AcroTemp". Le programme de traitement (exemple : Acrobat Exchange) devra mettre le résultat dans le sous-dossier "OUT" de ce dossier. Le fichier ainsi trouvé dans OUT viendra ensuite (et automatiquement) en remplacement de celui qui avait été archivé.

Folders

Les dossiers définis à l'aide du générateur de requêtes peuvent nécessiter des recherches approfondies dans la base de données. Afin d'éviter de les recalculer à chaque appel (ce qui serait pénalisant en terme de temps de réponse), ils sont stockés dans un sous-dossier par utilisateur placé dans ce dossier Folders. Ils sont recalculés dès que le délai indiqué en paramétrage du serveur web est dépassé ou lorsque les caractéristiques d'une requête sont modifiées.

KV_Temp

Les technologies de connexion à des bases externes génèrent de nombreux fichiers temporaires, ces fichiers sont tous organisés et stockés dans des sous-dossiers du dossier KV_Temp. Exemple : KV_record : les enregistrements de niveau 2 ; KV_RSS : le contenu des fils RSS...

NewScan et NEWTEMP

En saisie de fiche, si un utilisateur lance une application qui effectue une numérisation, le résultat de cette numérisation doit être placé dans le dossier "NewScan" (soit par une action volontaire lorsque l'utilisateur demande "Enregistrer sous", soit parce que le programme de numérisation a été ainsi réglé). Lorsque la fenêtre correspondant à la fiche en cours de saisie repasse au premier plan, le contenu de NewScan est basculé dans le sous-dossier "NEWTEMP" et attaché (en attente d'archivage) à la fiche en cours.

Si dans la version 6, vous avez paramétré votre scanner ou un raccourci vers le dossier Newscan de ALTEMP il convient de mettre celui-ci à jour.

Le dossier NewScan utilisé sera situé dans le sous dossier contenant la signature de votre fichier dans ALTEMP.

POP_Msg

Lors de la relève d'une boîte aux lettres via la centrale d'importation, les fichiers récupérés depuis le serveur SMTP sont stockés dans un sous-dossier dont le nom correspond à l'adresse relevée (sans les signes "@" ou ".").

Ressources

Lors de la mise au point des ressources du web, il est conseillé de procéder à des sauvegardes régulières (en utilisant le pop-up situé en haut à gauche de la liste des ressources). Ces fichiers de sauvegarde des ressources sont créés dans le dossier nommé "RESSOURCES".

Synchro\IN et Synchro\OUT

Si votre application fait l'objet d'une synchronisation, les lots reçus sont placés dans un dossier "IN" avant d'être intégrés ; les lots reçus sont placés dans un dossier "OUT".

TableAutorize

Les autorisations d'accès à une fiche pour un utilisateur sont calculées lors de sa connexion et conservées sous forme d'ensemble dans ces dossiers. Toutes les 2 minutes, un programme, qui s'exécute en tâche de fond, vérifie si des mouvements ont été enregistrés dans la base de données (à partir de la table "Log") et recalcule ces ensembles si des saisies ou modifications sont intervenues.

Temp

Ce dossier contient tous les fichiers temporaires de l'application. Ces fichiers ne sont pas ré-exploités d'une session sur l'autre. Il sont cependant écrits sur le disque afin de ne pas encombrer la base de données et de ne pas utiliser la mémoire vive de la machine pour des informations qui ne seront peut être plus ré-exploitées.

Les sous-dossiers propres au serveur web

WEBDBG

En phase de mise au point d'un serveur web, il arrive que l'on fasse appel à des fonctions avec une syntaxe incorrecte. Si l'application quitte, il est peut être difficile de savoir quelle URL a provoqué l'anomalie. En créant ce dossier, on provoque l'écriture du header http de chaque URL dans ce dossier. Si la requête se termine correctement, le fichier correspondant est effacé. Si une erreur survient, le fichier reste dans ce dossier et il suffit alors de vérifier son contenu avant de relancer l'application et de constater ainsi quelle URL provoque une anomalie. Il n'est pas conseillé de le conserver dès lors que l'anomalie aura disparu.

WEBLOG

Chaque URL transmise au serveur web fait l'objet d'une écriture dans un journal (ou log) et les informations qui s'y trouvent correspondent à ce qui est paramétré en paramétrage du serveur web.

LOGTRACE

Si ce dossier a été créé dans AKTemp, les erreurs et traces d'exécution de certains programmes y seront mentionnés. Particulièrement utile en phase de mise au point ou bien en cas de recherche d'anomalies, il n'est pas conseillé de conserver ce dossier de manière permanente.

WEBPOST

Lors de l'utilisation de bordereaux de saisie sur le web, les données sont envoyées en méthode "POST". Avant d'être traitées par les programme spécifique d'analyse de leur contenu, elles sont enregistrées dans des sous-dossiers du dossier WEBPOST. En phase de mise au point, cela permet de vérifier ce qui a été reçu par le serveur.

WEBTEMP

Des transformations de contenus de la base de données sont parfois nécessaires avant d'être envoyés vers le navigateur. C'est le cas des ressources image, qui sont converties en .jpg et placées dans le sous-dossier "Picts" et des zones de traitement de texte des fiches placées dans des sous-dossiers du sous-dossier WRTemp.

Ce dossier fonctionne comme un cache semi-permanent. Son contenu est réactualisé dès qu'une modification est apportée au contenu. Cependant, si vous constatez un décalage entre ce qu'affiche le navigateur et votre base de données, il est conseillé de vider le cache du navigateur et également le contenu de ce dossier.

WEBUSERS

Ce dossier contient des données de contexte propres à chaque utilisateur. Dès qu'un utilisateur se connecte à l'application avec un navigateur web, ses données sont calculées et stockées dans un sous-dossier correspondant à son identifiant ou un identifiant temporaire (si l'utilisateur est un invité). Lors de la demande d'une autre URL, Kentika recharge automatiquement les données de l'utilisateur.

Contenu d'un dossier de contexte

Le dossier propre à chaque utilisateur peut contenir les éléments suivants :

TempList : chaque liste que l'utilisateur affiche fait l'objet d'un fichier dans ce dossier. Ainsi, lors de la navigation dans une liste, il suffit d'en rechercher son contenu.

Exemple : lors de l'appel à l'URL suivante : "http://xxxx/Record.htm?idlist=2&record=131512495979"

Le fichier : "C:\ALTEMP\WEBUSERS\USERS\DOC\TempList\L_2.blb" est chargé et la liste dont le ID est 2 est restituée.

cooky.txt : date à laquelle le cooky a été envoyé à l'utilisateur, afin d'en gérer la pérennité

News_MaBase.blb : contenu des nouveautés présentées en page d'accueil. Le contenu est recalculé régulièrement (idem "Folders" décrit ci-dessus)

Param.txt : contient divers paramètres. Pour écrire et lire des paramètres dans ce fichier, utilisez les fonctions http_Contexte ("get";"monparametre";"";"") pour lire un paramètre et http_Contexte ("set";"monparametre";"";"mavaleur") pour écrire un paramètre.

Profil.blb : contient les données de profils de l'utilisateur : groupes et autorisations, tables autorisées, maquettes d'impression, outils de recherches, dossiers, dictionnaire de données.

Maintenance

Le contenu d'un certain nombre de fichiers doit être très précis. Si ce dernier se corrompt, il peut provoquer des anomalies à répétition de l'application. Dans la mesure où ils sont automatiquement régénérés, il est conseillé de purger une partie du contenu de AKTemp en cas d'anomalie.

Attention : ne procéder à des suppressions manuelles que lorsque l'application est quittée. En effet, il se peut qu'un programme s'attende à trouver un fichier et si ce dernier a disparu, cela peut provoquer une anomalie.

Contenu d'AKTemp que vous pouvez supprimer sans conséquence graves

• FOLDERS
• KV_TEMP
• TableAutorize
• Temp
• WEBPOST
• WEBTEMP
• WEBUSERS (seuls quelques paramètres risquent d'être perdus)

Contenu d'AKTemp qu'il est déconseillé de supprimer

• ACROTEMP : vous risquez de perdre des documents non encore traités.
• WEBDBG : si vous voulez identifier les URL posant problème, il faut que ce dossier existe, sinon vous pouvez le supprimer.
• POP_Msg : des informations relatives au traitement des emails sont stockées dans les sous-dossiers.
• NewScan : vous aurez besoin de le recréer suivant le mode d'acquisition que vous aurez choisi. NEWTEMP est créé automatiquement par Kentika.
• RESSOURCES : si vous supprimez ce dossier et son contenu, vous perdrez toutes les sauvegardes des ressources web que vous auriez pu faire.
• SYNCHRO IN et OUT : permet de vérifier le contenu des lots (à l'aide de la fonction "Importer des données" : son contenu est géré par l'application Kentika (paramètre : "Nombre de lots en historique" défini en paramétrage.
• WEBLOG : vous perdriez trace de l'activité au niveau du serveur WEB.

Une méthode conseillée pour ré-initialiser le contenu

A partir de l'écran des paramètres de connexion, l'option "Vider le cache" permet de supprimer du dossier AKTemp ce qui sera automatiquement recréé dès la prochaine sollicitation du serveur.