Acesso a dados – Drivers e RDDs no AdvPL

Introdução

Qualquer aplicação que trabalhe com persistência ou armazenamento de dados precisa ter uma forma eficiente de leitura e gravação destes dados. A maneira, forma ou aplicação usada para armazená-los deve ser a que melhor atende as suas necessidades, sejam elas de volume de dados, organização, ou desempenho de busca ou processamento.

Na linguagem AdvPL, temos acesso aos drivers chamados “locais”, para arquivos no disco em uma instância única de Application Server, e acesso a dados em arquitetura client-server, como o c-Tree Server, e bancos relacionais (SGBD’s) acessados através do gateway DBAccess. Neste post vamos nos aprofundar um pouco no armazenamento e acesso a dados do Protheus, com foco maior no acesso a dados em bancos relacionais homologados através do DBAccess.

Acesso a Dados no AdvPL

O AdvPL possui uma série de funções de acesso a dados, baseados na arquitetura xBase, de raiz ISAM, desenhada para obterm um excelente desempenho em acessos a dados sequenciais e indexados. Sua implementação é baseada no conceito de Drivers de Acesso, conhecido desde o Clipper como “RDD” (Replaceable Database Driver). Uma RDD possui uma série de funções pré-definidas, com comportamentos pré-definidos. Logo, ela funciona como uma abstração de acesso às informações, independente do meio físico onde a informação esteja armazenada.

Por exemplo, ao criar um programa que crie uma tabela, abra e popule alguns registros, originalmente para trabalhar com uma tabela no formato DBF, informamos o nome do Driver (ou RDD) que deve ser utilizada como parâmetro nas funções de criação da tabela e de abertura da tabela. Normalmente precisamos apenas alterar o nome do Driver neste programa para ele usar outro meio físico de armazenamento, sendo que o programa mantém as suas características funcionais.

DBF  e c-Tree

Com o surgimento do Protheus em 1999, sendo lançada a primeira versão do ERP Microsiga usando o AP5 (Advanced Protheus 5), o Protheus possuía uma versão do AP5Server para Windows 9x e uma para Windows NT, um Client de Interface, um IDE e um Monitor de processos, todos para Windows. O ERP Microsiga poderia usar arquivos no formato DBF para armazenar os meta-dados (dicionários) do ERP, e os dados efetivamente do ERP poderiam ser armazenados em DBF, usando ADS Local ou ADS Server, ou armazenados em um banco relacional homologado, acessado através do TOPConnect 2.x.

Pensando em oferecer outras opções de armazenamento de dados, E pensando também no porte do servidor de aplicação para o sistema operacional Linux, a Microsiga fez uma parceria com a empresa de software norte-americana Faircom(r), que fornece uma API de acesso a dados client-server e multi-plataforma. Como até aquele momento todo o software do ERP estava escrito para realizar manutenção e consulta dos dados usando RDDs ISAM, o desafio de tecnologia era implementar uma RDD nova, chamada CTREECDX, para ser usada como armazenamento dos meta-dados e/ou dos dados principais da aplicação. Como os primeiros testes realizados com os portes iniciais de Driver DBF para Linux apresentavam instabilidades operacionais em cenários de concorrência, optou-se por fazer uma parceria com a Faircom, e criar em conjunto uma versão especifica do c-Tree ACE para atender as necessidades e características de acesso a dados necessárias pela aplicação já existente, visando reaproveitar o máximo de código AdvPL possível, trocando nos códigos apenas o nome da RDD, e mantendo os comportamentos esperados.

Também com pequenas alterações, a RDD foi criada, e para minimizar mais ainda as alterações de código nos fontes já existentes, como as tabelas de dados da aplicação já eram abertas pelo ERP usando funções de FrameWork, e a abertura de arquivos de meta-dados e arquivos de dados temporários usava a RDD chamada “DBFCDX”, foi criado um parâmetro de configuração no Application Server, chamado localfiles, para permitir informar qual o driver que seria endereçado “por baixo” da aplicação, quando ela usasse o driver “DBFCDX”.

Com isso, bastava você criar um ambiente vazio, usando na configuração do ambiente (environment) a configuração localfiles=ctree, para que qualquer código fonte escrito usando o driver “DBFCDX” passasse a usar o motor de acesso a dados do c-Tree. Em ambientes Linux, não se têm a opção de usar DBF, apenas c-Tree. Houve também uma iniciativa de implementar uma RDD Btrieve(r) para acesso a meta-dados e dados da aplicação, mas devido a descontinuidade do fabricante da aplicação, esta RDD foi abandonada.

Como ainda havia a necessidade de alguns sistemas legados de fazer integrações com arquivos em formato DBF, foi criado um driver chamado “DBFCDXADS”, que ao ser utilizado, utiliza o driver do ADS Local para acesso aos dados. Logo, mesmo que o seu localfiles seja ctree, em um ambiente Windows, é possível abrir uma tabela em formato DBF. Com o novo porte do Application Server para 64 bits, o suporte a este driver foi descontinuado, e não está presente na Build 64 bits do Application Server.

Acesso a dados relacionais – SQL

Na época existia o TOPConnect 2, que também foi portado para Linux, mas existia uma versão específica para cada SGDB. MSSQL 6,5, MSSQL 7, Sybase, DB2, Oracle, PostgreSQL, Informix… A TOTVS optou por reescrever este gateway, dando-lhe o nome de TOPCOnnect 4.x, também multi-plataforma, mas com uma única versão (multi-database), capaz de se conectar com todos os bancos homologados. No lançamento do ERP Protheus 10, o TOPCOnnect 4.x passou por uma re-estruturação, ganhou mais funcionalidades, e passou a ser chamado TOTVSDBAccess, e posteriormente apenas DBAccess.

Com o uso de bancos relacionais, desde o TOPConnect 2, foi implementada uma forma de leitura de dados usando queries, ao invés da engine ISAM de acesso. Uma query é aberta na aplicação AdvPL como se fosse um ALIAS normal de sistema, aberta em modo exclusivo e somente leitura, onde a navegação nos registros é apenas para frente (Read-only e forward-only). Isto permite obter dados de mais de uma tabela, de forma mais simples e eficaz do que a abordagem ISAM.

Porém, o DBAccess mantém uma camada de acesso ISAM emulado, para que todos os códigos que usavam a RDD “TOPCONN” continuassem funcionando. E, as inserções e alterações de dados também são feitas usando este paradigma, com diversas otimizações para manter o comportamento da forma mais escalavel possível.

Acessando os dados pelo DBAccess

Através do DBAccess, podemos acessar os dados gravados nas tabelas usando Queries, havendo apenas a necessidade de algumas instruções adicionais para a abertura do “Alias” ou área de trabalho da query, devido a razões de compatibilidade de armazenamento. As queries dos módulos do software padrão do ERP Microsiga são escritas usando um conjunto de regras definidos pela Microsiga, chamado “SIGASQL”, que é muito parecido com o SQL ANSI, com algumas restrições e sintaxe pré-definida. Antes de submeter a query ao banco de dados, é usada uma função do FrameWork AdvPL chamada “ChangeQuery”, que verifica qual é o SGDB em uso, e realiza os ajustes necessários na Query para ela ser adequada / transformada para ser executada no banco em questão. Caso seja necessário em algum ponto específico do código, que seja usada uma abordagem ou instrução não suportada pela ChangeQuery, a aplicação AdvPL deve verificar qual o banco de dados da conexão atual (tcGetDB), e montar a query com a sintaxe específica para aquele SGDB, sem passar ela pela ChangeQuery(). A vantagem de uso da ChanegQuery() está na portabilidade. A utilização dela visa tornar transparente uma eventual migração do software entre SGDBs diferentes, ou mesmo a homologação de um novo SGDB, onde a ChangeQuery fará “por baixo” eventuais adequações para um novo SGDB homologado.

Convenções do SIGASQL

– Caso seja desejado obter uma coluna calculada a partir da concatenação de duas colunas, deve ser utilizado o operador “||” (dois pipes).
– Caso seja necessário extrair uma parte de uma string na Query, deve-se utilizar a função SUBSTRING().
– São permitidos apenas ANSI JOINS. Os JOINS com *= e afins não são suportados.
– Podem ser usados UNION, UNION ALL, ORDER BY, GROUP BY e até selects encadeados.

Existem outras características relacionadas diretamente com estes aspectos, acredito que elas são abordados em maiores detalhes na documentação da função ChangeQuery() na TDN, no link “http://tdn.totvs.com/display/public/mp/ChangeQuery“.E, existe outra documentação bem interessante na TDN, onde outros aspectos e alternativas de desenvolvimento com Queries em Advpl são abordadas, como por exemplo o “Embedded SQL”. Veja o documento na íntegra no link “http://tdn.totvs.com/display/framework/Desenvolvendo+queries+no+Protheus“.

Acesso a dados ISAM emulado pelo DBAccess

Uma tabela de dados criada pelo DBAccess pode ser acessada simplesmente abrindo a tabela diretamente pela função DbUseArea(), informando o nome físico da tabela e a RDD TOPCONN. Com algumas restrições, as funcionalidades de filtro (DbSetFilter), criação de índices (OrdCreate), busca ordenada (DbSetOrder/DbSeek), navegação (DbSkip/DbGoTop/DbGoBottom), deleção lógica (DbDelete) e demais operações são suportadas.

Os tipos de dados armazenados no SGDB não necessariamente são os mesmos dos dados originais do AdvPL. Por exemplo, um campo do tipo “D” data no AdvPL, será gravado como um campo Char(8) ou Varchar(8) no SGDB, o tipo lógico “L” no AdvPL será gravado como Char(1) ou Varchar(1), contendo as letras ‘T’ ou ‘F’. Um campo “M” Memo pode ser gravado usando vários tipos de container, porém estes dados são sempre acessados pelo ALIAS da tabela, não são recuperados por Query.

RDDs no AdvPL

O TOTVS application server oferece várias alternativas de acesso a dados. Nem todas são homologadas em todas as versões do executável do Application Server em todas as plataformas, algumas também não são homologadas pelos produtos do ERP Microsiga.

“DBFCDX” : Driver de acesso aos arquivos locais, ou meta-dados (dicionário do ERP). Sensível à configuração de ambiente “Localfiles” do arquivo de configuração do Application Server, seu default é “ADS” para plataforma Windows (usando DLLs do ADS Local), e CTREE para plataformas Linux (sensível a configuração CtreeMode do Application Server, pode tanto fazer acesso usando o driver local do c-Tree como através da mtCient.dll a um c-Tree Server).

“CTREECDX” : Driver de acesso a arquivos via c-Tree. Caso o Application Server não esteja configurado para conectar a um c-Tree Server, é carregada uma versão do driver local do c-Tree (ctreestd.dll) para acesso aos dados. Caso um ambiente vá utilizar mais de um Application Server, deve ser usado o c-Tree Server.

“DBFCDXADS” : Driver de acesso a arquivos via ADS Local. Pode ser utilizado em customizaçoes e integrações, apenas nas versões 32 bits do TOTVS Application Server para Windows.

“DBFCDXAX” : Driver para uso com ADS Server, não mais homologado pelas recentes versões de produtos do ERP Microsiga, acessava um ADS Server usando uma das versões de DLL client do ADS (ACE) distribuídas junto do executável do Application Server.

“TOPCONN” : Driver de acesso a tabelas em bancos relacionais, através do TOPCOnnect / DBAccess. Permite a execução de Queries. Existem vários bancos homologados para os produtos do ERP Microsiga, e o Driver TOPCONN também permite uma conexão direta via ODBC, chamada ODBC Genérica — desde que configurada no DBAccess Server — para acessar qualquer outra fonte de dados. Porém, neste caso, não há emulação de ISAM (Não é possível usar a ODBC genérica como base principal de dados do ERP), mas é possível executar statements diretamente pela conexão e abrir queries para consulta de dados. A ODBC genérica normalmente utilizada em integrações customizadas.

“CTREETMP” : Driver de acesso a arquivos temporários exclusivos por processo, implementado a partir da build 7.00.131227A do Application Server, encapsulado pelas funções FWOPENTEMP e FWCLOSETEMP. Utilizam um c-Tree Server DLL distribuído junto do pacote de eecutáveis do Application Server, para criar arquivos temporários na máquina onde a instância do Application Server está sendo executada, ao invés de criar na pasta raiz do ambiente (RootPath). Em ambientes com balanceamento de carga, é extremanente performática, pois não usa a conexão TCP (rede) para acessar os dados.

Qual driver devo utilizar

A aplicação padrão usa os drivers TOPCONN para informações do banco de dados da aplicação ERP, e a rdd local “DBFCDX” para os meta-dados e arquivos temporários — quando usada a função CriaTrab() do Framework AdvPL. Quando podemos usar um arquivo temporário que não precisa ser compartilhado com outros processos, podemos usar as funções FWOPENTEMP() e FWCLOSETEMP() para criar um arquivo temporário ‘local’ na máquina onde o Protheus Server está sendo executado, eliminando o overhead de acesso via rede.

A questão da escolha do local de armazenamento deve levar em conta de onde vêm a informação que será alimentada o arquivo, qual é o tamanho estimado destas informações, e qual é o tempo de vida desta informação. Um dos “mandamentos” do desempenho diz que, quanto mais perto do algoritmo estão os dados, melhor.

Uma tabela temporária criada para um procedimento exclusivo, como uma consulta ou um browse de informações em tela, onde o algoritmo está no AdvPL, e a informação será percorrida várias vezes, pode muito bem utilizar uma Query para recuperar as informações do SGBD, e armazená-la em uma tabela temporária exclusiva, usando a FwOpenTemp(). Uma vez criada, todas as iterações com estes dados estão isentos do overhead de rede, porém apenas o processo atual têm acesso a estes dados. E, caso a aplicação termine de forma inesperada (erro, queda de conexão, etc), estes dados estão “já eram”.

Se eles faziam parde de um processo demorado, onde vários resultados intermediários já haviam sido armazenados nela, tudo terá que ser refeito, a não ser que os resultados parciais já tenham sido gravados na base principal durante o processamento, e uma nova solicitação de processamento leve em conta que os dados já processados podem ser ignorados, uma segunda requisição do processo somente vai processar o que “falta”. Se os dados eram para consulta, não tem problema eles terem “evaporado”.

Quando conseguimos aplicar a regra de negócio direto no SGDB, podemos criar uma tabela para fins temporários no SGDB, alimentá-la com uma Query, por exemplo, sem precisar trafegar a informação pela rede, e depois fazer updates em blocos de informações usando instruções SQL ou Stored Procedures, eliminando a necessidade de tráfego do “grosso” dos dados ao Application Server, ou pelo menos conseguimos fazer uma parte do processo direto no SGDB, e trafegamos para o Application Server apenas os dados relevantes ao algoritmo, quando as regras de processamento estão no código AdvPL.

Existem outros aspectos que também precisam ser levados em conta, como por exemplo a necessidade de se ter todos os dados prontos de uma vez. Quando isto não é necessário, os dados podem ser trafegados sob demanda, o que evita do início de um processo paralelizável “sugar” o banco ou a banda de rede … Mas isto já seria tema para um post mais avançado sobre escalabilidade e performance.

Conclusão

Cada driver oferece vantagens e desvantagens em um determinado cenário. Nem sempre as respostas para tudo vão estar escritas e algum lugar. Na dúvida entre duas abordagens, teste e meça a eficiência do resultado (consumo de recursos e tempo de processo).

Espero que os posts de hoje tenham sido de alguma forma úteis, agradeço de novo a audiência, e desejo a todos mais TERABYTES de sucesso 😀 Até o próximo post, pessoal 😉