EuConquisto Composer MCP

### Evolução e customização #### 1. Implementação e Versionamento de Conectores Na plataforma, os conectores, sejam eles core ou customizados, desempenham papéis cruciais ao definir funcionalidades e fluxos específicos. A estrutura permite que tanto os conectores core, que representam funcionalidades principais, quanto os conectores customizados, que atendem a necessidades específicas dos clientes, coexistam e evoluam sem conflitos. O controle rigoroso de versão é mantido por meio da distribuição dos conectores como pacotes NuGet, garantindo um controle total e padronizado de suas versões. ##### **1.1. Controle de Versão e Ciclo de Vida** Os conectores, distribuídos como pacotes NuGet, seguem um ciclo de vida bem definido: **Versionamento Semântico**: A plataforma utiliza um sistema de versionamento semântico (MAJOR.MINOR.PATCH.BUILD), onde o número de build é incrementado a cada novo build gerado pelo DevOps. Em pacotes NuGet, o número de build é substituído por `-beta`. - **MAJOR**: Incrementado para mudanças significativas e incompatíveis com versões anteriores. - **MINOR**: Incrementado para adições de funcionalidades compatíveis com versões anteriores. - **PATCH**: Incrementado para correções de bugs que são compatíveis com versões anteriores. - **BUILD**: Número incremental gerado a cada build, representando o número de compilação da aplicação. **Pacotes NuGet**: Para pacotes NuGet, o número de build incremental é substituído por `-beta`, resultando em versões como `1.0.0-beta01`. Este diagrama ilustra o fluxo de versionamento utilizado para o desenvolvimento e integração de conectores core e customizados na plataforma. - **Branch `main`**: Representa a versão estável da aplicação que é disponibilizada em produção. Cada commit aqui recebe um tag de versão, seguindo o formato `MAJOR.MINOR.PATCH.BUILD`. - **Branch `develop`**: Usada para o desenvolvimento contínuo. Todas as novas funcionalidades e correções são integradas nesta branch antes de serem promovidas para a `main`. - **Projeto`conector_core`**: Exemplifica uma funcionalidade core existente em um conector. Onde sua utilização depende do uso padronizado da Interface Core. - **Projeto`conector_customizado`**: Exemplifica uma funcionalidade customizada em um conector. Integrações e endpoints externalizados não são manipulados pelo serviço. ::: mermaid gitGraph branch develop branch conector_core branch conector_customizado checkout main commit tag:"v1.0.0.0" checkout develop commit checkout main merge develop tag:"v1.0.0.1" checkout conector_core commit tag: "v1.0.0.1" commit tag: "v1.0.0.2" checkout develop merge conector_core checkout main merge develop tag: "v1.0.0.2" checkout conector_customizado commit tag: "v1.0.0.1" commit tag: "v1.0.0.2" checkout develop merge conector_customizado checkout main merge develop tag:"v1.0.0.3" checkout conector_core commit tag: "v1.0.0.3" checkout develop merge conector_core checkout main merge develop tag:"v1.0.0.4" --- **Detecção de Conflitos no Build**: O uso de bibliotecas como **Api.DigitalPages.Interfaces** e **Api.DigitalPages.Common.Data** garante que, se um conector não estiver em conformidade com as interfaces core, o erro será detectado durante o processo de build, impedindo a propagação de problemas para o ambiente de produção. **Ciclo de Vida Diferenciado**: - **Conectores Core**: São atualizados conforme a evolução da plataforma e seguem um ciclo de vida alinhado com as principais versões do produto. - **Conectores Customizados**: Embora possam ser adaptados às necessidades específicas de um cliente, são versionados e distribuídos como pacotes NuGet, garantindo que mudanças e atualizações sejam controladas de forma independente, sem afetar a estabilidade da plataforma principal, principalmente por não alterar qualquer interface core. ##### **1.2. Exemplo de Implementação de Conector Customizado** A seguir, um exemplo de como implementar um fluxo customizado utilizando um conector: ```csharp public class CustomConnector : IConnectorDataServerRequestV2, IConnectorICustomFlow { public Guid? ContextDirectoryUid { get; set; } public Guid? ContextProjectUid { get; set; } public Guid? ContextUserUid { get; set; } public Guid? ContextConnectorUid { get; set; } // Implementação da lógica de autorização dos fluxos public Task<List<IFlowEndpoint>> AuthorizedFlows() { var result = new List<IFlowEndpoint> { //... Endpoints aceitos pelo connector }; return result; } // Implementação do processamento das requisições public async Task<HttpResponseMessage> Process(IConnectorData userData, ServerRequestInfo requestInfo) { HttpResponseMessage result = null; if (requestInfo.Service == "webhook") { return // Fluxo personalizado } return new HttpResponseMessage(System.Net.HttpStatusCode.NotFound); } } ``` Nesta implementação: - **Interfaces Utilizadas**: A classe `CustomConnector` implementa as interfaces `IConnectorDataServerRequestV2` e `IConnectorICustomFlow`, que são definidas em **Api.DigitalPages.Interfaces**. Estas interfaces garantem a padronização e a integração com o restante da plataforma. - **Processamento de Requisições**: O método `Process` lida com requisições específicas, como "webhook", aplicando o fluxo customizado necessário. Caso o serviço não seja reconhecido, é retornada uma resposta de `NotFound`. ##### **1.3. Integração com o Serviço e Controle de Versão** - **Integração com Azure Functions**: Os conectores são integrados ao serviço principal, representado pelo Azure Functions. O serviço identifica o conector necessário e processa as requisições conforme as interfaces implementadas. - **Controle de Conflitos**: A estrutura de versionamento e a padronização garantida pelas bibliotecas da plataforma asseguram que as atualizações dos conectores core não gerem conflitos com conectores customizados. Além disso, como os conectores são distribuídos via NuGet, os clientes têm controle total sobre quais versões utilizam, permitindo uma gestão mais eficiente de compatibilidades. #### 2. Padronização e Evolução da Plataforma A plataforma foi projetada para suportar tanto a evolução natural das funcionalidades core quanto a introdução de customizações específicas dos clientes. Este design modular e padronizado facilita a manutenção, evolução e controle de qualidade, minimizando riscos de conflito e garantindo que todos os conectores, independentemente de sua origem, possam coexistir e ser atualizados de forma segura. - **Bibliotecas de Padronização**: - **Api.DigitalPages.Interfaces**: Contém todas as interfaces core utilizadas na plataforma. - **Api.DigitalPages.Common**: Oferece funções utilitárias para a plataforma core, como manipulação de JWT e operações de arquivo. - **Api.DigitalPages.Common.Data**: Implementa modelos base e wrappers que garantem a padronização do output JSON via API. - **Api.DigitalPages.DatabaseProvider**: Padroniza o setup e uso de dados salvos no banco, utilizando EntityFramework. - **Api.DigitalPages.Security**: Funções utilitárias para criptografia de conteúdo. - **Api.DigitalPages.Sdk**: Biblioteca em C# que simplifica o acesso aos recursos da plataforma. #### 3. Considerações Finais Esta documentação fornece uma visão abrangente de como os conectores, sejam eles core ou customizados, são implementados, versionados e gerenciados na plataforma. Com um controle rigoroso de versões e uma estrutura padronizada, a plataforma está bem equipada para evoluir de maneira contínua e segura, atendendo às necessidades específicas dos clientes sem comprometer a integridade e a estabilidade do produto como um todo.