# Q&A
- Como e porquê a api bim é usada?
- Ela é utilizada como intermediário entre o sienge e a aplicação .net/react para busca, armazenamento e envio de dados. É acessada de forma remota (Drakkar). Serve como uma centralização do fluxo e controle de dados dos usuários;
- Ela busca e armazena do Sienge dados de obras, orçamento e tabela de referência, que ficam salvos num banco (mongodb) que fica na mesma rede. Os dados armazenados servem para centralizar e ter uma melhor performance nas buscas, e vincular uma obra à um modelo do Revit.
- A api cria e valida um JWT em todas as requisições quando o usuário informa dados de login do sienge corretos como basic auth.
- É possível fazer tudo que é feito na api bim dentro do projeto .NET?
- Na api é feita conexão com o banco, conexão/chamada para o sienge, lógicas de negócio (montagem da EAP, tratamento de erro, etc);
- As chamadas pro sienge podem ser adaptadas tanto quanto as lógicas de negócio como a montagem da EAP e o tratamento de erro.
- É possível utilizar um banco em arquivo, por exemplo SQLite ou SQL Server Compact, para a utilização local ou, possívelmente, manter um banco online que serviria para todos os clientes(esse ponto é discutido em "ponderações sobre a Api");
- Quais seriam os impactos no sistema caso a api fosse removida?
- Não será possível realizar o login;
- Não será possível listar as obras da empresa;
- Não será possível listar as unidades construtivas das obras;
- Não será possível atualizar a tabela de referência da obra;
- Não será possível baixar o orçamento das obras do Sienge;
- Não será possível adicionar novos itens à EAP de uma obra;
- Não será possível remover itens da EAP de uma obra;
- Não será possível se comunicar com o Sienge;
- Não será possível relacionar uma obra com um modelo Revit;
- Pontos levantados sobre a remoção da api e a adaptação, tanto com um banco local quanto com um banco online, estão no tópico "ponderações sobre a Api";
- Como o projeto .NET se comunicaria com o banco e qual banco seria, se o banco pode ser local?
- O banco seria um Sqlite ou SQL Compact, que são bancos em arquivo, a comunicação pode ser local utilizando o entity framework. Esses bancos seriam embarcados na aplicação, sendo executados durante a execução da instalação.
- Pode ser configurado para que o banco seja mantido mesmo se o plugin for desinstalado;
- Deve haver algum mecanismo que envie a auditoria do cliente local para o sienge (esta é uma possibilidade);
- Qual o tamanho do esforço e a complexidade da mudança caso seja possível?
- No mínimo, seria necessário:
- Reescrever os endpoints da api utilizados para salvar e buscar as informações do sienge no banco do plugin, isso seria feito provavelmente criando um novo projeto na solução .NETm utilizando WCF (Windows Comunication Foundation), que seria um serviço rodando junto à aplicação na máquina do cliente;
- Reescrever as lógicas que tratam os dados dos serviços da EAP, como criação da árvore de serviços e atualizações dos níveis da EAP, e as chamadas para o Sienge;
- Acrescentar a conexão com banco de dados local, isso envolve instalação de drivers e criação de uma nova camada na aplicação;
- Pensar em um mecanismo de auditoria para os dados internos do plugin;
- Pensar em um mecanismo de backup de dados
- Modificar o wizard de instalação do plugin para que não exclua o banco sempre que uma versão seja instalada/removida;
- Modificar o front para consumir das apis internas novas (WCF);
- Aplicar tratamento de erros melhor estruturado nas apis WCF.
- Quais apis do sienge são utilizadas pela api do plugin?
- **GET** - *https://api.sienge.com.br/{tenant}/public/api/v1/enterprises/?type={type}&limit={limit}&offset={offset}*;
- **GET** - *https://api.sienge.com.br/{tenant}/public/api/v1/building-cost-estimations/{buildingId}/sheets*;
- **GET** - *https://api.sienge.com.br/{tenant}/public/api/v1/building-cost-estimations/{buildingId}/sheets/{buildingUnitId}/items?limit={limit}&offset={offset}*;
- **PUT** - *https://api.sienge.com.br/{tenant}/public/api/v1/building-cost-estimations/{buildingId}/sheets/{buildingUnitId}/items*;
- **GET** - *https://api.sienge.com.br/{tenant}/public/api/v1/cost-databases/{project.costDatabaseId}/work-items?buildingTypeId={project.buildingTypeId}&offset={offset}&limit={limit}*;

#### Considerações sobre autenticação
- Atualmente é possível criar um usuário de api na interface do sienge e pode utilizar a senha gerada (com expiração e tudo mais) para se autenticar e utilizar os endpoints publicos do Sienge;
- O plugin Revit pede usuário, senha e subdomínio (tenant) para realizar o login. Então, a responsabilidade de montar a url para o Sienge utilizando o subdomain fica totalmente à cargo do plugin Revit (.NET). Também fica como responsabilidade do plugin passar o usuário e senha informados em toda requisição que for para as apis do Sienge, usuário e senha estes que devem estar no formato Basic Auth;

# Ponderações sobre a API

## Sem Api

### Com Banco Externo
1. Sem a api, todos os clients teriam que acessar o banco diretamente;
2. O banco ficaria exposto direto na internet, qualquer pessoa do mundo poderia bater direto na porta do banco;
3. Todos os clients teriam que guardar a informação de conexão com o banco;
- Problemas de segurança, se um cliente vazar informação, todos ficam vulneráveis;
4. Todas as validações teriam que ser feitas no client (validar chamadas ao banco e retorno de informação do mesmo);
5. Pode ser gerado um token no Sienge com a informação de userdomain para que o plugin verifique a expiração e o userdomain do token e faça as requisições com o userdomain correto;
8. Seria necessário trazer toda a lógica da Api para o plugin Revit (Montagem da EAP a partir da lista flat de workitens, etc);

OBS: Poderia ter uma solução de banco com uma instância do mongo para cada client. Cada client teria sua própria instância na nuvem do mongo db, cada um com seu próprio usuário e senha. Assim, o usuário poderia criar seus projetos, sair e entrar em outro pc e continuar montando o orçamento normalmente;

### Com Banco Local
1. Só consegue acesso ao banco durante a execução da aplicação;
2. Alteração de máquina requer que o operador selecione novamente o projeto com o qual a obra deve ser relacionada;
4. Com engenharia reversa qualquer um conseguiria pegar os dados do banco, mesmo com os dados criptografados, seria possível pegar a chave de criptografia e assim ter acesso aos dados do banco;
5. Possívelmente, seria necessário guardar no banco local apenas o orçamento e a tabela de referência;
7. Como o front em react iria se comunicar com o c#? Utilizar o WCF como um serviço para criar os endpoints de consumo do front em react;
8. Seria necessário trazer toda a lógica da Api para o plugin Revit (Montagem da EAP a partir da lista flat de workitens, etc);
9. Seria necessário manter o banco do cliente durante as atualizações, possivelmente seria necessário realizar o dump do banco e restaurá-lo novamente caso o banco morra quando fechar a aplicação (Ou se o banco estiver num SQlite, por exemplo, não seria necessário isso);
10. O banco local traz a possibilidade de o usuário deletar/desinstalar o plugin e o banco poderá ser perdido. Assim, teria que ser feita de outra maneira o tracking de utilização do usuário caso seja necessária a auditoria de funções/ações que não passem pelo consumo de Api do sienge (que já faz a auditoria atualmente);
11. Poderíamos tentar usar o MixPanel para fazer essa auditoria de ações não trackeadas pelo Sienge;
12. Com banco local deveria existir uma forma de realizar backups periódicos online para evitar total perda de dados.

## Possibilidade de melhoria
A fim de melhorar o consumo da Api de PUT do Sienge, enchergou-se a possibilidade da criação de um enpoint no Sienge para atualizar um único item da EAP, ou de pelo menos estrutura um pouco maiores que um item, ao invés da atualização utilizando o orçamento completo. O que acontece é que atualmente, para atualizar os dados de um orçamento via API, é necessário enviar um POST contendo todos os dados de orçamento para serem atualizados. Mesmo quando a necessidade é de atualização de apenas um serviço ou um item da composição de serviço, ainda é necessário enviar toda a estrutura da EAP do orçamento.
A possibilidade de atualizar apenas um item ou talvez até atualizar em estruturas maiores mas que não necessite de toda a o orçamento, diminuiria o payload de dados utilizado. Com um menor custo de processamento por parte dos servidores devido à menor massa de dados processados e um melhor desempenho de execução, resultaria numa melhor experiência de real-time' para o usuário.

## Referências

- [Plugin Revit](https://git-unic.softplan.com.br/bim9/plugin-revit)
- [Introduçãp ao WCF Macoratti](http://www.macoratti.net/09/09/net_wcf1.htm)
- [Tutorial da Microsoft sobre o WCF](https://docs.microsoft.com/en-us/dotnet/framework/wcf/how-to-host-and-run-a-basic-wcf-service)
- [Qual database devemos usar?](https://stackoverflow.com/questions/67127/database-functionality-with-wpf-app-sqlite-sql-ce-other)
- [Usando SQL Server Compact 3.5 Macoratti](http://www.macoratti.net/08/07/vb_sqlce.htm)
- [Comparação de performance SQLite e SQL Server Compact](https://www.diericx.net/post/benchmark-embedded-dotnet-databases/)

> sfsdf