Histórico da Página
Fluxo Sinais e macros
- O provedor Sascar chama o webservice
- O webservice retorna os sinais que ainda não foram lidos
- Provedor converte os sinais e envia para o tracking:
- Caso na resposta do serviço o campo 'nomeMensagem' não seja vazio:
- Cria uma ocorrência 'Pernoite' caso o valor seja 'PERNOITE' ou 'PARADA PARA PERNOITE'
- Caso contrário, cria uma ocorrência com o valor de 'nomeMensagem'
- Caso tenha 'eventos' de 'código' 5, cria uma ocorrência 'tracking.occurrence.max.speed'
Configuração do provedor
O arquivo tracking-sascar.war deve ser salvo na pasta webapps do Tomcat.
O arquivo application-tracking-sascar.properties deve ser salvo na pasta 'CPLConfig' e deve ser editado.
Configurando application-tracking-sascar.properties
É necessário editar as propriedades dentro do arquivo da seguinte maneira:
* server.port: mesma porta que está configurada para o tomcat utilizar (Exemplo: 8080)
* eureka.client.serviceUrl.defaultZone: Url de acesso ao Gateway na neolog (Exemplo: `http://sascar.cloudneolog.com.br:8080/cockpit-gateway/eureka/`)
* sascar.user: Usuário cadastrado para acesso ao serviço da Sascar
* sascar.password: Senha do usuário cadastrado para acesso ao serviço da Sascar
* sascar.url: Url de acesso ao serviço da sascar (Exemplo: http://sasintegra.sascar.com.br:80/SasIntegra/SasIntegraWSService)
* sascar.max-threads-for-async-signal-creation (Opcional): Número de threads usadas para criação de sinal (Padrão: 42. Mínimo: 1)
* sascar.batch-size (Opcional): Quantidade de posições e mensagens para ler do webservice (Padrão: 500)
* sascar.velocity (Opcional): Indica se a velocidade informada no pacote de posições deve ser enviada para o rastreamento (Exemplo: true) (Padrão: false)
* sascar.temperature (Opcional): Indica se a temperatura informada no pacote de posições deve ser enviada para o rastreamento. Aceita os valores NONE, TEMPERATURE_1, TEMPERATURE_2 ou TEMPERATURE_3 (Padrão: NONE) |
* tracking.initial.delay (Opcional): Tempo, em milissegundos, antes de começar a enviar sinais (Padrão: 10000)
* tracking.fixed.delay (Opcional): Tempo, em milissegundos, entre o envio dos sinais (Padrão: 20000)
Velocidade
Quando a configuração de velocidade estiver disponível no Sascar, é possível enviá-la para o rastreamento, para
gerar ocorrências caso a velocidade esteja acima ou abaixo do esperado.
Para isso, é necessário ligar a property 'sascar.velocity'.
Temperatura
Quando a configuração de temperatura estiver disponível no Sascar, é possível enviá-la para o rastreamento, para
gerar ocorrências caso a temperatura esteja acima ou abaixo do esperado.
Para isso, é necessário ligar a property 'sascar.temperature'.
Porém, o Sascar possui três sensores de temperatura, e é necessário informar na property 'sascar.temperature' qual deles deverá ser utilizado.
Os valores possíveis são:
* NONE - Nenhuma informação de temperatura será enviada.
* TEMPERATURE_1 - Será enviado a informação de temperatura do sensor 1.
* TEMPERATURE_2 - Será enviado a informação de temperatura do sensor 2.
* TEMPERATURE_3 - Será enviado a informação de temperatura do sensor 3.
Simulando sinais
1. Com o [SoapUI](https://www.soapui.org/) crie um mock do wsdl disponível em <http://sasintegra.sascar.com.br:80/SasIntegra/SasIntegraWSService?wsdl>.
2. Crie uma resposta do mock, seguindo o exemplo em Exemplo de retorno do webservice.
3. Configure a property 'sascar.url' para apontar para seu mock.
4. Suba o provedor. Por padrão, à cada 20 segundos, o mock criado será chamado e as posições serão enviadas para o rastreamento.
Exemplo de chamada para o webservice
Bloco de código | ||
---|---|---|
| ||
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header/> <SOAP-ENV:Body> <ns3:obterPacotePosicoes xmlns:ns3="http://webservice.web.integracao.sascar.com.br/"> <!-- usuário e senha criados no sistema da sascar (configurado pelo application-tracking-sascar.properties) --> <usuario>Joaquim</usuario> <senha>S3nh4C0mLetr4sH4ck3r</senha> <!-- quantidade máxima de posições para adquirir (configurado pelo application-tracking-sascar.properties) --> <quantidade>300</quantidade> </ns3:obterPacotePosicoes> </SOAP-ENV:Body> </SOAP-ENV:Envelope> |
Exemplo de retorno do webservice
Bloco de código |
---|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://webservice.web.integracao.sascar.com.br/"> <soapenv:Header/> <soapenv:Body> <web:obterPacotePosicoesResponse> <!-- uma ou mais repetições --> <return> <!-- Número do dispositivo --> <idVeiculo>10</idVeiculo> <!-- coordenadas do sinal --> <latitude>-22.735486359342058</latitude> <longitude>-47.64359927583132</longitude> <!-- horário do sinal --> <!-- é possível usar uma data variável usando o SoapUI: --> <!-- <dataPosicao>${=new Date().format("YYYY-MM-dd'T'HH:mm:ss.SSS-03:00")}</dataPosicao> --> <dataPosicao>2018-08-02T17:55:05-03:00</dataPosicao> <!-- Nome da macro. Esta tag tem que estar presente, mas pode ser vazia Valores esperados: - "PERNOITE", "PARADA PARA PERNOITE" -> Gera ocorrência "Pernoite" Qualquer outro valor não vazio: - Será gerado uma ocorrência com o valor fornecido --> <nomeMensagem>PERNOITE</nomeMensagem> <!-- campos opcionais --> <!-- endereço do sinal --> <rua>Rua visconde do rio branco</rua> <cidade>Piracicaba</cidade> <uf>SP</uf> <!-- velocidade (apenas valor inteiro) --> <velocidade>60</velocidade> <!-- temperatura dos sensores (apenas valor inteiro) --> <temperatura1>25</temperatura1> <temperatura2>30</temperatura2> <temperatura3>35</temperatura3> <!-- eventos --> <!-- esta tag pode ser repetida para indicar mais eventos num único sinal --> <eventos> <!-- código 5 indica que passou do limite de velocidade e será gerada uma ocorrência --> <!-- outros códigos serão ignorados --> <codigo>5</codigo> </eventos> </return> </web:obterPacotePosicoesResponse> </soapenv:Body> </soapenv:Envelope> |
Configurações em properties
MBR
application-mbr.properties
- database.server.schema=${database.server.schema.gtw:DATABASE_NAME} -----> DATABASE_NAME sendo o nome da base utilizada no GTW
Monitoring
application-monitoring.properties
- database.server.schema=${database.server.schema.gtw:DATABASE_NAME} -----> DATABASE_NAME sendo o nome da base utilizada no GTW
Tracking
application-tracking.properties
- database.server.schema=${database.server.schema.gtw:DATABASE_NAME} -----> DATABASE_NAME sendo o nome da base utilizada no GTW
- tracking.providers.list[1] = sascar
Tracking Client
application-tracking-client.properties
- neolog.tracking.central.url= apontar para URL do Tracking Central, no caso de ambientes de PROD/QA, é utilizada a URL de uma VM nossa.
Tracking Central ()
application-database.properties
- spring.datasource.url=jdbc:postgresql://${database.server.host:nlg32v:5432}/${database.server.schema:DATABASE_SERVER_NAME} -----> DATABASE_SERVER_NAME sendo uma base distinta da base do GTW vazia que receba os sinais dos provedores
application-tracking-central.properties
- database.server.schema=DATABASE_SERVER_NAME -----> DATABASE_SERVER_NAME sendo uma base distinta do GTW vazia que receba os sinais dos provedores
Fluxo geral no código
> Esse fluxo será descrito de forma a evitar dificuldades de entendimento do fluxo por parte dos desenvolvedores. Portanto, será num formato técnico e serão referenciados nomes de classes, métodos, projetos, etc.
Os Tracking Providers (Provedores de Rastreamento) possuem um fluxo diferente um do outro. Porém, a maioria utiliza o 'tracking-provider-base' como um projeto suporte, ou seja, utilizam várias funcionalidades e fluxos do próprio projeto. O Sascar é um dos provedores que o utiliza.
No Sascar, existe uma classe 'SascarMain' que é a 'main' e as anotações de propriedades do 'Spring'. Pelas anotações é achado o método 'SascarRunner#run()', anotado com [*@Scheduled*](https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/scheduling.html#scheduling-annotation-support-scheduled) específico da Sascar. Esse método chama periodicamente o 'getSignals()' do 'SascarClient', fazendo com que o fluxo do Sascar seja executado constantemente.