Trabalho com Oracle EBS há mais de 18 anos, tendo experienciado a evolução completa de 11i para R12. Ao longo desta longa carreira, o desenvolvimento de relatórios personalizados sempre foi uma responsabilidade central inevitável. Em torno deste trabalho, certos problemas surgem ano após ano sem nunca terem sido fundamentalmente resolvidos.
Trabalho com Oracle EBS há mais de 18 anos, tendo experienciado a evolução completa de 11i para R12. Ao longo desta longa carreira, o desenvolvimento de relatórios personalizados sempre foi uma responsabilidade central inevitável. Em torno deste trabalho, certos problemas surgem ano após ano sem nunca terem sido fundamentalmente resolvidos.
Este artigo não pretende contar uma história. Apenas procura documentar honestamente os problemas que observei e experienciei ao longo dos anos, bem como as tentativas que fiz para os abordar. Espero que possa servir de referência para colegas que enfrentam desafios semelhantes.
No ecossistema EBS, existe um conjunto fixo de procedimentos entre a conclusão da escrita SQL e o momento em que um relatório se torna executável pelos utilizadores finais. Este processo é razoável e necessário no quadro de design do EBS—garante segurança, isolamento multi-organização, validação de parâmetros e agendamento de pedidos. No entanto, do ponto de vista da eficiência do desenvolvimento, o seu custo é realmente elevado.
Especificamente, após concluírem a escrita e os testes SQL, os desenvolvedores devem executar sequencialmente as seguintes operações:
Estes passos não envolvem lógica de negócio complexa—são tarefas puramente de configuração. Mas para um relatório simples, possivelmente de uso único, o custo de arranque deste processo é excessivamente elevado. Um relatório cujo SQL pode levar apenas 20 minutos a escrever muitas vezes requer mais de uma hora para percorrer todo o processo, com a maior parte do tempo consumida pela navegação em menus, preenchimento de campos e espera por respostas da página.
Ainda mais crítico, se o relatório exigir ajustes na lógica SQL ou nas definições de parâmetros após os testes, uma parte considerável dos passos acima deve ser repetida. Isto representa um estrangulamento significativo para cenários de desenvolvimento que requerem iteração rápida.
Este é o problema que considero central e que mais impacta a experiência do utilizador.
O formato de saída nativo dos Programas Concorrentes EBS é um ficheiro de texto (tipicamente .out ou .txt). Quer se trate de um relatório .rdf desenvolvido com Report Builder ou da saída de um procedimento armazenado PL/SQL, o que é finalmente entregue aos utilizadores é essencialmente um texto de largura fixa ou separado por delimitadores.
No entanto, o que os utilizadores de negócio necessitam no seu trabalho diário é, quase sem exceção, ficheiros de dados em formato Excel. Isto cria um "passo intermédio" de longa data: os utilizadores têm de copiar e colar o conteúdo do ficheiro de texto no Excel e depois usar a função "Texto para Colunas" para o dividir em várias colunas.
Este passo envolve vários problemas técnicos específicos:
Primeiro, problemas de largura de campo. Os desenvolvedores de relatórios têm de pré-especificar uma largura de visualização para cada campo de saída. Se o comprimento real dos dados de um campo exceder esta largura predefinida (por exemplo, campos de texto livre como descrições de artigos ou nomes de fornecedores), o EBS lida com isso através de quebra automática de linha, inserindo um caractere de quebra de linha no ficheiro de texto. Esta quebra de linha parece normal num visualizador de texto—o conteúdo é simplesmente exibido numa nova linha. Mas quando os utilizadores copiam todo o texto para o Excel e executam a divisão em colunas, o Excel reconhece esta quebra de linha como um terminador de linha, fazendo com que um único registo seja incorretamente dividido em duas ou mais linhas. O alinhamento de colunas de todos os registos subsequentes fica completamente corrompido. Os utilizadores têm de localizar e corrigir manualmente estes erros, ou reajustar as larguras de campo do relatório e submeter novamente o pedido.
Segundo, problemas de codificação de caracteres. O formato de codificação predefinido do ficheiro de texto muitas vezes não corresponde à codificação predefinida do Excel para abrir ficheiros. Isto é especialmente problemático ao lidar com caracteres multi-byte como chinês ou japonês, resultando frequentemente em texto ilegível. Os utilizadores têm de selecionar manualmente a codificação correta ao abrir o ficheiro de texto, ou especificar o formato de codificação durante a importação para o Excel. Para utilizadores de negócio sem formação técnica, é um fardo adicional e desnecessário.
Terceiro, o tratamento de formatos de números e datas. Números e datas exportados em ficheiros de texto estão tipicamente em formato de texto simples. Após colar no Excel, os utilizadores têm de definir manualmente os formatos de célula antes de poderem realizar cálculos como somas ou médias. Quando estão envolvidos separadores de milhares, precisão decimal ou formatos de exibição de datas, são necessários passos adicionais de ajuste manual.
Quarto, a eficiência de processamento com grandes conjuntos de dados. Quando um relatório devolve um grande volume de dados (por exemplo, mais de 10.000 linhas), a operação de copiar-colar mais divisão manual de colunas torna-se muito demorada. Além disso, o desempenho do Excel ao colar grandes quantidades de texto nem sempre é estável, resultando frequentemente em lentidão ou falta de resposta.
Estes problemas são prevalentes tanto nos relatórios padrão do EBS como nos relatórios personalizados. Estritamente falando, isto não é um "bug"—é uma escolha de design da época em que o EBS foi criado, quando a saída de texto era o método dominante para troca de dados entre plataformas. Mas no ambiente empresarial atual, esta escolha de design está gravemente desligada dos cenários de uso reais dos utilizadores.
Os departamentos de negócio geram frequentemente necessidades de análise de dados não periódicas nas suas operações diárias. Por exemplo:
As características de tais requisitos são: lógica SQL relativamente clara, âmbito de dados limitado, elevados requisitos de atualidade e uma alta probabilidade de uso único sem recorrência.
Sob o caminho de desenvolvimento padrão do EBS, mesmo um relatório ad hoc de uso único deve passar pelo processo de registo completo, desde a definição de um Executável até à sua montagem num Grupo de Pedidos. Isto significa que os desenvolvedores devem repetir tarefas de configuração não relacionadas com a lógica de negócio cada vez que respondem a tais pedidos ad hoc.
Outra solução alternativa comum é os desenvolvedores executarem SQL diretamente em ferramentas de base de dados (como PL/SQL Developer ou Toad), copiarem os resultados e enviá-los aos utilizadores em Excel. Esta abordagem contorna o processo de registo do EBS e é significativamente mais rápida, mas também contorna o controlo de acesso multi-organização e a validação de permissões de dados do EBS, introduzindo potenciais riscos de segurança de dados. Também não pode aproveitar o Concurrent Manager para agendamento e registo unificados.
Os problemas descritos acima não são novos. De facto, na comunidade de utilizadores do EBS e entre os profissionais, estas dificuldades são há muito um segredo público. No entanto, ao longo dos anos, as soluções da indústria têm-se concentrado principalmente nas seguintes abordagens, todas com eficácia limitada:
Nenhuma destas abordagens altera fundamentalmente o modelo de desenvolvimento de relatórios EBS. Os desenvolvedores ainda precisam de investir esforço tanto ao nível da escrita SQL como da configuração do sistema, e os utilizadores ainda precisam de gastar tempo extra tanto na aquisição como na limpeza de dados.
Com base nos problemas acima, tentei construir uma camada de ferramenta de relatórios independente, chamada SQLVantage. O seu posicionamento não é substituir o Concurrent Manager do EBS, mas sim servir como uma camada de resposta rápida complementar, cobrindo os seguintes cenários:
A filosofia de design central desta ferramenta é: eliminar o trabalho processual mais demorado e não relacionado com a lógica de negócio no desenvolvimento de relatórios EBS, permitindo que os desenvolvedores se concentrem diretamente nos dois elementos centrais—SQL e configuração de parâmetros.
A abordagem específica é a seguinte:
No lado do desenvolvimento, os desenvolvedores apenas precisam de preencher o nome do relatório, escrever a instrução SQL e definir os parâmetros de consulta (nome do parâmetro, tipo de dados, etiqueta de exibição, valor predefinido) na ferramenta. Após guardar, o relatório fica imediatamente disponível. Não é necessário definir um Executável, registar um Programa Concorrente, configurar Conjuntos de Valores ou montar Grupos de Pedidos. Todo o processo de configuração pode ser concluído em 3 a 5 minutos.
Em termos de segurança de dados, a ferramenta reutiliza o mecanismo de autenticação de utilizadores do EBS, garantindo que apenas utilizadores com as responsabilidades EBS apropriadas possam aceder e executar relatórios. A lógica de Controlo de Acesso Multi-Organização (MOAC) envolvida nas consultas SQL permanece nas próprias instruções SQL, controlada pelos desenvolvedores de acordo com os requisitos de negócio reais.
Em termos de formato de saída, a ferramenta gera diretamente ficheiros Excel .xlsx. Cada campo de resultado de consulta corresponde a uma coluna do Excel, e cada linha de dados corresponde a uma linha do Excel. As larguras dos campos são automaticamente adaptadas ao conteúdo, e textos longos não provocam quebras de linha que danificariam os dados. Números, datas e outros tipos de dados mantêm os seus atributos de tipo originais durante a exportação, permitindo que os utilizadores ordenem, filtrem e realizem cálculos diretamente ao abrir o ficheiro Excel.
Em termos de extensibilidade, além do Excel, a ferramenta também suporta saída em formato JSON, facilitando a integração com plataformas de dados externas ou sistemas BI.
Após um período de uso interno, esta ferramenta trouxe melhorias de eficiência nas seguintes áreas:
Ao mesmo tempo, também devo salientar as limitações desta ferramenta:
Durante 18 anos, o EBS tem sido uma plataforma de aplicações empresariais cuja estabilidade arquitetónica fundamental e rigor são indiscutíveis. Mas precisamente por causa desta estabilidade, algumas escolhas de design que eram razoáveis na sua época parecem lentas e pesadas nos cenários de uso atuais.
O custo do processo de desenvolvimento de relatórios, o formato de saída baseado em texto, o caminho de resposta para necessidades ad hoc—estes problemas não surgiram apenas hoje. É simplesmente que no ambiente atual, os seus custos se tornaram mais evidentes. Os ritmos de negócio estão a acelerar, as exigências das empresas sobre a capacidade de resposta dos dados estão a aumentar, e as ferramentas e processos que utilizamos permanecem presos numa era passada.
O SQLVantage é uma tentativa que fiz com base nestes problemas. Não é realmente uma inovação, mas sim uma simplificação e reorganização dos processos existentes. Se este artigo puder ressoar com alguns colegas, ou fornecer uma perspetiva de referência para aqueles que estão a pensar sobre problemas semelhantes, terá atingido o seu propósito.
Ao escrever isto, não pretendo apresentá-lo como uma "história de sucesso". É simplesmente alguém que tem sido repetidamente atormentado por problemas específicos em cenários de trabalho específicos, tentando melhorar esses problemas à sua maneira. Quão longe este caminho pode ir, ainda precisa de ser continuamente testado na prática. Mas pelo menos, a direção está certa—deixar os desenvolvedores voltarem ao SQL em si, deixar os utilizadores voltarem aos dados em si, e deixar a ferramenta tratar das coisas desnecessárias pelo meio.