RIA Mais Perto

Manoel Frederico - Gerente de Produto e Magic Evangelista
Manoel Frederico – Gerente de Produto e Magic Evangelista

O desenvolvimento de projetos RIA é provavelmente uma das maiores novidades dos últimos tempos no mundo uniPaaS.

Em várias oportunidades, como encontros de desenvolvedores, apresentações, e mesmo aqui no blog, foram abordados aspectos que tornam este novo modelo bastante atraente (veja aqui). E o uniPaaS é sem dúvida a ferramenta que torna mais fácil esta passagem Desktop ßà RIA. Quem estiver iniciando agora, já inicia bem. E quem já tiver projetos em andamento, tem a tarefa de portá-los para a nova plataforma.

E é sobre isso que vamos abordar a seguir.

Por mais que o uniPaaS se esforce para facilitar este trabalho (através de seu conceito de metadados e deployment nativo), há diferenças efetivas entre a arquitetura/plataforma Desktop/2 Camadas e a RIA/3 Camadas.

Ou seja: um programa RIA (RichClient) não poderá, algumas vezes, ser exatamente igual ao que era na sua versão Desktop (On-Line). Existem alguns ajustes que o desenvolvedor terá de fazer nestas rotinas, dependendo de como ela for originalmente (veja aqui).

E isso sempre traz algumas questões à discussão. A maior delas talvez seja: como dimensionar o esforço/trabalho que possa ser necessário para migrar um projeto (existente) Desktop para RIA. Este é o primeiro passo para se planejar os trabalhos, calcular custos, alocar recursos e programar novos releases.

Pensando nisso, a equipe técnica da MAGIC Brasil criou um utilitário (RIAAdvisor) que pode facilitar esta importante tarefa, fazendo um raio-X do projeto original Desktop e fornecendo um relatório de itens não conformes com a plataforma RIA, que irão requerer ajustes por parte da equipe de desenvolvimento.

NOTA: este utilitário não é um produto da MAGIC Brasil ou da MAGIC Enterprise, mas uma contribuição gratuita para a comunidade uniPaaS. Por isso, não há compromisso formal com evoluções ou suporte do mesmo. Ele é free, mas não é open source.

Este utilitário é composto por dois programas .NET: uniProjectSplitter e uniProjectAnalyzer. Eles foram criados com base em projetos uniPaaS da versão 1.9h. Como a MSE pode alterar a estrutura interna do código-fonte de seus projetos a qualquer tempo, é prudente que sejam utilizados com projetos desta mesma versão: 1.9.

uniProjectSplitter: Ele pega o projeto e divide-o em várias partes (arquivos), no total de N + 1, onde N = nro. de programas no projeto. Então, se o projeto possuir 2587 objetos no repositório de programas (sub-tarefas não são relevantes aqui), serão gerados 2588 arquivos. Cada arquivo gerado terá a extensão .mgcbr. Esta divisão é necessária porque um projeto pode alcançar até gigabytes no tamanho de seu código-fonte (XML).

uniProjectAnalyzer: Ele pega os arquivos (.mgcbr) criados anteriormente, analisa-os, e gera dois relatórios com as inconformidades encontradas: um resumido, e um detalhado. O resumido contém apenas os totalizadores. O detalhado relaciona em qual tarefa, expressão ou formulário o problema foi encontrado.

NOTA: este utilitário trabalha de acordo com a idéia de que o projeto inteiro será convertido, ou seja, todos os programas On-Line serão convertidos em RichClient. Quando este não é o caso, o relatório apresentado mostrará um esforço maior do que o efetivamente necessário.

Estes são os itens que a versão atual (1.0) do utilitário analisa:

NOTA: o termo “tarefa” usado a partir de agora refere-se tanto a um programa quanto a uma sub-tarefa.

1)      Campos OLE/ActiveX em tarefas On-Line: Este tipo de dado não é permitido em tarefas RIA. Precisam ser transferidos para programas batch, que rodam do lado do servidor. Os ActiveX precisam ser convertidos em Controles .NET para poderem ser usados nas telas RIA.

2)      Tarefas On-Line com handler RM Compatible: Esse handler não é permitido em tarefas RIA. O utilitário RM Converter que existe na instalação padrão do uniPaaS faz o trabalho de converter este handler em outros de outros tipos, equivalentes, mas obviamente é prudente testar o funcionamento das tarefas afetadas para certificar-se de que a comportamento anterior foi mantido.

3)      Uso de KBPUT/KBGET: Estas funções não são permitidas em tarefas RIA. O utilitário inclui no relatório as referências encontradas também em tarefas batch (embora somente nas tarefas On-Line elas representem um problema na migração).

4)      Tarefas On-Line sem transação Deferred: Transações físicas não são permitidas em tarefas RIA. As transações em tarefas RIA precisam ser do tipo Deferred. OBS: Quando se altera o tipo de programa de On-Line para RichClient, o Studio altera o seu tipo de transação para deferred se necessário, mas obviamente é prudente testar o funcionamento das tarefas afetadas para certificar-se de que a comportamento anterior foi mantido.

5)      Tarefas Batch que fazem chamadas para tarefas On-Line: Somente tarefas RIA podem fazer chamadas para uma tarefa RIA. Nestes casos, uma opção pode ser converter estas tarefas batch em RIA Não Interativa.

6)      Tarefas On-Line Existentes: Cada tarefa On-Line precisa ter o seu tipo mudado para RIA (através das propriedades da tarefa). Apenas os “programas” são incluídos na análise, porque o Studio possui a opção de trocar as sub-tarefas automaticamente.

7)      Uso de CALLDLL/CALDLLS/CALLDLLF: Estas funções são essencialmente server side, e o melhor é movê-las para programas batch.

8)      Tarefas On-Line com janelas Child ou ChildSplitter: Este tipo de janela (formulário) não é permitido em tarefas RIA. Eles precisam ser alterados.

9)      Tarefas On-Line com RaiseEvent Internal: User Action<1-20>: Estes eventos internos não são permitidos em tarefas RIA. É preciso criar eventos de usuário com estes mesmos nomes, no Main Program, e mudar o RaiseEvent de Internal para User.

10)   Tarefas On-Line com Event Handler Internal: User Action<1-20>: Estes handlers também (obviamente) não são permitidos em tarefas RIA. É preciso criar eventos de usuário com estes mesmos nomes, no Main Program, e mudar o Event (handler) de Internal para User.

11)   Tarefas On-Line com InvokeCOM ou Form Input/Output: Estas instruções não são permitidas em tarefas RIA. É preciso mover estas instruções para tarefas batch.

 

Como utilizar?

 

1)      Executar o checker (F8) em todo o projeto, para remover qualquer erro que possa existir. Especialmente, remover as expressões não utilizadas, pois elas interferem em alguns marcadores.

2)      Exporte o projeto inteiro em um único arquivo XML, numa pasta qualquer:

3)      Execute o utilitário uniProjectSplitter fornecendo o nome completo do XML do projeto (exportado). Serão gerados os respectivos arquivos .mgcbr (na mesma pasta do XML):

NOTA: se houverem alterações no código-fonte do projeto e uma nova exportação, é preciso apagar estes arquivos (.mgcbr) antigos e executar este utilitário novamente.

4)      Execute o utilitário uniProjectAnalyzer fornecendo o nome completo do XML do projeto (exportado). Pelo nome do arquivo do projeto ele identificará os respectivos arquivos .mgcbr e fará a análise:

Os relatórios da análise, Resumido e Detalhado, serão gerados na pasta %Temp%.

5)      Exemplo de relatório resumido:

6)      Exemplo de relatório detalhado:

Baixe o RIAAdvisor neste endereço, e entre de vez na nova era de desenvolvimento de sistemas para internet e multi-dispositivos com o uniPaaS.

Caso prefira, a Magic Software Brasil está realizando projetos de migração de aplicações para RIA. Se quiser analisar esta possibilidade, contate-nos para maiores informações: comercial@magisoftware.com.br

 

Manoel Frederico da Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil

Um comentário

  1. Já vi o trabalho que vou ter… somente meus 2000 programas, todos eles tem UserAction(1-20).. rsrs.. os novos já estão com HandlerEvent User

Deixe um comentário para Eric Abuleiz Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *