Protheus – do AP5 ao P11

Introdução

Desde o surgimento do Advanced Protheus 5.07 em 1999, até o Protheus 11, o produto ganhou novos módulos, funcionalidades e recursos. Desde implementações e extensões da Linguagem AdvPL, até o FrameWork AdvPL com MVC. Porém, até o momento não ouvi falar de nenhuma análise técnica entre as versões. Então, após ressuscitar alguns CDs de instalação antigos, e fazer algumas medições, eu cheguei a alguns números aproximados muito, muito interessantes.

Do Protheus 5 ao Protheus 11

Informações por Versão Ap5 Ap6 Ap7 Mp8 P10 P11
Tabelas (SX2) 991 1394 1681 1677 3700 6368
Índices (SIX) 2190 3124 4107 4249 8770 14868
Campos (SX3) 16306 22042 27087 27545 59420 103951
Campos Virtuais 1281 1746 2261 2104 5284 8890
Maior numero de campos 168 169 176 163 200 267
Maior tamanho de Registro 1794 3761 3761 3761 4022 4909
Tabela com mais índices 14 15 18 26 20 28
Índice com mais Campos 12 12 13 14 14 14
Índice com maior chave 152 203 212 214 232 505
Tamanho do RPO (MB) 28 44 44 36 60 174
Funções no RPO 15104 21665 24601 26177 46026 79811
Classes no RPO 57 57 61 287 603 2451
Resources RPO 2445 3604 4107 4455 7975 15928
Entrada no ERP – SIGAFAT
Memória Consumida (MB) 10,63 10,47 12,48 12,06 15,74 49,22
Chamadas de funções básicas do AdvPl 34690 35682 44170 36615 63844 377300
Chamadas de funções do Repositório 8423 8598 9128 3944 6444 53066
Chamadas de Operadores 514403 576713 614246 363848 589606 4287337
Memoria para Carga de Fontes (MB) 1,8 2,3 2,41 2,91 4,8 14,9
Fontes Carregados 38 44 47 52 72 215

Analisando por cima os dados encontrados, podemos ver que do Protheus 10 para  Protheus 11 houve um salto bem maior em relação às versões anteriores. Houveram muitas implementações no ERP, módulos novos, MVC, ferramentas, integrações e controles adicionais.

 

Ao migrar do P10 para o P11, muitos clientes precisaram refazer o “sizing” de máquina. Na verdade, sempre ao migrar de versão um “sizing” de máquina deve ser avaliado, pois dependendo do tamanho do ambiente, um aumento de consumo de memoria ou CPU de 10 % pode representar um número grande em valores absolutos. No caso do P10 para o P11, o salto foi muito grande, mesmo quem usava o P10 com uma folga razoável de hardware precisou mexer no parque de máquinas para escalar o ambiente.

Os dados obtidos com esta pesquisa são meramente informativos, e foram obtidos em sua maioria com as versões de repositório original do CD, e dicionários sem customização. Foi um trabalho muito gostoso rever as telas de todas as versões de produto que eu trabalhei direta ou indiretamente nos últimos 17 anos, funcionando em um Windows 10 😀

Evolução da Interface

A interface da aplicação ERP foi evoluindo e ganhando novos layouts e funcionalidades ao longo das versões do ERP Microsiga. No TDN, têm um post muito interessante, com vários prints de interface, de todas as versões do ERP Microsiga, desde as primeiras versões Windows (antes do Protheus), até o P12 !! Vale a pena conferir, você pode acessar pelo link http://tdn.totvs.com/display/framework/Microsiga+Protheus

Conclusão

Com o crescimento da plataforma de negócios e de todo o parque de soluções rodando em AdvPl em cima da plataforma TotvsTec, o desafio constante de aprimorar a plataforma e implementar recursos para tornar viável a implementação e operacionalização de soluções cada vez maiores faz parte da rotina diária de todos os colaboradores da TOTVS 😀

Desejo a todos TERABYTES de sucesso !!!

Abraços e Saudações 😉 

 

 

Damas em AdvPL

Introdução

Em 2006, eu fiz um jogo de Damas em AdvPL, para jogar contra o Computador. Não cheguei a reforçar muito o algoritmo de decisão, mas ficou bom o suficiente pra dar um pouco de trabalho. O fonte ainda está cm alguns remendos, ainda não está pronto para um post de fins didáticos, MAS, atendendo a pedidos no FaceBook, estou disponibilizando um Patch da P11 (RPO TOP / Português) do Jogo, para degustação 😀

O Jogo

Após aplicar o patch, basta iniciar o SmartClient com a função “U_APGAMES”, e será mostrada a interface abaixo, para você entrar com o NickName do Jogador.

Checkers003

Após inserir o NickName e clicar em “Iniciar”, inicia-se o jogo de Damas. Você joga com as pedras amarelas, e o computador com as azuis. Você inicia a partida. Para jogar, primeiro você clica em cima de uma pedra sua, depois clica no lugar onde a sua pedra deve ser movimentada, vide sequência abaixo:

Checkers006a

Checkers006b

Checkers006c

Assim que você jogar, o computador jogará uma pedra dele. E já é a sua vez de novo.

Regras

  • As pedras normais somente movimentam-se para a frente.Em nenhuma hipótese uma pedra normal movimenta-se para trás.
  • Não existe “assopro”. Se você oferecer uma ou mais pedras ao computador, ele é obrigado a comer a sua pedra, e vice-versa.
  • Se mais de uma pedra for oferecida, o adversário escolhe como e qual pedra ele vai atacar.
  • Ao chegar do outro lado do tabuleiro com uma pedra normal, ela vira uma “Dama”.
  • A Dama pode mover-se para a frente e para trás, mas apenas UMA CASA por vez.
  • O mecanismo de navegação do Computador é “reativo”, então para você ganhar o jogo, você tem que encurralar o computador e fazer ele entregar as suas peças.
  • É mais fácil vencê-lo em jogo aberto, havendo troca de peças, e você abrindo caminho primeiro para fazer uma Dama. Mas cuidado com as “arapucas”, ele pode oferecer “inocentemente” uma pedra, e limpar duas ou três suas. 😉

Patch

O Patch do jogo está disponível para download no link “https://github.com/siga0984/Blog/blob/master/tttp110_APGames.zip” . Basta abrir a página, e clicar em “View RAW”, no final da página, para o Browse fazer o Dowload do ZIP contendo o Patch.

Conclusão

Existem diversas melhorias previstas no design do jogo, e inclusive a separação completa do core do jogo e da interface, além da utilização de orientação a objetos. Uma vez passado a limpo, o jogo será disponibilizado na íntegra, co os fontes 😀

Espero que vocês gostem do desafio, joguem um pouco contra o algoritmo, postem seus resultados no FaceBook 😉 E se você gostou, faça como eu: Compartilhe 😀

Desejo a todos TERABYTES de SUCESSO 😀 Abraços 😉 

 

RunTime do AdvPL

Introdução

No primeiro post do Blog, em apenas um parágrafo foi dada uma definição bem sintética do que é o AdvPL: Trata-se de uma uma linguagem de programação estruturada com suporte a orientação de objetos, que roda em uma máquina virtual com arquitetura client-server e multi-plataforma.

Hoje vamos entrar um pouco mais fundo em algumas características da execução de um código AdvPL, desde a pré-compilação até a execução do Código. Mas antes, vamos com algumas definições.

Código AdvPL

A sintaxe da linguagem AdvPL é uma extensão da sintaxe xBase, mais conhecida pelo seu uso na linguagem Clipper. Um código fonte em AdvPL passa por uma etapa de pré-compilação, onde vários comandos são transformados em chamadas de funções, e “açúcares sintáticos” podem ser implementados, através de #defines, #translates, #command(s), #ifdef(s) e afins. Os comandos da linguagem AdvPL que realmente são “comandos” são as instruções de decisão e iteração, como WHILE, FOR, IF, ELSEIF , ELSE, CASE, END … praticamente todo o resto dos comandos são implementações feitas por #command, #xcommand ou #translate, que permitem você usar por exemplo um “comando” de abertura de tabela, como o comando “USE <cTabela> ALIAS <cAlias> [ SHARED | EXCLUSIVE ] [ VIA <cRdd> ] [READONLY] [NEW]”, que na etapa de pré-compilação vai ser transformando internamente na chamada da função DbUseArea().

Pré-compilação

Tanto o IDE como o TDS (versão anterior e atual do Ambiente de Desenvolvimento de aplicações AdvPL, respectivamente) trabalham com um pré-compilador (appre.exe). A partir do fonte AdvPL e dos respectivos #include(s) utilizados no código, a pré-compilação gera um novo arquivo, chamado de PPO (Pre Processed Output), e este sim é o código enviado ao AppServer para ser compilado.

Compilação

A compilação deste código gera um “ByteCode” em formato proprietário, interpretável somente pela máquina virtual do AppServer. O ByteCode gerado é criptografado e armazenado em um arquivo de repositório de objetos, configurado no AppServer para o ambiente onde os fontes estão sendo compilados. Damos o nome de “ambiente” a um espaço virtual de execução, que engloba um repositório de objetos e um ponto de acesso a uma pasta no disco (local ou remota via rede) para acesso a arquivos sob este identificador de ambiente, entre outras configurações de acesso a dados relacionais e comportamentos desejados para a instância do ambiente.

Repositório de Objetos

Armazena as funções e classes compiladas a partir dos fontes AdvPL, é fornecido pela TOTVS contendo as compilações dos módulos do ERP Microsiga do produto padrão. Contém também as funções do Framework AdvPL, usadas pelos fontes dos demais módulos, e que também são usados em customizações do produto, onde o próprio cliente pode criar um código em AdvPL, usando-se das funções básicas e de Framework AdvPL para customizar o produto padrão através de pontos de entrada (compilação de funções de usuário — USER FUNCTION(s) — com nomes especificos, onde existem pontos de chamada realizados pelo produto padrão do ERP), ou mesmo criando novas funcionalidades.

O repositório possui mecanismos de verificação de integridade e proteção de código, para evitar a engenharia reversa dos fontes compilados. A reversão de código é possível, e às vezes necessária quando um cliente por exemplo “perde” os fontes das customizações da versão em uso do seu ERP, e precisa delas no momento de uma migração de versão. O procedimento de “descompilação” neste caso é solicitado para a TOTVS mediante abertura de chamado, onde cada caso é avaliado.

O repositório de objetos também guarda arquivos de imagem (BMP,PNG,JPG), que podem ser inseridos em um Projeto AdvPL através do IDE/TDS e recuperados posteriormente em tempo de execução e usados diretamente por algumas funções, classes e comandos da linguagem que montam a interface da aplicação.

O Protheus 12 utiliza uma nova engine da máquina virtual do AppServer, com um novo formato de ByteCode, com mais instruções de baixo nível. Isto tornou o ByteCode ligeiramente maior, porém com ganhos de desempenho em alguns processos e funcionalidades.

Execução do AdvPL

Partindo de uma execução de um programa AdvPL, iniciado a partir do SmartClient, o SmartClient faz um HandShake com o AppServer via conexão TCP (ou SSL caso configurado), e solicita a execução de uma função. Ela pode ser uma “Main Function” — Função de entrada de módulo ou ferramenta do ERP — ou uma “User Function” — aplicações ou customizações criadas em AdvPL pelo próprio cliente.

Como o AdvPL é essencialmente dinâmico, os fontes do repositório são carregados na memória sob demanda, conforme as funções vão sendo chamadas. Quando o Menu do ERP é apresentado, todos os programas já carregados e executados até então, essencialmente fontes do Framework do AdvPL são mantidos na memória. Ao chamar uma opção de menu, o fonte e suas dependências são carregados sob demanda e executados, e quando o usuário encerra a opção e volta ao Menu do ERP, todos os fontes carregados desde o início daquela opção são descarregados da memória.

Quando a excecução é a chamada de menu da interface MDI (SIGAMDI), cada opção de menu cria um contexto e uma conexão separada com o AppServer, permitindo a execução de múltiplos programas sob a mesma interface, onde cada execução possui seu contexto e processo independentes. Cada opção de menu finalizada encerra o seu próprio conexto e descarrega todos os prograas da memória. Ao usar o mecanismo de Balanceamento de Carga do AdvPL, cada nova opção de Menu do MDI pode ser direcionada para o AppServer com menos processos em execução.

Para jobs, não existe balanceamento de carga nativo. Cada Job é executado na instância do serviço onde o AppServer está sendo executado. Hoje podemos emular um balanceamento realizando um RPC para um determinado serviço e subindo o job via RPC ( Nativo do AdvPL).

Atualmente o contexto de uma execução em AdvPL está implicitamente amarrado com uma Thread do Sistema Operacional. A arquitetura multi-thread do AppServer não estabelece afinidade entre as CPUS físicas do equipamento, o Scheduler de tarefas do sistema operacional e encarregado de distribuir as Threads e realocá-las por CPU a seu critério. Devido ao cenário extremamente variável de peso de execução das Threads, tentar estabelecer uma afinidade tende a ser pior do que deixar o sistema operacional escolher a CPU em uso.

AdvPL com interface – SmartClient

A execução de processos de interface AdvPL com o SmartClient é síncrona, a aplicação SmartClient é a resposável por renderizar a interface (Janela ou diálogo) construída pela aplicação AdvPL, e uma vez que a interface seja “ativada”, o AppServer passa a esperar por uma interação do usuário no SmartClient, como pressionar um botão ou preencher um campo. Entre ambos existe um mecanismo de verificação de conexão, chamado “pulso”. Quando o AppServer está aguardando por uma interação do usuário com a interface, mesmo que o usuário não dispare nenhum evento, a cada 60 segundos o SmartClient dispara um evento interno de “pulso” para o AppServer , para indicar que o SmartClient ainda está aberto. Caso o AppServer nao receba nenhum evento ou nenhum pulso do SmartClient em 3 minutos, ele assume que o SmartClient não está mais conseguindo se comunicar com o AppServer , e derruba/finaliza o processo em execução no AppServer , liberando os recursos utilizados ( arquivos e registros bloqueados, licenças, conexão com DBAccess,etc ).

Depuração de Código AdvPL

Através do IDE e/ou TDS, podemos depurar (ou “debugar”) um código AdvPL, colocando pontos de parada, inspecionando variáveis de memória, e determinando as etapas de execução (step into, step over, step out, run…). Deve-se tomar uma atenção especial no uso dos “Watches” de execução, pois a chamada de funções dentro de um “Watch” podem mudar o comportamento da aplicação, como por exemplo reposicionar o ponteiro de registro atual de uma tabela de dados, mudando o comportamento da aplicação enquanto ela está sendo depurada. Normalmente usamos os Watches para variáveis de memória. Através da Janela de Comandos do IDE/TDS, também podemos executar expressões, e até mudar conteúdos de variáveis durante a depuração através de instruções de atribuição. Isto pode ser útil em muitas situações.

Uso de memória

Normalmente a memória alocada por um programa é limpa quando o programa é finalizado. Durante a execução de código, existem algumas limpezas realizadas nos destrutores de componentes de interface, e no retorno ao stack (pilha) anterior após a execução de funções do Repositório de Objetos. Normalmente objetos são limpos quando não são mais referenciados, porém caso seja feita uma referência circular entre objetos, a limpeza somente ocorre quando a aplicação termina, ou quando for realizada explicitamente por uma função chamada “FreeObj()”.

Existem diversos recursos de monitoramento de memória do AppServer, um dos mais utilizados é a configuração DebugThreadUsedMemory, que pode ser habilitada no appserver.ini, na seção [GENERAL]. Esta configuração faz com que o AppServer mostre no Monitor de Processos do AppServer a quantidade de memória aproximada em uso por cada processo em execução.

Conclusão

Boa parte dos recursos mencionados neste tópico estão documentados no site oficial de documentação da TOTVS, o TDN (Totvs Development Network), que pode ser acessado no link http://tdn.totvs.com. O Post de hoje é só pra “molhar” o bico, os próximos posts em momento oportuno vão entrar em mais detalhes de cada uma destas operações 😀

Agradeço a audiência de todos, e desejo a vocês TERABYTES de sucesso !!! 

Abraços 😉