A Ferramenta por linha de comando embutida no TOTVS | Application Server permite diversas operações relacionadas a manipulação do RPO e execução de rotinas em batch. A ferramenta pode ser utilizada em processos de automação com a plataforma TOTVSTEC.
Parâmetros de linha do TOTVS | Application Server.
| Parâmetro de Linha | Sistema Operacional | Descrição | Observações |
|---|---|---|---|
Opção Run-console ou -debug | Windows | Executa o TOTVS | Application Server em modo console. | |
-daemon ou daemon | Linux | Executa o TOTVS | Application Server como um daemon no Linux. |
|
| -version | Linux / Windows | Exibe a versão do TOTVS | Application Server. |
|
| -fullversion | Linux / Windows | Exibe informações mais completas sobre a versão do Application Server. tais como: Build Version, Profile (Debug, Release ou Release com Debug), Arquitetura, Plataforma, data de geração e demais informações. |
|
-ini=<config_file.ini> ou -ini <config_file.ini> | Linux / Windows | Define um arquivo de configuração alternativo ao padrão do TOTVS | Application Server. |
|
| -install | Windows | Instalar o TOTVS | Application Server como um serviço do Windows. | |
| -remove | Windows | Remover o serviço do Windows do TOTVS | Application Server. | |
| -compile | Windows / Linux | Operações relacionadas ao acesso e alteração do repositório (RPO) | Opção de linha do comando para operações de alteração e manutenção do RPO. Detalhes do comando disponível em: AppServer Command Line - Compilação por linha de comando |
| -run | Windows / Linux | Operações relacionadas a execução de rotinas diretamente no TOTVS | Application Server. | Opção de linha do comando para operações de execução de rotinas RPO. Detalhes do comando disponível em: AppServer Command Line - Execução por linha de comando |
| -help | Windows / Linux | Exibe no console uma ajuda com as opções disponíveis no TOTVS | Application Server Command Line |
DISPONÍVEL A PARTIR DA VERSÃO 17.3.0.9
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Necessário para inicialização da ferramenta | Sim | |
| -files | Informa quais fontes serão compilados podendo ser informado das seguintes formas:
| Sim | |
| -includes | Informa o diretório de includes usado durante a o pré-processamento dos fontes. | Sim | |
| -env | Informa o ambiente que deverá ser acessado para compilação. | Sim | |
| -nodelfiles | Utilizado para debug, caso informado, não deleta os arquivos gerados durante o pré-processamento e também mantem os arquivos temporários .Lst gerados durante o processo. | Não | |
| -authorization | Informa a chave de compilação no formato de arquivo .aut, padrão TDS / TDSCli ou, o token de compilação no formato de arquivo .token, no padrão JWT. | Não | A PARTIR DA VERSÃO 20.3.2.0, NÃO SERÁ MAIS UTILIZADA A AUTORIZAÇÃO DA CHAVE DE COMPILAÇÃO. |
| -outreport | Gera os arquivos compile_sucess.log, que contem a lista de fontes compilados com sucesso no formato do arquivo .lst, e compile_errors.log, que contem a lista de fontes não compilados e os erros de compilação. A partir da versão 17.3.0.19, também é possível definir o diretório de saída para esses arquivos. | Não | DISPONÍVEL A PARTIR DA VERSÃO 17.3.0.15 |
| -exclude=<regex> | Define um padrão regex para exclusão de arquivos no processo de compilação. Os arquivos que satisfizerem o regex indicado serão ignorados. O regex deve ser informado no padrão da bilbioteca RE2, a syntax pode ser encontrada aqui. | Não | |
| -ignoresubdirs | Quando essa opção as subpastas dos caminhos de compilação serão ignorados. |
Tipo de arquivo com extensão .lst que pode conter uma lista de fontes e resources no formato de path absoluto, ou diretórios para compilação. Quando houverem diretórios, um novo arquivo .lst temporário com prefixo _generated será gerado para a extração dos arquivos contidos no diretório informado, compondo assim uma nova lista de arquivos a serem compilados. Por meio do parâmetro nodelfiles, é possível manter também esses arquivos temporários para análise.
O conteúdo do arquivo deverá respeitar as seguintes regras:
Veja o exemplo de arquivo anexado: exemplo.lst
Exemplos:
appserver.exe -compile -files=D:\totvs\lobo-guara\cmdline\teste.prw -includes=C:\totvs\lobo-guara\Include -src=D:\totvs\lobo-guara\cmdline -env=environment
appserver.exe -compile -files=D:\totvs\lobo-guara\cmdline -includes=C:\totvs\lobo-guara\Include -src=D:\totvs\lobo-guara\cmdline-env=environment
appserver.exe -compile -files=D:\totvs\lobo-guara\cmdline\lista.lst -includes=C:\totvs\lobo-guara\Include -src=D:\totvs\lobo-guara\cmdline -env=environment
Observação:
A partir da versão 20.3.2.0, os recursos de geração e de autenticação por meio de uma chave de compilação foram descontinuados. Será utilizado somente o token de compilação. Caso haja alguma tentativa de utilização destes parâmetros sejam será exibo um aviso informativo, "The Compilation key feature is no longer supported and the compilation token must be used from now on".
Compatível com a chave de compilação gerada e utilizada no TDS e TDSCli. Para a utilização da ferramenta Compile, é preciso exportar as informações de uma nova ou já existente chave criando um arquivo com extensão .aut. No Linux, é utilizado o mesmo padrão de criação de chave realizando o controle pelo UUID do disco porem, a chave é criada e criptografada utilizando algoritmo AES 256bits.
Exemplos:
Windows
[AUTHORIZATION] ID=FA15-EB7C GENERATION=12/02/2019 VALIDATION=13/05/2019 PERMISSION=1 KEY=042MQC032QYIQ74A1E7671302
Linux
[AUTHORIZATION] ID=d40f3aa2-d5ae-4a0b-a0f5-a44e29bcd344 GENERATION=20/02/2019 VALIDATION=21/05/2019 PERMISSION=1 KEY=gjvqs3U7vInn/VcX9Hl0Av2is+mLrr4j/BxHMdyR7uPaOcQC7OVtTIWhIMU0/5AkfipUxQukozs121WVNafNyQ==
Para criação de uma nova chave no Linux, será necessário a coleta do UUID onde a ferramenta está instalada e posteriormente entrar em contato com a Tecnologia - AppServer.
Comando para obtenção do UUID no linux:
./appsrvlinux -compile -uuid
Recurso para geração de path. Por default, os patchs serão gerados na pasta "cmdgenpatch" dentro do Environment.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Necessário para inicialização da ferramenta | Sim | |
| -genpatch | Indica geração de Patch | Sim | |
| -files | Informa os arquivos que irão compor o patch da seguinte forma:
| Sim | |
| -deletefiles | Informa quais arquivos irão ser deletados ao aplicar o patch.
| Não | DISPONÍVEL A PARTIR DA VERSÃO 20.3.2.15 |
| -env | Informa o ambiente que deverá ser acessado para compilação. | Sim | |
| -patchtype | Extensão de patch: ptm, upd ou pak. Por default, é gerado com extensão ptm. | Não | |
| -npatchtype | Mesmo que o parametro "patchtype" mas recebe valor numerico onde 1: UDP, 2: PAK, 3: PTM | Não | |
| -outgenpatch | Permite a definição de um diretório de output. | Não | DISPONÍVEL A PARTIR DA VERSÃO 17.3.0.19 |
Exemplos:
appserver.exe -compile -genpatch -files=mainfunc.prw -env=environment -patchtype=ptm
appserver.exe -compile -genpatch -files=mainfunc.prw;teste.prw -env=environment -patchtype=ptm
appserver.exe -compile -genpatch -files=D:\totvs\lobo-guara\patch.lst -env=environment -patchtype=ptm
appserver.exe -compile -genpatch -files=D:\totvs\lobo-guara\patch.lst -env=environment -patchtype=ptm -outgenpatch=d:\patchs\teste1
DISPONÍVEL A PARTIR DA VERSÃO 17.3.0.20
Este recurso permite ao desenvolvedor adicionar uma etapa de verificação do Patch antes de aplicá-lo. O resultado dessa verificação pode ser armazenado em um arquivo Log e analisado posteriormente.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Necessário para inicialização da ferramenta | Sim | |
| -validatePatch | Indica Validação de Patch | Sim | |
| -files | Informa o patch a ser aplicado com extensão ("PTM", "UPD" E "PAK"). | Sim | |
| -env | Informa o ambiente que deverá ser acessado para compilação. | Sim | |
| -outreport | Gera o arquivo patch_errors.log contendo o resultado da verificação de patch. Também é possível definir o diretório de saída para esse arquivo. | Não |
Exemplo:
appserver.exe -compile -validatepatch -files=D:\totvs\patch\tttp120.ptm -env=advplc -outreport
Recurso para aplicação de Patch.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Necessário para inicialização da ferramenta | Sim | |
| -applypatch | Indica aplicação de Patch | Sim | |
| -files | Informa o patch a ser aplicado com extensão ("PTM", "UPD" E "PAK"). | Sim | |
| -env | Informa o ambiente que deverá ser acessado para compilação. | Sim | |
| -applyoldprogram | Informa que serão aceitos fontes mais antigos que o RPO. Por default, aceita somente os fontes mais novos. | Não | |
| -cbfiles | Interno. Não é possível utilizar sem o token interno da TOTVS. | Não | DISPONÍVEL A PARTIR DA VERSÃO 20.3.1.3 |
Exemplo:
appserver.exe -compile -applypatch -files=D:\totvs\patch\tttp120.ptm -env=advplc -applyoldprogram
DISPONÍVEL A PARTIR DA VERSÃO 24.3.0.1
Recurso ConvertRPO para converter o RPO para nova versão de criptografia. Esse recurso só pode ser usado para converter o RPO Custom, o RPO Default não pode ser convertido.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Inicialização da ferramenta. | Sim | |
| -convertrpo | Informa que será realizado a função que converte o RPO para nova versão de criptografia. | Sim | |
| -env | Informa o ambiente que deverá ser desfragmentado. | Sim |
Exemplo:
appserver.exe -compile -convertrpo -env=advplc
Recurso DefragRPO para desfragmentação de RPO.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Inicialização da ferramenta. | Sim | |
| -defragrpo | Indica desfragmentação de RPO. | Sim | |
| -env | Informa o ambiente que deverá ser desfragmentado. | Sim |
Exemplo:
appserver.exe -compile -defragrpo -env=advplc
Recurso para verificar a integridade o RPO e definir o status do RPO como produtivo (production). Este recurso é de uso exclusivo da TOTVS pois é necessário um token de compilação com status produtivo.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Inicialização da ferramenta. | Sim | |
| -revalidateRPO | Indica revalidação do RPO. | Sim | |
| -env | Informa o ambiente que deverá ser revalidado. | Sim | |
| -authorization | Token com status produtivo para revalidação do RPO | Sim |
Exemplo:
appserver.exe -compile -revalidateRPO -env=advplc -authorization=prod.token
DISPONÍVEL A PARTIR DA VERSÃO 20.3.0.0
Realiza a inspeção de objetos (Fontes e recursos) no RPO de acordo com as regras de acesso: com token de autorização faz a inspeção no RPO default e sem token, faz a inspeção no RPO Custom. Por padrão, serão retornadas informações sobre "Resources" e "Sources", mas também é possível aplicar filtros para selecionar as informações desejadas.
O resultado será gravado no arquivo "inspector_objects.txt" contendo as informações: Data e hora de geração do arquivo, número total de objetos encontrados, filtros aplicados, ambiente, nome do objeto, data e hora, status do objeto e o tipo do RPO.
Caso não seja encontrado nenhum objeto no RPO, o arquivo de resultados será gerado sem o conteúdo listado e também será registrado uma mensagem no arquivo de log "inspectorobjects_errors.log".
Importante
| Source Status | Descrição |
|---|---|
| 0 | No Status (No Authorization) |
| 1 | Production |
| 2 | Development |
Importante
| RpoType | Descrição |
|---|---|
| 1 | Padrão |
| 2 | TLPP |
| 3 | Custom |
| 4 | Auxiliar |
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Inicialização da ferramenta. | Sim | |
| -inspectorobjects | inspetor de Objetos | Sim | |
| -env | Informa o ambiente | Sim | |
-applyField | Indica se a pesquisa deverá ser feita considerando apenas "Resources" ou "Sources". Por exemplo -applyField=sources. Por padrão retornará Sources e Resources. | Não | |
-authorization | Indica o token de compilação que irá selecionar o RPO a ser inspecionado. Caso não seja informado, o RPO Custom será selecionado por padrão. | Não | |
-outputdir | Define o diretório de saída para o arquivo no formato txt que contêm as informações coletadas. O diretório padrão é a pasta cmdoutpudir dentro do RoothPath. Também é possível alterar o diretório de saída para esse arquivo informando outro diretório. Por exemplo: -outputdir=c:\totvs\outrodir | Não | |
-outreport | Gera o arquivo inspectorobjects_erros.log. Por padrão, o diretório de saída do arquivo é na pasta cmdreport dentro do RootPath. Também é possível alterar o path de saída do arquivo indicando outro diretório. Por exemplo: -outreport=c:\totvs\report. | Não |
Exemplo:
./appserver -compile -inspectorobjects -env=test -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando apenas Resources:
./appserver -compile -inspectorobjects -env=test -applyField=resources -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando apenas Sources:
./appserver -compile -inspectorobjects -env=test -applyField=sources -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando fontes e recursos com token de compilação
./appserver -compile -inspectorobjects -env=test -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs -authorization=c:\tmp\development.token
DISPONÍVEL A PARTIR DA VERSÃO 20.3.0.0
Realiza a inspeção de Funções (Funções, Classes e Métodos) no RPO de acordo com as regras de acesso: com token de autorização faz a inspeção no RPO default e sem token, faz a inspeção no RPO Custom. Por padrão, serão retornadas informações sobre "Funções", "Classes" e "Métodos", mas também é possível aplicar filtros para selecionar as informações desejadas.
O resultado será gravado no arquivo "inspector_functions.txt" contendo as informações: Data e hora de geração do arquivo, número total de funções, classes e métodos encontrados, filtros aplicados, ambiente, nome da função, nome do objeto, número da linha, status do fonte e o tipo do RPO.
Caso não seja encontrado nenhuma função, Classe ou Método no RPO, o arquivo de resultados será gerado sem o conteúdo listado e também será registrado uma mensagem no arquivo de log "inspectorfunctions_errors.log".
Registros onde o nome da função é #NONE, significa que o fonte está vazio e não tem nenhuma função.
Importante
| Source Status | Descrição |
|---|---|
| 0 | No Status (No Authorization) |
| 1 | Production |
| 2 | Development |
Importante
| RpoType | Descrição |
|---|---|
| 1 | Padrão |
| 2 | TLPP |
| 3 | Custom |
| 4 | Auxiliar |
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -compile | Inicialização da ferramenta. | Sim | |
| -inspectorfunctions | inspetor de Funções | Sim | |
| -env | Informa o ambiente | Sim | |
-applyField | Indica se a pesquisa deverá ser feita considerando apenas "Functions" ou "ClassMethods". Por exemplo -applyField=functions. Por padrão retornará Functions, Class e Methods. | Não | |
-authorization | Indica o token de compilação que irá selecionar o RPO a ser inspecionado. Caso não seja informado, o RPO Custom será selecionado por padrão. | Não | |
-outputdir | Define o diretório de saída para o arquivo no formato txt que contêm as informações coletadas. O diretório padrão é a pasta cmdoutpudir dentro do RoothPath. Também é possível alterar o diretório de saída para esse arquivo informando outro diretório. Por exemplo: -outputdir=c:\totvs\outrodir | Não | |
-outreport | Gera o arquivo inspectorfunctions_erros.log. Por padrão, o diretório de saída do arquivo é na pasta cmdreport dentro do RootPath. Também é possível alterar o path de saída do arquivo indicando outro diretório. Por exemplo: -outreport=c:\totvs\report. | Não |
Exemplo:
./appserver -compile -inspectorfunctions -env=test -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando apenas Functions:
./appserver -compile -inspectorfunctions -env=test -applyField=functions -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando apenas Classes e Metódos:
./appserver -compile -inspectorfunctions -env=test -applyField=classmethods -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs
Exemplo listando funções, classes e métodos com token de compilação
./appserver -compile -inspectorfunctions -env=test -outputdir=c:\tmp\inspector -outreport=c:\tmp\inspector\logs -authorization=c:\tmp\development.token
DISPONÍVEL A PARTIR DA VERSÃO 17.3.0.9
Com este recurso, é possível executar programas TLPP, ADVPL e 4GL que não tenham interface gráfica utilizando apenas o TOTVS | Application Server. Lembrando que é possível somente a execução de Main e User Function.
O retorno da função ADVPL executada deverá ser inteiro. Esse retorno será o código de saída do processo.
| Nome | Descrição | Obrigatório | Observações |
|---|---|---|---|
| -run | Necessário para inicialização da ferramenta. Informa a função que será executada. | Sim | |
| -env | Necessário para informar o ambiente que deverá ser acessado para execução. | Sim | |
| -consolelog | Indica se deve forçar a gravação no console.log. Por padrão algumas informações já são gravadas no console.log, entretanto, caso esse parâmetro seja definido mais informações serão gravadas. | Não | |
| Parâmetros extras da função a ser executada | Informa os parâmetros extras da função que será executada. Não é preciso indica-los com nenhum operador, basta separa-los por espaço. Importante: o programa ADVPL/TLPP irá receber todos os parâmetros presentes na chamada do appserver.exe e não somente os parâmetros extras. | Não |
Exemplo estrutura genérica
Windows: appserver.exe -run=<nomeDaFuncao> -env=<nomeDoEnvironment> <quaisquer outros parâmetros para a função>
Linux: ./appsrvlinux -run=<nomeDaFuncao> -env=<nomeDoEnvironment> <quaisquer outros parâmetros para a função>
Exemplo estrutura prática
Exemplo de função, execução e saída esperada com passagem de parâmetros:
Main Function FuncRunAdvpl(parm As Variadic)
Local i
Conout(parm:vCount)
For i := 1 To parm:vCount
Conout(parm:vArgs[i])
Next
Return 1
Comando de execução:
appserver.exe -run=funcRunAdvpl -env=chg teste lalala
O recurso Variadic está disponível apenas para a linguagem TLPP.
Documentação: Variadic
Exemplo de função, execução e saída esperada utilizando entrada padrão
Exemplo de função, execução e saída esperada com passagem de parâmetros:
Main Function Soma()
Local n1
Local n2
Conout("Digite o primeiro valor:")
n1 := Val(conin())
Conout("Digite o segundo valor:")
n2 := Val(conin())
Conout("Soma:" + cValToChar(n1+n2))
Return 0
Comando de execução:
appserver.exe -run=soma -env=chg
Exemplo de programa 4GL:
MAIN
CALL Conout("Teste 4GL")
END MAIN
Comando de execução:
appserver.exe -run=teste4GL.4GL -env=p1212410sql
