# Propostas para o cenário de update

## Proposta 1 - Retornar objeto completo no POST, controlável por um header no Router
Nesta proposta, as seguintes modificações seriam necessárias:

### WEALTHSYSTEMS
- O integration Router deverá possuir um header para controle da possibilidade de mostrar/não mostrar o objeto inserido no MasterCRM na response da ação de *CREATE*/*UPSERT* para novos registros:
- Header
- Integration-Response
- Valores suportados:
- *full*: retorna o equivalente ao GET do registro inserido
- *minimum*: Retorna somente os atributos id, createdAt e updatedAt
- Ao omitir o header, o response retornado será equivalente a opção *minimum*
- As APIs de integração precisam receber esta informação do Integration-Router para que possam controlar o retorno das ações de *CREATE* e *UPSERT* para novos registros;
- Ação de update (PATCH) não realiza inserção de registros;
- Para inserir, deve-se fazer uma requisição com a ação de create (POST);
- Para atualizar, a requisição deve ser feita com a ação de update (PATCH);
- Para remover registros da lista, deve-se usar a ação de delete (DELETE) no endpoint de manipulação de lista;

### TOTVS
- Enviar a request de atualização Connector->MasterCRM com o header "Integration-Response" de acordo com o nível de resposta necessário;
- Ao disparar uma requisição de ação create/upsert para um novo registro vindo do ERP com o header "Integration-Response:full", o Connector deverá ler este objeto que foi retornado no response e armazenar os IDs de todos os elementos presentes nas listas para poder atualizar o item do subrecurso futuramente;
- Ao ler registros criados e atualizados pelo MasterCRM via GET, deverá ser armazenado no Connector todos os Ids de subrecursos para permitir atualização futura Connector->MasterCRM;

#### Considerações sobre a proposta 1
- Existe um esforço feito de forma conjunta;
- Para o piloto, poderá ser necessário comunicar o cliente que algumas entidades não poderão ser atualizadas pelo ERP, até que tenhamos esta abordagem implementada e testada;
- Resolve o problema a médio/longo prazo das atualizações via PATCH e nos dá fôlego para futuramente pensar em propostas para facilitar este cenário;

#### Estimativas
- WS: 30 h ( 2 h por endpoint + 4 h Integration Router + testes)

---

## Proposta 2 - Usar o external_id para operação específica para processamento de PATCH em subrecursos

Nesta proposta, as seguintes modificações seriam necessárias:

### WEALTHSYSTEMS
- Ao invés de usar o ID para fazer a atualização do item da lista nas requisições de ação update (PATCH), usaremos o atributo *externalId*

### TOTVS
- Informar em todos os diagramas **Connector->Master CRM** em requisições de PATCH, em subrecursos, os dados que identifiquem de forma única e exclusiva um registro da lista pelo campo *externalId*

### Exemplo:

`[
{ "op": "replace-by-external", "path": "/a/b/list-c/<external-id>", "value": "foo" },
]`

#### Considerações sobre a proposta 2

- Resolve apenas parte do problema, quando os registros são gerados pelo ERP.
- Não resolve o cenário de registros com listas gerados pelo MasterCRM (Ex.: Customer, User, Product);
- O exemplo abaixo demonstra que teremos falhas ao executar esta proposta:
- Um usuário do MasterCRM cadastra um cliente 'João' com 3 telefones;
- Connector lê o cliente 'João' do MasterCRM e os externalIds são enviados vazios (o externalId é gerado pelo ERP ou Connector);
- Connector envia o cliente 'João' para o ERP com 1 telefone;
- Connector recebe uma atualização do ERP do cliente 'João' com 1 telefone e o *externalId* do telefone populado
- Connector tenta usar o *externalId* do telefone do 'João' como chave, porém ao comparar o externalId com o MasterCRM, não dá match pois o externalId do item da lista do MasterCRM está vazio e isto resulta em inserção de informação do ERP e geraria duplicação dos registros no MasterCRM;

#### Estimativas
- WS: --

---

## Proposta 3 - A ação UPSERT ignorar provisoriamente campos não informados

Nesta proposta, as seguintes modificações seriam necessárias:

### WEALTHSYSTEMS
- Revisar todas as APIs de integração para que campos não informados na ação de upsert sejam ignorados, ou seja, não sejam modificados no MasterCRM;

### TOTVS
- Revisar os diagramas para que não mande dados de itens de subrecursos na operação de UPSERT sob risco de apagar registros inseridos pelo MasterCRM como telefone, email e endereço;

#### Considerações sobre a proposta 3
- Resolve somente a atualização do objeto principal como o exemplo da entidade User com relação a senha;
- Não resolve o cenário de atributos em lista como o próprio exemplo de user, onde existe uma lista de filiais ou então o exemplo de Customer com as listas de telefone, email, documentos e endereço;
- Ao mudar o comportamento do PUT dentro da opção de upsert acabaria infringindo as diretrizes da RFC:
- https://tools.ietf.org/html/rfc7231#page-26
- A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response
- https://tools.ietf.org/html/rfc5789
- The PUT method is already defined to overwrite a resource with a complete new body, and cannot be reused to do partial changes

#### Estimativas
- WS: --