Versionamento

Versão

Data

Comentários

1.0

23/09/2020

Versão inicial do documento.

Atualização do manual para conter etapas de instalação

2.0

20/01/2021

manual do sistema e seus módulos, assim como

configuração dos mesmos.

2.1

21/01/2021

Revisão, inclusão de informações nos módulos e

adicionando ANEXO I.

2.2

13/04/2021

Adicionando módulo “Service Discovery” e detalhamento de

configurações de observability.

1. Objetivo

Este documento tem como objetivo detalhar o processo de instalação e atualização do S-Works na versão 2.0 ou superior, em ambiente de homologação ou produção. Inicialmente, vamos tratar a instalação e configuração manual do sistema, e ao final do documento trataremos a utilização do instalador como forma de atualização

2. Dependências

A versão 2.0 do S-Works representa a migração do sistema do NET Framework 4.7.2 para o NET Core 3.1, portanto, é necessário realizar o download e instalação das seguintes dependências nos servidores de aplicação:

• Instale o .NET Core Runtime Hosting Bundle 3.1 mais recente: https://dotnet.microsoft.com/download/dotnet-core/3.1
  

• Em caso de ambientes clusterizados, certifique-se que os demais servidores utilizados nos módulos também tenham o runtime .NET Core 3.1 mais recente instalado.
  

3.Preparação do Ambiente e Backup

Download de Release, Backup e Licenciamento

• Caso a instalação esteja sendo feita em ambiente de produção, verifique se existe backup do banco de dados atualizado.
  

• Caso o último backup do banco de dados seja muito antigo, e existam “migrations” na versão sendo instalada, considere abortar a instalação.
  

• Realize o download do pacote de instalação do S-Works para dentro do servidor.
  

• As releases geradas para o S-Works geralmente se encontra na pasta “Releases” dentro de cada pasta de versão atual do sistema, no servidor de build, por exemplo:
  

\\172.16.1.62\Build\SWorks\VersaoAtual\S-Works_v2.0\Releases

• Faça Backup da pasta da aplicação atual, principalmente para preservarmos a pasta chamada LicenseKeys, que contém as chaves de licenciamento do cliente.
  

• Essa pasta precisa estar localizada no diretório do ChassiSVC contendo o serviço do orquestrador (OrquestradorSVC) ou o serviço de enfileiramento de processos (Producer/MQDispatcher).
  

1. Caso seja uma nova instalação, solicite à infraestrutura a geração de uma nova chave de licenciamento para o ambiente/cliente.
   

Limpeza de Instalação Anterior

Por se tratar de uma instalação em um novo framework .NET, é necessário realizar a limpeza e desinstalação dos módulos de versões anteriores à versão 2.0 que estejam instaladas.

1. Limpe todas as pastas dos módulos do sistema do ambiente a ser atualizado, ou seja, as pastas SWorks.WebApp, SWorks.SVC, SWorks.WCFService devem estar vazias.
   

2. Atenção para as ConnectionStrings que vão estar nos web.config, copiar as credenciais para aplicar nos novos arquivos de configuração dos módulos do SWorks.
   

3. Atenção também para os caminhos de “Logs” nos arquivos “log.config”. Preserve estes caminhos para manter a localização existente.
   

4. Renomeie a antiga pasta (Sworks.WCFService) para (Sworks.WebApi) ficando assim:
   

5. Desinstale os Windows Services atuais (ChassiSVC). Podem ser desinstalados mais facilmente usando "sc delete <NomeService>".
   

4. Instalação dos Módulos do S-Works

Abaixo seguem os principais módulos do S-Works.

Em azul escuro estão representados os módulos que necessitam instalação e configuração para funcionamento, e em azul claro estão os módulos que são executados internamento em outros módulos, sem necessidade de instalação explícita.

Módulos Web App e Web Api

Os módulos Web App e Web Api são responsáveis por conter a aplicação web e a API REST para integração com terceiros.

As aplicações web em .NET Core já possuem um servidor interno chamado “Kestrel”, e, portanto, o IIS funcionará apenas como proxy para receber as requisições e direcioná-las para a aplicação.

1. Acesse o IIS e configure/modifique o ApplicationPool, acessando nas configurações básicas a opção "Versão do .NET CLR" e selecione "Sem código gerenciado" ou "No Managed Code".
   

2. Se for a primeira instalação, copiar os arquivos manualmente do pacote de instalação para as suas respectivas pastas dos módulos do ambiente que está sendo atualizado.
   

Alteração no Nome do Módulo WCF Service para Web Api

Até a versão 1.42 do sistema, o módulo de integração era chamado “Sworks.WCFService” pelo fato de conter um serviço WCF respondendo em protoloco SOAP.

Esse protocolo não é mais suportado na versão 2.0 ou superior, contendo apenas a API REST para comunicação via HTTP.

Devido a isso, devemos renomear a aplicação instalada no IIS para “Sworks.WebApi”.

1. Acesse o IIS e remova a antiga aplicação SWorks.WCFService:
   

2. Crie uma nova pasta chamada “SWorks.WebApi” no diretório da aplicação e atualize o IIS para que a pasta seja exibida:
   

3. Clique com o botao direito sobre a pasta e selecione a opção “Convert to Application” e depois confirme a alteração clicando em OK.
   

4. Conforme dito anteriormente, aplicação web em NET Core não podem compartilhar um mesmo application pool, portanto vamos criar um novo application pool para o módulo “WebApi”.
   

5. Clique com o botão direito sobre “Application Pools” e depois em “Add Application
   

Pool.

6. Coloque o nome “SWorks.WebApi” para o novo application pool, e selecione “No
   

Managed Code” na opção “.NET CLR version”.

7. Clique com o botão direito sobre a aplicação “SWorks.WebApi”, depois em “Manage Application” e “Advanced Settings”.
   

8.  Altere o application pool vinculado para o criado anteriormente.

Web App e Web Api em Ambientes Clusterizados

Os módulos Web App e Web Api podem ser implantados de forma clusterizada, ou seja, atrás de um balanceador de carga para fins de escalabilidade das aplicações.

Quando implantados de forma clusterizada, faz-se necessária a configuração de um diretório compartilhado para armazenamento das chaves de proteção de dados.

Para configurar o caminho para armazenamento das chaves de proteção de dados, siga as instruções abaixo:

1. Abra o arquivo “appsettings.json” e procure pela configuração “KeyPath” dentro de “DataProtectionProvider”.
   

2. Essa propriedade indica o caminho onde as chaves utilizadas para proteção de dados da aplicação serão mantidas.
   

3. Em um servidor 24/7, por exemplo o AlwaysOn, crie e compartilhe uma pasta para cada módulo, por exemplo, “C:\Sworks\Sworks.WebApp.Keys” e “C:\Sworks\Sworks.WebApi.Keys”.
   

4. Certifique-se que o usuário do application pool das aplicações possui acesso de leitura e escrita nesses caminhos compartilhados.
   

5. Feito isso, configure o valor da propriedade “KeyPath” com o caminho da pasta compartilhada, conforme exemplo abaixo:
   

6. Repare que as barras invertidas precisam ser “escapadas”, portanto, são dobradas no JSON.
   

7. Após o término da instalação, e início da aplicação, verifique-se que o sistema criou um arquivo XML com prefixo “keys” nas pastas indicadas.
   

8. O sistema irá gerar o arquivo de forma automática se ele não existir, assim como fará a rotação de chaves a cada 90 dias.
   

Módulos Orquestrador (Producer/Worker) e Ações em Lote

Os módulos de orquestração (producer e worker), e o módulo de “Ações em Lote”, são executados utilizando a aplicação “ChassiSVC” como gerenciador de serviços.

Dito isto, todos esses módulos devem ser instalados na forma de Windows Service, utilizando a aplicação “sc” para criar/remover os serviços.

Abaixo seguem orientações genéricas de como instalar o ChassiSVC na forma de

Windows Service, e mais abaixo serão detalhadas as configurações de cada módulo:

• É necessário instalar o serviço do ChassiSVC no Windows, abra o CMD como Administrador e digite o seguinte comando: sc create ChassiSVC_NOMECLIENTE binPath="<CAMINHO_COMPLETO_CHASSISVC.exe>"
  

▪ Na  primeira  aba,  em  "Startup  type"  altere  para  "Automatic  (Delayed  Start)".

• Na segunda aba "Log On", utilize as credenciais de Administrator local ou Administrator do Domain
  

Para os módulos “Producer” e “Worker” essas credenciais precisam ter acesso à fila do MSMQ configurada. Mais detalhes sobre essa configuração no tópico relacionado.

• Na aba "Recovery", selecione "Restart the Service" nas 3 opções; First failure, Second failure e Subsequent failure.
  

Módulo Orquestrador (Producer/Worker)

O módulo orquestrador pode ser instalado de duas formas:

Orquestrador com Processamento Local

Método utilizado para ambientes de homologação ou clientes de baixa demanda (até aproximadamente 5 mil processos/mês).

Nesse tipo de implantação, o enfileiramento de processos acontece em memória, e seu processamento na mesma aplicação.

A seguinte configuração deve ser feita no arquivo ChassiSVC.dll.config:

<add ServiceType="TaskQueue" name="Serviço do Orquestrador S-Works" assemblyname="SWorks.Orquestrador, Version=1.1.0.0, Culture=neutral, PublicKeyToken=5c21879e795ae678" typename="SWorks.Orquestrador.OrquestradorSVC" MaxCount="4" WaitSecondsOnNoTasks="5" WaitSecondsOnCaptureError="20" WaitSecondsOnGetMaxCountError="20" />

• MaxCount: quantidade de threads de execução paralela de processos. O valor recomendado aqui é o resultado da quantidade de núcleos lógicos da instância multiplicado por 4. Números muito maiores do que isso podem acarretar em perda de performance no processamento.
  

Orquestrador com Processamento Distribuído

Método utilizado para clientes com grandes volumes de processamento, podendo ser configurado em ambiente auto escalável, ou máquinas ligadas 24/7.

Nesse método, o orquestrador é dividido em dois sub-módulos:

• Producer: módulo que realiza o enfileiramento de processos no MSMQ
  

• Worker: módulo que realiza o processamento dos itens enfileirados pelo “Producer”, constantemente buscando trabalho na fila do MSMQ.
  

Instalando o Message Queuing (MSMQ)

Para instalar o módulo Producer é necessário a instalação do MSMQ:

1. Em um servidor “AlwaysOn” (servidor 24/7), acesse o menu de adição de novos recursos do Windows e selecione “Servidor do MSMQ”:
   

2. Após instalação, acesse o “mmc” e adicione o “Snap-In” chamado “Gerenciamento do Computador” e navegue até a opção “Filas Privativas”, clicando com botão direito sobre essa pasta para criar uma nova fila:
   

3. Escolha um nome para a fila, por ex. “SWorksQueue” e deixe a opção “Transacional” desmarcada.
   

1. Esse mesmo nome de fila será utilizado nas configurações do “Producer” e “Worker”.
   

4. Clique com botão direito sobre a fila criada e clique em “Propriedades”.
   

5. Navegue até a aba “Segurança” e adicione o mesmo usuário que será utilizado nos Windows Services instalado do ChassiSVC.
   

1. Aplique a permissão “Controle Total” para o usuário adicionado.
   

Instalando/Configurando o Módulo Producer

Após instalação e configuração do MSMQ, siga as orientações abaixo para configurar o

ChassiSVC com o módulo Producer:

1. No mesmo servidor “AlwaysOn” onde o MSMQ foi instaladado, crie um pasta chamada “Sworks.Producer” com o conteúdo da pasta “SWorks.SVC” contida no pacote de instalação.
   

2. Abra o arquivo “ChassiSVC.dll.config” e certifique-se que apenas a seguinte linha de configuração estará presente na tag de services.
   

<add ServiceType="MQDispatcher" name="Serviço do Orquestrador S-Works" assemblyname="SWorks.Orquestrador, Version=1.1.0.0, Culture=neutral, PublicKeyToken=5c21879e795ae678"

typename="SWorks.Orquestrador.MQDispatcher" MaxCount="1"

WorkQueueName="SWorksQueue" WaitSecondsOnNoTasks="5" WaitSecondsOnCaptureError="20" WaitSecondsOnEnqueue="10" />

3. WorkQueueName: nome da fila privada criada no MSMQ. Se a fila não existir o módulo irá criá-la automaticamente, porém será necessário configurar as permissões de segurança manualmente.
   

4. MaxCount: indica a quantidade de itens a serem enfileirados no MSMQ. Esse valor pode ser aumentado caso a quantidade de workers disponíveis seja alta, visando aumentar a vazão de processamento.
   

5. WaitSecondsOnEnqueue: tempo, em segundos, a ser aguardado para cada turno de enfileiramento. Reduza esse tempo para enfileirar processos mais rapidamente sob o custo de maior consumo de CPU.
   

Instalando/Configurando o Módulo Worker

O módulo Worker também deve ser instalado na forma de Windows Service do ChassiSVC. Abaixo seguem as configurações necessárias para que esse módulo seja capaz de processar os itens da fila do MSMQ:

6. Em um servidor a ser utilizado exclusivamente como “Worker”, seja para construção de uma imagem em ambiente com autoscale ou em uma máquina ligada em horário integral, crie uma pasta chamada “Sworks.Worker” com o mesmo conteúdo da pasta “Sworks.SVC” presente no pacote de instalação.
   

7. Abra o arquivo “ChassiSVC.dll.config” e certifique-se que apenas a seguinte linha de configuração estará presente na tag de services.
   

<add ServiceType="MQWorker" name="Serviço do Orquestrador MQWorker S-Works" assemblyname="SWorks.Orquestrador, Version=1.1.0.0, Culture=neutral, PublicKeyToken=5c21879e795ae678"

typename="SWorks.Orquestrador.MQWorker" MaxCount="48"

WorkQueuePath="FormatName:DIRECT=TCP:172.28.0.7\private$\SWorksQueue"

WaitSecondsOnNoTasks="5" WaitSecondsOnCaptureError="30" />

8. WorkQueuePath: informação para conexão na fila do MSMQ, composto pelo IP privado da instância que contém o servidor MSMQ, e o nome da fila privada criada.
   

9. MaxCount: quantidade de threads de execução paralela de processos. O valor recomendado aqui é o resultado da quantidade de núcleos lógicos da instância multiplicado por 4. Números muito maiores do que isso podem acarretar em perda de performance no processamento.
   

Configuração de Firewall e Portas para MSMQ

Algumas infraestruturas em nuvem exigem a liberação de portas específicas para que a comunicação entre no protocolo do MSMQ seja viabilizada, como por exemplo na AWS. Se após a instalação, os workers não conseguirem “receber” trabalhos da fila do MSMQ, talvez seja necessário a liberação das seguintes portas:

• TCP: 1801
  

• RPC: 135, 2101*, 2103*, 2105*
  

• UDP: 3527, 1801
  

Módulo Ações em Lote

O módulo de “Ações em Lote” deve ser instalado num servidor “AlwaysOn”, usando também o “ChassiSVC” como Windows Service.

Siga os seguintes passos para configurar o módulo:

1. Crie uma pasta chamada “SWorks.AcoesLote” com conteúdo da pasta “SWorks.SVC” do pacote de instalação.
   

2. Abra o arquivo “ChassiSVC.dll.config” e certifique-se que apenas a seguinte linha de configuração estará presente na tag de services
   

<add ServiceType="TaskQueue" name="Serviço do Orquestrador de Ações em Lote" assemblyname="SWorks.AcoesLote, Version=1.0.0.0, Culture=neutral,

PublicKeyToken=5c21879e795ae678"

typename="SWorks.AcoesLote.OrquestradorLoteSVC" MaxCount="2" WaitSecondsOnNoTasks="30" WaitSecondsOnCaptureError="20" WaitSecondsOnGetMaxCountError="20" />

3. MaxCount: representa a quantidade de threads para execução paralela da ação em lote.
   

Módulo Distribuidor de Atividades (Activity Dispatcher)

O módulo de distribuição de atividades, também conhecido como Activity Dispatcher, é responsável por distribuir atividades manuais solicitadas pelos usuários operadores através do módulo Web App.

• Este módulo deve ser instalado na instância “AlwaysOn”, ou outra instância que se mantenha ligada 24/7.
  

• Anteriormente, esse módulo era instalado sob o gerenciador de serviços “ChassiSVC”, porém agora pode ser instalado como um Windows Service comum, utilizando a aplicação “sc” conforme mostrado anteriormente.
  

• Após instalação, abra o arquivo “appsettings.json”, localizado na pasta raiz da aplicação, e configure o IP privado do servidor na tag “Url”, nas configurações do
  

Kestrel, conforme abaixo:

• Verifique se a porta configurada está disponível. Caso não esteja, altere a porta manualmente.
  

• Aoinicializar,omóduloiráatualizaraconfiguração
  

“URL_WS_DISTRIBUICAO_ATIVIDADES” automaticamente.

Configuração Pós Instalação do Distribuidor de Atividades (Activity Dispatcher)

O sistema possui duas formas de controlar a distribuição de atividades manuais, a padrão, que usa consulta direta em banco de dados, e a recomendada usando o “Activity Dispatcher”.

Para ativar a distribuição de atividades usando o módulo “Activity Dispatcher”:

1. Acesse o menu de configurações em Administração -> Configurações.
   

2. Crie/modifiqueachavedeconfiguraçãodenome
   

“ARQUITETURA_BUSCA_ATIVIDADES_MANUAIS”

1. Atribua o valor “1” (sem aspas) para ativar a distribuição utilizando o módulo “Activity Dispatcher”.
   

2. O valor “2” indica que será utilizado busca direta usando banco de dados.
   

Módulo Service Discovery

O módulo “Service Discovery” é uma aplicação web, que deve ser instalada na forma de Windows Service, responsável por manter um registro de todos os módulos do sistema em execução.

A interação entre os demais módulos do S-Works e o Service Discovery ocorre da seguinte forma:

• Cada módulo do S-Works, durante a inicialização, se auto registra através do serviço de Service Discovery.
  

• O Service Discovery valida as informações do módulo, e armazena seus dados num arquivo de dados interno.
  

o Periodicamente, o Service Discovery irá “pingar” o serviço através de uma URL de health-check disponibilizada pelo módulo registrado.

o Caso um módulo não responda por 3 vezes seguidas, seu registro é apagado do arquivo de dados interno.

Instalação do Módulo Service Discovery

Este módulo deverá ser instalado num servidor “AlwaysOn” que seja acessível por todas as instâncias do cluster do S-Works.

• Para instalar o módulo como Windows Service, abra o CMD como Administrador e digite o seguinte comando: sc create SWorks_ServiceDiscovery binPath="<CAMINHO_COMPLETO\SWorks.ServiceDiscovery.exe>"
  

1

Configuração do ’Target File’ do Módulo Service Discovery

O módulo Service Discovery também mantém um arquivo chamado “Target File”, utilizado pelo Prometheus para obter os endpoints para realizar a leitura das métricas publicadas por cada módulo.

O seguinte trecho de configuração do arquivo appsettings.json diz respeito sobre essa funcionalidade.

• TargetFilePath: indica o caminho do arquivo onde as informações dos targets serão gravadas. O caminho informado deve ser acessível, em modo de leitura, pelo usuário de execução do Prometheus.
  

• GlobalLabels: JSON que representa configurações globais que serão inseridas em qualquer métrica lida pelo Prometheus. Recomenda-se utilizar as duas métricas
  

“ambiente” e “cliente”, caso a instalação do Prometheus seja compartilhada.

Diagrama de Comunicação do Service Discovery

O diagrama a seguir mostra o ciclo de comunicação entre o Service Discovery e os demais módulos do sistema.

5. Arquivos de Configuração

Devido à alteração de framework, algumas configurações dos módulos, que costumavam ficar nos arquivos “web.config” para aplicações web, e no arquivo “ChassiSVC.exe.config”, agora estão localizadas em outros arquivos:

Arquivo

Módulos

Descrição

Arquivo de configuração, em formato

Web App, Web Api,

JSON, presente nas aplicações web.

Responsável por conter a string de

appsettings.json

Distribuidor de

conexão e configurações que

Atividades

antigamente ficavam na tag

“AppSettings” do antigo “web.config”

Arquivo de configuração dos logs do

Web App, Web Api,

sistema, utilizando log4net. Utilize

log.config

Distribuidor de

para filtrar os níveis de logs registros,

Atividades

e tipos de saída, por ex.: arquivo,

Graylog.

Orquestrador

Arquivo que contém quais serviços o

ChassiSVC.dll.config

(Producer/Worker),

ChassiSVC deverá executar quando o

Ações em Lote

Windows Service for iniciado.

ChassiSVC.dll.json

*

Mesmo propósito do arquivo

“appsettings.json”.

ChassiSVC.dll.log.config

*

Mesmo propósito do arquivo

“log.config”.

Configuração da String de Conexão

• As configurações do WebApp e WebApi agora ficam num arquivo chamado "appsettings.json".
  

• Altere a connectionString nesse arquivo com as credenciais obtidas do antigo web.config. Essa é a tag de conexão usada no arquivo appSettings.json:
  

"DefaultConnection": "Server=localhost;Database=Sworks_banco;Integrated

Security=false;User ID=sworks_teste;Password=senha@senha"

• Verifique se os módulos WebApp e WebApi contém um arquivo web.config dentro da suas respectivas pastas, Caso não tenham, podemos pegar do ambiente de QA (172.16.0.39), O arquivo apenas contém informação para o IIS sobre qual módulo executar para processar a aplicação.
  

• Para configurar a string de conexão nos módulos que executam sob o “ChassiSVC”, abra o arquivo "ChassiSVC.dll.json” e utilize a mesma string de conexão.
  

Configurações de Logs

O arquivo responsável pelas configurações de log são:

• Log.config: para módulos que não executam sob o ChassiSVC.
  

• ChassiSVC.dll.log.config: para os módulos que executam sob o ChassiSVC.
  

Logs em Ambientes Clusterizados

Em ambientes clusterizados, onde os módulos estão em múltiplos servidores, é recomendado que se crie uma pasta compartilhada no servidor “AlwaysOn”, ou em qualquer servidor que fique ligado 24/7, com liberação de leitura/escrita para os usuários dos módulos, e em seguida alterar as configurações do “Appender” de nome “RollingLogFileAppender”.

Configuração de Log no Orquestrador (Worker)

O módulo Orquestrador (Worker) possui uma particularidade na configuração do log, que permite que cada linha de log exiba o código do processo em uma coluna específica, facilitando a aferição de problemas no processamento pela equipe de técnica.

1. Abra o arquivo de configuração de logs “ChassiSVC.dll.log.config”.
   

2. Em cada appender configurado, procure pela tag “conversionPattern”.
   

3. Atribua o seguite valor no campo “value”:
   

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%date [%thread] %-5level %logger -

[Processo|%property{processo}] - %message%newline" />

</layout>

4. Uma propriedade customizada chamada “processo” irá ser adicionada em cada linha de log registrado.
   

Configurações de Monitoramento e Observability

A partir da versão 2.1, todos os módulos do S-Works possuem configurações que dizem respeito à habilitação e configuração da coleta de métricas do sistema.

A instrumentação dos módulos é realizada usando a biblioteca AppMetrics, e suas configurações são realizadas através do arquivo appsettings.json de cada módulo instalado.

O seguinte trecho de configuração estará presente em todos os arquivos de templates de configuração, podendo ser reaproveitados e alterados para aplicação correta nos arquivos originais.

• MetricOptions: JSON que indica configurações globais.
  

15. GlobalTags: tags a serem aplicadas em todas as métricas coletas pelo
    

módulo configurado

15. Enabled: indica se a coleta de métricas está habilitada. Em módulos que não são aplicações Web, desabilitar essa tag também evita com que o
    

módulo inicialize um endpoint para leitura de métricas, economizando recursos de CPU e memória.

15. ReportingEnabled: indica quando o reporte de métricas está habilitado ou não. Manter “false”.
    

• MetricsWebTrackingOptions: configuração exclusiva para aplicações web, como o módulo WebApp e WebApi. Habilitar essas métricas faz com que o AppMetrics gere métricas usando um middleware no pipeline de comunicação do MVC, trazendo com detalhes mais informações sobre tempos de resposta, tamanho de requisições, e outros. Clique aqui para mais detalhes.
  

• MetricsEndpointEnabled: ativa ou desativa endpoints de métricas (“/metrics”).
  

• MetricsTextEndpointEnabled: ativa ou desativa endpoints de métricas com saída textual.
  

• EnvironmentInfoEndpointEnable: ativa ou desativa o endpoint que fornece informações sobre o ambiente (“/env”).
  

Configurações do Prometheus

A instrumentação do S-Works prepara métricas para serem extraídas no formato de leitura da ferramenta Prometheus. Este manual não abordará a instalação e configuração desta ferramenta, porém se faz necessária a informação de leitura dos endpoints de métricas.

Conforme falado anteriormente, o módulo Service Discovery é responsável por manter um arquivo, chamado de “Targets File”, que contém as informações de coleta de métricas a serem lidas pelo Prometheus durante a operação de scrape (leitura das métricas). Para informar ao Prometheus a localização desse arquivo:

• Acesse a pasta de instalação do Prometheus e abra o arquivo “prometheus.yml”
  

• Na propriedade “scrape_configs”, adicione a seguinte linha:
  

• Essa configuração dirá ao Prometheus que obtenha os endpoints de métricas utilizando
  

o arquivo gerenciado pelo Service Discovery.

Isso se

Configuração do Appender para Graylog

A partir da versão 1.42, o S-Works possui compatibilidade padrão para envio de registros de log para uma instalação de Graylog existente. Para isso, siga as instruções abaixo:

1. Abra o arquivo de log do módulo desejadado.
   

2. Adicione o seguinte “appender”
   

<appender name="GelfHttpAppender"

type="Gelf4net.Appender.GelfHttpAppender, Gelf4Net.HttpAppender"> <url value="http://localhost:12201/gelf%22 />

<layout type="Gelf4net.Layout.GelfLayout, Gelf4Net.HttpAppender"> <param name="AdditionalFields"

value="Ambiente:Dev,Cliente:Simply,Modulo:TestConsole,Level:%level" /> <!--<param name="Facility" value="RandomPhrases" />-->

<param name="IncludeLocationInformation" value="false" /> <param name="SendTimeStampAsString" value="false"/>

<!-- Sets the full_message and short_message to the specified pattern-->

<param name="ConversionPattern" value="%date [%thread] %-5level %logger - [Processo|%property{processo}] - %message%newline" />

</layout>

</appender>

3. No campo “url”, coloque o endereço do servidor onde o “input stream” para o protocolo “GELF” foi configurado no seu Graylog. Consulte a documentação do
   

Graylog ou o Wiki do S-Works para realiziar essa configuração no Graylog caso não exista.

4. Configure os campos adicionais a serem registrados na tag “AdditionalFields”.
   

5. Essas tags permitem com que tais campos sejam utilizados como filtros de pesquisa.
   

6. O exemplo acima contém, iniformações do processo iniformação só é exigida Orquestrador(Worker).
   

no padrão de conversão (conversion pattern) as em “[Processo|%property{processo}], porém essa para a configuração do appender do módulo

7. Respeite padrões para nomenclatura dos campos “Ambiente” e “Modulo” para facilitar a pesquisa.
   

8. Na tag root, adicione o “Appender” configurado, ficando da seguinte forma:
   

<root>

<level value="DEBUG" />

<appender-ref ref="RollingLogFileAppender" /> <appender-ref ref="GelfHttpAppender" />

</root>

Ao final da instalação, certifique-se que os logs estão sendo corretamente enviados para o Graylog.

Importante: Caso exista um appender chamado “AdoNetAppender” nas configurações, remova-o. Este appender salva informações de log em banco de dados, porém será descontinuado em breve.

6. O Instalador do S-Works

No pacote de release está contido o instalador do S-Works (SWorks.Instalador.exe), porém seu papel ainda é voltado para atualização do sistema, fazendo a interrupção dos applications pools e Windows Services devidos, e realizando a substituição dos arquivos das pastas de destino.

Execute o instalador como usuário administrador e siga as instruções na tela para criação do script de migração do banco de dados, se houver, configuração das pastas onde os módulos devem ser extraídos.

Anexo I - Checklist Pós Deploy

Objetivo

Este documento tem o intuito de orientá-lo na análise da consistência do sistema S-Works pós instalação/atualização. Segue abaixo os passos necessários de verificação.

Módulo Web App

1. Verifique a abertura do site. Ex:
   

Figura 1 - Validar se a versão apresentada bate com a versão instalada.

2. Realize login com o usuário.
   

3. Acesse algumas telas principais, por ex.: monitorar processos, detalhes de processo, edição de workflow.
   

Módulo Web Api

1. Acesse a página principal da WebApi. Atente-se para a URL de acesso. Ex:
   

” ou “{url}/index.html

2. Solicite ao cliente que invoque sua integração com o sistema.
   

3. Verifique a criação de processos, dados de entrada, documentos.
   

4. Verifique inicialização do processo, ou seja, passagem de status NOVO para
   

PENDENTE

Módulo Distribuidor de Atividades (Activity Dispatcher)

1. Verifique a inicialização correta do dispatcher, identificando no log os tempos sincronização/obtenção das atividades manuais no cache de distribuição. Ex:
   

Figura 3 - Arquivo de log do ActivityDispatcher

2. Como usuário no site, teste a distribuição de atividade manual.
   

Módulo Orquestrador (Producer)

1. Verifique a licença validada no log através do registro "Produto licenciado". Ex:
   

Figura 4 - Registro de log do Orquestrador Producer mostrando licença válida.

2. Verifique a presença no log de registros enfileirados (a não ser que não existam processos na fila, daí retornará 0).
   

Módulo Orquestrador (Worker)

1. Verifique a presença no log de obtenção de registros para processamento. Ex:
   

Figura 5 - Registro de log do Orquestrador Worker mostrando processos sendo recebidos.

2. Verifique na tela de diagnóstico na aplicação WebApp, se os processos estão sendo processados (processos verdinhos).
   

3. Acesse um dos processos processados após a implantação e verificar se contém erro no histórico de tarefas executadas.
   

Módulo Orquestrador – Processamento Local

Geralmente em ambientes menores, em vez de termos a dupla Producer+Worker, temos instalado apenas o Orquestrador que é responsável tanto por buscar os processos a serem processados, quanto de fato processar. Para isso então:

1. Verifique no log licença validada e obtenção de registros para processamento. Ex:
   

Figura 6 - Registro de log do Orquestrador mostrando licença válida.

Orientações Gerais

As seguintes orientações podem ser utilizadas em todos os módulos do sistema.

1. Verifique a presença de erros nos logs após a implantação.
   

2. Antes de iniciar as aplicações, limpe os arquivos de logs para facilitar o rastreio de erros após a implantação.
   

Ambientes com Integração Externa (Função)

Alguns ambientes possuem um mecanismo de integração externa, nesses casos possuímos 2 módulos avulsos implantados no ambiente de produção que são responsáveis por processar a integração de propostas no sistema.

1. SWorks.Funcao.WS: web service hospedado no IIS da máquina AlwaysOn, e sua verificação deve ser através da navegação para uma página do site. Ao acessar a URL, a seguinte página é exibida:
   

2. Para realizar os devidos testes, deve-se entrar num endereço de busca de proposta:
   

Figura 7 - Página inicial do módulo Funcao.WS

Figura 8 - Resultado de GET na URL de integração com Funcao.WS.

3. SWorks.Funcao.SVC: é um "ChassiSVC" (similar ao workers), implantados em um "AutoScaling Group".
   

1. Após implantação, solicite integração de propostas pelo cliente.

b. Verifique, a partir da tela de "Integração Função" no WebApp, se as propostas são integradas corretamente. Ex: