Aniversário Fabiane

Bom dia,

Informo que nossa colega Fabiane esta de aniversário hoje!

Feliz Aniversário Fabi! 
Tudo de Bom,
Muitas e Muitas Felicidades ...

Abraços

Revisão SLAs

Durante a visita do CEFET- RJ, Unirio e UFPR, foi solicitada a revisão de nossos SLAs. Abaixo segue o texto reescrito na tentativa de contemplar as solicitações apresentadas

Aguardamos considerações para que possamos apresentar essa versão aos clientes e, posteriormente, utilizá-la em nossos contratos.

Regras de Atendimento aos sistemas mantidos pela AVMB - SLA

Horários de atendimento: Define-se como o período de atendimento o tempo compreendido entre 9h e 18h (horário de Brasília), de segunda-feira a sexta-feira, exceto feriados nacionais. Nos feriados estaduais e municipais para Santa Maria – RS, haverá plantão dos nossos setores de suporte e atendimento. Denomina-se Horas Úteis as horas compreendidas nos horários de atendimento.

Número de atendimento. O número de atendimento será ilimitado, válido para os módulos e funcionalidades já implantados. Caso a funcionalidade ou o módulo necessite de implantação o atendimento se dará através de workshops.

Forma do atendimento.  Os atendimentos serão realizados através do registro dos chamados no SAC AVMB e chat AVMB On-line. Em casos excepcionais, os chamados poderão ser realizados através de telefone.

Prazos de atendimento. Os atendimentos terão os seguintes níveis de severidade:

Nível de severidade 0: É o nível de maior relevância. Sistema totalmente inoperante ou funcionalidade que implica em altíssima prioridade e disponibilidade em períodos considerados críticos.

Prazo para resposta: até 2 (duas) horas úteis.

Prazo para solução: atendimento remoto continuado até a resolução do problema.

Nível de severidade 1: Sistema, módulo ou funcionalidade parcialmente inoperante. Problemas identificados pelo cliente que estejam impedindo a execução de uma funcionalidade especifica referente a módulos já implantados e em uso pela instituição.

Prazo para resposta: até 8 (oito) horas úteis.

Prazo para solução: até 24 (vinte e quatro) horas úteis.

Nível de severidade 2:  Problema não impactante. Qualquer problema identificado pelo cliente em uma funcionalidade ou módulo do sistema já em uso, mas que não impede a sua execução.

Prazo para resposta: até 16 (dezesseis) horas úteis.

Prazo para solução: até 40 (quarenta) horas úteis.

Nível de severidade 3: Solicitação de adequação de uma funcionalidade. Qualquer solicitação do cliente referente a adequação de uma funcionalidade a suas necessidades. Este nível somente existirá para os contratos que tenham horas de desenvolvimento.

Prazo para resposta: até 40 (quarenta) horas úteis.

Prazo para solução: conforme cronograma apresentado ao cliente após análise da equipe técnica, o cronograma deve ter o aceite do cliente.

Nível de severidade 4: Questões diversas de trato gerencial.

Qualquer demanda de trato mais gerencial como, por exemplo, solicitações de treinamentos, solicitações de implantação de módulos, questões gerenciais que não envolvem diretamente operações nas aplicações do sistema.

Prazo para resposta: até 40 (quarenta) horas úteis.

Prazo para solução: conforme cronograma apresentado ao cliente após análise da equipe técnica, o cronograma deve ter o aceite do cliente.

Nível de Severidade 5: Esclarecimento de dúvidas pontuais de operação dos aplicativos de módulos já implantados e em uso pela instituição e, que não demandem análises complexas de dados e que não dependam de acesso ao ambiente do cliente.

Prazo de Resposta: Oito horas úteis

Prazo para solução: Em conjunto com o prazo de resposta

Nível de Severidade Excepcional: Pré-agendado entre as partes. Rotinas e procedimentos que impliquem em necessidade de altíssima disponibilidade e performance do sistema, deverão ser previamente agendadas junto à AVMB que, por sua vez, procederá a implantação do atendimento chamado de ´plantão 24 horas´, tornando disponível um profissional, de localização imediata, de forma ininterrupta, durante a duração do processo agendado, com o objetivo de sanar toda e qualquer intercorrência, no que tange a instabilidade, parada do processamento ou outro problema sistêmico. 

Enquadram-se neste nível o atendimento a resolução de problemas de análise e geração de dados para atendimentos as exigências de órgãos de fiscalização federais, estaduais ou municipais e tais demandas, deverão ser reportadas a AVMB com uma antecedência de cinco dias úteis, antes da data final de entrega dos dados aos órgãos solicitantes. 

Havendo necessidade de envio de mais informações por parte da Instituição, os prazos começarão a ser contados quando do recebimento das informações.

Inatividade de Usuários no SIM/SIE

Segue detalhes referente ao controle de inatividade feito pelo GCA no SIM/SIE a partir de hoje:

• O controle de inatividade é feito por cada instância do GCA e se aplica em cada estação cliente que acessa o sistema. 
• Chamadas efetuadas ao servidor de aplicações continuarão seu processamento mesmo que a sessão da aplicação chamadora seja finalizada (nesse caso não haverá retorno da operação).
• O tempo de sessão que controlará a inatividade do usuário será independente de aplicação aberta e/ou ativa, sendo controlado exclusivamente pelo GCA. 

• A inatividade será detectada pela ausência de qualquer interação em periféricos da máquina de acordo com cada sessão ativa do windows (inclusive bloqueadas).
• Acessos feitos via terminal service terão seu controle de inatividade feito dentro de cada sessão TS (sessão do windows).
• Ao atingir o tempo máximo de inatividade o sistema fecha qualquer aplicação/relatório aberto pela(s) instância(s) corrente(s) do GCA. Aplicações que estejam com registros em modo de inserção/edição (não salvos em banco) são fechadas imediatamente pelo sistema sem qualquer confirmação ou ação do usuário.

• É possível configurar determinadas aplicações para que não sejam afetadas pelo controle de inatividade quando abertas, evitando que processamentos longos com múltiplas chamadas sejam finalizados antes do seu término.
• Aplicações/Relatórios não são mais mantidos em execução quando a instância do GCA em que foram abertos é finalizada. O usuário é avisado e precisa confirmar a saída.

Configurações disponíveis nos Parâmetros do SGCA (GCAParSGCA.exe):

• Opção para habilitar/desabilitar o controle de inatividade em todas as aplicações do sistema.
• Definição do tempo de sessão.
• Opção para habilitar/desabilitar a exibição do tempo restante até o encerramento da sessão.
• Opção para não ativar o controle de inatividade quando o usuário logado for Administrador do Sistema.

Configurações disponíveis no Cadastro de Aplicações (GCAMAplicacoes.exe):

• Opção para pausar o controle de inatividade quando o mesmo estiver em execução. Configuração necessária para impedir que processamentos longos e efetuados com mais de uma chamada ao servidor de aplicações sejam interrompidos, mesmo quando não houver interação do usuário com a máquina.

Aniversário Gigio

Bom dia,

Informo que nosso colega Gigio estava de aniversário ontem dia 13/07!

Feliz Aniversário Gigio! 
Tudo de Bom,
Muitas Felicidades ...

Abraços

Monitoramento de Conexões/Eventos do Contexto

Foi disponibilizado em nossos ambientes uma aplicação para monitoramento de transações e chamadas ao Contexto, visando melhorar a detecção de bugs, performance de SQL, operações longas e situações similares.

A aplicação monitora qualquer chamada que passe pelo Contexto do sistema como execução de instruções SQL (DML/DDL), operações que envolvam transações ou mesmo as que requisitam algum dado contido/mantido pelo Contexto. O monitoramento é feito por servidor de aplicação e independente do número de bancos que estejam sendo acessados simultaneamente.

Funcionamento

Abrir a aplicação “AppSI/Ferramentas_SI/ContextLogAnalizer.exe” diretamente no servidor de aplicações com usuário Administrador da máquina.

• Ativar/Desativar Contexto: Permite preparar o Contexto para rastreamento de qualquer chamada.
• Ativar/Desativar Log: Quando ativo monitora todas as chamadas feitas e as armazena em memória no pacote “pkContextLogAnalizer” até que seja feito o flush das operações.

ATENÇÃO! O ativamento do Contexto e do Log só deverão ser utilizados para análise de problemas, otimização ou situação similar. Essa funcionalidade deve ficar INATIVA no ambiente de produção quando os dados coletados não estiverem sendo monitorados.

Ao ativar o Log todas as operações passadas pelo Contexto do servidor são armazenadas (independe do banco de dados que esteja em uso por cada conexão). As conexões que já estejam em uso poderão ser vistas na guia de Conexões. Essa guia é atualizada automaticamente enquanto o Log está ativo.

Clicando em cada conexão serão mostrados os detalhes da mesma e um resumo do que está sendo executado (enquanto ativa). Caso a conexão já esteja disponível (ociosa) será exibido o resumo da última execução. Para detalhar cada chamada deve-se utilizar a guia “Pilha de Chamadas”.­­

Na guia Pilha de Chamadas ficam as informações detalhadas de cada operação. Essas informações ficam em memória no servidor de aplicações e são renovadas/sobrescritas a cada 10min. Clicando em “Atualizar” é possível visualizar o que está em execução atualmente ou o que já foi executado nos últimos 10min. As informações contidas nessa guia não são atualizadas automaticamente permitindo que o usuário trabalhe com os dados e faça a atualização apenas quando achar necessário.

Exemplos de Informações que podem ser coletadas pela aplicação

• Operações executadas por cada chamada à camada servidora das aplicações
• Tempo gasto em cada conexão, chamada ou metaquery executada
• Conexões ativas e em transação
• Objetos ativos/em execução no COM+
• SQL executados com valores de cada parâmetro
• Exceções geradas durante as chamadas
• Nº de Transações iniciadas/comitadas
• Dados de cada conexão/chamada como usuário/IP e aplicação de origem
• Pilha ordenada de execuções em cada chamada

Dados que são coletados durante o monitoramento

Por conexão ativada: Usuário do Banco, Nº da Conexão, Usuário, Aplicação, IP do Usuário, Alias do Banco, Hora Inicial, Hora Final, Tempo de uso, Em Transação

Por evento executado: Nº da Conexão, Alias do Banco, Método, Nome da Query, Aplicação Servidora, Hora Inicial, Hora Final, Tempo de Execução, ID da Aplicação, ID do Usuário, SQL executado, Parâmetros do SQL, Nº da Chamada, Classe de Exceção, Mensagem de Exceção

Por pacote ativado: Aplicativo, PID, Programa, Objetos, Ativados, Em Chamada, Tempo de Chamada

Outras informações e cruzamentos de dados poderão ser adicionados futuramente conforme a necessidade. Qualquer dúvida favor mandar email.

Aniversário Bira

Bom dia,

Informo que hoje nosso colega Ubirajara esta de aniversário!

Feliz Aniversário Bira! 
Tudo de Bom,
Muitas Felicidades ...

Abraços

Relatórios SIM/SIE com Autenticação e QRCode (Dev)

Segue detalhes técnicos para implementação de relatórios na arquitetura SIM/SIE utilizando autenticação e QRCode:

1. Adicionar os componentes TQRLabelAutenticacao e TQRImageQRCode ao relatório (caso não esteja disponível na aba de componentes efetuar a atualização da LibCDESP):

2. Salvar e compilar. Exemplo de relatório gerado: 

3. Ao utilizar qualquer App de leitura de QRCode será feito o redirecionamento para o site de autenticação (configurado por instituição), já com a chave do relatório preenchida. Exemplo redirecionando para um de nossos portais: 

Observações:

• O QRCode é gerado independente do formato final (PDF ou QuickReport).
• A utilização de QRCode só pode ser feita se o componente de autenticação também estiver presente.
• Se a autenticação é desabilitada via cadastro de aplicações o QRCode e o código de autenticação não são mostrados (é possível prever o componente dentro de cada DLL e habilitar sua exibição individualmente, não obrigando que a Instituição utilize a autenticação). 
• O componente pode ser utilizado em qualquer local do relatório, em diferentes tamanhos. Para manter um padrão em todos os relatório do sistema foi definido que a utilização do código de autenticação e QRCode deverá seguir o padrão como mostrado na imagem acima.
• Para um bom reconhecimento do código pelas câmeras dos dispositivos recomenda-se que o componente  TQRImageQRCode tenha um tamanho mínimo de 60x60 pixels.
• A geração do QRCode é feita através do executável QRCode.exe contido na pasta "AppSi/Bibliotecas" (já disponível nos clientes e em nossos ambientes). Para quem desenvolve com servidor de aplicações local deverá copiar este binário para sua máquina (para fins de teste de desenvolvimento).