SAI.TXT Concorrência

[Antonio Carlos L]

Por favor tenho a seguinte situação :

Cinco estações acessam um pasta em rede onde o ACBrMonitor efetua a monitoração.

Por exemplo X:\MONITOR

A primeira estação a faturar gera os arquivos TMPMAQ4.TXT nesta pasta comum e NFE000001.TXT em X:\MONITOR\NOTASTXT

Feito isso, passa a monitorar através de um laço While com um Sleep de 500 a INEXISTÊNCIA de ENT.TXT 
que será excluído pelo ACbrMonitor.

Não encontrando ENT.TXT renomeia TMPMAQ4.TX para ENT.TXT e através de um laço While com um Sleep de 1000 passa a aguardar o arquivo SAI.TXT 

Ao encontrar SAI.TXT ele é copiado em memória e excuído pela estação onde roda a aplicação.

Mas esta ocorrendo algo estranho.

Dependendo da nota ( acho que quantidade de itens ou internet sei lá ) duas estações que faturem quase ao mesmo tempo passam a aguardar o mesmo SAI.TXT já que o ACBrMonitor exclui o arquivi ENT.TXT ao realizar a leitura e não ao termino do processamento.

Muita gente usa o ACBrMonitor e não vi esse relato no forum , devo estar fazendo algo errado.

Agradeço as considerações.

Obrigado.

[Antonio Carlos L]

Em tempo : Para contornar isso recorri a uma gambiara, crio na mesma pasta um aquivo LOCK.LCK para impedir que outra estação escute a pasta enquanto o arquivo existir.

[José M. S. Junior]

Para implementar esse tipo de integração, é importante que tenha um controle baseado no arquivo de Retorno (SAI.TXT)... Para cada método processado pelo ACBrMonitor precisa sempre do arquivo de resposta para permitir que o ACBrMonitor leia um novo arquivo. Lembrando que para este tempo de retorno deve levar em consideração o TimeOut configurado para alguns comandos específicos, como por exemplo o de Envio de NFe...

[Antonio Carlos L]

Obrigado @José M. S. Junior pela sua resposta.

Esse tempo é que não consigo precisar, quando acontece requisição quase simultânea e existe latência.

Se eu colocar um Sleep maior isso já melhora muito

Em homologação não dava erro, mas quando coloquei em produção ...

ENT.TXT     SAI.TXT
  F           F
  V           F
  F           V

Controlando apenas pelos aquivos.

Como ENT.TXT é excluído ao ser lido, havendo demora no processamento da nota haverá momento em que a situação de ambos os arquivos não existirem vai acontecer.

Claro que posso travar essa concorrência com um FLAG no banco ou no disco e havendo esse FLAG as demais estações ficam obrigadas a aguardar.

Mas queria saber se existe solução mais elegante apenas com o ENT e SAI

Obrigado

[José M. S. Junior]

Bom dia

Quanto ao tempo de espera implementado na sua aplicação pode ser dinâmico... Se for um método que exija timeout como por exemplo envio de NFe, passe o mesmo timeout configurado no ACBrMonitor para o processo, assim não terá problemas de tempo de espera na leitura do retorno por parte da sua aplicação... Quando ao semáforo que precisa implementar para aguardar o comando em processo, independente da forma como controle isso, precisa sempre se basear na leitura do retorno para permitir o envio de um novo método, poderia ser uma classe que gerencie esse fila de métodos e o diretório de respostas...

[Kiko Fernandes]

Bom dia!
Se você enviar ENT.TXT a resposta será no arquivo SAI.txt
Se você enviar ENT1.txt a resposta será no arquivo SAI1.txt
Se você enviar ENT2.txt a resposta será no arquivo SAI2.txt
Deste modo  você pode configurar a sua estação e cada uma ter a sua resposta em arquivos independentes.