Migração MSDAORA para ORAOLEDB - Troca do SELECT

Na minha postagem anterior dei uma visão geral do projeto. Para os técnicos pode ter sido uma decepção, principalmente para aqueles que estão enfrentando os mesmos problemas, pois a exposição era muito teórica. Na postagem de hoje, vou ser um pouco mais técnico, mostrando como fiz a conversão das páginas que continham o comando SQL SELECT, sem contudo descer ao nível dos comandos de programação.

Um fato que facilitou muito a conversão, foi a padronização do código, o que me permitiu a busca dos pontos que deveriam ser alterados sem muitas variações.

Descreverei o processo de conversão, para que você, usando qualquer linguagem de programação possa repeti-lo. Como dito na postagem anterior, fiz a conversão utilizando o ORACLE PL/SQL. Não pretendo descer ao nível do código, mostrando os comandos, mas falar de um processo que pode ser repetido. Mostrar o código ajudaria muito pouco, uma vez que existem particularidades em cada aplicação e suas páginas que dificultam a criação de uma ferramenta de conversão automática que atenda a todas as necessidades. A criação dessa ferramenta estava fora do escopo do projeto.

A primeira atividade do programa, foi adicionar à página uma função para buscar uma nova conexão ao Banco de Dados (BD). Isso foi feito colocando um novo INCLUDE do arquivo que contém a função de busca de conexões logo após a primeira linha.

A função de busca de conexões é um pouco mais complexa no novo provider (ORAOLEDB) que no antigo. Então, em uma postagem específica, detalharei a sua construção.

!--#include file="/ConnectionOracle.asp"-->

Depois passei a identificar a criação do RecordSet para transformá-lo. No MSDAORA, a característica era a seguinte:

         set rsXxx = server.createObject("ADODB.RecordSet")
         rsXxx.open "comandoSql", "String de Conexão", ...

Onde: rsXxx é o nome do RecordSet

Essas linhas passaram a ter as seguintes características no ORAOLEDB:

 set conn = getConnection("XXX")
 set rsXxx = conn.createDynaset( "comandoSql", 0 )

Observe que eu troquei a criação do objeto no MSDAORA por uma chamada a uma função, onde passo o nome do BD que quero acessar. Essa função é responsável por criar o objeto de conexão e devolvê-lo à página. A função getConnection(BD) foi incluída na página ao adicionarmos um INCLUDE como primeiro passo.

Basicamente o que o programa de conversão precisou fazer, foi encontrar uma linha com o texto "server.createObject" e dentro dela identificar e guardar o nome do "RecordSet", que sempre era a primeira "palavra" depois do comando "set". Identificada a linha e o "RecordSet", bastou trocá-la pela linha com a obtenção da conexão no novo provider.

Depois, precisei localizar uma linha que tivesse a seguinte característica:

         "nomeDoRecordSet".open

Bastando trocá-la pelo comando do novo provider.

         set "nomeDoRecordSet" = conn.createDynaset( sql , 0 )

Com esses dois passos, conseguir trocar todas as páginas do sistema que continham o comando SQL SELECT.

Na próxima postagem discorrerei como foi a troca da páginas com chamadas às Stored Procedures.

Migração MSDAORA para ORAOLEDB

Recentemente fui procurado pela diretoria de uma empresa para resolver-lhes um problema técnico que muito lhes afligia: Com o advento do Windows 2008 Server, a Microsoft parou de dar suporte OLEDB através do seu provedor de acesso, conhecido com MSDAORA (Microsoft 'Data Access Object' for Oracle). Este acesso existia desde os tempos do Windows NT. Evidentemente uma empresa tenta colocar a responsablidade na outra.

Dessa forma, sobrou para os seus clientes o ônus de resolver o problema. E não é um problema qualquer, pelo menos para o meu cliente (acesse o site). Vejam o seu cenário:

Sua aplicação, um Sistema de Cobrança de Inadimplência (Call Center especializado em cobrança), totalmente desenvolvido para web, usa as seguintes tecnologias:

Servidor de Web: Microsoft IIS
Páginas da Web: ASP Clássico
Banco de Dados: Oracle 10 em diante
Sistema Operacional: Windows até 2003 para servidor de web / qualquer Sistema Operacional que suporte Oracle para o servidor de banco de Dados.
Características arquiteturais:
1) 95% das regras de negócio escritas em PL/SQL (liguagem para criação de Stored Procedures da Oracle)
2) As páginas ASP só tocam o BD para fazer "SELECTS" e chamar Stored Procedures.
3) Nenhum UPDATE, DELETE ou INSERT é utilizado.
4) O controle das transações (Commit/Rollback) também é feito pelas Stored Procedures.

Minha primeira ação foi buscar na Internet ferramentas que me possiilitassem fazer a conversão automática. Achei algumas, mas todas falharam na conversão da chamada as Stored Procedures.

Nos passos iniciais, contei também com a ajuda do meu amigo Alexandre Nascimento, Gerente de Desenvolvimento de Sistemas da i-Hunter que me passou os primeiros exemplos de página invocando o "provider" da Oracle. Ao Alexandre e a i-Hunter meus sinceros agradecimentos.

Quantidade de Artefatos (programas ou páginas ASP):
ASA: 3
ASP: 848
INCLUDES: 490
JS: 31
Total: 1.372

Com a consciência do cenário acima, utilizei a seguinte abordagem:
A) Conversão manual de uma página que invoca Stored Procedures.
b) Conversão manual de uma página com comando SELECT.
C) Teste das páginas convertidas manualmente.
D) Medição do tempo investido nas atividades acima ("A", "B" e "C"). O tempo foi de 1h por artefato, o que projetou um custo de cerca noventa mil reais (R$ 90.000,00), três meses de trabalho utilizando três recursos.

Passando a fase seguinte, ainda fazendo a prova de conceito, tomei as seguintes ações:
E) Criação de um modelo de dados com apenas duas tabelas (ARQUIVO [id do Arquivo, Diretório ASP, Nome do Arquivo ASP e Extensão]e LINHA [id do Arquivo, Número da Linha Original, Conteúdo da linha Original, Número da Linha Convertida, Conteúdo da Linha Convertida]).
F) Programa de carga para levar os arquivos de código para as tabelas.
G) Três programas: Um para conversão dos SELECTs, um para conversão de STORED PROCEDURE e um para gravação do resultado.
H) Teste dos artefatos convertidos e refino dos programas acima.

Quando considerei que os programas estavam maduros, coloquei o processo para executar para todos os demais artefatos do sistema.

O processo fez a conversão de todos artefatos em apenas dois (2) minutos.
Observação:
B.1) Utilizei o PL/SQL para escrever os programas de carga e migração.
B.2) Foram utilizadas cento e sessenta (160) horas nessas atividades.

O resultado final foi o seguinte:

- Troca de um projeto:
   De 1.400 horas por um projetos de 160 horas.
   De R$ 90.000 por um projeto de R$ 10.400.

Isso tudo com a confiabililidade de um processo automatizado.

Caso você precise de mais detalhes, poste um comentário ou escreva para o meu e-mail.

---

Clique aqui e veja a postagem sobre a troca do comando SQL SELECT.