REGISTRO DOI: 10.69849/revistaft/fa10202601172104
Mayla Jamile Carrera da Silva1
Ranniher da Silva Rosa2
Marcos Vinicius Sadala Barreto3
Geovane Nobre Lamarão4
André Augusto Pacheco de Carvalho5
RESUMO
Considerando a crescente dependência de planilhas colaborativas para a tomada de decisões, garantir a integridade e a rastreabilidade dos dados tornou-se cada vez mais crucial. Este artigo apresenta o desenvolvimento e a implementação de uma aplicação de log em Google Apps Script para monitorar e registrar alterações no Google Sheets, enfrentando as limitações da ferramenta nativa relacionadas à rastreabilidade, integridade de dados e segurança da informação. O principal objetivo é fornecer um sistema automatizado capaz de rastrear com precisão as modificações feitas pelos usuários, garantindo transparência e confiabilidade em documentos compartilhados. A solução também inclui um mecanismo de reversão e notificações por e-mail em tempo real para melhorar o controle sobre as atividades colaborativas. A metodologia envolveu uma análise exploratória dos recursos do Google Apps Script, prototipagem, implementação das funcionalidades finais e testes. Gatilhos de eventos foram usados para capturar as alterações e uma estratégia de backup foi empregada para preservar os valores anteriores às alterações. Serviços como PropertiesService, MailApp e LockService garantiram a sincronização e a consistência. Testes automatizados conduzidos com o framework GasT (Google Apps Script Testing) validaram a funcionalidade e a estabilidade do aplicativo, confirmando sua viabilidade técnica e contribuição para o gerenciamento eficiente de dados em ambientes dinâmicos.
Palavras-chave: Auditoria, Google Apps Script, Google Sheets, Log, Monitoramento.
1 INTRODUÇÃO
O uso de planilhas eletrônicas, como o Google Sheets, tornou-se essencial para o gerenciamento de dados em contextos colaborativos e é amplamente adotado em ambientes corporativos devido à sua flexibilidade e facilidade de compartilhamento em tempo real. No entanto, suas limitações podem comprometer a rastreabilidade, a segurança e a integridade das informações, especialmente em ambientes onde o controle de dados é crítico.
Ao usar planilhas do Google Sheets, alguns problemas podem ser identificados. Ao acessar o histórico, é difícil identificar os valores anteriores de uma célula após uma alteração. Há um risco significativo de perda de metadados, como a data e a hora da alteração, já que o Google Sheets permite a edição manual dos nomes das versões da planilha, que por padrão são rotuladas com o registro de data e hora. Essa prática compromete a integridade temporal das alterações. Quando é necessário recuperar um valor modificado em uma versão, não é possível restaurar o valor de uma célula específica; em vez disso, todo o bloco de alterações feitas durante o mesmo período da versão precisa ser restaurado. Embora seja possível acessar o histórico de edições de uma célula sem acessar o histórico de versões, não é possível restaurar o valor anterior sem sobrescrevê-lo manualmente. Além disso, é necessário navegar linearmente pelas edições da célula para localizar uma alteração específica, o que se torna cada vez mais difícil para alterações mais antigas.
Silva et al. (2019) criaram um gatilho genérico, juntamente com programação PL/SQL, para automatizar o armazenamento de logs para qualquer tipo de tabela com o objetivo de monitorar o banco de dados, prevenir alterações não autorizadas sem registro e, assim, evitar erros nas informações apresentadas. A proposta introduziu uma tabela de log responsável por receber todas as informações quando o gatilho é ativado; essa tabela de log é incrementada ao longo do tempo, permitindo a observação de alterações e a identificação do usuário responsável. O resultado foi uma facilidade no registro e na leitura de dados modificados de qualquer tabela presente no banco de dados.
Entretanto, Sebben (2023) apresentou uma solução com o objetivo de centralizar e padronizar a estrutura de logs para que informações específicas de microsserviços não sejam perdidas e possam ser melhor utilizadas. Neste estudo, os logs são registrados para corresponder às etapas do processo de negócio, visando uma melhor compreensão de onde os problemas ocorrem, e o gerenciamento de logs é realizado centralmente por um middleware. O estudo definiu um modelo de arquitetura padrão e uma interface de comunicação que podem ser implementados de diversas maneiras e com diferentes tecnologias. Um protótipo foi desenvolvido para testes, e a abordagem se mostrou eficaz para o seu propósito. A metodologia apresentada não substitui os mecanismos convencionais de logs e rastreamento distribuídos, mas os complementa com informações relevantes para este aspecto do problema.
É importante destacar que o estudo e o desenvolvimento de metodologias para aprimorar o registro de logs em diversas áreas constituem um tema relevante na literatura atual. Pesquisadores implementam constantemente novos métodos ou modelos para garantir que as informações não sejam perdidas durante os processos (IMRAN et al., 2017). Nesse contexto, este artigo contribui apresentando uma implementação de log com funcionalidades adicionais de rollback e notificações em tempo real para superar as limitações do Google Sheets.
2 FUNDAMENTAÇÃO TEÓRICA
O conceito de registro de logs é essencial no contexto de sistemas de banco de dados, especialmente para garantir a recuperação de dados, a integridade e a rastreabilidade das operações. Ele ajuda a rastrear modificações indevidas, sejam acidentais ou maliciosas, permitindo a identificação de alterações incorretas que poderiam levar a decisões imprecisas ou fraudulentas. De acordo com Elmasri e Navathe (2011), um log é um arquivo sequencial mantido em disco onde todos os eventos que alteram os dados, como inserções, exclusões e atualizações, são registrados. Esse registro permite que o sistema restaure o estado anterior dos dados em caso de falhas, garantindo as propriedades das transações: Atomicidade, Consistência, Isolamento e Durabilidade (ACID).
Outro aspecto fundamental dos sistemas de banco de dados é o controle de concorrência, que garante que transações simultâneas não causem efeitos indesejáveis, preservando a integridade dos dados. Técnicas como bloqueio e ordenação por carimbo de tempo são aplicadas para garantir isolamento e consistência. Nesse cenário, o log complementa essas técnicas, registrando a ordem e os efeitos das operações realizadas, permitindo a recuperação do estado correto dos dados mesmo em caso de falhas ou reversões de transações (ELMASRI; NAVATHE, 2011).
Gray e Reuter (1993) vão além, enfatizando a importância do registro de logs, afirmando: “O log era originalmente usado apenas para recuperação de transações. Cada vez mais, ele está sendo usado para funções mais amplas. Auditores corporativos que avaliam um sistema de transações podem usar o log para verificar se as transformações estão corretas.” Essa observação destaca que o registro de logs transcende seu papel tradicional de recuperação, assumindo um papel essencial na auditoria, permitindo a verificação e validação das alterações feitas nos dados.
3 METODOLOGIA
O desenvolvimento da solução de log para as planilhas Google Sheets seguiu uma abordagem dividida em quatro etapas principais: investigação da viabilidade do uso dos recursos do Google Apps Script, prototipagem da funcionalidade básica de um log, implementação da versão final com todas as funcionalidades propostas e, por fim, execução de testes.
3.1 Investigação técnica inicial
Nesta fase, foi realizada uma análise da documentação oficial do Google Apps Script com o objetivo de identificar:
- Mecanismos de captura de eventos: o Google Apps Script disponibiliza funções de acionadores (triggers) que permitem detectar automaticamente a ocorrência de determinados eventos. Foram considerados dois principais acionadores: onEdit, que é executado quando um usuário altera o conteúdo de uma célula; e onChange, que é disparado tanto por edições de conteúdo quanto por alterações estruturais na planilha.
- Disponibilidade de metadados: foi realizada uma avaliação dos objetos de evento retornados por cada acionador, com foco em verificar se fornecem as informações necessárias para o funcionamento do log, como: data e hora da alteração, valor anterior, valor novo, nome da planilha, aba alterada e intervalo de células modificadas. Com base nessa análise, concluiu-se que o gatilho onEdit seria o mais adequado, pois fornece todos os metadados necessários para um registro completo das alterações, em comparação com o gatilho onChange, que captura apenas qual planilha foi modificada, o tipo de alteração e o nível de autorização sob o qual o script foi executado.
3.2 Prototipagem
Nesta etapa, foi desenvolvido o primeiro protótipo do sistema de log. Foi criada uma interface utilizando o recurso de interface do usuário (classe Ui) do Google Apps Script, por meio da qual foi adicionado um menu à planilha, permitindo ao usuário iniciar o monitoramento de alterações.
A criação do acionador instalável (trigger) do tipo onEdit, para a captura das informações necessárias para o log, foi realizada com o uso da classe ScriptApp, conforme a imagem abaixo:
Figura 1: Trecho de código responsável pela criação do trigger instalável onEdit
Devido à limitação da propriedade oldValue do evento — que não fornece os valores antigos quando um intervalo de células é alterado — tornou-se necessário implementar uma estratégia de backup. Antes da execução do acionador, é feito um backup do estado atual da aba que foi alterada, para que possam ser recuperados os valores antigos quando alterados, conforme a imagem a seguir:
Figura 2: Trecho de código responsável por buscar os valores antigos contidos na aba de backup
3.3 Versão Final
Nesta fase, foram implementadas as funcionalidades complementares do sistema de log: reversão de alterações (rollback), envio de notificações por e-mail e uma interface lateral, possibilitando o usuário a selecionar qual aba deve ser monitorada e ajustar preferências de envio de notificações:
Figura 3: Print da tela onde aparece o menu da aplicação
Outros serviços do Google Apps Script foram utilizados nesta etapa:
- PropertiesService: utilizado para armazenar informações persistentes da aplicação, como o nome da aba atualmente monitorada e o e-mail do destinatário das notificações;
- MailApp: responsável pelo envio das notificações de alteração por email, com base nas preferências do usuário;
- LockService: utilizado para garantir a consistência dos dados em situações de concorrência, impedindo que múltiplos processos acessem e modifiquem simultaneamente os registros de log ou o backup. Isso evita conflitos e possíveis perdas de informação:
Figura 4: Trecho de código responsável pela criação do lock
3.4 Testes
3.4.1 Testes de unidade
Para assegurar o correto funcionamento das funcionalidades implementadas na aplicação de Log, foram realizados testes utilizando a biblioteca GasT. GasT é um framework de testes compatível com o padrão TAP (Test Anything Protocol) e específico para Google Apps Script. Ele oferece uma forma simples e eficiente de verificar se os scripts desenvolvidos estão se comportando conforme o esperado.
3.4.2 Teste de desempenho
Devido às limitações do ambiente Google Apps Script, como restrições de tempo máximo de execução (cerca de 6 minutos por execução), ausência de possibilidade de executar testes paralelos ou em background e a impossibilidade de simular triggers de forma nativa, não foi possível implementar testes de desempenho mais sofisticados, que envolvessem concorrência, monitoramento detalhado de uso de CPU e memória, ou simulações em larga escala com dados reais; o único teste viável para avaliação de desempenho da aplicação foi a medição do tempo médio de execução da função chamada pelo trigger onEdit.
Assim, o teste foi conduzido por meio da invocação direta da função, utilizando objetos de evento simulados. O procedimento consistiu na medição do tempo total gasto pela função ao processar um número pré-definido de alterações simuladas (100 iterações), incluindo a captura do evento e o registro no log. Para essa finalidade, foi desenvolvido um script que executa repetidamente chamadas simuladas do evento de edição, para a captura do tempo aproximado necessário para processar essas operações:
Figura 5: Primeira parte do script utilizado para simular alterações na planilha
Figura 6: Segunda parte do script utilizado para simular alterações na planilha
Figura 7: Terceira parte do script utilizado para simular alterações na planilha
4 RESULTADOS
4.1 Implementação do Log
Foram obtidos resultados satisfatórios com a implementação da solução de log. Os registros capturados pelo acionador onEdit passaram a ser armazenados em uma aba dedicada chamada “Log”, que guarda as informações de cada alteração:
Figura 8: Print da aba de log com os registros das alterações
4.2 Execução dos testes
Com o uso da biblioteca GasT, foram criados e executados testes automatizados que cobriram os principais cenários da aplicação:
Figura 9: Print do log de execução dos testes de unidade usando o GasT
Como resultado da execução do teste de desempenho, foi obtido a seguinte tabela:
Tabela 1: Resultado da execução do teste de desempenho
5 CONCLUSÃO
Este artigo apresenta o desenvolvimento de uma solução eficaz para o monitoramento detalhado de alterações no Google Sheets, superando as limitações nativas da ferramenta. A aplicação, implementada em Google Apps Script, permite o registro preciso das modificações, atendendo aos objetivos propostos. Os recursos de reversão e notificação em tempo real proporcionam maior controle e segurança no gerenciamento de informações, agregando valor a ambientes colaborativos. Os testes realizados confirmam a viabilidade técnica e a confiabilidade do sistema, reconhecendo as limitações inerentes ao ambiente Google Apps Script, particularmente em relação ao desempenho sob alta carga e concorrência. Este estudo contribui demonstrando a adaptabilidade do conceito de registro de alterações, tradicionalmente aplicado em bancos de dados, ao contexto de planilhas colaborativas, tanto conceitualmente quanto por meio do desenvolvimento e implementação de uma solução prática.
REFERÊNCIAS
SILVA, A. et al. (2019). Log genérico: para banco de dados oracle utilizando trigger. Trabalho de conclusão de curso (Curso Superior de Tecnologia em Banco de Dados). Faculdade de Tecnologia FATEC Bauru, Bauru. Disponível em: https://ric.cps.sp.gov.br/handle/123456789/12183.
SEBBEN, N. (2023). Modelo de logs para identificação de falhas de processo em arquiteturas de microsserviços. Trabalho de Conclusão de Curso, Universidade de Caxias do Sul. Disponível em: https://repositorio.ucs.br/xmlui/bitstream/handle/11338/13372/TCC%20Natalia%20Sebben.pdf?sequence=1&isAllowed=y.
IMRAN, M. et al. (2017). Provenance based data integrity checking and verification in cloud environments. PLoS ONE, v. 12, n. 5, e0177576. https://doi.org/10.1371/journal.pone.0177576.
ELMASRI, R., NAVATHE, S. (2011). Sistemas de banco de dados. 6. ed. São Paulo: Pearson Addison Wesley. Cap. 21–23.
GRAY, J., REUTER, A. (1993). Transaction Processing: Concepts and Techniques. San Francisco: Morgan Kaufmann Publishers. Cap. 9.
GOOGLE DEVELOPERS. Extending Google Sheets. Disponível em: https://developers.google.com/apps-script/guides/sheets. Atualizado em: 4 jun. 2025.
LI, Huan. GasT – Google Apps Script Testing-framework. Disponível em: https://github.com/huan/gast.
1Discente do Curso Superior de Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Pará, Belém. Email: maylajamile16@gmail.com.
2Discente do Curso Superior de Análise e Desenvolvimento de Sistemas do Instituto Federal de Educação, Ciência e Tecnologia do Pará, Belém. Email: ranniher@gmail.com.
3Possui graduação em Licenciatura Plena em Matemática pela Universidade Estadual do Pará (2003), graduação em Tecnólogo em Processamento de Dados pelo Centro de Ensino Superior do Para (2000), mestrado em Engenharia Elétrica pela Universidade Federal do Pará (2007) e doutorado em Engenharia Elétrica pela Universidade Federal do Pará (2019) na área de computação aplicada. Atualmente é professor de Educação Básica, Técnico e Tecnológico do Instituto Federal de Educação, Ciência e Tecnologia do Pará atuante nos cursos de Tecnólogo em Processamento de Dados e Técnico em Informática. Tem experiência na área de análise de sistemas, persistência poliglota, modelagem matemática, controle retroalimentado, ciência de dados e auditoria em sistemas. E-mail: marcos.sadala@ifpa.edu.br.
4Possui graduação em Curso Superior de Tecnologia em Processamento de Dados pelo Centro de Ensino Superior do Pará CESUPA (2001). Pesquisador/Bolsista/CNPq da Universidade Federal do Pará UFPA na área de Geociências com ênfase em Estratigrafia (2002).Especialista em Análise de Sistemas pela Universidade Federal do Pará UFPA (2002). Atualmente, Professor de Educação Básica, Técnico e Tecnológico do Instituto Federal de Educação, Ciência e Tecnologia do Pará IFPA desde (2003). Atuou como Coordenador Geral do Pará da Universidade Aberta do Brasil UAB (2011). Foi Coordenador Geral do Pará do Programa Nacional de Acesso ao Ensino Técnico e Emprego PRONATEC (2012). E-mail: geovane.lamarao@ifpa.edu.br.
5Possui graduação em Ciência da Computação pelo Centro Universitário do Pará (2007). Especialista em Desenvolvimento de Aplicações para Internet pela Universidade Federal do Pará (2010). Mestre em Engenharia Elétrica aplicada à Computação pela Universidade Federal do Pará (2015) e Doutor em Engenharia Elétrica aplicada à Computação pela Universidade Federal do Pará (2021). Atualmente, Professor de Educação Básica, Técnico e Tecnológico do Instituto Federal de Educação, Ciência e Tecnologia do Pará IFPA. E-mail: andre.pacheco@ifpa.edu.br.