Selecionar a opção de rastro Todos os Clientes, em vez de um rastro em particular, exibe uma lista de todos os arquivos de rastro para todos os rastros ativados.

Por motivos de segurança, os registros de auditoria estão sempre habilitados. Por padrão, os registros de auditoria são mantidos por dez dias no Reporting Server do WebFOCUS. É possível personalizar por quanto tempo os registros são mantidos, salvar eventos de sign-in em registros diferentes e salvar registros em um banco de dados.

Para mais informações sobre como alterar o comportamento padrão do armazenamento ou o local padrão de logs, consulte Configurações dos Diretórios de Aplicativo.

Para visualizar os registros de auditoria, você deve se conectar como um usuário administrativo com o SystemFullControl no ROOT. Os registros são acessados através do Console Administrativo.

1. Selecione Diagnósticos no painel de navegação do Console Administrativo e, em seguida, na pasta Rastros, selecione Todos os Clientes.

   A lista de logs aparece.

2. Role para baixo e selecione audit.log para abrir o arquivo.

   Logs mais antigos aparecem com a data anexada ao nome do arquivo, na forma audit.log_YYYY_MM_DD.log. Por padrão, os logs são mantidos por dez dias. Esta duração é determinada pelo valor da definição IBI_Log_Retain_Days, nas definições de configuração.

O local do log de auditoria é determinado pelo arquivo WEB-INF\classes\log4j.xml. Por padrão, este local é o diretório /ibi/WebFOCUS81/logs e todos os eventos são registrados em um único arquivo. Para salvar eventos de conexão de usuários, incluindo desconexões e sessões expiradas, em um arquivo separado, você deve criar um anexador no log4j.xml e modificar o nome do registrador de com.ibi.uoa.signin para apontar para o novo anexador.

1. Abra o arquivo drive:/ibi/WebFOCUS81/webapps/webfocus/WEB-INF/classes/log4j.xml.
2. Insira um novo anexador, que salva eventos em um arquivo de nome siginout.log, como ilustrado no código de exemplo a seguir.

   <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. Faça uma pesquisa no arquivo por logger name="com.ibi.uoa.signin" e atualize a entrada para:

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

4. Salve o arquivo.

Os eventos de conexão agora estão registrados em signinout.log, que irá aparecer na lista de rastros em Todos os Clientes.

Você pode salvar eventos de segurança em um banco de dados utilizando o Apache Log4j JDBC Appender.

1. Determine quais informações você precisa capturar.

   Por exemplo, talvez seja necessário salvar eventos de conexão e de usuários em um banco de dados, capturando as seguintes informações:

   • Tentativas de conexão e desconexão.
   • Criação, modificação e remoção de usuários.
   • Usuários adicionados ou removidos de grupos.
2. Crie a tabela de banco de dados que será utilizada para armazenar as informações de registros de auditoria. A tabela deve conter colunas apropriadas para as informações capturadas.

   Para o exemplo discutido na primeira etapa, você pode criar uma tabela para capturar os IDs de usuários, logs de data e hora, nomes dos registradores e eventos de auditoria para tentativas de conexão e usuário com o seguinte código.

   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. Atualize o arquivo drive:/ibi/WebFOCUS81/webapps/webfocus/WEB-INF/classes/log4j.xml para associar os nomes do JDBC Appender com os nomes dos registradores especificados em Eventos de segurança e para incluir a referência do anexador (appender-ref), que utiliza o nome do JDBC Appender para os eventos apropriados. Para este exemplo, siga os passos abaixo.
   1. Adicione o JDBC Appender ao arquivo log4j.xml com o seguinte código.

      <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. Determine onde as informações serão registradas e adicione a referência do JDBC Appender aos nomes de registradores.
   • Para registrar as informaçõessomente no banco de dados externo, utilize o seguinte código:

     <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>

   • Para registrar as informações no WebFOCUS e no banco de dados externo, utilize o seguinte código:

     <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. Se o arquivo drive:/ibi/WebFOCUS81/webapps/webfocus/webfocus.war estiver implantado no servidor do aplicativo, atualize e reimplante o arquivo webfocus.war. Se o diretório detalhado drive:/ibi/WebFOCUS81/webapps/webfocus estiver implantado, avance para o próximo passo.
5. Recicle o servidor do aplicativo.

A tabela do banco de dados captura cada evento de segurança em uma linha separada, como ilustrado na imagem a seguir.

A tabela a seguir lista os tipos de eventos de segurança para auditoria do WebFOCUS.

Na tabela a seguir, cada entrada é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de configuração indicado por config.
• ID do monitor do usuário que executou a ação.
• Evento específico sendo registrado. Neste caso, configUpdate, uma atualização da configuração.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Nome do arquivo afetado, normalmente webconfig.xml.
• Nome do usuário que executou a ação.
• novo valor da propriedade alterada.
• Antigo valor da propriedade alterada.

[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

Na tabela a seguir, cada entrada de registro é composto pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de conteúdo indicado por conteúdo.
• ID do monitor do usuário que executou a ação.
• Evento específico, por exemplo, createFolder ou puItem.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Nome do usuário que executou a ação.
• Local do conteúdo afetado pela ação.
• Campos alterados pela ação.

[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

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de grupo indicado por groups.
• ID do monitor do usuário que executou a ação.
• Descrição da ação, por exemplo, createGroup ou putGroup.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Nome e ID numérico único do grupo afetados pela ação.
• Campos alterados pela ação.

Cada usuário e grupo é identificado por um ID numérico único, as como por um nome.

[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

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de propriedade indicado por ownership.
• A ação tomada, como uma mudança de propriedade, indicada por changeOwner ou a publicação de um item, indicada por makePublic.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Se o recurso herda sua privacidade do seu pai.
• O caminho completo do comando IBFS.
• O ID do usuário do novo proprietário do recurso.
• Tipo de proprietário, G para grupos e U para usuários.

[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

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de função indicado por groups.
• ID do monitor do usuário que executou a ação.
• ID do usuário do indivíduo que executou a ação.
• Evento específico, por exemplo, createRole.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Nome da função afetada pela ação.
• Política para a função.

[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;

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de regra indicado por rules.
• ID do monitor do usuário que executou a ação.
• ID do usuário do indivíduo que executou a ação.
• Evento específico, por exemplo, addGroupRule ou addUserRule.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Local do recurso ao qual a regra se aplica.
• Política de acesso da regra.
• Caso a regra se aplique apenas a este local, aos seus secundários ou a este local e seus secundários.

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um compartilhamento de evento indicado por compartilhamentos.
• ID do monitor do usuário que executou a ação.
• ID do usuário do indivíduo que executou a ação.
• Evento específico, por exemplo, clearShares.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Se o proprietário do recurso é um grupo ou um usuário individual, G ou U.
• O ID do proprietário.

[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

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de sign-in indicado por signin.
• ID do monitor do usuário que executou a ação.
• ID do usuário do indivíduo que executou a ação.
• Descrição da ação, por exemplo, conexão.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• Nome e ID do monitor do usuário que se conectou.
• O endereço IP e o agente do usuário ou tipo de navegador, se disponível.

Cada usuário é identificado por um ID numérico único, assim como um nome.

[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)

Na tabela a seguir, cada entrada de registro é composta pelos seguintes elementos:

• Marca temporal no formato AAAA-MM-DD hh:mm:ss,sss.
• Nível de log, como INFO.
• Tipo de evento sendo registrado. Neste caso, um evento de usuário indicado por users.
• ID do monitor do usuário que executou a ação.
• Descrição da ação, por exemplo, createUser ou putUser.
• No caso de sucesso ou falha da ação, com as indicações SUCCESS ou FAILURE.
• ID do usuário e ID numérico único do usuário afetados pela ação.
• Campos alterados pela ação.

Cada usuário e grupo é identificado por um ID numérico único, as como por um nome.

Evento	Entrada de Registro
O usuário é criado	[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
Os detalhes do usuário são modificados	[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
A conta do usuário é desabilitada	[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
A conta do usuário é apagada	[YYYY-MM-DD hh:mm:ss,sss] grupos de INFO monitor_ID user_ID removeUserFromGroup {SUCCESS|FAILURE} usuário:user_ID (user_number) grupo:group_name (group_ID) [YYYY-MM-DD hh:mm:ss,sss] usuários de INFO monitor_ID user_ID status:{ACTIVE|INACTIVE} email:email_address desc:description
A senha foi alterada	[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

Todas as atividades da ferramenta InfoAssit, do Portal de BI e do ReportCaster são rastreadas e anexadas ao arquivo de log de nome event.loh, localizado no diretório drive: /ibi/WebFOCUS81/logs. Os seguintes níveis de rastreamento estão disponíveis:

• DESATIVADO. Nenhuma atividade é incluída no arquivo de registro.
• FATAL. Produz rastreamento mínimo.
• ERRO. Registra informações somente se um erro ocorrer.
• AVISO. Captura apenas mensagens de aviso.
• INFO. Captura apenas mensagens informativas.
• DEPURAR. Produz rastreamento máximo.
• RASTRO. Ativa o rastreamento.

Ele rastreia conexões do cliente com o Reporting Server. O tipo de rastreamento que aparece (NGXXJ ou JLINK) depende da definição IBI_EDACONNECTOR.

Os nomes do arquivo de rastreamento do seguinte formulário:

sequencenumber_tracetype_Connector_date_time.trace

onde:

sequencenumber

Um novo número de sequência é gerado com todos os arquivos de rastreamento que são criados e ajuda a determinar a ordem de processamento ao revisar rastreamentos para mais de um componente.

tracetype

O tipo de rastro é NGXXJ ou JLINK.

date_time

É a data e hora em que o arquivo foi criado.

Observação: Essa definição atualiza a definição CONNECTOR_TRACE na seção de Parâmetros de Inicialização do menu Configuração do Console Administrativo. No entanto, definir TRACE=ON sobrescreve a definição de CONNECTOR_TRACE. Quando TRACE=ON está ativado, a informação do rastreamento do Conector do Cliente é incluída no arquivo de rastreamento do componente (por exemplo, WFServlet) que usa a API (WFAPI) do WebFOCUS para fazer uso do conector do cliente.

O rastreamento de Sistemas de Informação Geográfica (GIS) mostra as etapas realizadas nas solicitações de processo para desenhar mapas ou executar relatórios.

O nível 1 exibe detalhes mínimos. O nível 4 exibe detalhes máximos. É recomendado sempre usar o nível 4.

O rastreamento fornece as seguintes informações:

• Solicitações de consulta ArcXML do ArcIMS
• Solicitações de desenho de mapa do ArcXML
• Respostas do ArcXML
• Código para invocar procedimentos FOCEXEC
• Respostas de relatório
• Respostas XML do usadas para desenhar mapas

As informações sobre os gráficos do lado do servidor (SSG) estão disponíveis ao usar a opção de rastreamento Gráfico, no menu Diagnóstico no Console de Administração. A informação que é exibida depende de SSG_EXTERNAL=YES (baseado em processo) ou SSG_EXTERNAL=NO (baseado em encadeamento).

Quando as definições SSG_ENABLE=YES e SSG_EXTERNAL estão configuradas como YES, é possível acessá-las na seção Gráfico das Configurações do Cliente. O WFServlet inicia um novo processo Java para chamar o mecanismo de gráfico. SSG_EXTERNAL=YES sempre requer tempo de inicialização já que ele analisa todas as propriedades do gráfico quando o Mecanismo de Gráfico é carregado. Se o rastreamento for ativado e houver um execução de uma solicitação de gráfico, três arquivos de rastreamento serão exibidos no seguinte formato:

sequence_number_SSGexternal_date_time.trace

Fornece todas as informações de rastro relacionadas à execução de solicitação de gráfico. Isso inclui número de liberação, informações de análise e chamadas de API enviadas ao mecanismo de gráfico.

sequence_number_SSGexternal_ERROR_date_time.trace

Fornece informações sobre quaisquer erros que ocorrerem durante os processos separados de JVM.

sequence_number_SSGexternal_OUTPUT_date_time.trace

Fornece informações sobre diversos processos JVM.

Quando SSG_ENABLE=YES e SSG_EXTERNAL=NO, um único arquivo de rastreamento é exibido no seguinte formato:

sequence_number_graph_date_time.trace

Semelhantemente a sequence number_SSGexternal_date_time.trace, esse arquivo de rastro fornece todas as informações de rastro relacionadas à execução de solicitação de gráfico.

Os seguintes níveis de rastreamento estão disponíveis:

• OFF. Nenhuma atividade é incluída no arquivo de registro.
• FATAL. Produz rastreamento mínimo.
• ERRO. Registra informações somente se um erro ocorrer.
• AVISO. Captura apenas mensagens de aviso.
• INFO. Captura apenas mensagens informativas.
• DEPURAR. Produz rastreamento máximo.
• RASTRO. Ativa o rastreamento.

Observação: Quando SSG_ENABLE=NO, nenhum arquivo de rastro é criado já que os gráficos applet são executados no navegador em vez de serem criados no servidor de aplicativo.

Isto fornece rastreamento de todos os parâmetros e chamadas HTTP para cada chamada JSP.

É possível visualizar as informações do arquivo de log e rastreamento para o Utilitário de Limpeza de bilhete Adiado MR no Console de Administração do

Arquivo de Log do Utilitário de Limpeza de Bilhete Adiado MR

O Utilitário de Limpeza de Bilhete Adiado MR cria um arquivo de log toda vez que o utilitário é executado. Os arquivos de registro podem ser visualizados ao clicar na opção Utilitário de Limpeza de bilhete Adiado MR no menu Rastreamentos sob a seção Diagnóstico do Console de Administração.

O nome do arquivo do arquivo de log assume o seguinte formato:

mrdtcleanup_date_time.log

onde:

Data

É a data em que o arquivo de log foi criado no formato Ano Mês Dia (AAAA-MM-DD).

hora

É o horário em que o arquivo de log foi criado no formato Hora Minuto Segundo (HMS).

Por exemplo, um arquivo de log criado na sexta-feira, dia 24 de agosto de 2012 às 2:46:52 PM aparece como mrdtcleanup_120824_144354.log.

Clique no nome do arquivo de log, por exemplo, mrdtcleanup_060818_144354.log, para exibir as informações do arquivo de log. Para excluir o arquivo de log, selecione a caixa de seleção próxima ao arquivo de log e clique em Excluir. Também é possível usar as opções Selecionar Tudo e Cancelar Seleção de Todos, conforme necessário, ou clique na opção Atualizar para garantir que informações mínimas apareçam no console.

A ativação dos rastreamentos NLS através do Console de Administração do exibe as seguintes informações:

• Código de Idioma do Sistema (Idioma e Valores Regionais) da máquina do servidor da Web.
• Número da página de código de Codificação CGI sendo usado.
• Método de Inicialização JSP usado e mensagem de erro NLS do Java quando quaisquer das ferramentas HTML são iniciadas.

O rastreamento da Transformação OLAP fornece conteúdo enviado do navegador ao Cliente WebFOCUS, como a consulta e a resposta resultante definida.

O rastreamento dos valores OLAP fornece informações similares às do rastreamento de Transformação OLAP e é utilizado para rastrear a consulta quando o usuário solicita valores de dados do Painel OLAP ou do Painel de Controle OLAP para fazer a seleção de gravação.

O rastro de procedimento permite que você visualize as entradas de log de solicitação ou a sintaxe que foi enviada ao Reporting Server para processo. Quando os rastreamentos do procedimento são ativados, a definição de PROCEDURE_LOG na seção de Parâmetros de Inicialização do Console de Administração do é automaticamente definida para ativada.

O arquivo de log recebe o nome procedure.log e está localizado no diretório drive:/ibi/WebFOCUS81/logs.

Os arquivos de log podem ser visualizados através da seleção de Rastro de Procedimento, localizado na seção Diagnóstico do Consola Administrativo. Clique no nome do arquivo de log para abrir o arquivo. Você pode selecionar Todas as Entradas para todas as sessões, que lista o início do procedimento e da saída, ou Todos os Detalhes para todas as sessões, que exibe a sintaxe do procedimento.

O rastro de Monitorar Logs fornece informações sobre uma ou mais sessões consecutivas. O armazenamento de logs é ativado através da opção Monitorar Sessão da seção Diagnóstico. É possível habilitar rastros para todas as sessões ou para sessões individuais selecionadas. O Monitorar Logs fornece os seguintes níveis de informações de diagnóstico:

• DESATIVADO. Nenhuma informação é gravada no arquivo monitor.log.
• FATAL. Produz rastreamento mínimo.
• ERRO. Registra informações somente se um erro ocorrer.
• AVISO. Captura apenas mensagens de aviso.
• INFO. Captura apenas mensagens informativas.
• DEPURAR. Produz rastreamento máximo.
• RASTRO. Ativa o rastreamento.

A informação que é gravada no arquivo de log é baseada no nível de log que é definido. Por exemplo, o nível de log INFO fornece as seguintes informações no log:

[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

onde:

MonID

É um identificador exclusivo para cada sessão.

ClientUser

É o ID de usuário do que está executando a solicitação.

ReqID

É o identificador exclusivo de solicitação para o Reporting Server.

Nó

É o nome do Servidor do Relatório que está executando a solicitação.

ServerUser

É o ID de usuário do Servidor do Relatório.

Concluído

É o horário, em milissegundos, no qual a solicitação foi concluída.

TimeUsed

É a duração do horário, em milissegundos, que a solicitação demorou para ser executada.

ReqInfo

Fornece informações sobre a solicitação, como o nome do aplicativo e o nome do procedimento do relatório.

O nível de log está normalmente configurado para INFO. DEPURAR é o nível recomendado para a resolução de problemas. Para obter mais informações sobre o log de monitoramento, consulte Como Monitorar Sessões do WebFOCUS .

O Rastro de Segurança da Web rastreia solicitações de validação afetadas pelas Definições de Validação. As opções de nível de log são:

• DESATIVADO. Nenhuma informação é gravada no arquivo monitor.log.
• FATAL. Produz rastreamento mínimo.
• ERRO. Registra informações somente se um erro ocorrer.
• AVISO. Captura apenas mensagens de aviso.
• INFO. Captura apenas mensagens informativas.
• DEPURAR. Produz rastreamento máximo.
• RASTRO. Ativa o rastreamento.

Os Serviços da Web permitem que você desenvolva aplicativos nos ambientes .NET ou Java e execute a funcionalidade do WebFOCUS a partir desses ambientes.

Cada arquivo de rastreamento é uma chamada de função separada dos Serviços da Web que rastreia as mensagens SOAP. Isso é importante quando os programadores desejam depurar seus programas .NET ou Java ao invocar as funções de Serviço da Web do WebFOCUS .

O rastro do WFServlet controla as solicitações processadas pela implementação WFServlet do Cliente WebFOCUS O nome do arquivo de rastreamento assume o seguinte formato:

sequencenumber_WFServlet_WFAPI_date_time.trace

Um novo número de sequência é gerado com todos os arquivos de rastreamento que são criados. As partes relacionadas a hora e data especificam a data e o horário em que o arquivo foi criado.