Recepção de múltiplas requisições por segundo utilizando o driver Elipse WebService.

O driver Elipse WebService (ElipseWS) não enfileira requisições e reflete só o último POST entre dois scans. Para receber acima de 1 requisição por segundo sem perdas, use o Driver SequenceWebService.

1. Introdução

Ao integrar sistemas externos que enviam dados ao E3 por WebService (via POST HTTP/SOAP), é comum a necessidade de receber mais de uma requisição por segundo. Nesses cenários, quem usa o driver Elipse WebService (ElipseWS) costuma observar que, ao disparar várias requisições em sequência rápida, apenas parte delas é refletida no supervisório — na prática, o comportamento se estabiliza em torno de uma requisição por segundo, e as demais parecem “perdidas”.

Essa observação está correta e não é um defeito: é uma característica de projeto desses drivers. Este artigo explica por que isso acontece e apresenta o driver Elipse SequenceWebService, desenvolvido justamente para receber essas requisições sem descartá-las.

2. Por que o driver ElipseWS “perde” requisições

O driver ElipseWS disponibiliza um WebService para receber chamadas de terceiros, mas não trata filas. O dado recebido é processado no scan do bloco que faz as atualizações. Assim, se vários POSTs chegam entre dois scans desse bloco, apenas o último é refletido no supervisório — os anteriores são sobrescritos antes de serem lidos.

Não existe configuração de tamanho de fila ou tempo de buffer nesse driver para aumentar a taxa de recepção — ele simplesmente não enfileira as requisições.
Diminuir o tempo de scan do bloco não resolve: como não há fila, duas requisições que cheguem dentro de um mesmo ciclo continuam colidindo.

3. A solução: driver Elipse SequenceWebService

O Driver Elipse SequenceWebService foi criado para esse tipo de integração. A diferença fundamental é que ele mantém uma fila em memória de todas as atualizações recebidas e as repassa ao supervisório via callbacks — individualmente ou em lotes, para melhor desempenho. Com isso, requisições enviadas em sequência rápida (mais rápidas que o scan) não são descartadas.

Fila em memória das requisições recebidas, processadas em sequência.
Persistência em disco: ao parar (por exemplo, na reinicialização do supervisório), as atualizações pendentes são salvas e recuperadas ao iniciar.
Aceita o corpo da requisição em JSON ou XML.

Aspecto	ElipseWS	SequenceWebService
Enfileiramento das requisições	Não	Sim (fila em memória)
Acima de 1 requisição por segundo	Só o último POST entre scans é refletido	Todas processadas em sequência
Pendências ao parar/reiniciar	—	Salvas em disco e recuperadas
Formato do corpo	—	JSON ou XML

4. Como é a requisição (operação UPDATE TAG)

O WebService recebe POST com três parâmetros. O Operation e o Entity vão nos cabeçalhos (headers); os dados vão no corpo:

Parâmetro	Onde	Conteúdo
`Operation`	Header	A operação — por exemplo, `UPDATE TAG`
`Entity`	Header	Identificador do tag a atualizar (ex.: `TagInterno1`)
`Content-Type`	Header	`application/json` ou `application/xml`
Dados	Corpo	`Value`, `Quality` e `Time`

Exemplo de corpo em JSON:

{ "Value": "625.4", "Quality": 193, "Time": "2025-08-19T15:02:31" }

Mesmo conteúdo em XML:

O Time deve ser uma String no formato ISO 8601 (YYYY-MM-DDTHH:MM:SS). A resposta do WebService é um JSON com o resultado do processamento:

Resposta

{ "Err": 0, "ErrMsg": "OK" }

Err = 0 indica que a requisição foi recebida e processada com sucesso.

5. Configuração do tag no lado do WebService

No driver SequenceWebService, o tag que recebe a atualização é do tipo Somente Leitura (via Callback): ele é atualizado automaticamente quando chega uma requisição UPDATE TAG. A única propriedade a configurar é o Item, que deve ser igual ao parâmetro Entity da requisição.

Propriedade do tag	Valor
`Item`	Igual ao `Entity` da requisição (ex.: `TagInterno1`)
`Device`	Não utilizado
`N1..N4` / `B1..B4`	Não utilizados

A correspondência é direta:

Na requisição (header)	Na configuração do tag
`Entity: TagInterno1`	Tag com `Item = TagInterno1`

No driver SequenceWebService, adicione o tag que receberá o dado — uma Tag PLC para um valor único ou uma Tag Bloco quando o Value for um array.
Preencha apenas a propriedade Item com o identificador que virá no Entity. Deixe Device e N1..N4/B1..B4 sem uso.
Ao receber a requisição, o driver localiza (via Callback) o tag com Item igual ao Entity e atualiza nele o Value, o Quality e o Time.

Imporatnte
O Item precisa corresponder exatamente ao Entity enviado. Se não houver tag com esse Item, o driver não encontra o destino e a atualização não é aplicada.

6. Como testar se o WebService está respondendo

Uma forma rápida de validar é fazer uma chamada HTTP direta com o curl. O curl é uma ferramenta de linha de comando para enviar requisições HTTP (GET/POST) direto pelo terminal — serve para testar se um serviço está no ar, sem precisar de uma aplicação. No PowerShell do Windows, o equivalente nativo é o Invoke-RestMethod.

Exemplo de um envio de teste (operação UPDATE TAG; ajuste host/porta conforme a configuração do driver):

PowerShell

$headers = @{ "Operation" = "UPDATE TAG"; "Entity" = "TagInterno1" }
$body = '{"Value":"625.4","Quality":193,"Time":"2025-08-19T15:02:31"}'
Invoke-RestMethod -Method Post -Uri "http://localhost:5051/" -Headers $headers -ContentType "application/json" -Body $body

Resposta esperada:

Err ErrMsg
--- ------
  0 OK

O retorno Err: 0 / OK confirma que o WebService recebeu e processou a requisição corretamente.

Ao usar o curl.exe (em vez do Invoke-RestMethod) dentro do PowerShell, o corpo JSON entre aspas pode ter as aspas duplas removidas pelo shell, gerando erro de parsing no servidor. Nesse caso, salve o JSON em um arquivo e envie com -d "@arquivo.json", ou use o Invoke-RestMethod como acima.

7. Observações e boas práticas

O comportamento de ~1 requisição/segundo do driver ElipseWS é esperado (ausência de fila), não é bug — e não há parâmetro para ajustá-lo.
Para ingestão de dados em alta frequência, use o SequenceWebService, que enfileira e processa em sequência.
O Item do tag no servidor deve bater exatamente com o Entity da requisição.
O corpo pode ser JSON ou XML — escolha conforme o sistema de origem e ajuste o Content-Type.
Como o driver persiste pendências em disco, atualizações recebidas pouco antes de uma parada não são perdidas.