Riopro Blog

A encomenda já havia sido feita a aproximadamente 2 anos, quando fechamos um contrato que incluía a integração do nosso sistema financeiro (FinanceRP) com um módulo para autenticar a entrada de sócios nas dependências de nosso cliente.

Desde o início, sabíamos que essa integração passaria necessariamente por reescrever o protocolo de qualquer que fosse a catraca em Java. Não era pessimismo, o que acontece é que em geral os fabricantes/distribuidores de catracas e relógios de ponto fornecem apenas um ocx ou uma dll, que só funcionam no Janelas, e por isso, nem se o componente fosse escrito em C++ daria para fazer um acesso por JNI (ou talvez até desse, mas acredito que o trabalho fosse ser ainda maior e a solução final não tão elegante), já que nossos servidores eram/são 100% Linux (rodando a distribuição Ubuntu). Além disso, objetivávamos controlar a catraca em modo real-time, e não em modo batch, e portanto o acesso deveria ter o menor número de camadas possível para garantir performance e maior controle das operações.
Esquecemos disso por quase um ano e meio, visto que o fornecedor das catracas não havia sido definido e portanto não teríamos como trabalhar a interface com o nosso sistema. Apesar de nosso sistema ser fundamentalmente Web, o que fizemos nesse meio tempo foi pré-preparamos nossos objetos que fariam internamente o processamento das validações e definimos uma idéia de interface que esperávamos ter junto à catraca.

Chegado o momento da escolha do fornecedor, fomos buscar os mais eficientes, cujas catracas funcionassem sobre protocolo TCP/IP (por uma questão de tecnologia mais apropriada para o futuro), os que tinham os melhores produtos, mas principalmente aqueles que queriam colaborar cedendo gentilmente o modelo de comunicação (não necessariamente os fontes, é óbvio).

Ao final, havia sobrado unicamente a Dimep, que é um tradicional fornecedor de relógios de ponto e catracas de acesso. Esse artigo não se propõe a ser um anúncio grátis da Dimep, até porque eles tem seus problemas e certamente existem outros bons fornecedores também. Mas não devemos deixar de ressaltar a boa vontade e suporte para compreensão do modelo do protocolo deles.

Isso nos leva a um item importante e que pode frustrar um pouco a comunidade de software livre: devido ao acordo de confidencialidade assinado por nosso cliente, com nossa interveniência, com a Dimep, nada que não for estritamente presente no manual do usuário normal da catraca será comentado. Fonte, então, nem pensar (se bem que vocês sempre podem comprar de nós a nossa classe compilada :)).

Para não deixar todo mundo com água na boca, esse artigo se propõe a duas coisas:

1. Falar que sim, é possível fazer a comunicação em Java (como qualquer desenvolvedor que conhece Java deveria supor) e que o funcionamento no Linux funciona perfeitamente (afinal, podemos dizer que o Linux nasceu para a comunicação em rede e vice-versa);
2. Dar algumas dicas que podem não salvar a vida de todos, mas certamente cortam o caminho para muitos que tentarem desenvolver sua própria API para operar com as catracas da Dimep (e só da Dimep, que foi a única que implementamos até o fim).

A solução que implementamos utilizou o modelo Micropoint-IP, mas com certeza seria possível implementações similares nas catracas que utilizam de acesso pela porta serial e idênticas nos relógios de ponto, visto que o equipamento de autenticação e a interface é a mesma. Aumentei sua esperança?

Outros detalhes interessantes são:

• A implementação da nossa API usou basicamente o pacote java.nio, portanto vale a pena estudá-lo com cuidado;
• A catraca aceita códigos de barra nos padrões intercalado 2 de 5 e barcode 39;
• Ela também aceita que o último dígito do código de barras seja um DV11 (padrão para quem gera boletos) e a validação é feita diretamente na catraca e não enviada pela catraca para o computador. Se geramos um código 000019 e 9 é o DV11 da carteira, então a catraca enviará somente 00001);
• Um item importante e que só depois de olhar no manual dos usuários soubemos com certeza: as catracas da Dimep só aceitam códigos com até 15 números, podendo ter um 16°, contanto que o 16° seja um DV11 do código (até porque todo código intercalado 2 de 5 deve necessariamente possuir um par de números);
• O tamanho das barras do código deve possuir uma espessura mínima. Nossos códigos possuem 16 números e para que você possa repetir um teste que funcionará com certeza é: 0000000000097039. Se você imprimir esse código com um tamanho (considere o tamanho da primeira barra preta até a última barra preta) de 3,9cm, o leitor lerá, com muita boa vontade, 3% das vezes. Aumentando a espessura da barra para que esse código possa ter um tamanho de 4,9cm, conseguimos um nível de acerto próximo a 99% (imprimindo as barras em uma impressora laser também). Portanto considere isso para não ter gasto desnecessário;
• a rigidez do papel obviamente ajuda na leitura e na durabilidade. Se for um cartão plástico, melhor ainda;
• O IP, bem como o nome da catraca são definidos por catraca e convém operar as catracas em uma subrede, para acelerar a comunicação entre as catracas e o computador responsável por atender as requisições.

Em suma, é isso. Espero que o artigo seja útil para os desenvolvedores ou empresas que vão se aventurar no trabalhoso processo de confecção desse tipo de API.