Key | Ticket Movidesk | Summary | Documentation |
---|---|---|---|
| |||
| |||
Orion | Mensagem de retorno no login do Orion em caso de falha de comunicação com o Viasell |
Aprimorar a rotina de reset do serviço ResetServiceImpl do sistema Orion para garantir que, em caso de falha de comunicação com os serviços da Viasell, seja exibida uma mensagem informativa ao usuário.
2.1. Refatoração do Método realizaReset
private Reset realizaReset(String series, String mac) { String clientSeries = formatSeries(series); try { return makeRequestWithExceptionHandling(url, clientSeries, mac); } catch (Exception e) { logger.error("Erro na primeira tentativa:", e); return makeRequestWithExceptionHandling(url2, clientSeries, mac); } } private String formatSeries(String series) { if (NumberUtil.isInteger(series)) { return String.valueOf(Integer.parseInt(series)); } return series; } private Reset makeRequestWithExceptionHandling(String url, String series, String mac) { try { return restTemplate.getForObject(url, Reset.class, series, mac); } catch (ResourceAccessException | HttpClientErrorException | HttpServerErrorException e) { throw e; } catch (Exception e) { logger.error("Erro na segunda tentativa:", e); throw e; } } 2.2. Adição do Método handleValidationAndResponse
public ResetSerieMacTOResponse handleValidationAndResponse(SerieMacTO to) { try { reset(); boolean isValid = valid(); logger.info("Orion liberado"); return createResponse(isValid, "Orion liberado"); } catch (Exception e) { return handleException(e); } } 2.3. Métodos de Tratamento de Exceções e Criação de Respostas
private ResetSerieMacTOResponse createResponse(boolean hasSuccess, String message) { return ResetSerieMacTOResponse.builder() .hasSuccess(hasSuccess) .message(message) .build(); } private ResetSerieMacTOResponse handleException(Exception e) { ResetExceptionHandler resetExceptionHandler = new ResetExceptionHandler(e); String logMessage = resetExceptionHandler.getLogMessage(); logger.error(logMessage + ": " + e.getMessage()); return createResponse(false, logMessage); } 2.4. Introdução da Classe ResetExceptionHandler
public class ResetExceptionHandler { private final Exception exception; public ResetExceptionHandler(Exception exception) { this.exception = exception; } public String getLogMessage() { if (exception instanceof HttpClientErrorException) { return "Erro de comunicação com o cliente HTTP"; } else if (exception instanceof HttpServerErrorException) { return "Erro de comunicação com o servidor HTTP"; } else if (exception instanceof ResourceAccessException) { return "Erro de acesso ao recurso"; } else if (exception instanceof IllegalArgumentException) { return "Argumento inválido fornecido"; } else if (exception instanceof IllegalStateException) { return "Estado inválido encontrado"; } else if (exception instanceof ResetException) { return "Erro no reset"; } else { return "Erro geral"; } } } 2.5. Padronização da Resposta com a Classe ResetSerieMacTOResponse
@Data @Builder public class ResetSerieMacTOResponse { private Boolean hasSuccess; private String message; } 2.6. Ajuste no Controller para Utilizar a Resposta Padronizada
@PostMapping public ResetSerieMacTOResponse save(@RequestBody SerieMacTO to) { configuracaoService.save(Configuracao.builder().chave(ConfiguracaoChave.SERIE).valor("\"" + to.getSerie() + "\"").build()); configuracaoService.save(Configuracao.builder().chave(ConfiguracaoChave.MAC).valor("\"" + to.getMac() + "\"").build()); return resetService.handleValidationAndResponse(to); } Estas alterações visam melhorar a clareza e a especificidade na detecção de erros, fornecer feedback útil ao usuário final, e assegurar que o processo de reset seja robusto e de fácil manutenção, além de padronizar a resposta da API. | |
1.Menu Client Assistente 2.Objetivo Alterar a lógica do disparo manual existente dentro da plataforma 3.Alteração Agora o disparo manual funciona de forma síncrona, ao executar ele, o processamento acontece no mesmo momento e é devolvida a resposta dentro da aplicação. @SneakyThrows @PostMapping(value = "/manual", produces = MediaType.APPLICATION_JSON_VALUE) @ResponseBody public ResponseEntity<String> byManual(@RequestBody DisparoManualMeta disparoManualMeta) { Gson gson = new Gson(); Config config = configRepository.getOne(configRepository.getLastId()); String result = disparoAutomaticoService.executeManual(disparoManualMeta.id, disparoManualMeta.pdf).generateJson(); JsonObject jsonObject = webhookService.sendMessageToWebhook( config.getMeta_webhook_url(), result, true ); if (jsonObject == null) { JsonObject errorJson = new JsonObject(); errorJson.addProperty("message", "error"); return new ResponseEntity<>(gson.toJson(errorJson), HttpStatus.OK); } String json = gson.toJson(jsonObject); return new ResponseEntity<>(json, HttpStatus.OK); } Dessa forma o método requer um id (ID do menu a ser executado) e se é um disparo com arquivo PDF ou Imagem | |||
0 | 1.Menu Orion → Banco de Dados 2.Objetivo Criar feature que grava os logs do Orion no banco MySQL 3.Alteração O Orion utiliza o log4j2 para geração de logs, e todos os apontamentos e códigos estão sendo feitos para o banco h2, sendo tudo fixo nessa parte. Logo o que teve que ser feito foi a refatoração do log4j2.xml para um formato que consiga atender tanto os logs no h2 como no mysql, ai entra as peculiaridades de cada banco em si. Dessa forma teve que criar dois métodos o getDatabase e o getDatabaseLogs, pelo fato dos logs ter a possibilidade de funcionar no banco MySQL além do H2. <ConnectionFactory class="br.com.viasoft.orion.security.LogFactory" method="getDatabaseConnectionLogs" /> Um fato importante a se destacar que o Orion vai utilizar MySQL se ele encontrar as seguintes variáveis de ambiente
Após ele encontrar as variáveis ele vai tentar fazer um test-connection, caso encontre sucesso vai utilizar o MySQL para armazenar os logs, caso contrário vai utilizar o banco H2 para tudo. // Exemplo da iniciação da base Connection conn = LogFactory.getDatabaseConnectionLogs(); StringBuilder sql = null; try { boolean isH2 = true; if (conn != null) { if (conn.getMetaData() != null) { if (conn.getMetaData().getDatabaseProductName() != null) { isH2 = !conn.getMetaData().getDatabaseProductName().equals("MySQL"); } } } logger.info("Iniciando com base: " + (isH2 ? "H2" : "MySQL")); sql = isH2 ? sqlBuildH2() : sqlBuildMySQL(); Houveram diversas mudanças dentro do código, mas cabe ressaltar que todas tiveram o requisito principal em deixar os dois bancos funcionando ao mesmo tempo. Aqui é um guia descrito durante a tarefa para dar as instruções de como conectar os logs pelo MySQL no Orion, | ||
1.Menu Orion → Banco de Dados 2.Objetivo Realizar analise das difcildades para realizar a migração do banco H2 para MySQL 3.Alteração A analise foi feita seguindo duas princiapais vertentes: Primeira, foi analisada a migração que foi cancelada pela NextAge, através da branch/tarefa - OR-776Getting issue details... STATUS , pode se dizer que foi realizado bastante alterações no código já visando essa mudança de banco, foi coloado até migradores de dados dentro do orion-api, porém o projeto não foi para a frente, teve tarefa para correção de +20 erros, e muito na época não foi para a frente por causa do custo e de dificildades de migração e testes no projeto. Hoje a migração que foi feita na época não seria compativel com o código que temos no Orion hoje, pelo fato de muitos arquivos já estar dando coflito. Segunda, fiz uma analise pensando na grandiosidade no projeto do Orion e na confiabilidade e que os dados precisam ter, nesse sentido preciamos ter inúmeros testes de Checksum e de contas de números de registros antes de realizar qualquer migração. Visto isso seria necessário implementar classes que tenham função só de testar para verificar se o banco foi migrado 100% correto. Além disso temos alguns pontos principais também:
Todos esses pontos serão discutidos juntamente com o relator da tarefa Luciano César Ascari . Exemplificação gráfica: | |||
0 | Orion - Estudar forma de manter retrocompatibilidade entre banco H2 e MySQL | 1.Menu Orion → Banco de Dados 2.Objetivo Verificar se é possível deixar os dois bancos funcionando ao mesmo tempo 3.Alteração A solução para permitir que o Orion funcione com H2 ou MySQL envolve a configuração de uma flag que determine qual banco de dados será utilizado, detalhe que essa funcionalidade já foi utilizada para migrar os logs para o MySQL. Pelos estudos não vai precisar manter em .war diferentes, pelo fato de que não vamos ter informações fixas dentro do código-fonte do Orion, ele vai buscar as informações direto das variáveis de ambiente do sistema para verificar qual banco deverá usar. A principal dificuldade encontrada está nos repositórios e serviços que possuem SQL fixos. Para resolver isso, é necessário adaptar o código para que seja mais genérico, ou então, utilizar a API do Hibernate para evitar SQL nativo. Em casos onde o SQL nativo for inevitável, podemos parametrizar o banco de dados utilizado, exemplo: @Query(value = "SELECT * FROM ${tableName} WHERE id = :id", nativeQuery = true) Optional<Entity> findById(@Param("tableName") String tableName, @Param("id") Long id); Agora a análise de forma separada # Model Os models no projeto Orion representam as entidades do banco de dados. Como o Spring Data JPA abstrai grande parte das diferenças entre bancos de dados, o impacto nos models é mínimo, independentemente de você usar H2 ou MySQL. # Repository Os repositories são responsáveis por interagir com o banco de dados. A maioria das operações de CRUD são diretamente suportadas pelo Spring Data JPA, independentemente do banco subjacente. No entanto, desafios podem surgir ao usar queries SQL nativas, que podem diferenciar entre H2 e MySQL. # Controller Os controllers no Spring Boot geralmente não são afetados pelo tipo de banco de dados utilizado, uma vez que eles lidam principalmente com a lógica e encaminham solicitações para os serviços e repositórios. | |
1.Menu Orion → Dashboards → Filtro 2.Objetivo Analisar Bug que está acontecendo dentro das fonte de dados setando sempre a mesma data padrão não importa o que mudar 3.Alteração Primeiramente foi realizado uma atualização no cliente deixando o mesmo na última versão possível conforme a data vigente. Após isso comecei a depurar para verificar se realmente havia algum bug, e realmente não importava o valor que era colocado dentro do input ele sempre iria manter o valor inicial, isso tanto analisando atarvés de resultados de SQL, como parametros que o front enviava para o back. Então foi verificado que o cliente utiliza uma forma de elaborar relatórios que fugia dos padrões, afinal ele possuia filtros de valores variavies (Data atual, Primeira Data do Mês e etc) sendo assim os valores que o parametro enviava eram sempre os padrões pois no Orion não é possível fitlrar um filtro através de algum parametro não fixo. Conforme o esquema acima podemos verificar que o ID (DTIN, DTFI) no caso são os mesmos dentro dos filtros principais do que os filtros do filtro de Marca. Ou seja nesse caso acontecia o seguinte, por mais que era alterado os filtros do dash principal o Orion ia analisar todos e obter uma reposta padrão, e como não conseguia obter um simples resultado, ele pegava o valor padrão do parametro. Então a solução nesse caso foi tirar o filtro de data dentro do filtro de Marca, mas o que poderia ser feito também seria alterar o nome dos parametros dentro do filtro do filtro para outro valor que não fosse DTIN e DTFI e colocar um valor fixo. | |||
Orion - Bug ao colocar fonte de dados vinculado a "ASSUNTO" nos Agendamentos | 1.Menu Orion → Excel → Agendamento → Fonte de Dados por E-mail 2.Objetivo Verificar qual parte da Rotina está gerando erro e ajustar 3.Alteração Foi verificado que dentro do front o caminho estava tudo certo, as informações estavam sendo mantidas no banco: Porém o erro estava acontecendo na hora em que ele tentava buscar se a fonte de dados utilizado pelo relatório excel era a mesma que seria utilizada para gerar o parametro. Porém ele tentava fazer essa buscar, mas a informação da fonte de dados como assunto nunca era injetada, ou seja, sempre fazia uma comparação de algum ID comparando com null. private void setarAssuntoEmail(Excel excel, AgendamentoTarefa agendamentoTarefa) { agendamentoTarefa.setAssuntoEmail(""); if(agendamentoTarefa.getCampoParametroAssuntoEmail().equals("campo")) { List<FonteDadosResult> results = new ArrayList<>(); for (ExcelFonteDados fonteDados : excel.getDados()) { var res = fonteDadosService.executeAndReturn(fonteDados.getFonteDados()); if (res != null && !res.getList().isEmpty()){ // Adicionado fonte de dados em casos em que ela não retorna - TECD-2226 if (res.getFonteDados() == null && fonteDados.getFonteDados() != null) { res.setFonteDados(fonteDados.getFonteDados()); } results.add(res); } } this.setAssuntoEmailCampo(results, excel, agendamentoTarefa); } else { this.setAssuntoEmailParametro(excel, agendamentoTarefa); } } Além disso também foi retirado uma parte do código que fazia um replace de qualquer tipo de espaço que tivesse no assunto, pois foi visto que não era necessário e funcionaria normalmente sem aquilo. | ||
Fluxo de Caixa - Problemas em Functions ao utilizar via Docker | 1.Menu Orion → Fluxo de Caixa 2.Objetivo Verificar motivo e ajustar o porquê as functions não estão funcionando corretamente 3.Alteração Foi verificado que anteriormente as versões do Oracle não necessariamente precisam do ; no final da function/procedure para funcionar pois consideravam o end-of-file já suficiente, porém nas versões Oracle que estão sendo implementadas nos servidores da Cloud 1.0 e 2.0 precisam necessariamente da pontuação. Logo foi conferido todas as functions/procedures que não possuíam o ; após o END da procedure, e as que não possuíam eram a seguintes: DIAS_UTEIS_FLUXO_CAIXA ULTVALORMOEDA E ambas foram corrigidas e agora apresentam funcionando normal. | ||
0 | 1.Menu Orion → Fonte de Dados → Filtro 2.Objetivo Verificar se a situação que está ocorrendo no cliente se trata de um bug, e se caso, sim, deverá ser ajustada 3.Alteração Foi verificado que as configurações de “Limite” e “Limite de dados mostrados em tela” estava configurado muito errado conforme o número de dados que o filtro de itens exigia. O limite estava configurado em 500 (que não se trata nem de 100% da quantidade de itens que o cliente possuía) e no limite de dados mostrados em tela estava em 20, sendo assim ocasionava uma duplicidade de fatores dentro do filtro. Configuração realizada: Resultado do filtro após configurações: Da forma como que estava, como ele tem mais de 800 registros, ele gerava duas vezes até 500 (que era o limite estabelecido) ficando assim os registros duplicados, pois carregava duas vezes. | ||
API - Criar forma de mensagens serem formatas para se encaixar nas regras do Meta | 1.Menu Orion → Plugin Assistente 2.Objetivo Analisar quais as principais regras dentro dos message_templates que podem impactar e serem tratadas pelo própio Assistente 3.Alteração Tudo foi baseado na seguinte documentação: https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/ As principais regras encontradas foram as seguintes.
Logo foi realizado alguns tratamentos iniciais para validar se já funcionaria como o esperado e parava de dar os erros mais comuns, os tratamentos inicias foram a retirada do caractere pipe, os espaços em sequência e a quebra de linha: public String inMetaRules(String input) { //Remove quebras de linha String withoutNewLines = input.replaceAll("\\n", " "); //Remove mais de 3 espaços consecutivos String withoutConsecutiveSpaces = withoutNewLines.replaceAll("\\s{4,}", " "); //Substitua o caractere pipe por um espaço String withoutPipes = withoutConsecutiveSpaces.replaceAll("\\|", " "); return withoutPipes; } Esse método acima será acionado como tratamento antes de enviar qualquer mensagem de template. | ||
API - Criar tabela de referência de modelo (Modelo -> Template) para casos que pode haver banimento | 1.Menu Orion → Plugin Assistente 2.Objetivo Criar tabela de referência de templates conforme os nomes dentro do Meta 3.Alteração Conforme aconteceu durante os testes, nem sempre é possível utilizar nomes padrões para os templates padrões, anteriormente tínhamos essa referência abaixo, mas foi verificado que caso um desses templates seja banido leva 4 semanas para que o mesmo nome do template possa ser criado novamente, ou seja é necessário que os nome dos templates não seja fixos ao código. Tipo do Template | Nome do Template Texto | default Imagem | default_imagem Documento | default_document Por isso foi criado essa opção dentro da pagina inicial do assistente aonde o usuário pode configurar o nome do template para cada tipo de disparo (texto, imagem e documento). Lembrando que todos vem com o valor padrão que são os valores da tabela de referência acima, mas podem ser alterados a qualquer momento. | ||
0 | Plugins - Correção do plugin Ficha Cadastral Cliente (TURIM) | 1.Menu Orion → Plugin Ficha Cadastral → Personalizações 2.Objetivo Criar 3 novas branchs do projeto Ficha Cadastral, incluindo as personalizações feitas apenas em arquivos locais no cliente 3.Alteração Na branchs tiveram que ser corrigido alguns SQL que estavam com coalesce que eram aceitos no banco firebird, mas no oracle gerava erro: -- Exemplo de um caso -- Antes COALESCE(CONTAMOVATIVECON.A6HAPLANT, '') AS CULTIVADO, COALESCE(CONTAMOVATIVECON.A6PRODANUALSC, '') AS PRODUTIVIDADE, COALESCE(CONTAMOVATIVECON.A5FATBRUTOANUAL, '') AS VALOR -- Depois COALESCE(CONTAMOVATIVECON.A6HAPLANT, '') AS CULTIVADO, COALESCE(CONTAMOVATIVECON.A6PRODANUALSC, '') AS PRODUTIVIDADE, COALESCE(CONTAMOVATIVECON.A5FATBRUTOANUAL, '') AS VALOR Como o projeto foi migrado do 0 para o Linux, tivemos que adicionar vários endpoints que retornavam o stacktrace para saber o que está dando de errado dentro dos plugins, logo foi adicionado o seguinte código: // Apenas um trecho de uma exception mais genérica que o código pegava // Pegando o stacktrace inserindo em uma string e jogando para o navegador a resposta } catch (Exception e) { StringWriter sw = new StringWriter(); PrintWriter pw = new PrintWriter(sw); e.printStackTrace(pw); String stackTrace = sw.toString(); throw new Exception("Erro desconhecido ao gerar relatório: " + caminho + "\n" + stackTrace, e); Além de sql, teve que ser alterado algumas formas de caminhos, que são fixas dentro do projeto, como o cliente mudou de servidor de Windows para Linux teve que ser feitas algumas mudanças nesse sentido. // Antes report = "/reports/ficha_cadastral/FichaCadastral.jasper"; // Depois report = "/opt/Orion/webapps/ficha_cadastralothers/WEB-INF/classes/reports/ficha_cadastral/FichaCadastral.jasper"; Foi realizado também a mudanças das imagens dentro do template jasper, pois em todos os templates as imagens estavam com diretórios fixos do servidor Windows do cliente, sendo assim os arquivos .jrxml e .jasper tiveram que ser alterados. A parte do bower_components também não estava sendo extraída dentro do servidor Linux, pelo fato de não estar com o npm instalado, então foi inserido todo o bower_components dentro do próprio .war, sendo que o bower_components foi gerado na minha máquina, para evitar de instalar npm no cliente. Uma das mudanças também foi a mudança de forma de buscar arquivos pois o getResourceAsStream não estava funcionando como esperado, e logo foi trocado para o FileInputStream. // Essa parte do código também estava completamente errada, pois quando um arquivo não é encontrado ele gera um erro // E dessa forma que estava ele validava se era null // Lembrando que esse in se refere ao FileInputStream if (in == null) { throw new Exception("Arquivo do relatorio nao encontrado: " + caminho); } Houve também mudanças no sentido do objdc6 para o ojdbc8, e também a inclusão da nova lib que libera os plugins para se conectarem a https. Essas mudanças foram genericas e aplicadas em ambas as branchs, agora o que geralmente mudava de uma branch para a outra era os templates .jasper, e todos os arquivos que geravam de alguma forma o path que ela iria ser extraida dentro do sistema (Todos os arquivos estão descritos na Descrição) | |
1.Menu Orion → Viadecisor 2.Objetivo Corrigir a rota de upload que não está funcionando e implementar método para verificar tamanho do arquivo 3.Alteração Para corrigir foi utilizado para o form data as seguintes medidas: // Para utilizar o form-date no body: MultiValueMap<String, Object> // Setando configurando fixa nos headers headers.setContentType(MediaType.MULTIPART_FORM_DATA); Método verificador: private boolean canUpload(String filePath) { File file = new File(filePath); if (!file.exists()) { return false; } long fileSizeInBytes = file.length(); long fileSizeInMB = fileSizeInBytes / (1024 * 1024); return fileSizeInMB <= 50; } | |||
1.Menu Orion → Viadecisor (API Versão API Oficial) 2.Objetivo 3.Alteração 3.1 - 3.2 - 3.3 - 3.4 - | |||
0 | 1.Menu Orion → Viadecisor (API Versão API Oficial) 2.Objetivo Criar Enquete dentro do Assistente Meta 3.Alteração Foi criado uma nova rotina no assistente utilizando o WhatsApp Flows https://developers.facebook.com/docs/whatsapp/flows/ . Aonde dispara uma enquete para o usuário vinculado a disparo automático de texto, podendo ter qualquer texto dentro da mensagem desde que esteja dentro das regras da Meta, o template criado é um padrão que está dentro das documentações . Dentro do assistente foi criado um modal para verificar o resultado das pesquisas, e caso necessário todos os resultados estarão na tabela SURVEY_AUDIT | ||
1.Menu Orion → Viadecisor (API Versão API Oficial) 2.Objetivo Criação de algumas melhorias na nova API Meta WhatsApp solicitadas por clientes e analisadas internamente 3.Alteração 3.1 - Atualmente dentro do Asssitente todos os templates padrões são os relacioandos a marketing pelo fato de que são muito mais abragentes em questão do que pode ser enviado sem causar nenhum banimento ou má qualidade de algum modelo em especifico. Mas pelo fato de ser algo relacionado a Marketing ele tem um custo mais elevado em questão dos demais. Por isso foi criado uma rotina dentro do Assistente aonde poderá ser utilizado templates utilitários que reduzem o custo do disparo de U$ 0,0625 para U$ 0,035. Mas o contexto do conteúdo do disparo estar dentro desse contexto:
Para implementar basta executar esse diagrama no banco: ALTER TABLE MENU ADD META_TEMPLATE VARCHAR(255); COMMIT; Agora já dentro do assisnte é necessário configurar o nome do template criado através das rotinas da Meta no campo “Meta - Template de Utilidade”. Para a parte do Meta e até dentro do Assistente foi criada uma documentação completa para auxiliar em todos os casos de integração com templates de utilidade: Criação de Templates - Assistente Meta 3.2 - Essa funcionalidade já existia dentro da api antiga, aonde dentro do launcher tinha uma opção que desativava totalmente qualquer tipo de interação com o usuário que não fosse através de disparo automático. Também havia essa funcionalidade dentro da api, mas ela enviava uma mensagem caso o usuário mandasse alguma interação: Frase enviada:
Porém conversando com o Marcos Antonio De Santi Boneti ele deu ideia de utilizarmos essa mesma funcionalidade para o que já tinhamos no launcher da api antiga, que ele bloqueia todas as requisições de chat e conversasão que não seja através de disparo automático. Pois não há nenhum cliente que hoje envia essa frase, eles sempre desligam totalmente ou deixam totalmente habilitado, não existe meio termo nesse caso. Logo foi feito a migração, quando essa opção estiver ativa ele vai sempre enviar BAD_REQUEST para qualquer requisição vinda por Webhook para interação via chat. Exemplo de um dos tratamentos realizados: if (config.getEnvioaut_only() == 1) { return new ResponseEntity<>(HttpStatus.BAD_REQUEST); } | |||
1.Menu Orion → Viadecisor (API Versão API Oficial) 2.Objetivo Ajustar bugs que estão acotnecendo com alguns clientes nessa fase de validação do Assistente Meta 3.Alteração 3.1 - Nesse primeiro caso teve que ser realizada uma migração, anteiormente para o encerramento das sessões era utilizada a rotina de disparos automáticos (na api antiga), pois todo e qualquer tipo de agendamento gerava mensagens automáticas. Porém agora como todo disparo automático gera um custo elevador por mensagem para cliente, foi verificado a possibilidade de gerar e enviar essas mengens sem utilizar os model messages da Meta API. Ele funciona através de um cron que executada a cada minuto no segundo 0, pega a configuração atual, se caso verificar se não é pra deixar a api ligada ou até mesmo o cliente utiliza apenas disparo automático ele não vai fazer nada. Caso ele ignore essas duas condicionais ele irá verificar todos os clientes que estão há mais de 15 minutos com a sessão sem nenhuma interação e enviar a seguinte mensagem (finalizando a sessão). Vale ressaltar que agora essa mensagem não utiliza nenhum message template. “Por questões de segurança, encerrarei sua sessão agora. Para acessar o menu novamente, basta enviar um Oi." Além de enviar a frase, internamente ele vai fazer um update no banco, setando o cliente na etapa 5 (etapa para validar senha) e menu -1 (que seria o menu antes de todos). @Scheduled(cron = "0 * * * * *") @Transactional public void closeSessionsAfter15() throws Exception { Gson gson = new Gson(); Config config = configRepository.getOne(configRepository.getLastId()); if (config.getEnvioaut_only() == 1) { return; } if (config.getMeta_online() == 0 || config.getMeta_online() == null) { return; } MessageContainer messageContainer = new MessageContainer(config, messageAuditRepository, templateMessageRepository, false); if (config.getMeta_online() == 1) { messageContainer = chatService.sendWarningCloseSession(messageContainer); JsonObject jsonObject = webhookService.sendMessageToWebhook( config.getMeta_webhook_url(), messageContainer.generateJson(), false, false ); if (jsonObject == null) { System.out.println("API OFF"); } } } 3.2 - Através de testes, foi verificado que ele sempre mantinha a última imagem, pelo fato de não querer repetir a mesma frase durante todas as imagens do disparo, mas isso foi visto que era algo necessário. Formato Antigo: -------- -------- -------- Imagem 1 Imagem 2 Imagem 3 Texto -------- -------- -------- Formato Após correção: -------- -------- -------- Imagem 1 Imagem 2 Imagem 3 Texto Texto Texto -------- -------- -------- Único detalhe que validando muito bem essa parte após diversos testes, a meta não respeita muito bem uma ordem de envios conforme a ordem que é enviado para eles, dessa forma pode acabar desconfigurando a ordem de chegada das mensagens para o cliente, (sendo bem comum). Por esse motivo e outros relacionados a custo, seria muito mais vantojoso e melhor organizado seria utilizar o uso do template de documento invés de imagem. A comunicação com a Meta Cloud Api ela é de forma assincrona, sendo assim, todas as requisições que enviamos para eles é respondida com algum retorno de sucesso antes mesmo que qualquer mensagem seja enviada para qualquer que seja o destinatario. 3.3 - Sobre esse caso, ele já foi ajustado através da - TECD-1034Getting issue details... STATUS O cliente não deve estar com os últimos diagramas atualizados (código abaixo retirado direto dos diagramas do projeto): /* Alterações 12/07/2023 */ /* Antes de executar verificar e editar todos os decisores que estão cadastrados com 9 extra e modificar */ ALTER TABLE DECISOR MODIFY NUMERO VARCHAR2(10); COMMIT; | |||
1.Menu Orion → Viadecisor (API Versão API Oficial) 2.Objetivo Verificar se todos os problemas apresentados são bugs reais, ou se são bugs que acontece pelo fato do sistema ser Firebird, e se caso for encontrado algum bug deverá ser arrumado 3.Alteração 3.1 - Sobre os menu diretores, realmente havia um problema que não deixar o mesmo acessar nenhum menu, afinal a lógica ainda contia algumas especialidades que eram da api antiga, sendo assim todo número era cortardo os dois primeiros, mas nessa nossa api não precisa. Exemplo (554299822852): Tentava encontrar um decisor com o seguinte número: 99822852 Após novos tratamentos: 4299822852 3.2 - Realmente estava gerando um erro interno após o jasper não ser gerado, pois ele tentava enviar um arquivo não existente para o VsObjectStorage, aonde gerava um erro interno e não gerava nenhum resposta. Logo foi feito um tratamento para caso não houvesse dados ele não faz nenhuma comunicação VsObjectStorage e já devolve diretamente para o Webhook. 3.3 - Nesse caso parece ser uma peculiaridade do própria base firebird, pois em testes feitos com a base Oracle, o contato não cria nenhum registro caso não ache ele no banco, sendo assim necessário em debug maior no caso e verificar se deverá ser dado o suporte a bases firebird. 3.4 - Foi feito tratamentos nesse caso para que se caso não encontre a pessoa via SQL principal irá simplesmente abandonar qualquer decisão futura ao tentar gerar algum tipo de menu. | |||
API - Criar forma de não precisar criar as tabelas na mão, e tudo ser feito automático | 1.Menu Orion → Viadecisor → Criação de Tabelas 2.Objetivo Analisar formas de todos os diagramas serem criados de forma automática 3.Alteração Foi verificado como era feita a criação das tabelas em plugins como planejamento de safra e fluxo de caixa, e foi adptado para um que funcionasse para o viadeicsor. Dentro da classe ViaDecisorConfig na parte de Configuration foi importado uma lógica que verificar sql um por um para verificar se o script será executado: sqlTest = "SELECT * FROM ETAPA"; sql = "CREATE TABLE ETAPA (\n" + " ID INT NOT NULL,\n" + " TITULO VARCHAR(45) NOT NULL,\n" + " CONSTRAINT PK_ETAPA PRIMARY KEY (ID))"; if (verifyIfShouldExecute(sqlTest, jdbcTemplate)) executeSql(stmt, sql); Exemplo de lógica implantanda, mas temos vários INSERTS, MODIFY aonde somaram mais de 700 linhas de diagramas/testes. | ||
API - Alguns relatórios não estão sendo enviados através do agendamento e apenas disparo manual | 1.Menu Orion → Viadecisor → Disparo automático 2.Objetivo Verificar motivo da inconsistência estar acontecendo dentro dos agendamentos 3.Alteração O cliente relatou, e foi comprado via testes que o o mesmo disparo automático estava sendo disparado corretamente via disparo manual, mas quando ele estava agendado para algum horário especifico ele não era enviado. E através de debug no projeto foi verificado que todos os relatórios que não estavam com a tag “MULTIPLO” no banco habilitado, que significado que entraria para o sistema de fila não estavam funcionando corretamente. Isso se deu pela migração da ferramenta ser feita para duas api consumidoras diferentes: whatsapp-web-js e Meta. Logo foi implementado nova lógica entre os repositórios de disparo automático para que tenha métodos inpedentes para cada api, para que a lógica de um não possa influenciar de jeito nenhuma lógica do outro. O campo é o que está grifado em amarelo. | ||
0 | 1.Menu VsApi → Elasticserach → Vetorização de contextos 2.Objetivo Verificar as documentações e usar também a comunidade para verificar o que devemos implementar no nosso projeto com base nas vetorizações de contextos 3.Documentação Se entrarmos das documentações do ElasticVectorSearch https://api.python.langchain.com/en/latest/vectorstores/langchain_community.vectorstores.elastic_vector_search.ElasticVectorSearch.html é possível ver de cara uma mensagem de decaprated: Ele foi migrado para a ElasticsearchStore, aonde ficou muito mais completo agora, pois faz parte de um projeto langchain_elasticsearch invés de langchain_community. Sendo adicionado diversas funcionalidades como strategy, vector_query_field, query_field, distance_strategy. Mas de longe a melhor melhoria foi escolher a estratégia. Qual estratégia escolher? ApproxRetrievalStrategy (padrão) - Ela usa o algoritmo HNSW para realizar uma pesquisa aproximada do vizinho mais próximo. Esta é a estratégia mais rápida e eficiente em termos de memória. ExactRetrievalStrategy - Esta estratégia é usada para realizar uma pesquisa de força bruta / vizinho mais próximo exato via script_score (É uma funcionalidade do Elasticsearch que permite modificar a pontuação (score) de documentos durante uma pesquisa, usando um script personalizado. O script pode usar qualquer campo do documento para calcular a nova pontuação. Isso é útil quando você deseja personalizar a relevância de seus resultados de pesquisa com base em critérios específicos do seu aplicativo) SparseRetrievalStrategy - Esta estratégia é usada para realizar uma pesquisa de vetor esparsa via text_expansion (refere a técnicas usadas para expandir uma consulta de pesquisa com sinônimos, termos relacionados ou variações de um termo para melhorar a precisão e a abrangência dos resultados da pesquisa). Mas algumas coisas mudaram no sentido de busca de documentos, por padrão o ElasticsearchStore não da mais opção de colocar quantos números de documentos você deseja buscar, ou até mesmo o score que os documentos teriam que ter para aparecer dentro das buscas de indices, isso é feito automaticamente, mas se caso for necessário é possível utilizar o SelfQueryRetriever, que se trata de um auxiliador nesse sentido, mas nos meus testes não achei necessidade para usar o tal método. O próprio langchain não aconselha utilizar essa parte, resposta do próprio langchain.
Criação da POC: elastic_vector_search = ElasticsearchStore( es_connection=es_client, index_name=index, embedding=embedding ) llm = ChatOpenAI(openai_api_key=openai_api_key, temperature=0.5) chat_prompt = hub.pull("langchain-ai/chat-langchain-rephrase") history_aware_retriever = create_history_aware_retriever( llm, elastic_vector_search.as_retriever(), chat_prompt ) | ||
0 | 1.Menu VsAPI → Langchain → Prompt 2.Objetivo Verificar qual a estratégia de prompt está sendo mais utilizada nesse momento, considerando a latest do langchain 3.Alteração Anteriormente o prompt era gerado de uma forma bem manual, aonde através de uma string formatada era possível colocar algumas variáveis que mais para frente seriam preenchidas pelo langchain, exemplo: context, chat_history e input. E logo após isso chamávamos o PromptTemplate e indicavamos de forma manual quais foram as variáveis adicionadas e qual a variável de prompt utilizada. Forma que era utilizada: prompt_template = "Prompt: " + prompt + """ Context: {context} Chat History: {chat_history} User Input: {question}""" FINAL_PROMPT = PromptTemplate( input_variables=["context", "question", "chat_history"], template=prompt_template ) Atualmente o PromptTemplate já foi descontinuado, mas ainda há algumas semelhanças, pois usamos um método que seria o ChatPromptTemplate, mas nesse método ele já reconhece naturalmente todas as variáveis setadas automaticamente. # https://api.python.langchain.com/en/latest/prompts/langchain_core.prompts.chat.ChatPromptTemplate.html real_prompt = ChatPromptTemplate.from_messages([ ("system", f"{prompt}"), MessagesPlaceholder("chat_history"), ("assistant", "{context}"), ("human", "{input}") ]) Além disso, nessa nova forma, nós conseguimos configurar de onde está vindo cada uma das mensagens, ou seja, o contexto vem sempre do “assistant”, o prompt vem sempre do “system” e o “human” que vai perguntar alguma coisa entra como a última interação. Esse modelo de prompt é muito mais completo pelo fato que pode ser adicionada infinitas varáveis e diversas interações até a última ação, a qual seria a do próprio cliente, além de tudo isso o “chat_history” não entra categorizado nem como “assistant” e nem como “system” ele próprio faz esse controle. Além desse novo prompt é importante que ressaltar que agora temos um prompt que tem a função de auxiliar o retriever para gerar perguntas e respostas para ele mesmo.
E vendo através das documentações é possível construir um prompt, ou também podemos utilizar alguns que o próprio langhcian disponibiliza. def get_history_aware_retriever(llm: ChatOpenAI, vector: ElasticsearchStore): # Conforme as documentações do langhcain https://smith.langchain.com/hub/langchain-ai/chat-langchain-rephrase chat_prompt = hub.pull("langchain-ai/chat-langchain-rephrase") history_aware_retriever = create_history_aware_retriever( llm, vector.as_retriever(), chat_prompt ) return history_aware_retriever | ||
0 | VsIA Api - Verificar como pode ser resolvido LangChainDeprecationWarning | 1.Menu VsApi → Novas implementações considerando langchain 0.2.5 2.Objetivo Verificar todas as partes que estavam com o deprecated e transferir para as novas versões 3.Alteração Para executar o projeto antigo do VsApi ele já dava 3 erros de decrepeciado logo de cara o qual são os: 1. LangChainDeprecationWarning: The class `OpenAIEmbeddings` was deprecated in LangChain 0.0.9 and will be removed in 0.3.0. An updated version of the class exists in the langchain-openai package and should be used instead. To use it run `pip install -U langchain-openai` and import as `from langchain_openai import OpenAIEmbeddings`. ✅ 2.LangChainPendingDeprecationWarning: The class `ElasticVectorSearch` will be deprecated in a future version. Use Use ElasticsearchStore class in langchain-elasticsearch package instead. ✅ 3. UserWarning: ElasticVectorSearch will be removed in a future release. SeeElasticsearch integration docs on how to upgrade. ✅ 3.1 - Para instanciar um vector do Elastic sempre é necessário anexar uma estratégia de embedidgs que ele irá executar para analisar as documentações e responder conforme elas, e no nosso caso sempre era passado a OpenAIEmbeddings porém faz um bom tempo que o langchain os seus pacotes, agora temos langchain_openai, langchain_elasticsearch, langchain_community… E por isso foi alterado a lógica do Embedding, aonde ele faz parte de um pacote especifico da OpenAI, a sua implementação no geral não foi alterado e até deu suporte a passar a chave da openai_api_key como parâmetro (aonde antes não era possível). from langchain_openai import OpenAIEmbeddings # Por default usa o modelo de embedding: text-embedding-ada-002 # Por default o tamanho da chunck é 1000 (O qual é usado hoje nas estratégias de embedding) embedding = OpenAIEmbeddings(openai_api_key=openai_api_key) # ... 3.2 e 3.3 - O mesmo aconteceu com o ElasticVectorSearch, ele saiu do pacote inicial do elastic, aonde antes uma única lib do elastic dava suporte a toda estrutura, e agora é divida em submódulos, no geral essa refatoração teve mudanças em seus principais métodos e estrategias, mas ainda mantém sua função principal como vector. from langchain_elasticsearch import ElasticsearchStore import elasticsearch # Outra coisa que foi alterada nesse sentido foi que agora instanciamos uma conexão do elasticsearch de forma convencional # E só depois passamos para o vetor como parametro # Anteriormente o próprio vetor cuidava da conexão es_client= elasticsearch.Elasticsearch( hosts=elastic_full_url ) # Aqui em si ele mantém a mesma lógica no geral, recebendo um index de contexto, estratégia de embedding # Mas o seu uso mudou muito daqui para frente # https://api.python.langchain.com/en/latest/vectorstores/langchain_community.vectorstores.elasticsearch.ElasticsearchStore.html # Por padrão utiliza a estratégia ApproxRetrievalStrategy # Mas pode ser alterada para ExactRetrievalStrategy, ApproxRetrievalStrategy, or SparseRetrievalStrategy. elastic_vector_search = ElasticsearchStore( es_connection=es_client, index_name=index, embedding=embedding ) E uma principal mudança no ElasticserachStore, foi que agora após instanciar ele é possível fazer os embeddings utilizando ele mesmo através do método add_documents}}ou {{aadd_documents, aonde a única diferença entre eles é que um trabalha de forma síncrona e outro de forma assíncrona. Após essa implementação do langchain podemos utilizar o ElasticsearchStore para auxiliar na criação dos embeddings facilmente. Aqui está um exemplo aonde peguei um arquivo de texto e fiz o embedding em um índice específico utilizando as novas documentações. from langchain_text_splitters import CharacterTextSplitter import elasticsearch from langchain_openai import OpenAIEmbeddings from langchain_elasticsearch import ElasticsearchStore with open("windows.txt", encoding="utf-8") as f: windows_manual = f.read() text_splitter = CharacterTextSplitter( separator="\n\n", chunk_size=1000, chunk_overlap=200, length_function=len, is_separator_regex=False, ) metadatas = [{"document": "windows.pdf"}] docs = text_splitter.create_documents([windows_manual], metadatas=metadatas) es_client = elasticsearch.Elasticsearch( hosts=elastic ) embedding = OpenAIEmbeddings(openai_api_key=openai_api_key) elastic_vector_search = ElasticsearchStore( es_connection=es_client, index_name=index, embedding=embedding ) elastic_vector_search.add_documents(docs) # Em poucas linhas uma estratégia de embedding muito útil | |
0 | 1.Menu VsAPI → Segurança 2.Objetivo Alterar parte de segurança da API 3.Alteração Foi retirado todo e qualquer tipo de autenticação que havia dentro da api | ||
VsIA Api - Criar sistema de memória interno dentro do langchain com elasticsearch | 1.Menu VsIA Api → Histórico de Mensagens 2.Objetivo Criar um fork de uma biblioteca que já faz integração com histórico de chats com langchain e elasticsearch 3.Alteração Nesse sentido foi verficado que a biblioteca do elasticsearch atendia parcialmente nossas demandas, logo foi realizada uma adptação e refatoração do código deles para conseguir servir a nossa demanda. O langchain possui o método ElasticsearchChatMessageHistory que se trata de uma classe que faz a criação de uma conexão com o elasticsearch e além disso é possível adicionar mensagens e visualizar as mensagens no histórico. Mas para o nosso uso nós precisávamos conseguir odernar as mensagens, além disso limitar a quantidade delas. Por isso foi criado realizado as modicações no ElasticsearchChatMessageHistory e agora ele é o VsApiChatMessageHistory. Métodos: def teste(): # Para instaciar o método preciamos inserir algumas informações # Nesse caso temos que colocar a url, username, password do servidor do elastic # E também temos que passar o index (Indice que irá armazenar o histórico) # e o session_id (que se trata da memoria do usuario naquela especifica sessão/chat) history = VsApiChatMessageHistory( es_url=url, es_user=username, es_password=password, index=index, session_id=session_id ) # Também podemos adicionar uma mensagem humana, que no caso seria o input do usuario history.add_human_message("Olá me chamo Lucca") # E também podemos adicionar uma mensagem de IA, que seria a resposta do bot history.add_ia_message("Olá Lucca, como posso te ajudar?") # Através desse método conseguimos descrever se queremos a ordem das mensagens de forma # crescente ou decrescente, e também podemos limitar a quantidade de mensagens que queremos # deve ser usar desc para ordem decrescente e asc para ordem crescente last_four_messages = history.messagesLimitedBy('desc', 4) # E temos um método que retorna as mensagens de forma alternada # Dessa forma sempre teremos human, ia, human, ia, human, ia... order_messages = history.alternate_messages(last_four_messages) | ||
0 | VsIA Api - Confeir as versoes do OpenAI considerando as versões compatíveis com o langchain | 1.Menu VsIA Api → OpenAI 2.Objetivo Verificar versão da OpenIA 3.Alteração Anteriormente nas versões do langchain tínhamos que fazer um combinado entre a versão do langchain com a versão da OpenIA para que as bibliotecas pudessem funcionar corretamente em conjunto. Mas parece que dentro dessas novas versões do langchain o próprio langchain criou um pacote nele mesmo para fazer a gestão das versões e chamadas com a OpenIA. >> langchain==0.2.5 >> langchain-openai==0.1.9 No caso ao baixar através do pip install langchain ele já puxara a latest da openai juntamente com ele, ou seja não precisa de implementações e grande pesquisa para funcionar. | |
0 | 1.Menu VsRel - Gerador de relatórios 2.Objetivo 3.Alteração | ||
1.Menu Webhook Assistente Meta 2.Objetivo Criação de rotas para o caminho reverso Webhook → Client 3.Alteração A rota POST no /webhook foi criada com o intuito dessa comunicação recebendo um objeto chamado "mesages" que deve ser processado dentro do Assistente: @api.post("/webhook") async def whatsapp_webhook(request: Request): try: body = await request.json() # https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/payload-examples#text-messages if 'entry' in body and isinstance(body['entry'], list) and body['entry']: if 'changes' in body['entry'][0] and isinstance(body['entry'][0]['changes'], list) and body['entry'][0]['changes']: if 'value' in body['entry'][0]['changes'][0] and 'messages' in body['entry'][0]['changes'][0]['value'] and isinstance(body['entry'][0]['changes'][0]['value']['messages'], list) and body['entry'][0]['changes'][0]['value']['messages']: if 'metadata' in body['entry'][0]['changes'][0]['value'] and 'phone_number_id' in body['entry'][0]['changes'][0]['value']['metadata']: phone_number_id = body['entry'][0]['changes'][0]['value']['metadata']['phone_number_id'] from_number = body['entry'][0]['changes'][0]['value']['messages'][0]['from'] message_body = body['entry'][0]['changes'][0]['value']['messages'][0]['text']['body'] res = await verify_message_owner(phone_number_id, from_number, message_body) except Exception as e: print(e) return JSONResponse(content="", status_code=200) Ele faz uma verificação para ver a mensagem é uma mensagem de texto que se encaixa dentro das mensagens de payload-examples da própria documentação da meta e logo após isso faz a seguinte rota: → Requisição dentro do Redis para verificar o pertencente do phone_number_id → Login no Orion para pegar o access_token → Requisição para o Assistente para verificar se tem alguma resposta válida para o número solicitante → Assistente irá enviar uma requisição direta para o webhook para continuar o fluxo comum … Além disso é necessário que seja feito uma configuração de resposta dentro do plataforma Meta: Configurar uma URL de retorno de chamada e um token verificador, além disso também é necessário configurar os campos do Webhook nas versão v19.0 | |||
Verificar motivo no conversation de estar recebendo respostas em dobro | 1.Menu Webhook Assistente Meta 2.Objetivo Verificar motivo do Assistente estar repetindo mensagens 3.Alteração Foi verificado que o Assistente de Personalizações estava repetindo todas as mensagens conforme o print abaixo: E como foi verificado na - TECD-2135Getting issue details... STATUS a meta sempre irá enviar a requisição para todos os webhooks configurados não importando o aplicativo. E acontecia o seguinte cenário: Como as duas API, tanto a Blue como a Red estavam configuradas no mesmo link de webhook as duas batiam e eram respondidas já que ambas eram direcionadas a aplicações igual (Orion). Logo a solução será o seguinte, quando tivermos mais de um número dentro de uma mesma conta meta elas deverão utilizar links diferentes, nesse caso uma está configurada no /webhook e outro no /webhook2 | ||
Verificar motivo de sempre estar recebendo POST de outros números cadastrados na mesma conta VIASOFT | 1.Menu Webhook Assistente Meta 2.Objetivo Verificar motivo de estar recebendo POST de outros aplicativos dentro do meta 3.Alteração Foi verificado que isso se trata de um comportamento padrão da Meta, todo número cadastrado dentro da plataforma está ligada a todos os aplicativos os quais tem permissão (mesmo que não seja necessariamente o número principal do aplicativo). Esboço de forma de funcionamento: | ||
1.Menu Webhook Assistente Meta API 2.Objetivo Implementar banco de dados de cache para poupar tempo entre requisições e manter salvo a url para responder parte da conversation 3.Alteração Para implementar de banco de dados foi utilizado o Redis, pelo fato da sua fácil instalação, utilização e a praticidade que traz um banco NoSQL. No caso do webhook temos uma classe que funciona como um gerenciador do Redis, apresentando métodos de update (com possível tempo de expiração), get, delete e etc. A sua utilização se dá pelo fato do fato de termos que mandar update de resposta para a api do Assistente que ficará dentro do Orion, e para isso precisamos fazer login dentro da platafaorma e precisamos de dados como: URL do Orion, Usuário Administrador e Senha do Administrador. Essas informações ficaram salvas após a primeira a requisição e serão atualizadas caso necessário. Além disso como é necessário fazer o login no Orion sempre a cada update necessário, foi desenvolvido métodos que armazenam o access_token do Orion por um tempo de validadade dentro das diretrizes do OAuth , e tempo as senhas são armazenadas dentro da criptografia que o Orion utiliza. Guia de documentação do Redis utilizado: https://redis.io/docs/latest/operate/oss_and_stack/install/install-redis/install-redis-on-windows/ # Schema NoSQL ''' phone_number_id -> orion_url||admin||senha webhook||phone_number_id -> webhook_url Usando double pipe como separador ''' | |||
Forma de cadastro da API já saber o endereço caso seja apenas conversation | 1.Menu Webhook e Viasoft Assistente 2.Objeitvo Criar Rotas para comunicar inicialmente antes de qualquer interação possível para que o webhook saiba qual rota deve responder 3.Alteração Foi criado primeiramente uma rota dentro do Webhook para que ela faça o salvamento das informações inciais e já validar se a conexão com o Orion vai funcionar corretamente. POST /assistente/configuration Body: { "config": { "phone_number_id": "string", "token": "string", "webhook_url": "string", "verify_token": "string", "orion_url": "string", "orion_user": "string", "orion_pass": "string" } } E requer uma authorization basic fixa que está dentro de ambos projetos, Webhook e Assistente Meta. E dentro do Assistente, foi criado um botão dentro do modal de configurações, aonde quando apertado faz uma request sincrona, aonde já devolve ali mesmo um alerta se a configuração foi feita com sucesso ou se ocorreu algum erro interno, ou até mesmo algum erro de configuração. Lembrando que é importante preencher todos os campos antes de apertar o botão. E o botão pode ser apertado quantas vezes for necessário, afinal não cria registros novos apenas atualiza os já existentes. | ||
1.Menu Webhook WhatsApp Meta API 2.Objetivo Verificar melhor versão de api para utilizar e quais rotas de mais fácil utilização 3.Alteração Para integração foi utilizado a mais nova versão atualmente da api v19.0 https://developers.facebook.com/docs/whatsapp/cloud-api/reference/messages#mensagens-de-texto Exemplos de body ja formatos em python que estão sendo utilizados na API: ## Body para imagens return { "messaging_product": "whatsapp", "recipient_type": "individual", "to": f"{from_number}", "type": "template", "template": { "name": f"{type.replace('-', '_')}", "language": { "code": "en" }, "components": [ { "type": "header", "parameters": [ { "type": "image", "image": { "link": f"{unquote(file_link)}" } } ] }, { "type": "body", "parameters": [ { "type": "text", "text": f"{content}" } ] } ] } } Além disso foi criados métodos que leem o objeto MessageContainer vindo do Java e divide as informações entre body, link e headers para serem enviado para a Cloud Meta API. | |||
1.Menu Webhook → Assistente Meta Api 2.Objetivo Criação de padrão de resposta para erros e respostas coerentes vindo da api meta e outros possíveis erros de comunicação 3.Alteração Primeiramente foi criado um código que analisa o comportamento da resposta vindo da api da meta conforme a tabela oficial de erro de deles, dessa forma é pego o código do erro e o erro que vem em Inglês e bate no código e traz uma resposta em português do erro, formas de solução e tudo mais. Caso também a resposta for positiva ela passa por uma analise para verificar se realmente foi positiva e retorna. A resposta se baseia em duas principais formas, aonde ambas mostram a resposta individual por id de todas as mensagens enviadas pelo array dentro do body, e além disso caso aconteça outro erro de comunicação no redis, orion ou na api da meta. O status é como é definido se o disparo deu certo (accepted ou rejected), exemplo: { "1": [ { "status": "accepted", "meta_response": { "messaging_product": "whatsapp", "contacts": [ { "input": "42999611684", "wa_id": "554299611684" } ], "messages": [ { "id": "wamid.HBgMNTU0Mjk5NjExNjg0FQIAERgSOUU3MzdDRThGMUIwMzMxNkUzAA==" } ] } } ], "2": [ { "status": "accepted", "meta_response": { "messaging_product": "whatsapp", "contacts": [ { "input": "42999611684", "wa_id": "554299611684" } ], "messages": [ { "id": "wamid.HBgMNTU0Mjk5NjExNjg0FQIAERgSMDg5QkQ5RkE5RTQ5OTJBN0NDAA==" } ] } } ] } | |||
1.Menu
3.Alteração | |||
1.Menu 2.Objetivo 3.Alteração | |||
Gravar o log dos registros de exclusões na Auditoria ElasticSearch e Consultar Conteúdo Antigo 2 | 1.Menu 2.Objetivo 3.Alteração | ||
Campo Data nos registros de auditoria gerados pelo TMS está sendo enviado para fila vazio | 1.Menu 2.Objetivo 3.Alteração | ||
1.Menu 2.Objetivo 3.Alteração
| |||
NAOTEM | Novo controle de cache para dicionário de dados e redução de consumo de API's do server | 1.Menu 2.Objetivo 3.Alteração | |
1.Menu 2.Objetivo 3.Alteração
| |||
Estudar possibilidade de substituir Sentry por Elastic com Kibana | 1.Menu 2.Objetivo 3.Alteração
| ||
0 | Inconsistência » Comportamento indevido ao trabalhar com Nested Dataset na arquitetura TMS | 1.Menu 2.Objetivo 3.Alteração
| |
0 | 1.Menu 2.Objetivo 3.Alteração | ||
Fintech - Refatorar chamadas de "gerarBoleto" para que não precisem parâmetros na url | 1.Menu 2.Objetivo 3.Alteração | ||
1.Menu
| |||
654373 | Erro de RemoteDB ao tentar salvar um consulta personalizada no Person | 1.Menu 2.Objetivo 3.Alteração | |
Fintech - Implementar microserviço de "migration" para Fintech semelhante a "database" do Filt e CRM | 1.Menu 2.Objetivo 3.Alteração
| ||
0 | 1.Menu 2.Objetivo 3.Alteração
| ||
1.Menu 2.Objetivo 3.Alteração
| |||
Melhorias novo licenciamento debatidas em reunião com Cesar e Sérgio | 1.Menu 2.Objetivo 3.Alteração
| ||
1.Menu 2.Objetivo 3.Alteração | |||
1.Menu 2.Objetivo 3.Alteração
| |||
0 | Replicar commit de correção de carregar fundo do sistema para 2024.06 | 1.Menu 2.Objetivo 3.Alteração | |
Version Manager - Implementar validação por data de liberação. | 1.Menu 2.Objetivo 3.Alteração | ||
629862 | 1.Menu 2.Objetivo 3.Alteração | ||
Não consumir licença no método de listagem de usuários utilizando licença | 1.Menu 2.Objetivo 3.Alteração | ||
1.Menu 2.Objetivo 3.Alteração | |||
633483 | Relatório de Direitos de Acesso listando informações de módulos não filtrados. | 1.Menu 2.Objetivo 3.Alteração | |
1.Menu 2.Objetivo 3.Alteração | |||
1.Menu 2.Objetivo 3.Alteração Criado novos campos na Entity LogErro. Estes campos serão alimentados com base em alguns padrões de tags que já são enviados no JSON gerado pelo MadExcept private String usuario; private String empresa; private String empresaCnpj; private String tenantId; private String nomeExecutavel; private String ip; private String nomeComputador; | |||
1.Menu 2.Objetivo 3.Alteração | |||
Sobre o bucket de armazenamento Foi criado na OCI no compartimento CRM um bucket específico para armazenamento de informações do CRM. A imagem abaixo exibe o bucket criado: Atenção: Ao bucket foi criada uma regra de ciclo de vida para que a cada 30 dias o arquivo armazenado ele seja excluído. Caso esse prazo precise ser maior ou menor, favor informar para que adaptemos conforme a necessidade. Caso seja necessário não ter controle de tempo é possível excluir a regra e os arquivos ficarão armazenados até que seja executado comando específico pedindo a deleção. Sobre a instância do vs-object-storage No OKE da tecnologia na OCI foi configurado e iniciado um novo pod e service específico para o CRM chamado vs-object-storage-crm. Foi incluída uma nova entrada de DNS com a definição vs-object-storage-crm.viasoft.com.br apontando para o ip 144.22.218.121 para uso específico do CRM. Dessa forma já está disponível o acesso ao bucket via object storage. Segue aqui o arquivo json de collection do Postman para facilitar a compreensão e uso: vs-object-storage-crm.postman_collection.json Sobre segurança na comunicação. Alguns EndPoints foram definidos com necessidade de passar um token do tipo “Bearer Token”. Para esses casos ficou fixo o token: XMTiZSz7hW7UHvJqBXjeEzxWBU1RMvN0URhwByPDf44Ytpv662f7ddd665c3 São os endpoints que precisam de token:
Explicando um pouco sobre os endpoints envolvidos:
São parâmetros necessários: “file” que seria o arquivo em si e “folder” que seria a estrutura no bucket que deseja que seja criado para esse arquivo. Por exemplo, se quiser pode ser definido uma estrutura de pastas com o identificador do cliente para separar arquivos por cliente. No retorno do endpoint vem dois parametros a “url” que é temporária, para uso imediato, em alguns minutos ela fica inválida. E o “path” que é uma chave criada para futura consulta e baixa do arquivo. Esse “path” que deve ser armazenado para futura busca ou baixa do arquivo. Para exemplo, a sugestão é utilizar o collection do Postman em anexo.
O parâmetro necessário é o “path”.
| |||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | Criação de Cluster Kubernetes Gerenciado para o Ambiente Dev | . | |
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
635592 | . | ||
0 | . | ||
0 | RevTelas - Aplicação das novas telas no projeto Agro3c - Parte 4 | . | |
635592 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
. | . | ||
635592 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
0 | . | ||
572345 | . | ||
0 | . | ||
0 | . | ||
0 | IA - Acompanhar e auxiliar desenvolvimento das requisições do Analytics para o serviço de Insights | . | |
0 | App H1 Fintech - Melhorar lógica para encontrar a chave PIX sendo ela válida como CPF e telefone | . | |
0 | . | ||
0 | . | ||
0 | . | ||
. | . | ||
0 | . | ||
0 | Implementar serviço de monitoramento e controle de acessos a API | . | |
0 | . | ||
0 | . | ||
0 | . | ||
0 | Atualização e compilação dos projetos do agro (continuação da TECD-2140) | . | |
0 | RevTelas - Aplicação das novas telas no projeto Agro3c - Parte 2 | . | |
0 | . | ||
0 | . | ||
0 | . | ||
. | |||
0 | . | ||
0 | . | ||
. | |||
. | |||
. | |||
0 | . | ||
. | |||
. | |||
. | |||
0 | Fintech - Subir nova versão do apk Android e iOS com a nova versão do extrato | . | |
0 | . | ||
614950 | Rotina Fluxo de Caixa não carrega adequadamente os filtros salvos | . | |
. | |||
. | |||
0 | . | ||
Criar ambiente da Aplicação Satélite Construshow Portal do Cliente | . | ||
Inconsistência no sequencial ao copiar e colar cabeçalho de cobrança no sistema | . | ||
Remover bloqueio de data atrelado a data de validade do sistema | . | ||
. | |||
. | |||
Implementar chamada para disparar processo de cópia dos direitos de acesso por vertical | . | ||
0 | . | ||
. | |||
Sinonimos das tabelas RBITEMHIST e VSCONSULTAHIST - Não foram criados | . | ||
. | |||
IA - Criar um protótipo no Whatsapp para conversar com os dados do Analytics | . | ||
IA - Autopilot - Adicionar indicador de tickets com Desenvolvimento ao Painel | . | ||
. | |||
. | |||
Adequar retenção dos logs no elastic, automatizando retenção de 7 a 15 dias no máximo usando Ansible | . | ||
. | |||
. | |||
. | |||
0 | . | ||
. | |||
. | |||
0 | . | ||
. | |||
Vs-object-storage permitir subir arquivo com nome pré-definido | . | ||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
IA - Realizar o treinamento da Base usando os dados do Analytics | . | ||
. | |||
0 | Incompatibilidade na Abertura de Telas Entre Delphi XE7 e Berlin | . | |
. | |||
Verificar a possibilidade de fazer Filter utilizando o campo personalizado no cds padrão da tela | . | ||
Mudar fundo dos ERP´s principalmente quanto a parte de redes sociais | . | ||
. | |||
. | |||
. | |||
Filt: Erro na criação de base de dados no microserviço gestao-empresa | . | ||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
. | |||
Atualizar commons DEV do Agrotitan para versão mais recente da tecnologia | . | ||
. | |||
Opsgenie primeiros recursos da tecnologia com avisos de monitoramento | . | ||
. | |||
VSREL: Erro ao emitir relatórios por dentro do módulo Folha. | . | ||
Manual para clientes de cadastros necessários na Meta para funcionamento da API do Whatsapp | . | ||
. | |||
. | |||
CI/CD Filt - Verificar indisponibilidade dos pods nas atualizações | . | ||
. | |||
Upgrade de memória no servidor oriongru-01 (Orion 1 - Cloud 2.0) | . | ||
. | |||
. | |||
. | |||
. | |||
Fintech - Implementar ambiente de Dev, Produção e Sandbox conforme adequação da TECD-2087 | . | ||
Fintech - Alterar hospedagem de banco de dados oficial para um MySql autogerenciado com backup | . | ||
. | |||
. | |||
Análise de metodologia e ferramenta de "insights com IA" por dentro do ERP - Parte 2 | . | ||
Engenharia de Prompt para Padronização de Texto das Features (Gherkin e BDD) | . | ||
Implementação de Aplicação para Transcrição de Vídeo para Texto | . | ||
Após cadastrar certificado digital no VIASOFTX retorna KEY VIOLATION | . | ||
. | |||
. | |||
. | |||
. | |||
Deploy do AgroMonitor na cloud 2.0 não está gerando o DNS corretamente | . | ||
. | |||
. | |||
582893,583344 | . | ||
Automatização da criação de imagens produtos web/mobile Construshow/Petroshow | . | ||
. | |||
. | |||
. | |||
. | |||
. | |||
Erro ao Utilizar Funcionalidade de Sub-Consultas nas Consultas Padrões do Sistema | . | ||
. | |||
Análise de metodologia e ferramenta de "insights com IA" por dentro do ERP | . | ||
. | |||
13/03/2024 - Viasoft_3C - Relatório de direito de acesso apresentando informações incorretas | . | ||
. | |||
. | |||
. | |||
. | |||
Implementar o FieldName, o DataSet e a Chave do Grid no Ctrl + Shift + F7 | . | ||
. | |||
Criar parâmetros de login e senha para os executáveis Viasoft. | . | ||
1.Menu | |||
Portal Documentos » Gravar o XML de todos os NSU devolvidos pelo SEFAZ | 1.Menu
{ "Cnpj":"00000000000000", // CNPJ da empresa "Tipo":"NFE", // NFE ou CTE "Filtro": 0, // 0 - Os ultimos N NSU (usa o "valor"); 1 - Todos os NSU maior ou igual a "valor"; 2 - Apenas o nsu igual a "valor"; 3 - Chave igual a "valor" "Valor": "10", "Restric1":"540950960760950660860140750360750660460350550350250650860560960040450650550550960160750350850640450860", // Numero de Serie do certificado, criptografado "Restric2":"000250450950140350250910" // Senha do certificado, criptografado } | ||
1.Menu
Segue exemplo de código: Uses Graphics, Controls, StdCtrls, CxGridCol, Menus, DB, cxTextEdit, cxCheckBox, cxCalc, cxCalendar, cxMaskEdit, cxButtonEdit, cxDropDownEdit; var Coluna1 : TcxGridColuna; Coluna2 : TcxGridColuna; Coluna3 : TcxGridColuna; Coluna4 : TcxGridColuna; Coluna5 : TcxGridColuna; Coluna6 : TcxGridColuna; Coluna7 : TcxGridColuna; CheckProp : TcxCheckBoxProperties; EditProp : TcxTextEditProperties; CalEditProp : TcxCalcEditProperties; DateEditProp : TcxDateEditProperties; MaskEditProp : TcxMaskEditProperties; ButtonEditProp : TcxButtonEditProperties; ComboBoxProp : TcxComboBoxProperties; begin Coluna1 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'Boolean', 'Boolean', 0, 'FormaPgto'); CheckProp := TcxCheckBoxProperties(Coluna1.Coluna.Properties); Coluna2 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'Texto', 'Texto', 5, 'FormaPgto'); EditProp := TcxTextEditProperties(Coluna2.Coluna.Properties); Coluna3 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'Inteiro', 'Inteiro', 5, 'FormaPgto'); CalEditProp := TcxCalcEditProperties(Coluna3.Coluna.Properties); Coluna4 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'DataHora', 'DATAHORA', 5, 'FormaPgto'); DateEditProp := TcxDateEditProperties(Coluna4.Coluna.Properties); Coluna5 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'Hora', 'HORA', 5, 'FormaPgto'); MaskEditProp := TcxMaskEditProperties(Coluna5.Coluna.Properties); Coluna6 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'EditBotao', 'BUTTONEDIT', 5, 'FormaPgto'); ButtonEditProp := TcxButtonEditProperties(Coluna6.Coluna.Properties); Coluna7 := TcxGridColuna.Create(FCustoParcela.ViewFormaPagamento, 'Combo', 'COMBO', 5, 'FormaPgto'); ComboBoxProp := TcxComboBoxProperties(Coluna7.Coluna.Properties); // Exemplo de outras propriedasdes que podem ser acessadas Coluna7.Coluna.HeaderHint := 'Mouse sobre a coluna'; Coluna7.Coluna.VisibleForCustomization := False; Coluna7.Coluna.Options.Moving := False; end; Link da documentação no Confluence: | |||
Atalho F12 não está verificando a senha do usuário VIASOFT no AD. | 1.Menu | ||
1.Menu 2.Objetivo 3.Alteração
exception.validar-duplicados=true exception.max-duplicados=15
MaxErrosDuplicados = 0; | |||
Código: uPrinc uses Unit1; var F : TForm1; begin try F := TForm1.Create(nil); F.Criar(F); F.ShowModal; finally F.Free end end; Unit1 {$FORM TForm1, Unit1.sfm} uses DB, DBClient, uVsClientDataset, Classes, Graphics, Controls, Forms, Dialogs, cxGrid, dxCore, cxGridDBTableView, cxGridLevel, cxStyles, cxData, cxCustomData, cxGridPopupMenu, Classes, Graphics, Controls, Forms, Dialogs, DB, DBClient , Bib, Windows, UProcRapidaCds, Grids, VsDBGrid, DBCtrls, StdCtrls, DBGrids, ExtCtrls, SysUtils, System, CxGridCol; procedure BuscarTabela; begin cds.Data := dmConexao3c.QueryPegaData('SEL_PESQUISAFILTRO' , '*' , [ '?', '1:s', 'PESSOA' , '?', '2:s', 'IDPESSOA<1000' , 'P', 'ID' , 1] , [ftString, ftString, ftInteger] , [8, 20, 0]); end; procedure Criar(AForm : TForm); var Grid: TcxGrid; Level: TcxGridLevel; View: TcxGridDBTableView; Style: TcxStyle; pm: TcxGridPopupMenu; begin BuscarTabela; // Cria o Grid Grid := TcxGrid.Create(AForm); Grid.Parent := AForm; Grid.Align := alClient; // Cria um Level Level := Grid.Levels.Add; Level.Name := 'SomeLevelName'; // Cria a View View := Grid.CreateView(TcxGridDBTableView) as TcxGridDBTableView; View.Name := 'SomeViewName'; View.FilterRow.Visible := True; View.OptionsView.Footer := True; // ... Ligacoes Level.GridView := View; View.DataController.DataSource := ds; // ... Cria todas as colunas View.DataController.CreateAllItems; View.Columns[0].Caption := 'Código'; View.Columns[1].Caption := 'Nome'; View.Columns[2].Caption := 'CNPJ/CPF'; View.Columns[0].Summary.FooterKind := skMax; Style:= TcxStyle.Create(AForm); // Style.Color := $00FEF3CF; Style.TextColor := clRed; View.Columns[0].PropertiesClassName := 'TcxComboBoxProperties'; View.Styles.ContentEven := Style; pm := TcxGridPopupMenu.Create(AForm); pm.Grid := Grid; pm.AlwaysFireOnPopup := True; end; | |||
https://nimitz.atlassian.net/wiki/spaces/TD/pages/edit-v2/3514335259 | |||
0 | Adição de uma nova coluna com as propostas canceladas pelo colaborador na tela das propostas do admin. | ||
Alteracao no front end do consignado. Permitindo possuir parceiro, remover o parceiro e ordenando o parceiro por ordem alfabetica no dropbox da empressa. | |||
Consignado - Usuario administrador precisa ver os anexos dos colaboradores | Alteração da tela dos colaboradores, alteração necessária apensa no frontend Angular. Componente fdic-colaboradores sofreu alterações na tabela. | ||
0 | Alteração do código beneficiário no momento do cadastro do convenio, pois a conta é cadastrada antes do convenio. Tarefa finalizada porém alguma contas Sicredi sofrerão ajustes manuais e serão validadas. | ||
Alterações na trigger ‘trg_colab_empresa’_au do banco de homologação e de produção. | |||
Campos adicionados no banco de dados de producao e homologacao | |||
0 | Como definido na tarefa estão sendo enviados e-mails para o Admin e RH, porém pela urgência e característica da demanda esta tarefa será dividida em duas partes. Essa primeira parte está sendo enviado o email para os destinatários desejados, na segunda parte será criada uma página HTML definido um novo layout de envio de e-mails, visto que a biblioteca usada no Consignado precisa que seja criada uma página HTML para envio de e-mail. Neste momento está sendo usada uma página genérica para Admin e RH a segunda parte da tarefa comtempla criar páginas HTML distintas para cada destinatário. | ||
Criação de um combox nos detalhes da empresa para adicionar quem é o parceiro responsavel pelo credenciamento desta. | |||
0 | Criação de uma classe estatica chamada de ConversorUtil, dessa forma não sendo necessario injetar na classe SimuladorFormDirective, e deixando essa classe e o método diferencaDiasEntreTipoDate disponíveis para serem usados em outras partes do código. | ||
Criação no back end do controller/service/repository do parceiro. | |||
Dados nao localizados sendo necessário executar requisições na api da tecnospeed para preenchimento do código de barra e nosso numero impressão. | |||
Dados obtidos com sucesso via api Tecnospeed. | |||
Erro retornado pela api da Tecnospeed TituloNumeroDocumento - Tamanho máximo do campo é 10 caracteres | |||
0 | Foi criado a branch - TECD-2376Getting issue details... STATUS diretamente pela IDE. O método do backend estava com problemas de escopo na variavel. | ||
Foi necessario atualizar os base64 que estavam no banco de producao com os novos templates para gerar relatorios. | |||
Foram necessarias alteracoes na Fintech e no Filt. | |||
IA - Autopilot - Classificador de criticidade dos atendimentos | Documentação de Implantação do Microserviço vs-urgency-classifierPassos para Implantação1. Clonar o RepositórioPrimeiro, clone o repositório do Bitbucket: git clone <https://bitbucket.org/viasoftnimitz/vs-urgency-classifier> 2. Configurar Variáveis de AmbienteRenomeie o arquivo .env-exemplo para .env e edite as variáveis conforme necessário: mv .env-exemplo .env nano .env Certifique-se de preencher todas as variáveis necessárias no arquivo .env, incluindo as configurações para conexão com o PostgreSQL. 3. Configurar Banco de Dados PostgreSQLGaranta que você tenha um banco de dados PostgreSQL disponível e configure as seguintes variáveis no arquivo .env:
4. Implantar no DockerPara implantar o serviço usando Docker, execute o seguinte comando, apontando para a porta 5005: docker build -t vs-urgency-classifier . docker run -d -p 5005:5005 --env-file .env vs-urgency-classifier 5. Configurar o NginxConfigure o Nginx para apontar para o servidor onde o microserviço está rodando. Adicione uma configuração no seu arquivo de configuração do Nginx, semelhante ao exemplo abaixo: server { listen 80; server_name seu_dominio.com; location / { proxy_pass <http://localhost:5005;> proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } Reinicie o Nginx para aplicar as novas configurações: sudo systemctl restart nginx 6. Configurar Gatilho no MovideskAcesse o Movidesk e navegue até as configurações de gatilho:
7. Manutenção de PromptCaso seja necessário atualizar alguma coisa no prompt, edite o arquivo classifier_langchain.py. 8. Atualizar Token do MovideskSe for necessário alterar o token do Movidesk, edite o arquivo .env e atualize o valor da variável correspondente ao token. | ||
0 | Implementar um aplicativo para realizar o papel de producer de filas da OCI (OCI Queues) | Informações do projetoObjetivoFornecer uma interface entre receber uma mensagem Json via Rest e armazenar ela em uma OCI Queue. Esse aplicativo é um produtor de mensagens em uma Queue. Parametros necessáriosConfigurar no application.properties: oci.config.path= oci.config.endpoint= oci.config.queue-ocid= O path é o caminho onde o arquivo config está armazenado (arquivo semelhante ao do resource .oci/config). Endpoint e queue-ocid são informações que são obtidas na criação das queues. Métodos a serem utilizados/ e /pingsão métodos GET servem só para teste se a API subiu. /api/sendmétodo POST cujo valor do body será armazenado como mensagem na Queue. AtençãoComo trata-se de um recurso da OCI atentar-se com um uso de chave privada com direitos de acesso de usuário como serviço para execução. | |
Consignado - Desenvolver Layout de tela para o Vendedor Executivo | Inclusao do parceiro para receber comissoes das empresas. | ||
0 | Modificação no metodo que gera a remessa na api da Fintech. | ||
0 | Consignado - Criar módulo para admin de Central de cobrança para o Consignado | Na reunião de tecnologia do dia 16/07/2024 verificou-se que esta tarefa não será desenvolvida, pois já existe uma planilha que resolve de forma ágil a questão solicitada. | |
0 | Consignado - Mostrar apenas propostas aprovadas pelo admim ao RH | Necessário alterações na classe EmpresaOperacoesComponent, para no momento das buscas das propostas aprovadas verifique a situação das propostas em relação ao Admin, assim como nas propostas reprovadas. | |
0 | Necessário corrigir os endpoints de criação e alteração de convenios na Fintech, também foram pedidos ajustes nas variaveis do Filt para enviar valores com 0 a esquerda. | ||
Realizado testes e a sugestão é atualziar a versao do UniDac | |||
Realizados testes para verificar a funcionalidade, sendo aprovado pela equipe comercial. Funcionalidade foi desenvolvida no antigo quadro Trello da Fintech. | |||
Refatoracao da classe HomePage para que o saldo seja buscado na inicializacao do app. | |||
Boleto Híbrido Compartilhado - Banco do Brasil, Sicreed, Itaú e Santander | Será documentado individualmente por cada vertical | ||
Tarefa concluida e enviada diretamente para a branch master, em homologacao nao apresentava o mesmo comportamento. | |||
0 | Tarefa já foi desenvolvida no Trello que veio da Fintech para Tecnologia. | ||
0 | Consignado - Mostrar empresa mesmo quando estiver em fase de simulação. | Tarefa já foi desenvolvida no Trello que veio da Fintech para Tecnologia. | |
Consignado - Nao permitir ao colaborador alterar alguns campos apos enviar a simulacao | Testado e validado com a equipe comercial da Fintech. | ||
0 | TESTE | ||
Validado e implementado. No momento foi definido pelo comercial que nao ha necessidade de validacoes na chave pix ou maiores implementacoes, somente cadastrando essa no banco de dados, junto aos dados bancarios. |
277 issues Refresh