---
# System prepended metadata

title: Passos para teste de novas versões do data-catalog

---

# Passos para teste de novas versões do data-catalog

## Acesso ao tenant ambiente DEV Data Discovery
- url: http://dev.bdd.wssim.com.br:84
- userName: admin@totvscrm.com.br
- pass: totvscrm2k20
- company: datacatalog

## Passo 1 - Atualização do ambiente

### 1.1 - Executar o migration do serviço de negócio
- Executar a migration do serviço de negócio no tenant do datacatalog para atualizar o serviço de negócio

### 1.2 - Atualizar o serviço de negócio no rancher do ambiente
- Entrar em contato com as pessoas abaixo para solicitar a atualização da nova versão do serviço no rancher:
    - Everton Pedrolo
    - André Gros
    - Eduardo Squisatti
    - Hendric Cechinato
- Exemplo de serviços que podem ser necessários atualizar: midgard, heimdall, sales


### 1.2 - Inserir dados na tabela/atributo que foi liberado pelo serviço de negócio
- Para testar as modificações feitas pelo serviço, é necessário que tenha dados no atributo ou tabela.
- O BDD tem acesso apenas a registros que possuam o atributo external_id com valores.
    - Registros com external_id nulos não são lidos


### 1.3 - Passos para executar o migration no banco do datacatalog
- **Atenção:** O banco de DEV tem nomenclatura no padrão abaixo:
    - customer
    - product
- Em produção, os bancos tem nomenclatura no padrão:
    - db_customer
- Para o teste do script no ambiente DEV, substitua db_ por vazio;
- Executar o script de migrations pelo flyway:

Tenant: 14

> ./gradlew flywayMigrate -Pflyway.url=jdbc:postgresql://dev.bdd.wssim.com.br:5432/sales -Pflyway.user=wealthsystems -Pflyway.password=ws18012001 -Pflyway.table=schema_version -Pflyway.schemas=tenant_number --no-daemon

- Validar se não houve algum conflito de IDs na execução ou algum erro de constraint;

----

## Passo 2 - Validação visual
### 2.1 - Acessar o Data Discovery e criar um novo job de integração

   ![](https://i.imgur.com/NZkrB0P.png)

*Data Discovery > Data integration > Jobs*

### 2.2 - Dê um título para o Job de integração

Para facilitar futuramente o teste de integração, dê um nome ao job de teste. Exemplo: 

![](https://i.imgur.com/hrtlxDt.png)


### 2.3 - Selecionar a tabela modificada pelo migration na origem MasterCRM
Exemplo: *Opportunity - Opportunity*

### 2.4 - Selecionar "Analytics" como destino e criar um novo dataset

### 2.5 - Avançar para a tela de mapeamento
Nesta tela é possível validar visualmente se o campo/tabela nova ou alterada modificado pelo script da versão nova está presente no catálogo


### 2.6 - Validar os itens abaixo quanto a consistência

#### 2.6.1 - Se o tipo do campo está correto:
- Correspondente ao campo **field.data_type** no banco de datacatalog. Alguns tipos:
                - number:  ![](https://i.imgur.com/dtfzlfR.png)
                - timestamp: ![](https://i.imgur.com/vE4TwdA.png)
                - date:    ![](https://i.imgur.com/GbvSnEq.png)
                - text:    ![](https://i.imgur.com/GV93iJL.png)
                - boolean: ![](https://i.imgur.com/YmD7KQ2.png)

#### 2.6.2 - Se a restrição de not null do campo está de acordo com as necessidade da API de negócio: 
- Este controle é feito através do campo **is_nullable**:
	- **true** permite valores null;
	- **false** não permite null;
	- Campos do tipo not null aparecem com um símbolo * antes do nome do campo. Exemplo:
        -  ![](https://i.imgur.com/B0uMHAm.png)

#### 2.6.3 - Se o atributo for depreciado:
- Existe uma flag de controle na tabela field **is_deprecated**. Registros depreciados aparecem em cinza e tachado:
	- **true** para atributos depreciados;
	- **false** para atributos válidos;
	- Exemplo: ![](https://i.imgur.com/zbgO1Do.png)

#### 2.6.4 - Se o atributo teve uma breve explicação da sua função:
- Existe um atributo na tabela field chamado de **description** para que seja registrado brevemente sua função.
- Em tela, quando é passado o mouse em cima do atributo, a descrição aparece da seguinte forma:

![](https://i.imgur.com/kXzwzLp.png)


#### 2.6.5 - Se o atributo for do tipo array
- Se o atributo for do tipo lista, o tratamento também deve ser explicitado no script;
- O controle é feito no campo field.is_array:
    - **true** para atributos de lista;
	- **false** para outros tipos;
    - Em tela o campo do tipo lista é mostrado com os caracteres [] no nome do campo;

-------
## Passo 3 - Integração de teste da entidade alterada
Se todos os passos anteriores estão corretos, por último fazemos uma integração de teste para o analytics com a entidade afetada pela nova versão do migration do catalogo para validar se todos os atributos estão presentes no banco de dados;

#### 3.1 - Avance ao último passo do Job de integração e finalize

No canto direito da tela, finalize o job:

![](https://i.imgur.com/XWxSWUO.png)


#### 3.2 - Execute o job de integração

Após finalizado, pressione Run para executar o job:

![](https://i.imgur.com/bt8U4cs.png)


#### 3.3 - Valide os resultados

- Acesse a tela de logs de execução:

![](https://i.imgur.com/i0lE9zu.png)

- Veja os detalhes da integração:

![](https://i.imgur.com/6Miz2AW.png)

Se a execução aconteceu com sucesso, significa dizer que todos os atributos foram lidos da maneira esperada ;)

