Protheus

Projeto autoral para estudar Protheus em Docker com configuração versionada, automação operacional e práticas iniciais de DevOps.

Projeto autoral para aprender TL++ construindo uma ferramenta real de documentação para diferentes gerações de APIs REST Protheus.

Quando alguém fala em usar PostgreSQL com Protheus, pode estar descrevendo duas arquiteturas bem diferentes. Na primeira, o PostgreSQL é o banco transacional do ERP. AppServer, DBAccess, driver e banco fazem parte do caminho usado pelas operações do Protheus. Na segunda, o ERP continua em seu banco atual, enquanto uma instância PostgreSQL separada recebe dados para integrações, APIs, relatórios ou aplicações próprias. As duas opções são válidas, mas resolvem problemas distintos. Misturá-las na mesma conversa costuma gerar expectativas erradas sobre homologação, acesso aos dados, desempenho e responsabilidade operacional. ...

Depois de organizar o ambiente, automatizar sua preparação e exercitar o backup e a restauração do PostgreSQL, faltava responder a uma pergunta: o que pode ser validado continuamente sem distribuir os artefatos do Protheus nem iniciar o ERP? A quinta parte do Protheus Docker Lab encerra esta série com um workflow de integração contínua para a configuração versionada e os scripts do projeto. Ela também registra os limites dessa automação, porque um pipeline aprovado não significa, sozinho, que o ambiente Protheus está funcional. ...

No Hello World REST em TL++ , publicamos uma operação pequena e verificamos seus metadados no YAML produzido pelo REST-DOC. A etapa seguinte foi implementar uma resposta equivalente em AdvPL, usando WSRESTFUL, e repetir a exportação. Os dois endpoints responderam corretamente às requisições autenticadas. Na documentação gerada, porém, o resultado foi diferente: a operação TL++ apareceu; a operação AdvPL não foi encontrada. Essa comparação ajuda a delimitar o problema que o Protheus OpenAPI pretende investigar. Publicar um serviço e descobrir seus metadados são capacidades que precisam ser verificadas separadamente. ...

Uma validação começa com poucas condições. Depois recebe uma mensagem na tela, uma consulta de parâmetro, uma atualização de registro e uma exceção para determinado processo. Quando alguém precisa mudar a regra, já é difícil saber quais outros comportamentos serão afetados. No artigo AdvPL não precisa ser código legado , discuti como decisões de organização influenciam o custo de manutenção. Aqui, vamos trabalhar uma dessas decisões: separar responsabilidades dentro de uma rotina sem transformar uma alteração pequena em uma reescrita. ...

Depois de automatizar a configuração local , precisamos saber o que acontece com os dados quando o ambiente para, volta ou tem seus contêineres recriados. A Parte 4 do Protheus Docker Lab já está publicada. Ela reúne o inventário de persistência, o backup do PostgreSQL, um ensaio de restauração em banco separado e a rotina de manutenção. Este artigo acompanha a versão 4310980 do repositório . As evidências citadas são as documentadas na execução de 12/09/2026. ...

O primeiro experimento do Protheus OpenAPI começou com uma rota pequena: receber uma requisição GET e devolver um JSON com três campos. Esse recorte permitiu investigar duas perguntas: consigo publicar um endpoint REST em TL++ no ambiente do laboratório? E quais informações desse endpoint aparecem na documentação produzida pelo gerador nativo? No artigo de apresentação , mostrei como essa investigação contribuiu para a proposta do projeto. Agora, vou detalhar o caminho entre o fonte TL++, a resposta HTTP e o artefato gerado pelo REST-DOC. ...

Versão de referência: este artigo foi revisado com base no commit 3dfe986 , que registra a automação e a validação local da terceira parte do Protheus Docker Lab. Um ambiente reproduzível não deveria depender de uma lista de comandos lembrada apenas por quem o criou. Depois de organizar os serviços e arquivos do Protheus Docker Lab , a etapa seguinte foi transformar o procedimento documentado em um fluxo operacional pequeno, previsível e seguro para os arquivos locais. ...

Documentar uma API parece simples enquanto código e documentação nascem juntos. O problema aparece depois. Uma rota muda, um parâmetro é acrescentado, uma resposta ganha outro formato e a especificação continua descrevendo a versão anterior. Aos poucos, o contrato que deveria ajudar consumidores, testes e integrações deixa de representar o serviço publicado. No Protheus, existe ainda uma dificuldade adicional: APIs REST desenvolvidas em momentos diferentes podem usar modelos diferentes. De um lado estão endpoints TL++ baseados em annotations. De outro, serviços AdvPL construídos com WSRESTFUL, WSMETHOD e estruturas relacionadas. ...