TOTVS Roteirização e Entregas

Árvore de páginas

Versões comparadas

Versão antiga 9

changes.mady.by.user Julio Vinicius Oliveira dos Santos

Gravado em

comparado com

Nova versão Atual

changes.mady.by.user Julio Vinicius Oliveira dos Santos

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

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'
ÂncorasascarProvidersascarProvider

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
  • server.port: mesma porta que está configurada para o tomcat utilizar (Exemplo: 8080) 
* eureka* sascar
  • sascar.user: Usuário cadastrado para acesso ao serviço da Sascar 
* sascar
  • sascar.password: Senha do usuário cadastrado para acesso ao serviço da Sascar 
* sascar* sascar
  • 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
  • sascar.batch-size (Opcional): Quantidade de posições e mensagens para ler do webservice (Padrão: 500) 
* sascar
  • 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
  • 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
  • tracking.initial.delay (Opcional): Tempo, em milissegundos, antes de começar a enviar sinais (Padrão: 10000) 
* tracking
  • 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

Bloco de código
languagexml
<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
        •  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 () 

                  Tracking Central

                  Informações
                  Não necessário para ambientes de produção, visto que é usado o Tracking Central da VM
                  • 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.