[[_TOC_]] #Introdução #Convenção de Nomes ##Recursos Azure Para os recursos da Azure utilizamos a padronização conforme documentação oficial da Microsoft. Sugestão de nomes pode ser obtida aqui https://docs.microsoft.com/pt-br/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations ##Arquitetura de Referência Com relação ao desenho, alem do padrao dos resources, segue uma tabela abaixo com os padrões usados: |Sigla|Descrição| |-|-| |ENV | Ambientes como DEV, HMG, PRD| |Device | Dispositivo| |C2D | Cloud to Device: Envio do Cloud/Hub para o Device| |D2C | Device to Cloud: Envio do Device para o Cloud/Hub| #Descrição dos Fluxos ##1.0 - Register Devices Item responsavel pelo processo de Onboard dos dispositivos que farão conexão com o IOT HUB. Para cada dispositivo é necessário utilizar uma "connection string" específica ou no caso passar um atributo chamado [DeviceId] o qual é uma identificação única para o dispositivo dentro da plataforma. Como sugestão podemos ter: - Guid: Global unique identifier como por exemplo "559fe024-e48c-48ab-92fc-146d783df6e9" - Codigo: Pode-se atribuir algum numero sequencial como por exemplo: "1" - Nome Amigavel: Podemos padronizar e pensar em uma estrutura que seja legivel e compreensivel facilitando a identificação. Exemplo: "vale-suico-pool-23" Nesse caso poderia ser composto pelo [cliente] + [numero da piscina] O registro dos devices pode ser feito de diversas formas como: - Portal Azure: acessando portal, localizando o recurso "iot-ipoolcare-[env]", clicando em Iot Edge, link https://docs.microsoft.com/en-us/azure/iot-edge/how-to-manual-provision-symmetric-key?view=iotedge-2018-06&tabs=azure-portal%2Cwindows - Azure Iot Explore: baixando e instalando a ferramenta conforme link https://github.com/Azure/azure-iot-explorer/blob/master/README.md. - Usando utilitários de linha de comando: Exemplo: az iot hub device-identity create --hub-name {YourIoTHubName} --device-id MyDotnetDevice ##2.0 - [D2C] - Send Events/Telemetria Essa sessão trata dos eventos envidos do Device para o Cloud. Imaginando algum payload, com dados de temperatura, pressao, ph, etc, esses dados são encaminhados para o Iot Hub. No momento do recebimento é feito um SPLIT para garantir dois processamento. São eles: - 3.0 Enfileiramento - 4.0 Execução de uma Function ##3.0 - Fila: Azure Service Bus "sb-ipoolcare-[env]" Esse processo esta dividido em duas partes: ### 3.1 - Save device moviments - Queue "sbq-device-controls": So recebe as movimentações dos dispotivos. Eventos de CREATE, DELETE, CONNECT, DISCONNECT. Existe uma Function "func-ipoolcare-d2c-devicecontrol-[env]" ouvindo essa fila onde a recomendação é que persista em um "Database exclusivo" ou em uma tabela para controlar as informações desses eventos. Sugestao do Database "sqldb-device[env]" - Topic "sbt-telemetry": Recebe a telemetria propriamente dito, payload enviado pelo Device. Nesse tópico tem inicialmente 2 CONSUMERS os com os nomes ### 3.1 - Persistence - sub-persistence: Separei pensando na persistencia, em banco de dados. Function "func-ipoolcare-d2c-dataflow-[env]" Sugestao do Database "sqldb-telemetry-[env]" ### 3.1 - Alert and Notification - sub-notification: Separei pensando em notificacoes, baseado em alguma regra de negocio(banco de dados), avaliar/disparar notificações. Function: "func-ipoolcare-d2c-notification-[env]" Sugestao do Database "sqldb-notification-[env]" ##4.0 - [D2C] Function: Processamento "Near time" Essa é a segunda parte do **SPLIT** a qual pode, ou nao, tratar algumas requisições no momento em que elas chegam enquanto os dados sao enfileirados, persistidos e notificados. Crei pensando em dar algumas resposta "rapaida" ou executar algum processo mais imediato. Como por exemplo ir no **Banco de Dados** verificar alguma regra, executar algum calculo o mesmo responder algo pro device que originou a chamada. ##5.0 - [C2D] Parametrized command Processo utilizado onde através do ADMIN será possivel executar comandos direto no **Device**. Atraves do APIM, chamaremos um ApiApp que poderá, ou não, se conectar ao banco por conta de regras, e enfileirar os comandos em um Service Bus Queue "sbq-device-command". Após enfileiramento teremos uma Function "func-ipoolcare-c2d-devicecommand-[env]", tipo Service Bus Trigger, responsável por tirar da fila e caso necessário enviar as NOTIFICAÇÕES para uma nova fila ou DISPARAR no momento. No repositorio de codigo eh possivel analisar como implementar esse tipo de chamada bem como implementar um "callback" para saber se o dado foi ou nao recebido pelo Device. [https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/iot-hub/iot-hub-csharp-csharp-c2d.md] ##5.1 - Execution Command Notification Para alertar usuario sobre execução do comando, aconselho enfileiramento proprio ou para queue "sub-notification" para que use um mecanismo unico de notificação. #Databases Recomendado a organizar em Databases diferentes levando em consideração o contexto. Exemplo: **sqldb-device-[env]** Informacoes do dispositivo. Informacoes sobre o dispositivo como por exemplo conexao, disconexao, criação de novos devices, ou seja, tudo que estiver ligado ao **Device**. **sqldb-telemetry-[env]** Informacoes de **telemetria**. No caso todos os payloads das operações bem como tabelas de domini oque envolvam regras de negocio, parametrizacoes e afins. **sqldb-notification-[env]** Informacoes de notificações como por exemplo historico de envio de mensagens de sms, e-mail, templates e assim por diante. #Site Administrativo - ADMIN ##**Estatico** Caso o conteudo seja apenas estatico podemos utilizar um Blob Storage para os arquivos html, css, javascript. ##**Dinamico** No caso de ter linguagens de programação no backend, como por exemplo, java/php/asp.net, podemos utilizar um **Web App**. #Links Uteis ##SDK CSHARP https://github.com/Azure/azure-iot-sdk-csharp ##Segurança https://docs.microsoft.com/en-us/azure/iot-fundamentals/iot-security-deployment ##Exemplo de Codigo ###Cloud to Device https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/iot-hub/iot-hub-csharp-csharp-c2d.md