Criando um serviço e importando XML

com .NET
Criando um serviço e importando XML com .NET

Autor: Dennes Torres – dennestorres@bufaloinfo.com.br

Extraído do site: http://www.bufaloinfo.com.br

O Visual Studio .NET possui muitos novos recursos, possibilitando que realizemos tarefas antes
muito difíceis de serem realizadas com VB 6.0.

Vamos então fazer uma aplicação de exemplo para demonstrar alguns desses recursos. Em nossa
aplicação vamos fiscalizar um determinado diretório (c:\dados, por exemplo), identificando a
criação de novos arquivos neste diretório. Ao ser criado um novo arquivo, iremos ler seu conteúdo
(que estará em formato XML) para um DataSet e importar seu conteúdo para uma tabela do banco.

A tabela terá a seguinte estrutura:

Nome varchar(40)
cargo varchar(30)

Apenas para o exemplo não importa muito quando campos utilizaremos, isso não alterará a forma
de construir o código.

Para começar precisaremos criar uma nova aplicação. Mas não criaremos uma WindowsApplication
comum, para garantir que a aplicação possa estar sempre rodando e que possa ser iniciada de
imediato quando o sistema iniciar deveremos criar a aplicação como Windows Service, ou seja, um
serviço do Windows.
Vamos chamar o serviço de ImportacaoDados. Além de criar o projeto com esse nome devemos
alterar o ServiceName da classe Service1 que é criada para nós. Podemos Também alterar o nome
da classe, name, para ImportacaoDados, por exemplo. Devemos usar a janela de propriedades, não
o código, pois este nome aparece em vários locais do código de inicialização do serviço.

As propriedades da classe ImportacaoDados (que herda as características da classe ServiceBase)

possui várias propriedades que determinam os eventos do sistema que o serviço pode tratar. A
configuração default já é adequada, com a propriedade CanStop definida como true, indicando que
o serviço trata o evento de stop, e a propriedade autolog como true, indicando que o serviço irá
automaticamente logar os eventos de stop, start que ocorrerem.

Todo serviço precisa de um instalador, que é criado dentro do mesmo Assembly do serviço. Mas o
VB.NET pode inserir o instalador no projeto automaticamente, basta que na janela de propriedades,
com a classe ImportacaoDados selecionada, cliquemos na instrução Add Instaler, na parte inferior
da janela de propriedades.

Fazendo isso será criado um novo arquivo .VB chamado ProjectInstaller.VB . Neste arquivo são
criados os componentes ServiceInstaller1 e ServiceProcessInstaller1. Precisamos configurar esses
dois componentes :

No ServiceInstaller1 vamos alterar o starType para Automatic. Isso determina que o serviço deverá
ser configurado para se iniciar automaticamente sempre que o Windows se iniciar. É interessante
observar que poderíamos também configurar as dependencias do serviço, determinando que para se
iniciar o serviço precisará que outros já estejam iniciados. No nosso exemplo, porém, não
precisamos configurar isso.
No ServiceProcessInstaller1 deveremos alterar a propriedade Account para LocalSystem,
determinando assim que no momento de instalação o serviço deve ser configurado para rodar na
LocalSystemAccount, conta local do sistema.

Voltando ao Service1.vb, vamos inserir um componente chamado FileSystemWatcher. Este objeto

nos permite fazer uma tarefa que antes era extremamente complexa : Vigiar o sistema de arquivos
para identificar alterações em arquivos, deleção, criação de novos arquivos, ou outros eventos no
sistema.

Vamos alterar o nome do FileSystemWatcher, chamando-o apenas de FSW. Existem 3 propriedades

que determinam quais arquivos serão vigiados : Filter, determina o filtro de arquivos, configurado
como "*.*" por default. Path determina o caminho da pasta que será vigiada e NotifyFilter
determina os eventos que serão checados.

Em nosso exemplo verificaremos apenas a criação de arquivos, então podemos alterar notifyFilter
para Filename. Iremos também configurar o Path como "C:\dados" e manter o filter da forma que
está. Um recurso interessante que devemos utilizar são as Dynamic Properties. Filter e Path são
ótimos candidatos a serem configurados como Dynamic Properties. A configuração de Dynamic
Properties nos permite vincular uma propriedade de um determinado objeto a uma configuração no
manifesto da aplicação. Desta forma podemos manter os valores de filter e path gravados em um
arquivo externo, o que fará com que estas propriedades sejam facilmente alteradas mesmo com a
aplicação já compilada.

Basta para isso selecionarmos na janela de propriedades o item Dynamic Properties e darmos um
nome que será utilizado para a gravação das propriedades Filter e Path. Ao fazermos isso o janela de
propriedades passa a sinalizar o fato das propriedades estarem sendo lidas de um arquivo de
configuração, enquanto no solution explorer podemos observar que é adicionado o arquivo de
configuração, inicialmente com o nome de APP.config.

A propriedade EnableRaisingEvents do FileSystemWatcher funciona como um on/off,

determinando se ele estará ou não vigiando o sistema de arquivos e disparando eventos para nos
alertar do ocorrido.

Como estamos desenvolvendo um serviço, vamos inicialmente configurar a EnableRaisingEvents

como False e vamos habilita-la/desabilita-la no start/stop do serviço. Para isso basta entrarmos no
código do service1.vb e começarmos o desenvolvimento, veja :

Protected Overrides Sub OnStart(ByVal args() As String)

' Add code here to start your service. This method should set things
' in motion so your service can do its work.
FSW.EnableRaisingEvents = True
End Sub
Protected Overrides Sub OnStop()
' Add code here to perform any tear-down necessary to stop your service.
FSW.EnableRaisingEvents = False
End Sub

No Service1.vb, deveremos criar um objeto OledbConnection e um objeto OledbCommand que

servirão para fazermos a conexão com o banco de dados e atualizarmos os dados no banco. Vamos
chama-los de CN e CMD, para ficar mais fácil trabalhar com eles. Precisaremos definir a string de
conexão no objeto CN. A string de conexão é outra excelente candidata a se transformar em
Dynamic Properties, não apenas neste exemplo mas eu diria que em toda aplicação, desta forma
permitindo que a localização do banco de dados possa ser facilmente alterada, apenas corrigindo a
string dentro do manifesto da aplicação.

Já no objeto CMD vamos liga-lo com o objeto CN e definir o commandText. Podemos montar o
CommandText dinâmicamente através do query Builder, basta termos o cuidado de alterar o tipo da
query para insert into e utilizarmos ? nos valores que deverão ser preenchidos por parâmetros.

O objeto OLEDBCOMMAND sempre pergunta, após a montagem da query, se podem redefinir a

coleção de parâmetros do Command. Devemos permitir e ele irá criar a definição dos parâmetros
nome e cargo para nós. Podemos ver o que foi feito através da coleção parameters, mas não iremos
alterar nada.
Chegou a hora então de programarmos o evento Created do FSW, que é disparado sempre que um
novo arquivo é criado no diretório que está sendo vigiado. Nosso objetivo é criar um DataSet e
carregar para dentro do DataSet os dados do novo arquivo. Veja como fica o inicio deste código :

Private Sub FSW_Created(ByVal sender As Object, ByVal e As

System.IO.FileSystemEventArgs) Handles FSW.Created

Dim ds As New DataSet()

ds.ReadXml(e.FullPath)

End Sub

Assim, com apenas duas linhas de código carregamos para um DataSet o conteúdo do novo arquivo.
Agora precisamos atualizar o banco. Isso exigiria normalmente que fizessemos um algorítimo como
loop para jogarmos os dados no banco executando o Command. Bem, não no .NET. Podemos
apenas criar um DataAdapter, liga-lo ao Command e utiliza-lo para atualizar o banco
automaticamente. Veja como fica o código:

Private Sub FSW_Created(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs)

Handles FSW.Created

Dim ds As New DataSet()

Dim da As OleDb.OleDbDataAdapter

ds.ReadXml(e.FullPath)

da = New OleDb.OleDbDataAdapter()
da.InsertCommand = cmd

da.Update(ds, "funcionario")

ds.Dispose()
ds = Nothing
da.Dispose()
da = Nothing
End Sub

Observem que este data adapter nem ao menos possui um selectCommand. Isso não é necessário já
que estamos apenas inserindo registros no banco.

Pronto. Está feito. Isso mesmo. Com Poquissimas linhas de código, praticamente um
desenvolvimento todo visual, conseguimos montar uma aplicação que será instalada como serviço
do Windows, monitorar os arquivos criados em um diretório, ler o conteúdo destes arquivos e jogar
os dados para uma tabela de banco.

O próximo passo é instalar esse serviço. Para isso o framework nos traz um utilitário chamado
installutil. Executando no prompt InstallUtil este utilitário dispara o instalador que criamos em
nosso assembly e o instalador por sua vez se encarrega de fazer as configurações do serviço na
máquina.

Você agora só precisa agora ter cuidado com a montagem do arquivo XML, pois o dataSet é um
pouco temperamental na leitura deste arquivo. Veja um exemplo de como ele fica :

<cadfunc>
<funcionario>
<nome>Joao</nome>
<cargo>faxineiro</cargo>
</funcionario>
</cadfunc>

Observe a forma como os dados estão montados : Nome e cargo estão colados a suas respectivas
tags. Veja um exemplo do que sereia uma montagem ERRADA :

<cadfunc>
<funcionario>
<nome>
Joao
</nome>
<cargo>
faxineiro
</cargo>
</funcionario>
</cadfunc>
Você pode pensar a principio que não existe nada errado neste XML e, realmente, ele é um XML
válido. Mas se olhar mais atentamente poderá observar que dentro do campo nome e dentro do
campo cargo temos 2 CR (Enter, código ASC=13). Isso será lido como parte dos dados e inserido
como informação nestes campos, dentro do banco de dados. Desta forma devemos tomar cuidado
com o que inserimos nas tags de dados do XML.

Tendo esse cuidado, você poderá montar vários arquivos e joga-los, um por um, no diretório que
está sendo vigiado por sua aplicação. Poderá observar como a aplicação lê o conteúdo do XML e
executa o insert na base de dados.