Conceitos do Integrador de Apps
Aplicativo: um serviço que é adicionado ao construtor e contém todas as entidades coletadas. É uma automação de "conexão" + "gatilhos" ou "ações". Na plataforma da Albato, está situado na lista de conexões à disposição do utilizador, com o nome de “apps”.
Ferramenta de Solicitação: um widget no qual a própria solicitação HTTP é configurada na API. São configurados a própria solicitação de saída, o analisador de resposta e o tratamento de erros para esta solicitação. Aparece em todas as entidades que fazem solicitações de API.
Conexão: o usuário final tem acesso ao aplicativo, com seus dados. Todos os dados inseridos durante a criação são salvos em uma conexão e são usados no futuro para construir solicitações de API. As conexões podem ser ilimitadas.
Autenticação: acontece após a criação do modelo de comportamento de autorização no aplicativo. Possibilita configurar quais parâmetros solicitar ao usuário ao criar uma conexão, para salvar esses dados na memória da conexão e depois transferi-los em todas as outras solicitações de API. O modelo de obtenção de tokens de acesso e sua renovação, se necessário, também é configurado.
Autorização: processo que ocorre após ser validada a autenticação, com a intenção de verificar se determinado usuário terá a permissão para utilizar, executar recursos ou manipular determinados dados
Campos de conexão: campos personalizados que são solicitados ao usuário final da Albato ao criar uma conexão com o aplicativo. Esses são campos que não estão diretamente relacionados à autenticação e podem ser usados em qualquer lugar. Por exemplo, pode ser um domínio ou subdomínio que o usuário especificará na conexão e o valor será salvo dentro da estrutura de sua conexão. Depois, o valor pode ser usado em todas as outras entidades, inserindo-o na URL de solicitação.
Gatilhos: uma entidade que responde ao evento desejado, dependendo das configurações. Quando ocorre o evento desejado, a automação é lançada, recebendo os dados deste evento e passando para as etapas de ações. Os gatilhos têm dois modelos de comportamento. O primeiro é o “Webhook”, no qual o gatilho é iniciado quando uma solicitação chega a uma URL específica e passa pelo filtro. Já o segundo é a “API”, cujo gatilho pesquisa independentemente o serviço por meio de solicitações HTTP a cada cinco minutos, recebendo uma lista de entidades novas e alteradas, bem como filtrando entidades adicionais por ID / Data de modificação (para não receber nenhuma duplicata em cinco minutos).
Ações: uma entidade que faz uma solicitação HTTP de saída para o serviço, de acordo com um determinado cenário (para uma URL específica com um corpo de solicitação pré-configurado). A ação ocorre depois que o gatilho é disparado no bundle e envia todos os campos preenchidos no pacote para o serviço.
Listas: listas dinâmicas (obtendo elementos por meio da API) ou listas estáticas, que podem ser posteriormente vinculadas a um campo de ação específico. Por exemplo, existe um campo “Status”, no qual você precisa inserir o ID do status exigido, mas os status e seus respectivos IDs são diferentes. A lista dinâmica permitirá obter o ID dos status do usuário final e nas configurações de ação o campo se transformará em uma lista. A lista também pode ser estática, com um conjunto específico de elementos.
Apanhador de Webhooks: entidade que se liga aos gatilhos com o comportamento “Webhook”. O catcher permite obter um Webhook de teste em uma automação com todos os parâmetros necessários e, para cada parâmetro, criar um campo de gatilho separado. Os valores desses parâmetros são transferidos para esses campos. É necessário quando o gatilho praticamente não tem nenhum conjunto de campos estáticos e toda vez é preciso obter diferentes campos.
Listas de campos personalizados: igual a listas regulares. Por meio da API temos uma lista de campos personalizados específicos. Esta lista é ligada a um gatilho ou ação e o usuário final consegue ver seus campos.
Seção de fileira: um conjunto específico de campos, que está em um grupo de objetos ([{}]), podendo vir em gatilhos e sair (ser despachado) em ações. A seção em si é um grupo concreto, e os campos da seção são aqueles que estão em cada objeto deste grupo. Ao adicionar uma seção de fileira ao gatilho, é possível acessar o evento junto à própria entidade e todo seu grupo anexado (por exemplo Produtos), no qual não há um conjunto estritamente definido de objetos.
Versão: estrutura do App integrado definida a partir da sua atualização.
Ferramenta de Solicitação: um widget no qual a própria solicitação HTTP é configurada na API. São configurados a própria solicitação de saída, o analisador de resposta e o tratamento de erros para esta solicitação. Aparece em todas as entidades que fazem solicitações de API.
Conexão: o usuário final tem acesso ao aplicativo, com seus dados. Todos os dados inseridos durante a criação são salvos em uma conexão e são usados no futuro para construir solicitações de API. As conexões podem ser ilimitadas.
Autenticação: acontece após a criação do modelo de comportamento de autorização no aplicativo. Possibilita configurar quais parâmetros solicitar ao usuário ao criar uma conexão, para salvar esses dados na memória da conexão e depois transferi-los em todas as outras solicitações de API. O modelo de obtenção de tokens de acesso e sua renovação, se necessário, também é configurado.
Autorização: processo que ocorre após ser validada a autenticação, com a intenção de verificar se determinado usuário terá a permissão para utilizar, executar recursos ou manipular determinados dados
Campos de conexão: campos personalizados que são solicitados ao usuário final da Albato ao criar uma conexão com o aplicativo. Esses são campos que não estão diretamente relacionados à autenticação e podem ser usados em qualquer lugar. Por exemplo, pode ser um domínio ou subdomínio que o usuário especificará na conexão e o valor será salvo dentro da estrutura de sua conexão. Depois, o valor pode ser usado em todas as outras entidades, inserindo-o na URL de solicitação.
Gatilhos: uma entidade que responde ao evento desejado, dependendo das configurações. Quando ocorre o evento desejado, a automação é lançada, recebendo os dados deste evento e passando para as etapas de ações. Os gatilhos têm dois modelos de comportamento. O primeiro é o “Webhook”, no qual o gatilho é iniciado quando uma solicitação chega a uma URL específica e passa pelo filtro. Já o segundo é a “API”, cujo gatilho pesquisa independentemente o serviço por meio de solicitações HTTP a cada cinco minutos, recebendo uma lista de entidades novas e alteradas, bem como filtrando entidades adicionais por ID / Data de modificação (para não receber nenhuma duplicata em cinco minutos).
Ações: uma entidade que faz uma solicitação HTTP de saída para o serviço, de acordo com um determinado cenário (para uma URL específica com um corpo de solicitação pré-configurado). A ação ocorre depois que o gatilho é disparado no bundle e envia todos os campos preenchidos no pacote para o serviço.
Listas: listas dinâmicas (obtendo elementos por meio da API) ou listas estáticas, que podem ser posteriormente vinculadas a um campo de ação específico. Por exemplo, existe um campo “Status”, no qual você precisa inserir o ID do status exigido, mas os status e seus respectivos IDs são diferentes. A lista dinâmica permitirá obter o ID dos status do usuário final e nas configurações de ação o campo se transformará em uma lista. A lista também pode ser estática, com um conjunto específico de elementos.
Apanhador de Webhooks: entidade que se liga aos gatilhos com o comportamento “Webhook”. O catcher permite obter um Webhook de teste em uma automação com todos os parâmetros necessários e, para cada parâmetro, criar um campo de gatilho separado. Os valores desses parâmetros são transferidos para esses campos. É necessário quando o gatilho praticamente não tem nenhum conjunto de campos estáticos e toda vez é preciso obter diferentes campos.
Listas de campos personalizados: igual a listas regulares. Por meio da API temos uma lista de campos personalizados específicos. Esta lista é ligada a um gatilho ou ação e o usuário final consegue ver seus campos.
Seção de fileira: um conjunto específico de campos, que está em um grupo de objetos ([{}]), podendo vir em gatilhos e sair (ser despachado) em ações. A seção em si é um grupo concreto, e os campos da seção são aqueles que estão em cada objeto deste grupo. Ao adicionar uma seção de fileira ao gatilho, é possível acessar o evento junto à própria entidade e todo seu grupo anexado (por exemplo Produtos), no qual não há um conjunto estritamente definido de objetos.
Versão: estrutura do App integrado definida a partir da sua atualização.
Atualizado em: 01/12/2022
Obrigado!