Configuração do provedor - sascarProvider

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.

Fluxo Sinais e macros

1.  O provedor Sascar chama o webservice
2.  O webservice retorna os sinais que ainda não foram lidos
3. Provedor converte os sinais e envia para o tracking:
4. Caso na resposta do serviço o campo 'nomeMensagem' não seja vazio:
5. Cria uma ocorrência 'Pernoite' caso o valor seja 'PERNOITE' ou 'PARADA PARA PERNOITE'
6. Caso contrário, cria uma ocorrência com o valor de 'nomeMensagem'
7. Caso tenha 'eventos' de 'código' 5, cria uma ocorrência 'tracking.occurrence.max.speed'

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

<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

<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.