S-Works - Manual de Instalação da Versão 2.2
Versionamento
Versão | Data | Comentários |
1.0 | 23/09/2020 | Versão inicial do documento. |
2.0 | 20/01/2021 | Atualização do manual para conter etapas de instalação 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. |
2.3 | 20/05/2021 | Substituição da ferramenta MSMQ pelo RabbitMQ. |
Objetivo
Detalhar o processo de instalação e atualização do S-Works na versão 2.2 ou superior, em ambiente de homologação ou produção.
Características do documento
Características do documento
Abordagem da instalação e configuração manual do sistema, e ao final do documento a utilização do instalador como forma de atualização.
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
Faz-se 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 ambientes clusterizados, certifique-se que os demais servidores utilizados nos módulos também tenham o runtime .NET Core 3.1 mais recente instalado.
Preparação do Ambiente e Backup
Download de Release, Backup e Licenciamento
- Instalação sendo feita em ambiente de produção, verifique se existe backup do banco de dados atualizado.
- Backup do banco de dados (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.
- 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
Backup da pasta da aplicação atual - principalmente para preservarmos a pasta chamada LicenseKeys, que contém as chaves de licenciamento do cliente.
A 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).
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 instaladas.
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.
Atenção
ConnectionStrings que vão estar nos web.config, copiar as credenciais para aplicar nos novos arquivos de configuração dos módulos do SWorks.
Atenção também para os caminhos de “Logs” nos arquivos “log.config”. Preserve estes caminhos para manter a localização existente.
Renomeie a antiga pasta (Sworks.WCFService) para (Sworks.WebApi) :
Desinstale os Windows Services atuais (ChassiSVC). Para ser desinstalados ,use "sc delete <NomeService>".
Instalação dos Módulos do S-Works ( 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 , os módulos que são executados internamento em outros módulos, sem necessidade de instalação explícita.
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.
Aplicações web em .NET Core, já possuem um servidor interno chamado “Kestrel”, e, por isto, o IIS funcionará apenas como proxy para receber as requisições e direcioná-las para a aplicação.
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".
Primeira instalação
Faça uma cópia dos arquivos manualmente do pacote de instalação para as suas respectivas pastas dos módulos do ambiente que está sendo atualizado.
Aplicações Web em NET Core, exigem a configuração de um application pool para cada aplicação, portanto, não é possível compartilhar um mesmo application pool para duas ou mais aplicações.
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.
Acesse o IIS e remova a antiga aplicação SWorks.WCFService:
Clique com o botâo direito sobre a pasta e selecione a opção “Convert to Application” e depois confirme a alteração clicando em OK.
A aplicação web em NET Core não pode compartilhar um mesmo application pool, portanto crie um novo application pool para o módulo “WebApi”.
Coloque o nome “SWorks.WebApi” para o novo application pool, e selecione “No Managed Code” na opção “.NET CLR version”.
Clique com o botão direito sobre a aplicação “SWorks.WebApi”, depois em “Manage Application” e “Advanced Settings”.
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, 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.
Anteriormente, aplicações Net Framework utilizavam uma chave chamada “MachineKey”, configurada pelo IIS, como objeto para criptografia de dados, como cookies de sessão por ex.. Devido à portabilidade do NET Core, um novo mecanismo de proteção de dados foi implementado. Utilizamos o mecanismo via file system para armazenar tais chaves.
Instruções para configurar o caminho para armazenamento das chaves de proteção de dados:
- Abra o arquivo “appsettings.json” e procure pela configuração “KeyPath” dentro de “DataProtectionProvider”. Essa propriedade indica o caminho onde as chaves utilizadas para proteção de dados da aplicação serão mantidas.
- 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”.
- Certifique-se que o usuário do application pool das aplicações possui acesso de leitura e escrita nos caminhos compartilhados.
- Configure o valor da propriedade “KeyPath” com o caminho da pasta compartilhada, conforme exemplo abaixo:
- Repare que as barras invertidas precisam ser “escapadas”, portanto, são dobradas no JSON.
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.
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.
Todos esses módulos devem ser instalados na forma de Windows Service, utilizando a aplicação “sc” para criar/remover os serviços.
Orientações genéricas de como instalar o ChassiSVC na forma de Windows Service, e o detalhamento das configurações de cada módulo:
Faz-se 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.
Na aba "Recovery", selecione "Restart the Service" nas três opções( First failure, Second failure e Subsequent failure).
A configuração de qual serviço que será executado dentro do Windows Services do ChassiSVC é determinada no arquivo “ChassiSVC.dll.config”, na tag “services”. Apenas um serviço deve ser executado dentro de um mesmo ChassiSVC, ou seja, cada módulo deverá ter uma pasta de instalação separada.
Módulo Orquestrador (Producer/Worker) 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 RabbitMQ
- Worker: Módulo que realiza o processamento dos itens enfileirados pelo “Producer”, constantemente buscando trabalho na fila do RabbitMQ.
Instalando o RabbitMQ
Para instalar o módulo Producer é necessário a instalação do RabbitMQ:
Em um servidor “AlwaysOn” (servidor 24/7), acesse o site do RabbitMQ e faça o download da ferramenta:
https://www.rabbitmq.com/install-windows.html#installer
O RabbitMQ necessita que a linguagem Erlang, esteja instalada na máquina. Caso o instalador do RabbitMQ identifique a falta dela, será solicitado a instalação, bem como o link para realizar o download.
Após instalação, será possivel identificar o RabbitMQ como serviço, já em execução:
Deve-se instalar um plugin chamado RabbitMQ Message Deduplication Plugin, realizando o download da release mais recente no seguinte endereço:
Realize o download dos dois arquivos sinalizados na imagem, são eles:
elixir-{version}.ez e rabbitmq-message-deduplication-{version}.ez
Mova os dois arquivos baixados para a pasta de plugins do RabbitMQ, que normalmente está no caminho:
“C:\Program Files\RabbitMQ Server\rabbitmq_server-{version}\plugins”
Abra o cmd como administrador e navegue até o diretório \sbin que situa-se dentro da pasta raiz de instalação do RabbitMQ, por exemplo:
“C:\Program Files\RabbitMQ Server\rabbitmq_server-3.8.16\sbin”
Execute o comando para habilitar o plugin adicionado:
“rabbitmq-plugins enable rabbitmq_message_deduplication”
Execute o comando no mesmo diretório para habilitar o plugin de gerenciamento via interface do RabbitMQ:
“rabbitmq-plugins enable rabbitmq_management”
Após executar os comandos, reinicie o serviço do RabbitMQ e os plugins já estarão em uso e a configuração do RabbitMQ estará finalizada.
Por padrão, é possivel acessar o painel de gerenciamento pelo seguinte endereço:
http://localhost:15672
Instalando/Configurando o Módulo Producer
Após instalação e configuração do RabbitMQ, siga as orientações.
Configuração d o ChassiSVC com o módulo Producer:
No mesmo servidor “AlwaysOn” onde o RabbitMQ foi instalado:
- Crie um pasta chamada “Sworks.Producer” com o conteúdo da pasta “SWorks.SVC” contida no pacote de instalação.
- 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="RabbitMQProducer" name="Serviço de Producer" assemblyname="SWorks.Orquestrador, Version=1.1.0.0, Culture=neutral, PublicKeyToken=5c21879e795ae678" typename="SWorks.Orquestrador.RabbitMQProducer" User="sworks" Password="sworks" MaxCount="4" Host="localhost" Port="5672" QueueName="Queue01" WaitSecondsOnNoTasks="5" WaitSecondsOnCaptureError="20" WaitSecondsOnEnqueue="10" />
O módulo Worker também deve ser instalado na forma de Windows Service do ChassiSVC.
Configurações necessárias
Para que esse módulo seja capaz de processar os itens da fila do RabbitMQ, 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.
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="RabbitMQConsumer" name="Serviço de Consumer" assemblyname="SWorks.Orquestrador, Version=1.1.0.0, Culture=neutral, PublicKeyToken=5c21879e795ae678" typename="SWorks.Orquestrador.RabbitMQConsumer" User="sworks" Password="sworks" MaxCount="4" Host="localhost" Port="5672" QueueName="Queue01" WaitSecondsOnNoTasks="5" WaitSecondsOnCaptureError="20" WaitSecondsOnEnqueue="10" />
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.
Passos para configurar o módulo
Crie uma pasta chamada “SWorks.AcoesLote” com conteúdo da pasta “SWorks.SVC” do pacote de instalação.
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" />
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.
Ao inicializar, o módulo, atualizar a configuração
“URL_WS_DISTRIBUICAO_ATIVIDADES” automaticamente.
Certifique-se que a URL do Activity Dispatcher possui uma “/” no final. A falta dessa barra final pode acarretar em erro de conexão entre o módulo Web App e o Activity Dispatcher.
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”:
- Acesse o menu de configurações em Administração -> Configurações.
Crie/modifique a chave de configuração de nome “ARQUITETURA_BUSCA_ATIVIDADES_MANUAIS”
Atribua o valor “1” (sem aspas) para ativar a distribuição utilizando o módulo “Activity Dispatcher”.
O valor “2” indica que será utilizado busca direta usando banco de dados.
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.
- Periodicamente, o Service Discovery irá “pingar” o serviço através de uma URL de health-check disponibilizada pelo módulo registrado.
- 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>"
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.
Funcionalidade
Configuração do arquivo appsettings.json
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.
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”,
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.
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 e 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.
- Abra o arquivo de configuração de logs “ChassiSVC.dll.log.config”.
- Em cada appender configurado, procure pela tag “conversionPattern”.
- Atribua o seguite valor no campo “value”:
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%date [%thread] %-5level %logger - [Processo|%property{processo}] - %message%newline" />
</layout>
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.
Configurações do Prometheus
A instrumentação do S-Works prepara métricas para serem extraídas no formato de leitura da ferramenta Prometheus.
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
Para informar ao Prometheus a localização desse arquivo:
Essa configuração dirá ao Prometheus que obtenha os endpoints de métricas utilizando o arquivo gerenciado pelo Service Discovery.
Isso se Devido à dinamicidade de instâncias em execução do S-Works, quando implantado de forma clusterizada e utilizando recursos de auto-scaling, a configuração de endpoints de scrape precisa ser constantemente atualizada pelo Service Discovery. Dessa forma, o Prometheus sempre estará coletando as métricas das instâncias/módulos em execução.
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.
Instruções
- Abra o arquivo de log do módulo desejadado.
- Adicione o seguinte “appender”
Adicione o seguinte “appender”
<appender name="GelfHttpAppender" type="Gelf4net.Appender.GelfHttpAppender, Gelf4Net.HttpAppender">
<url value="http://localhost:12201/gelf" />
<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>
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.
Configure os campos adicionais a serem registrados na tag “AdditionalFields”.
Essas tags permitem com que tais campos sejam utilizados como filtros de pesquisa.
O exemplo acima contém, no padrão de conversão (conversion pattern) as iniformações do processo em “[Processo|%property{processo}], porém essa iniformação só é exigida para a configuração do appender do módulo Orquestrador(Worker).
Respeite padrões para nomenclatura dos campos “Ambiente” e “Modulo” para facilitar a pesquisa.
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.
As pastas dos módulos, no pacote de release, contém arquivos com sufixo ".template" contendo exemplo de configuração. Esses arquivos podem ser clonados, removendo o sufixo, para serem usados como referência de configuração.
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.
Só utilize o instalador caso todos os módulos já estejam pré-instalados e configurados, ou para realizar a geração do script de migration na primeira etapa do instalador.
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
Orientar 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.
Figura 1 - Validar se a versão apresentada bate com a versão instalada.
Verifique a abertura do site.
- Realize login com o usuário.
- Acesse algumas telas principais, como, monitorar processos, detalhes de processo, edição de workflow.
Módulo Web Api
- Solicite ao cliente que invoque sua integração com o sistema.
- Verifique a criação de processos, dados de entrada, documentos.
- Verifique inicialização do processo, ou seja, passagem de status NOVO para PENDENTE.
Módulo Distribuidor de Atividades (Activity Dispatcher)
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 - Arquivo de log do ActivityDispatcher
Como usuário no site, teste a distribuição de atividade manual.
Módulo Orquestrador (Producer)
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.
Orientações Gerais
Em todos os módulos do sistema, verifique a presença de erros nos logs após a implantação.
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í 2 módulos avulsos implantados no ambiente de produção que são responsáveis por processar a integração de propostas no sistema.
Figura 7 - Página inicial do módulo Funcao.WS
Related Articles
S-Works - Manual de Instalação da Versão 2.0 - v2 2 1
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, ...S-Works - Manual de atualização
Este documento possui informações e passo-a-passo para a execução da atualização do sistema S-Works em ambiente On-primese(ambiente aos cuidados da Contratante). Em ambientes On-cloud(ambiente aos cuidados da Contratada) este procedimento é realizado ...Novidades da Versão S-Works 2.3
Objetivo Este documento, tem como objetivo, apresentar melhorias e as novas funcionalidades implementadas na Versão S-Works 2.3. Resumo das novidades Criação de perfil personalizado: Agora você poderá criar perfis e configurá-los de acordo com a sua ...S-Works - Manual de Instalação da Versão - v2 4
ATENÇÃO, ARQUIVO ORIGINAL EM PDF ANEXO Sumário Versionamento 3 1. Objetivo 4 2. Dependências 4 3. Preparação do Ambiente e Backup 4 Download de Release, Backup e Licenciamento 4 Limpeza de Instalação Anterior 5 4. Os ...Novidades da versão S-Works 2 4
1. Verificar qualidade do arquivo de imagem CÓDIGO: 92966 Novo método na API Core com objetivo validar a qualidade da imagem. Essa parametrização tem como característica garantir que a imagem que está sendo importada para S-Works possui a quantidade ...