Camada de serviços



Camada de Serviços ou Service Layer (SL) é a camada intermediária entre a apresentação e o armazenamento de dados. Ele abstrai lógicas de negócios e acesso aos dados. A ideia por trás dessa camada é ter uma arquitetura que possa suportar múltiplas camadas de apresentação e consumo de dados, como web, celular, etc. Isso proporciona um gerenciamento mais fácil, uma melhor abstração e escalabilidade, suportando um grande número e variedade de clientes simultâneos.

Você sabe o que é Service Layer?

Em conceito simples, ETL (Extract Transform Load), traduzindo Extração Transformação Carregamento, são ferramentas de software cuja função é extrair dados de diversas fontes, transformar esses dados conforme regras de negócio e por fim carregar esses dados.

Extração de dados de fontes externas

Em conceito simples, ETL (Extract Transform Load), traduzindo Extração Transformação Carregamento, são ferramentas de software cuja função é extrair dados de diversas fontes, transformar esses dados conforme regras de negócio e por fim carregar esses dados.

Transformação dos dados para atender às necessidades de negócios

O estágio de transformação aplica uma série de regras ou funções aos dados extraídos para derivar os dados a serem carregados. Algumas fontes de dados necessitarão de pouca manipulação de dados.

Carregamento dos dados

A fase de carregamento consiste na colocação dos dados em um novo local ou banco de dados.

Para utilização dos recursos disponíveis na migração de dados é prudente que o responsável pela execução de todos o fluxo tenha conhecimento da arquitetura de serviços REST com JSON e conhecimento em ETL;

Realizar o processo primeiro em ambiente de homologação, para posteriormente realizar em ambiente de produção;

No momento da carga final, se atentar aos dados já existentes na base Fly, para reduzir conflitos em dados comuns;

Realizar o envio em lote com o máximo de registro possível, agilizando assim o processo;

Criar uma automatização na rotina de análise dos retornos dos lotes, facilitando assim a análise necessária.


As ferramentas e técnicas necessárias para realizar esta tarefa ficam a critério dos responsável pelo processo de migração.

Aconselha-se que o processo de carga de dados siga o fluxo descrito abaixo, onde iremos descrever as atividades necessárias ao processo de carga, elencando os procedimentos que envolvem liberação, preparação de ambiente, migração de dados, homologação dos dados e carga final.

Lembrando que realizar o processo primeiro em ambiente de teste, para posteriormente realizar em ambiente de produção é uma boa prática e uma recomendação importante.

1 - Base de teste - Solicitar token à Betha Sistemas

Uma vez que os dados já estiverem na estrutura apropriada para execução dos serviços, é necessária a aquisição de um token juntamente ao setor de senhas da Betha Sistemas. É necessário ainda, que a entidade esteja liberada com as licenças dos produtos.

O token é uma chave formada por 32 algarismos alfanuméricos, organizados em grupos de 8, 4, 4, 4, e 12 dígitos. Ele tem como finalidade identificar a entidade e o banco de dados, na web, que receberão os dados migrados, inicialmente no processo de migração homologação e após para o oficial.

Exemplo de token: ga1499bb-bad8-4w63-9999-9aa000311g63

Atenção! Saiba que o token identifica a entidade e o banco web. Então cuidado ao solicitar e usá-lo, para que as informações não sejam migradas para a entidade e o banco errados, pois a correção é complicada e difícil de ser realizada, sendo responsabilidade do migrador realizar essa correção.

2 - Base de teste - Migrar dados

Com o token em mãos, fornecido pela Betha, é possível iniciar o processo de alimentação, que consiste na carga dos dados nos sistemas destinos. Esse processo pode ocorrer na forma de carga inicial, incremental ou a mescla das duas formas.

Para atender essas necessidades os Services Layers disponibilizam os métodos POST, GET, PUT e DELETE, bem como, o método PATCH para atualizações pontuais em alguns serviços.

  • POST - Realiza inserções de registros no sistema destino;
  • GET - Realiza uma consulta obtendo uma listagem de dados completa e paginada dos registros existentes na entidade.
        • GET passando o ID do Registro Web - Realiza a consulta do registro existente no sistema destino;
        • GET passando o ID do lote - Gera a visualização do resultado do processamento do lote enviado.
  • PUT - Realiza alterações do registro completo no sistema destino;
  • DELETE - Realiza exclusões de registro no sistema destino;
  • PATCH - Realiza alteração em parte de determinado registro existente no sistema destino.

Todos os dados deverão ser enviados em lote, para o qual será gerado um código único por sistema e retornado pelo serviço para posterior consulta. Com esse código em mãos é possível utilizar o serviço de consulta de lote para receber as informações com o status do lote e a situação de cada registro contido nele.

Atenção! A única forma de consultar o retorno de um lote é com o código do lote (idLote). Por esse motivo, esse código deve ser armazenado em sua estrutura de dados local.

Identificadores

O processo de migração irá retornar identificadores referentes aos dados migrados, os quais seguem descritos abaixo juntamente com seu significado.

  1. idGerado - Esse identificador contém o ID do registro gravado no sistema de destino (Fly/Cloud). Como exemplo é o código da pessoa ou o da despesa. Além disso, com esse ID, será possível atualzar informações por inteiro ou de forma parcial de algo já gravado no sistema de destino (Fly/Cloud).
  2. idIntegração - Identificador do cliente, dessa forma o processo de migração possibilita que seja enviado pelo analista de conversão o seu ID de identificação do registro nos dados de origem. Este iD não será registrado no sistema de destino, porém será retornado juntamente com as resposatar da consulta do lote;
  3. idLote - Identificador dos lotes que foram enviados aos serviços do sistema de destino;
  4. idExistente - Esse identificador contém o ID do registro já existente no sistema de destino (Fly/Cloud) quando o registro enviado está duplicando em relação a regra de negócio. Exemplo: quando enviado uma pessoa com um CPF já existente no sistem de destino, a consulta de lote apresentará um erro de duplicidade do registro e o código da pessoa já existente é retornado.

3 - Base de teste - Homologar dados migrados

Esta tarefa é uma das principais do processo de migração, pois neste momento é realizada a conferência e a validação dos dados migrados para a entidade web. Para realizar a conferência nos retornos dos lotes, utilize a URL de consulta de lotes do sistema migrado e o método GET passando o ID do lote.

Atenção! A URL e os dados utilizados no exemplo abaixo são meramente ilustrativos e com objetivo de facilitar o entendimento. 

Detalhes da resposta: 

  • statusLote - Indica o situação de processamento do lote incluindo todos os seus itens;
  • idIntegracao - Informa o identificador de cada integração enviada no lote, se informado;
  • satus - Exibe o situação do registro na integração enviada no lote;
  • idGeracao - Indica os indicadores dos cadastros criados na integração.

Realize a comparação das informações registradas em ambos os sistemas, conferindo se todos os dados estruturados (conforme tarefa "Extrair e estruturar dados") estão inseridos corretamente na base teste de conversão.

Efetue também a emissão de relatórios de fechamento em ambos os sistemas e compare-os. Por exemplo o balancete de verificação contábil.

4 - Base de produção - Solicitar token à Betha Sistemas

Uma vez que os dados foram carregados e homologados na entidade de teste, é necessário que os dados sejam carregados na entidade de produção.

Conforme informado no item 1 - Base de teste: Solicitar token à Betha Sistemas, obter novamente o token de carga agora direciona para a entidade web de produção que os dados serão carregados.

Atenção! Na solicitação do token à Betha Sistemas, é importante que seja informado e fique bem claro ao atendente, que a geração do token deve ser feita para a migração dos dados e para o banco de produção, ou seja, banco oficila do cliente.

5 - Base de produção - Migrar dados

Nesta tarefa é efetuado o processo final de todo o ciclo de carga de dados, ou seja, é o momento de enviar os dados para a base de produção do cliente, também denominado como base oficial.

Nesta fase todos os devidos ajustes já foram realizados durante o processo de homologação e neste caso, a necessidade é que os dados extraídos e devidamente preparados sejam migrados utilizando os serviços disponíveis com o token da entidade de produção obtido anteriormente.

É o desenvolvimento de dois ou mais produtos/sistemas empenhados em trabalhar em conjunto, onde a ação de um provoca reação no outro.

Hoje, um tipo de interação muito comum é a interação de dados, na qual o primeiro sistema processa algo e sua saída é enviada a um segundo sistema e esse, iniciará seu processo de execução ou armazenamento de dados para futura execução.