Sélectionner la trace Tous les clients au lieu d'une trace particulière a pour effet d'afficher une liste de tous les fichiers de trace associés aux traces activées.

Pour des raisons de sécurité, les journaux d'audit sont toujours activés. Par défaut, les journaux d'audit sont enregistrés pour 10 jours sur le serveur de génération de rapport WebFOCUS. Vous pouvez personnaliser cette durée pendant laquelle les journaux sont enregistrés, enregistrer les événements de connexion dans un journal séparé, et enregistrer les journaux dans une base de données.

Pour plus d'informations relatives à la modification du comportement par défaut ou l'emplacement du journal par défaut, consultez Paramètres Répertoires d'application .

Pour visualiser le jour d'audit, vous devez vous connecter en tant qu'utilisateur administratif avec le paramètre SystemFullControl sur ROOT. Les journaux sont accédés via la console d'administration.

1. Sélectionnez Diagnostics dans le volet de navigation de la console d'administration, puis, dans le dossier Traces, sélectionnez Tous les clients.

   La liste des journaux clients apparaît.

2. Déroulez puis sélectionnez audit.log pour ouvrir le fichier.

   Les journaux anciens apparaissent avec la date ajoutée à leur nom de fichier sous la forme audit.log_YYYY_MM_DD.log. Par défaut, les journaux sont gardés pendant dix jours. Cette durée est déterminée par la valeur du paramètre IBI_Log_Retain_Days dans les paramètres de configuration.

L'emplacement du fichier d'audit est déterminé par le fichier WEB-INF\classes\log4j.xml. L'emplacement par défaut est /ibi/WebFOCUS81/logs et tous les événements sont écrits dans un seul fichier. Pour enregistrer des événements de connexion utilisateur, y compris les déconnexions et les expirations, dans un fichier séparé, vous devez créer un nouvel appender dans le fichier log4j.xml puis modifier le nom du logger dans com.ibi.uoa.signin pour le faire pointer sur le nouvel appender.

1. Ouvrez le fichier drive:/ibi/WebFOCUS81/webapps/webfocus/WEB-INF/classes/log4j.xml.
2. Insérez un nouvel appender, qui enregistre les événements de connexion dans un fichier nommé signinout.log, comme le montre le code d'exemple suivant.

   <appender name="LOGuoaSignInOut" class="org.apache.log4j.DailyRollingFileAppender">
     <param name="File" value="C:/ibi/WebFOCUS81/logs/signinout.log"/>
     <param name="DatePattern" value="'_'yyyy-MM-dd'.log'"/>
     <param name="immediateFlush" value="true"/>
     <param name="append" value="true"/>
     <layout class="org.apache.log4j.PatternLayout">
     <param name="ConversionPattern" value="[%d] %-5p %-16.16X{remoteAddress} %-20.20t %m%n" />
     </layout>
   </appender>

3. Recherchez dans le fichier le texte logger name="com.ibi.uoa.signin" et mettez à jour l'entrée pour écrire :

   <logger name="com.ibi.uoa.signin" additivity="false">
      <level value="info" />
      <appender-ref ref="LOGuoaSignInOut"/>
   </logger>

4. Enregistrez le fichier.

Les événements de connexion sont maintenant enregistrés dans signinout.log, ce qui apparaîtra dans la liste des traces Tous les clients.

Vous pouvez enregistrer les événements de sécurité dans une base de données en utilisant l'appender Apache Log4j JDBC.

1. Déterminez quelle information vous avez besoin de capturer.

   Par exemple, il est possible que vous ayez à enregistrer les événements de sécurité de connexion utilisateur dans une base de données, en capturant l'information suivante :

   • Tentatives de connexion et de déconnexion.
   • Création, modification, suppression d'utilisateurs.
   • Utilisateurs qui ont été ajoutés aux groupes ou supprimés.
2. Créez la table de la base de données qui sera utilisée pour stocker l'information du journal d'audit. La table doit avoir les colonnes appropriées pour que cette information soit capturée.

   Pour l'exemple discuté dans l'étape 1, vous pouvez créer une table pour capturer les ID utilisateur, les tampons date/heure, les noms de connecteur, ainsi que les événements d'audit pour les tentatives de connexion et les utilisateurs, à l'aide du code suivant.

   CREATE TABLE WF_AUDIT_LOG (
   USERID VARCHAR(255),   --- Signed-in user
   DATETIME VARCHAR(255), --- Date and timestamp
   LOGGER VARCHAR(255),   --- Logger name
   MESSAGE VARCHAR(255)); --- Event

3. Mettez à jour le fichier drive:/ibi/WebFOCUS81/webapps/webfocus/WEB-INF/classes/log4j.xml pour associer l'appender JDBC avec les noms de connecteur spécifiés dans Evénements Sécurité et pour inclure la référence appender (appender-ref), qui utilise le nom de l'appender JDBC pour les événements correspondants. Pour cet exemple, suivez les étapes suivantes.
   1. Ajouter l'appender JDBC au fichier log4j.xml avec le code suivant.

      <appender name="LOGdb" class="org.apache.log4j.jdbc.JDBCAppender">
         <param name="URL" value="jdbc:derby://localhost:1527/WebFOCUS81;create=true"/>
         <param name="Driver" value="org.apache.derby.jdbc.ClientDriver"/>
         <param name="User" value="webfocus"/>
         <param name="Password" value="webfocus"/>
         <layout class="org.apache.log4j.PatternLayout">
         <param name="ConversionPattern" value="INSERT INTO WF_AUDIT_LOG
               (USERID,DATETIME,LOGGER,MESSAGE)VALUES ('%X{userId}','%d', '%c', '%m')" />
         </layout>
      </appender>

   2. Déterminez où l'information a été journalisée, ajoutez la référence Appender JDBC aux noms du logger.
   • Pour journaliser l'information uniquement dans une base de données externe, utilisez le code suivant :

     <logger name="com.ibi.uoa.users" additivity="false">
        <level value="info" />
        <appender-ref ref="LOGdb" />
     </logger>
     <logger name="com.ibi.uoa.signin" additivity="false">
        <level value="info" />
        <appender-ref ref="LOGdb" />
     </logger>

   • Pour journaliser les informations à la fois dans WebFOCUS et dans une base de données externe, utiliser le code suivant :

     <logger name="com.ibi.uoa.users" additivity="false">
        <level value="info" />
        <appender-ref ref="LOGuoa" />
        <appender-ref ref="LOGdb" />
     </logger>
     <logger name="com.ibi.uoa.signin" additivity="false">
        <level value="info" />
        <appender-ref ref="LOGuoa" />
        <appender-ref ref="LOGdb" />
     </logger>

4. Si le fichier drive:/ibi/WebFOCUS81/webapps/webfocus/webfocus.war est déployée sur le serveur d'applications, mettez à jour le fichier webfocus.war puis redéployez. Si le répertoire drive:/ibi/WebFOCUS81/webapps/webfocus est déployé à la place, passez directement à l'étape suivante.
5. Recyclez le serveur d'applications.

La table de la base de données capture tous les événements de la sécurité dans une ligne séparée, comme le montre l'image suivante.

La table suivante fournit la liste des types d'événement sécurité enregistrés pour l'audit dans WebFOCUS.

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de configuration indiqué par config.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• Événement spécifique qui a été journalisé, dans ce cas, configUpdate, une mise à jour de la configuration.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Nom du fichier affecté, typiquement webconfig.xml.
• Nom de l'utilisateur qui a effectué cette action.
• Nouvelle valeur de la propriété modifiée.
• Ancienne valeur de la propriété modifiée.

[YYYY-MM-DD hh:mm:ss,sss] INFO config monitor_ID user_ID 
configUpdate {SUCCESS|FAILURE} file:file_name user:user_ID 
parameterName:parameter_name newValue:new_value oldValue:old_value

[YYYY-MM-DD hh:mm:ss,sss] INFO config monitor_ID user_ID 
configUpdate {SUCCESS|FAILURE} file:license_key_file user:user_ID 
parameterName:parameter_name newKey:new_value newSite:site_code

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de contenu indiqué par content.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• Evénements spécifiques, par exemple, createFolder ou putItem.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Nom de l'utilisateur qui a effectué cette action.
• Emplacement du contenu affecté par cette action.
• Champs affectés par cette action.

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID 
delete {SUCCESS|FAILURE} user:user_ID folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID  
moveFolder {SUCCESS|FAILURE} user:user_ID  srcitem:old_IBFS_address dstitem:new_IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID 
putFolderProperties {SUCCESS|FAILURE} user:user_ID 
folder:new_IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID 
createItem {SUCCESS|FAILURE} user:user_ID folder:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID 
putItem {SUCCESS|FAILURE} user:user_ID item:IBFS_address

[YYYY-MM-DD hh:mm:ss,sss] INFO content monitor_ID user_ID 
delete {SUCCESS|FAILURE} user:user_ID item:IBFS_address

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de groupe indiqué par groups.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• Description de l'action, par exemple, createGroup or putGroup.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Nom et identifiant numérique unique du groupe affecté par l'action.
• Champs affectés par cette action.

Chaque utilisateur et chaque groupe sont identifiés par un identifiant numérique unique, ainsi que par un nom.

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_ID user_ID 
createGroup {SUCCESS|FAILURE} name:group_name (group_ID) 
parent:group_parent (parent_group_ID) desc:group_description extGrp:external_group_mappings

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_ID user_ID 
deleteGroup {SUCCESS|FAILURE} group:IBFS_address (group_ID) 
users-autoremoved:number_of_group_members

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_ID user_ID 
putGroup {SUCCESS|FAILURE} groupPath:IBFS_address (group_ID) 
newdesc:new_description olddesc:old_description 
externalGroups:external_group_mappings

[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_ID user_ID 
renameGroup {SUCCESS|FAILURE} name:group_name (group_ID) 
parent:parent_group oldName:old_group_name

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de propriétés indiqué par ownership..
• L'action effectuée, tel que le changement du propriétaire, indiquée par changeOwner, ou la publication d'un élément, indiquée par makePublic.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Si une ressource hérite de ses propriétés de son parent.
• Le chemin complet IBFS de la ressource.
• L'identifiant utilisateur du nouveau propriétaire de la ressource.
• Type de propriétaire, G pour un groupe ou U pour un utilisateur.

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_ID user_ID 
makePrivate {SUCCESS|FAILURE} inherited:{TRUE|FALSE} strPath:IBFS_address ownerName:owner_group_name ownerType:G

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_ID user_ID 
changeOwner {SUCCESS|FAILURE} inherited:{TRUE|FALSE} 
strPath:IBFS_address ownerName:owner_user_ID ownerType:U

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_ID user_ID 
makeManaged {SUCCESS|FAILURE} resource:IBFS_address 
ownerName:new_owner ownerType:U

[YYYY-MM-DD hh:mm:ss,sss] INFO ownership monitor_ID user_ID 
isPublishable {SUCCESS|FAILURE} inherited:{TRUE|FALSE} 
ownerName:parent_folder

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de rôle indiqué par roles.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• ID Utilisateur de l'utilisateur qui a effectué cette action.
• Événement spécifique, par exemple, createRole.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Emplacement du rôle affecté par cette action.
• Stratégie pour le rôle.

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_ID user_ID 
createRole {SUCCESS|FAILURE} role:role_name (role_ID) 
desc:description policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_ID user_ID  
putRole {SUCCESS|FAILURE} role:role_name (role_ID)   
desc:description policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_ID user_ID 
deleteRole {SUCCESS|FAILURE} role:role_name (role_ID) 
udr-autoremoved:number_user_default_rules_using_the_role 
policy:privilege_name:OPERATION;

[YYYY-MM-DD hh:mm:ss,sss] INFO roles monitor_ID user_ID  
createRole {SUCCESS|FAILURE} role:role_name_copy (role_ID) 
desc:description_copy policy:privilege_name:OPERATION;

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de règle indiqué par rules.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• ID Utilisateur de l'utilisateur qui a effectué cette action.
• Événement spécifique, par exemple, ddGroupRule oUaddUserRule.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Emplacement de sources à laquelle la règle s'applique.
• Stratégie d'accès de la règle.
• Si la règle s'applique à son emplacement uniquement, l'enfant de cet emplacement seulement, ou à cet emplacement et à son enfant.

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement utilisateur indiqué par partages.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• ID Utilisateur de l'utilisateur qui a effectué cette action.
• Événement spécifique, par exemple, clearShares.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Si le propriétaire de la ressource est un groupe ou un utilisateur individuel, G ou U.
• L'ID propriétaire.

[YYYY-MM-DD hh:mm:ss,sss] INFO shares monitor_ID user_ID  
{SUCCESS|FAILURE} resource:IBFS_address 
count:number_of_parties_shared_with ownerType:{G|U} ownerID:owner_ID

[YYYY-MM-DD hh:mm:ss,sss] INFO shares monitor_ID user_ID 
clearShares {SUCCESS|FAILURE} resource:IBFS_address 
count:number_of_parties_shared_with ownerType:{G|U} ownerID:owner_ID

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement de connexion indiqué par signin.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• ID Utilisateur de l'utilisateur qui a effectué cette action.
• Description de l'action, par exemple, connexion.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• Nom et ID moniteur de l'utilisateur qui s'est connecté.
• L'adresse IP et l'agent utilisateur ou le type de navigateur, si disponible.

Chaque utilisateur peut identifier par un ID numérique unique, ainsi que par un nom.

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_ID user_ID 
signIn {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID 
IPaddr:IP_address userAgent:user_agent

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_ID user_ID 
signOut {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID

[YYYY-MM-DD hh:mm:ss,sss] INFO signin monitor_ID user_ID 
signOut {SUCCESS|FAILURE} user:user_ID monitorId:monitor_ID

authentication Failure-unregistered_user User:xyzabc

authentication Failure-EDA-RC User:admin RC:32033
EDANODE:EDASERVE

authentication Failure-EDA-RC User:bn01618 RC:32034 
EDANODE:EDASERVE

authentication Failure-Unknown User:cssadmin RC:32063 
EDANODE:EDASERVE

authentication Failure-EDA-RC User:cssadmin RC:32034 
EDANODE:EDASERVE

ERROR_AUTHENTICATION_FAILURE (5003)

ERROR_AUTHENTICATION_FAILURE_ID_INACTIVE (5006)

ERROR_AUTHENTICATION_MUST_CHANGE_PASSWORD (5007)

ERROR_AUTHENTICATION_PASSWORD_EXPIRED (5008)

ERROR_AUTHENTICATION_USER_LOCKED (5009)

ERROR_AUTHENTICATION_USER_ALREADY_LOGGED_IN (5020)

Dans la table suivante, chaque entrée de journal est composée des éléments suivants :

• Tampon date/heure, au format YYYY-MM-DD hh:mm:ss,sss.
• Niveau du journal, tel que INFO.
• Type d'événement journalisé, dans ce cas, un événement utilisateur indiqué par utilisateurs.
• ID Moniteur de l'utilisateur qui a effectué cette action.
• Description de l'action, par exemple, createUser or putUser.
• L'action est exécutée avec succès ou échoue, ce qui est indiqué par SUCCESS ou FAILURE.
• ID utilisateur et identifiant numérique unique de l'utilisateur affecté par l'action.
• Champs affectés par cette action.

Chaque utilisateur et chaque groupe sont identifiés par un identifiant numérique unique, ainsi que par un nom.

Evénement	entrée Journal
Un utilisateur a été créé	[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_ID user_ID  createUser {SUCCESS|FAILURE} user:user_ID (user_number) status:{ACTIVE|INACTIVE} email:email_address desc:description
Les détails d'un utilisateur ont été modifiés	[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_ID user_ID  putUser {SUCCESS|FAILURE} user:user_description (user_ID)  status:status email:email_address desc:description
Le compte utilisateur est désactivé	[YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_ID user_ID  putUser {SUCCESS|FAILURE} user:user_ID (user_number) status:INACTIVE email:email_address desc:description
Le compte utilisateur est supprimé	[YYYY-MM-DD hh:mm:ss,sss] INFO groups monitor_ID user_ID removeUserFromGroup {SUCCESS|FAILURE} user:user_ID (user_number) group:group_name (group_ID) [YYYY-MM-DD hh:mm:ss,sss] INFO users monitor_ID user_ID status:{ACTIVE|INACTIVE} email:email_address desc:description
Le mot de passe a été changé	[YYYY-MM-DD hh:mm:ss,sss] INFO users changePassword {SUCCESS|FAILURE} user:user_whose_password_is_changed (user_number)  status:{ACTIVE|INACTIVE} email:email_address desc:description

Toutes les activités de l'outil InfoAssist, BI Portal, et ReportCaster sont suivies et enregistrées dans le fichier journal event.log, situé dans le répertoire drive:/ibi/WebFOCUS81/logs.Les niveaux d'analyse suivants sont disponibles :

• OFF. Aucune activité n'est écrite dans le fichier journal.
• FATAL. Produit un minimum d'analyse.
• ERROR. Journalise les informations seulement si une erreur survient.
• WARN. Ne capture que des messages d'avertissement.
• INFO. Ne capture que des messages d'informations.
• DEBUG. Produit un maximum d'analyses.
• TRACE. Active l'analyse.

Cette option trace les connexions du Client au Serveur de génération de rapport. Le type de trace qui s'affiche (NGXXJ ou JLINK) dépend du paramètre IBI_EDACONNECTOR.

Les noms de fichier de trace sont de la forme :

sequencenumber_tracetype_Connector_date_time.trace

où :

sequencenumber

Un nouveau numéro d'ordre est généré chaque fois qu'un fichier de trace est créé. Il aide à déterminer l'ordre de traitement lors de l'analyse de traces pour plusieurs composants.

tracetype

Il s'agit de types de trace, NGXXJ ou JLINK.

date_time

Il s'agit de la date/heure de la création du fichier.

Remarque : ce paramètre met à jour les paramètres CONNECTOR_TRACE dans la section paramètres de démarrage dans la section configuration de la console d'administration. Cependant, activer la trace (TRACE=ON) a pour effet d'annuler le paramètre CONNECTOR_TRACE. Lorsque la trace est activée (TRACE=ON), les informations de la trace Connecteur du client sont incluses dans le fichier trace du composant (par exemple, WFServlet) qui utilise l'API (WFAPI) WebFOCUS pour se servir du Connecteur Client.

La trace des systèmes d'informations géographiques (SIG) montrent les étapes suivies dans le traitement de requêtes pour dessiner des cartes ou exécuter des rapports.

Le niveau 1 donne le moins de détails et le niveau 4 donne le plus de détails. Il vous est recommandé de toujours utiliser le niveau 4.

La trace fournit les informations suivantes :

• Les demandes de requête ArcXML depuis ArcIMS
• Les demades de dessin de cartes ArcXML
• Les réponses ArcXML
• Code utilisé pour appeler les procédures FOCEXEC
• Réponses Rapport
• Les réponses XML à utiliser pour dessiner des cartes

Les informations à propos des Graphiques Côté Serveur (SSG) sont disponibles en utilisant l'option de traçage de graphique sous la section Diagnostics dans la Console d'administration. Les informations disponibles diffèrent selon que SSG_EXTERNAL=YES (basé traitement) ou SSG_EXTERNAL=NO (basé thread) est défini.

Quand SSG_ENABLE=YES et SSG_EXTERNAL ont la valeur oui (Yes), ces paramètres sont accessibles dans la section graphique des paramètres client. WFServlet démarre un nouveau processus Java pour invoquer le moteur graphique. SSG_EXTERNAL=YES nécessite du temps de démarrage car elle analyse toutes les propriétés de graphique lorsque le moteur de graphique est chargé. Si le traçage est activé et vous exécutez une requête de graphique, trois fichiers de trace s'affichent au format :

sequence_number_SSGexternal_date_time.trace

Fournit toutes les informations de trace relatives à l'exécution de la requête de graphique. Cela comprend le numéro de révision, les informations d'analyse et les appels API envoyés au Moteur de Graphique.

sequence_number_SSGexternal_ERROR_date_time.trace

Fournit des informations relatives aux erreurs rencontrées lors des processus JVM distincts.

sequence_number_SSGexternal_OUTPUT_date_time.trace

Fournit des informations sur plusieurs traitements JVM.

La définition SSG_ENABLE=YES et SSG_EXTERNAL=NO a pour résultat l'affichage d'un fichier de trace au format :

sequence_number_graph_date_time.trace

Similaire à sequence number_SSGexternal_date_time.trace, ce fichier de trace fournit toutes les information de trace relatives à l'exécution de la requête de graphique.

Les niveaux d'analyse suivants sont disponibles :

• OFF. Aucune activité n'est écrite dans le fichier journal.
• FATAL. Produit un minimum d'analyse.
• ERROR. Journalise les informations seulement si une erreur survient.
• WARN. Ne capture que des messages d'avertissement.
• INFO. Ne capture que des messages d'informations.
• DEBUG. Produit un maximum d'analyses.
• TRACE. Active l'analyse.

Remarque : la définition SSG_ENABLE=NO ne crée aucun fichier de trace car les graphiques d'applet sont exécutés dans le navigateur et non pas sur le serveur de l'application.

Ceci fournit le traçage pour tous les appels HTTP et les paramètres de chaque appel JSP.

Vous pouvez afficher les informations de fichier journal et de trace pour l'Utilitaire de nettoyage de tickets différés MR dans la console d'administration

Fichier de journal de l'Utilitaire de nettoyage de tickets différés MR

Un fichier de journal est créé chaque fois que l'Utilitaire de nettoyage de tickets différés MR est exécuté. Pour afficher les fichiers journaux, cliquez sur l'option Utilitaire de nettoyage des tickets différés Managed Reporting situé dans le dossier Traces sous la section Diagnostics de la Console d'administration.

Le nom de fichier du fichier journal est écrit au format :

mrdtcleanup_date_time.log

où :

date

est la date de création du fichier journal aux format Année-Mois-Jour (YYYY-MM-DD).

time

Il s'agit de la date/heure à laquelle le fichier journal a été créé au format heure – minute – seconde (HMS).

Par exemple, un fichier créait à la date Friday, August 24, 2012 2:46:52 PM apparaît en tant que mrdtcleanup_120824_144354.log.

Cliquez sur le nom du fichier journal, par exemple mrdtcleanup_060818_144354.log, pour afficher l'information du fichier journal.. Pour supprimer le fichier de journal, cochez la case à côté du fichier de journal, puis cliquez sur Supprimer. Vous pouvez aussi utiliser les options Tout sélectionner et Tout désélectionner au besoin, ou vous pouvez cliquer sur l'option Actualiser afin d'assurer que les informations les plus récentes s'affichent dans la console.

Activer NLS avec la Console d'Administration affiche les informations suivantes :

• L'emplacement du système (spécifié par les valeurs Langue et Pays) de l'ordinateur où réside le serveur web.
• Le numéro de la page de code du codage CGI utilisé.
• La méthode d'initialisation JSP utilisée et le message d'erreur NLS reçu de Java lorsqu'un outil HTML est lancé.

La trace Transformations OLAP fournit le contenu qui est envoyé du navigateur au client WebFOCUS, comme la requête et le jeu de réponses résultant.

Ceci fournit des informations semblables à celles de la trace Transformation OLAP ; elle est utilisée pour tracer la requête lorsque l'utilisateur demande des valeurs de données depuis le volet OLAP ou le Panneau de Configuration OLAP afin d'effectuer la sélection d'enregistrements.

La trace Procédure vous permet de voir les entrées de requêtes ou la syntaxe qui ont été envoyées vers le serveur de génération de rapport pour traitement. Lorsque cette trace est activée, le paramètre PROCEDURE_LOG situé dans la zone Paramètres de démarrage de la console d'administration est défini automatiquement à ON.

le fichier journal est nommé procedure.log et est placé dans le répertoire drive:/ibi/WebFOCUS81/logs.

Les fichiers de journal peuvent être visualisés en sélectionnant Trace Procédure dans la section diagnostics de la Console d'administration. Cliquez sur le nom du fichier journal pour l'ouvrir. Vous pouvez sélectionner Toutes les entrées pour toutes les sections, qui liste le démarrage des procédures et de la génération des sorties, ou bien Tous les détails pour toutes les sessions, de la procédure.

La trace du Journal de contrôle fournissent des informations sur une ou plusieurs sessions actives. La connexion est activée via l'option contrôleur de cette session dans la section diagnostics. Vous pouvez activer les traces pour toute section au pour un certain nombre de sessions individuelles que vous avez sélectionnées. Le Journal de contrôle fournit des informations de diagnostics sur les niveaux suivants :

• OFF. Aucune information n'est inscrite sur le fichier monitor.log.
• FATAL. Produit un minimum d'analyse.
• ERROR. Journalise les informations seulement si une erreur survient.
• WARN. Ne capture que des messages d'avertissement.
• INFO. Ne capture que des messages d'informations.
• DEBUG. Produit un maximum d'analyses.
• TRACE. Active l'analyse.

Les informations qui sont inscrites sur le fichier de journal sont basées sur le niveau de journal qui est défini. Par exemple, le niveau de journal INFO fournit les informations suivantes dans le fichier :

[YYYY-MM-DD hh:mm:ss,sss] INFO ReqEnd MonID=monitor_ID 
ClientUser=user_ID ReqID=16.29.03.987-1 Node=node ServerUser= 
Completed=completion_time TimeUsed=time_to_run_requestReqInfo=request_information

où :

MonID

est l'unique identifiant pour chaque session.

ClientUser

est l'identifiant utilisateur qui exécute la requête.

ReqID

est identifiant unique de requête pour le serveur de génération de rapport.

Node

est le nom du serveur de rapport qui exécute la requête.

ServerUser

est l'identifiant utilisateur pour le Serveur de génération de rapport.

Completed

est l'heure, en millisecondes, à laquelle la requête a été exécutée.

TimeUSed

est la durée de temps, en millisecondes, pour l'exécution d'une requête.

ReqInfo

Fournit des informations sur la requête, telles que le nom d'application et le nom de la procédure de la requête.

Le niveau de journalisation est habituellement mis sur INFO. DEBUG est le niveau recommandé pour la résolution de problèmes. Pour plus d'informations sur le journal de contrôle, consultez Sessions de contrôle WebFOCUS .

La Trace Sécurité Web effectue le suivi des requêtes de validation affectées par les Paramètres de Validation. Les options de niveau de journal sont :

• OFF. Aucune information n'est inscrite sur le fichier monitor.log.
• FATAL. Produit un minimum d'analyse.
• ERROR. Journalise les informations seulement si une erreur survient.
• WARN. Ne capture que des messages d'avertissement.
• INFO. Ne capture que des messages d'informations.
• DEBUG. Produit un maximum d'analyses.
• TRACE. Active l'analyse.

Les services Web vous permettent de développer des applications dans les environnements .NET ou Java et d'utiliser les fonctonnalités de WebFOCUS à partir de ces environnements.

Chaque fichier de trace constitue un appel de fonction WebFOCUS distinct qui trace les messages SOAP. Ceci est important lorsque les programmeurs veulent déboguer leurs programmes .NET ou Java quand ils font appel aux fonctions de Services Web de WebFOCUS.

la trace WFServelt détermine les requêtes traitées par l'implémentation WFServlet du client WebFOCUS. Le nom du fichier de trace est de la forme :

sequencenumber_WFServlet_WFAPI_date_time.trace

Un nouveau numéro d'ordre est généré chaque fois qu'un fichier de trace est créé. Les éléments date et heure indiquent la date et l'heure de création du fichier.