Como resolver este problema que a cada dia se torna mais complicado?
Com a popularização da internet é cada vez mais comum que programadores autônomos ou mesmo empresas softwarehouses, que desenvolvem sistemas para pequenas empresas, tenham clientes em cidades diferentes (leia-se distantes) daquela em que residem. E muitas vezes, até em estados diferentes. Esse fato ocasiona um grande transtorno para correção de pequenos bugs que possam vir a aparecer no sistema, e, freqüentemente este é um motivo para desentendimentos entre o desenvolvedor e o cliente. O deslocamento até outra cidade pode se tornar inviável e também querer que o cliente apresente uma visão técnica do problema seria injusto. Muitas vezes estes erros aparecem em circunstâncias aleatórias, que não dá pra ficar tentando simular a situação em que ele ocorre, para ver se ele aparece.
Diz o ditado: "A informática veio para solucionar os problemas que não existiam antes dela". Será verdade? Será que com o avanço da tecnologia, da facilidade de acesso e obtenção da informação, da agilidade dos processos e do aumento da produtividade ainda não são suficientes para que se elimine esta imagem negativa que existe da informática? Uma ciencia problemática?
Ao meu ver, a informática chegou pra ficar, mas o que ainda está em descompasso com ela, é a adaptação do ser humano à esta teconologia. Adaptação esta que não requer apenas mudanças de hábitos ou de comportamento, mas também de cultura, principalmente cultura organizacional.
Mas, voltando ao assunto do suporte, muitas vezes pode-se contornar o fator distância usando recursos de administração remota entre computadores. Como isto funciona?
Você instala um software de administração remota, um na máquina do cliente e o outro na sua máquina. Na máquina do cliente, o software deverá estar carregado aguardando uma conexão. Você pode conectar a ele através de uma linha discada diretamente (Disca para a maquina do cliente) ou então através de uma conexão WEB que em muitos casos sai mais barato.
Através da conexão remota, você pode acessar a máquina do cliente e verificar configurações, logs e arquivos, bem como o estado deles. Mas a conexão remota pode não resolver o problema quando não se trata de CONFIGURAÇÕES apenas. A conexão remota não resolve problemas de falhas no sistema e você precisa saber como, onde e porque ele ocorreu.
O problema: como capturar erros do sistema e conseguir saber exatamente onde ocorrem?
A solução: criar um log de todos os erros (não tratados) que ocorrerem no sistema, formatá-los e gerar um arquivo para que o cliente possa enviá-lo. Sendo assim o desenvolvedor poderia enviar um executável (ou dll) corrigido via E-Mail ou via conexão remota.
Mas, como capturar estes erros de forma a sabermos o que está dando errado no programa? Para a captura dos erros utilizaremos o evento OnException do TApplication.
Faremos da seguinte forma:
1. Declare a procedure na seção "private" do seu form principal:
procedure CapturaErro (Sender: TObject; E: Exception);
2. Crie o corpo da procedure na unit do seu form principal:
procedure TForm1.CapturaErro (Sender: TObject; E: Exception);
begin
MessageDlg(e.message,mtError,[mbOK],0);
end;
3. Quando o evento OnException do TApplication for disparado, ele deverá executar a procedure CapturaErro. Para isso insira o código no evento OnCreate do seu form principal.
procedure TForm1.FormCreate(Sender: TObject);
begin
application.onexception := capturaerro;
end;
Com a montagem desta estrutura conseguimos capturar qualquer erro gerado pelo sistema e apresentar ao usuário de uma forma personalizada. Só que isto pode não ser suficiente pois a mensagem somente será exibida quando o erro ocorrer e muitas vezes o usuário não poderá parar o seu serviço a espera de conseguir uma solução junto ao suporte.
Outra forma de voce obter os erros ocorridos no sistema é o uso de blocos protegidos em todas as instruções críticas que seu sistema tenha, tais como operações de I/O, Manipulação de bancos de dados ou comunicação na rede (Lan, Web, WAP, Etc..). Através dos blocos protegidos é possível você obter dados sobre o erro na área do Except.
Vejemos um exemplo disto:
procedure TForm1.FormCreate(Sender: TObject);
begin
Try
except;
On E: Exception do
begin
MessageDlg(e.message,mtError,[mbOK],0);
savelogerror(screen.activeform.name,screen.activecontrol.name,'2345');
end;
end;
end;
Onde savelogerror é uma função que se encarregará de gerar este referido log. Neste caso será gerado apenas um log detalhado (O fonte está no final deste artigo), que voce poderá obter informações mais detalhadas a respeito do erro como veremos mais adiante.
Fig 1: No momento que o erro ocorre, é interessante você tratá-lo com informações detalhadas
de forma que o usuário possa passar-lhe algumas informações por telefone.
COMO GERAR O "LOG" DOS ERROS?
Agora precisamos complementar essas informações e gerar um log para as exceções geradas pelo sistema. Mas onde armazenariamos o log dos erros? Isto poderia ser feito de diversas maneiras:
1. Gravar localmente na máquina do usuário.
2. Gravar em um arquivo compartilhado por todas as máquinas.
3. Gravar no banco de dados do sistema.
Utilizaremos a primeira proposta acima: Gravar localmente na máquina do usuário. Algumas informações precisam ser capturadas quando ocorrer uma exceção, são elas:
1. Data e horário.
2. Form que estava sendo utilizado.
3. Controle que estava ativo (com foco).
4. Unit onde ocorreu o erro
5. Linha onde ocorreu o erro
5. Mensagem do erro.
Estes são os principais campos que precisamos gravar no arquivo texto. É lógico que você poderá acrescentar mais dados ao log de forma a obter o máximo de informações possíveis da ocorrência do mesmo. Lembre-se que quanto mais informações forem coletadas, mais rápido você encontrará as causas do erro e mais rápido ainda você poderá solucioná-lo.
Criando e acessando o arquivo de log.
Para acessar e incluir dados no nosso aquivo de log, usaremos a metodologia mais básica para isto. O AssignFile. Abaixo temos a listagem de uma função que irá salvar dados do erro quando ele ocorrer:
PS: Antes que alguem me escreva peguntando, você pode usar esta função sem ressalva alguma.
function SaveLogError(Const AFormError,AControlError, ALineError, AUnitError, ASimbolError, ADescription, ATypeError, AInsError, ATableError: string): integer;
CloseFile(VLogFile);
var
VMemory: TMemoryStatus;
VLogFile: TextFile;
VLogFileName: string;
vcount : Integer;
begin
VMemory.dwLength := SizeOf(TMemoryStatus);
GlobalMemoryStatus(VMemory);
VLogFileName := format('%serrorsys.log',[ExtractFilePath(Application.ExeName)]);
try
AssignFile(VLogFile,VLogFileName);
if FileExists(VLogFileName) then
begin
Append(VLogFile);
Writeln(VLogFile,'');
Writeln(VLogFile,'--------------------------------------------------------------');
Writeln(VLogFile,'');
end
else
begin
Rewrite(VLogFile);
Writeln(VLogFile,'CABTEC - Soluções em códigos de barras');
Writeln(VLogFile,'Fone 3295-3295 - E-Mail: suporte@cabtec.com.br');
Writeln(VLogFile,'Rua Araguari, nº 358/16º andar - Barro Preto ');
Writeln(VLogFile,'20190-110 - Belo Horizonte - MG');
Writeln(VLogFile,'==============================================================');
Writeln(VLogFile,'');
end;
Writeln(VLogFile,format('DATE/TIME............: %s',[DateTimeToStr(Now)]));
Writeln(VLogFile,format('Version Number.......: %s',[ReturnVersion(4)]));
Writeln(VLogFile,format('Active Form..........: %s',[AFormError]));
Writeln(VLogFile,format('Active Control.......: %s',[AControlError]));
Writeln(VLogFile,format('Unit Error...........: %s',[AUnitError]));
Writeln(VLogFile,format('Call Symbol..........: %s',[ASimbolError]));
Writeln(VLogFile,format('Exception type.......: %s',[ATypeError]));
Writeln(VLogFile,format('Exception Message....: %s',[ADescription]));
Writeln(VLogFile,format('Instruction error....: %s',[AInsError]));
Writeln(VLogFile,format('Line error...........: %s',[ALineError]));
Writeln(VLogFile,format('Table Error..........: %s',[ATableError]));
result := IOResult;
except
result := IOResult;
result := -1;
end;
end;
Conforme foi colocado mais acima, você pode usar esta função dentro de uma área de Except ou então do Application.OnException. Com este código conseguimos gravar no arquivo de log a mensagem de erro com todas as outras informações possíveis onde ocorreu e porque ocorreu o erro.
Veja abaixo, a listagem gerada pelo código acima:
CABTEC - Soluções em códigos de barras
Fone 3295-3295 - E-Mail: suporte@cabtec.com.br
Rua Araguari, nº 358/16º andar - Barro Preto
20190-110 - Belo Horizonte - MG
==============================================================
DATE/TIME............: 17/01/2003 18:17:44
Version Number.......: 1.1.1.76
Active Form..........: Form_Imp
Active Control.......: Button1
Unit Error...........: Unit_Imp;
Call Symbol..........: procedure TForm_Imp.Button1Click(Sender: TObject);
Exception type.......: EConvertError
Exception Message....: 'a' is not a valid integer value
Instruction error....: AdoQuery_Package.Post;
Line error...........: 177
Table Error..........: PACKAGES
---------------------------------------------------------------
DATE/TIME............: 17/01/2003 18:18:17
Version Number.......: 1.1.1.76
Active Form..........: Form_Imp
Active Control.......: Button1
Unit Error...........: Unit_Imp;
Call Symbol..........: procedure TForm_Imp.Button1Click(Sender: TObject);
Exception type.......: EConvertError
Exception Message....: 'a' is not a valid integer value
Instruction error....: AdoQuery_Package.Post;
Line error...........: 177
Table Error..........: PACKAGES
---------------------------------------------------------------
Como podemos ver, este log possui informações mais do que suficientes para que possamos vasculhar o fonte em busca do erro.
ENVIANDO O LOG DE ERROS.
Algumas empresas, que possuem recursos digamos, de sobra, e que possuem internet integrada com a intranet podem fazer uso desta tecnologia para auxiliar os clientes distantes e locais também. Como? Através de algumas ferramentas interessantes para WEB, tais como o CGI. O sistema ao gerar um erro, cria um log que será enviado, através de uma conexão com a WEB e uma chamada a um CGI, para a empresa desenvolvedora. Lá este log pode ser usado para muitas coisas:
- Cadastro de histórico de erros ocorridos no sistema. Sua frequência e ocorrências e circunstâncias em que ele ocorre.
- Disponibilização visual do erro para o departamento de desenvolvimento.
Fig 2: Alguns Logs podem ser disponibilizados na Intranet/Internet pelos Clientes distantes.
Isto permite que se faça um cadastro de erros ocorridos no sistema.
Para o envio e visualização dos erros, podemos fazer valer dois recursos interessantíssimos: 1) Você envia anexo ao E-Mail, o arquivo de log de erros do sistema. 2) Podemos rodar uma rotina que captura a tela do erro, ou do Desktop, e a enviamos anexa em um E-mail também.
Para o envio, a maneira mais simples seria "chamar" um programa de e-mail já instalado na máquina do usuário, passando como parâmetros o endereço de e-mail, assunto e corpo da mensagem.
Faremos isso no botão "enviar" da seguinte maneira:
procedure TForm2.btEnviarClick(Sender: TObject);
var
email, mensagem, LF: string;
begin
// string para salto de linha
LF := '%0D%0A';
// montagem do corpo do e-mail
mensagem := '';
with form1.Table1 do
begin
DisableControls;
First;
While not (eof) do
begin
mensagem := mensagem +
'Data: ' + FieldbyName('DataHora').asString + LF +
'Form: ' + FieldbyName('Form').asString + LF +
'Controle: ' + FieldByName('Controle').asString + LF +
'Mensagem: ' + FieldByName('Mensagem').asString + LF + LF;
Next;
Application.ProcessMessages;
end;
EnableControls;
end;
// abre o programa e passa parâmetros para envio.
email := 'mailto:xxx@yyy.com.br'; // seu endereço de e-mail
email := email + '?subject=' + 'Log de Erros'; // assunto
email := email + '&body=' + mensagem; // corpo do e-mail
ShellExecute(Handle,'open',pchar(email),nil,nil,SW_SHOWNORMAL);
end;
Fig 3: O Internet Explorer possui um registro de erros que envia automaticamente o relatório para eles.
Recurso este que gera muita polêmica a respeito da privacidade
EXECUTANDO UM "PRINT SCREEN"
Uma coisa que pode ser muito útil para estes casos, ou até mesmo pra outros objetivos, é a realização de um "print-scrren" coisa que muitas vezes um usuário não dá conta de realizar e fica complicado, de certa maneira, explicar por telefone. Abaixo temos uma rotina que realiza tal processo e salva o conteúdo em um bitmap:
procedure ScreenError(sFileName: string);
var
hWindow: HWND;
bm: TBitmap;
Left, Top, Width, Height: Word;
R: TRect;
dc: HDC;
begin
hWindow := GetForeGroundWindow;
Bm := TBitmap.Create;
if IsWindow(hWindow) then
begin
GetWindowRect(hWindow, R);
Left := R.Left;
Top := R.Top;
Width := R.Right - R.Left;
Height := R.Bottom - R.Top;
bm.Width := Width;
bm.Height := Height;
dc := GetDc(0);
try
BitBlt(bm.Canvas.Handle,0,0,Width,Height,Dc,Left,Top,SRCCOPY);
bm.SaveToFile(sFileName);
finally
Bm.Free;
ReleaseDc(0, dc);
end;
end;
end;
Esta rotina pode ser executada Dentro do Except após o usuário clicar em um botão de um Showmessage que avise sobre o erro. uma dica interessante, para esta função acima, é que ela tenha como nome a data e hora no formato DDMMYYYYHHMMSS.BMP. Desta forma fica mais prático salvar tantas telas quantas forem necessárias sem que haja o risco de uma sobrescrever a outra. Pode-se, depois disto, atachar esta tela no E-Mail (Vide a rotina de envio do E-Mail) e enviar para o departamento de suporte. Com isto você terá dados e suprimentos mais do que suficientes para solucionar o problema o mais rápido possível.
CONCLUSÃO
A tendência é que este problema se agrave mais ainda já que a WEB veio pra ficar e, graças a evolução da logística, a distância a cada dia se torna um problema menos sério e menos crítico (para a logística). Quem vai pagar o pato disto tudo é o departamento de suporte, que terá que resolver problemas a distância ( deparando com problemas de fuso horário em muitos casos) com o mínimo de recursos possíveis e no menor espaço de tempo possível. Nestas condições, é extemamente fundamental que seu programa esteja apto a cooperar, armazenando o máximo de informações possíveis sobre falhas e procedimentos indevidos por parte do usuário. O log de erros de um sistema é extremamente útil, principalmente no período de implantação, e é também uma ajuda incalculável na hora de prestar esta assistência técnica à distância. Mas é bom também tratar qualquer problema que possa acontecer na geração do log de erros para que o próprio controle de erros não se torne mais um problema.
Visite também:
Automatic bug report sending from your application
