Escolar Documentos
Profissional Documentos
Cultura Documentos
xCPML
Guia do Programador
Versão 1.0.7
Julho/2014
Introdução
Representado por um arquivo XML devidamente validado, um script de programação CPM
cuida de toda a lógica operacional de coleta de dados do seu projeto de automação. Para
livrá-lo de detalhes técnicos entediantes, definidos uma camada de abstração que lhe
garante um ambiente de trabalho simples, ágil e muito confortável.
Você poderá usar qualquer editor de texto sem formatação (notepad, gedit, etc) para
programar seus scripts e, dentro em breve, também contará com um ambiente integrado de
desenvolvimento (IDE) intuitivo e cheio de recursos. O CPM roda em qualquer sistema
operacional que suporte uma Java Virtual Machine (JVM), isso inclui o Windows, Linux, OS X
Solaris, etc.
Por ser desenvolvido em Java, necessita que o HOST que o executa, tenha uma versão do
Java devidamente instalado e configurado, para tanto, caso não tenha muita experiência com
esta linguagem, http://www.java.com/pt_BR/download/help/download_options.xml é um bom
lugar para começar.
Importante!
As TAGs XML
Definimos um conjunto de TAGs XML específicas para servir de “comandos” para a
programação dos scripts e, mesmo não sendo muitas TAGs (14 até o momento), decidimos
separá-las em dois grupos básicos: TAGs de projeto e TAGs de programação. As TAGs de
programação são todas aquelas que devem aparecer contidas em um bloco
<program></program> as demais são consideradas, então, TAGs de projeto.
A maioria das TAGs XML definidas possuem um elemento de abertura e outro de fechamento
e devem ser digitadas em “caixa baixa” (letra minúscula). Essas TAGs são containers de
outras, pois você poderá introduzir outras TAGs no interior do bloco que as define. Todas as
TAGs nesta condição respeitam o seguinte formato <x>...</x>, onde o “x” representa um
nome de uma TAG válida, por exemplo: datasource, project, program, etc. Outras TAGs (a
minoria), por não serem containers para outras, não necessitam de elemento de fechamento
(são resolvidas em uma única linha), neste caso, seu formato geral se resume a: <x />.
São exemplos destas TAGs: terminal, get, put e clear.
Novas TAGs surgirão e as atuais, com o tempo, alteradas ou excluídas, mas, não se
preocupe, o CPM sempre saberá executar seus scripts antigos sem que você tenha que
alterá-los.
Entidades XML pré-definidas
Você deve ter notado que a XML define alguns caracteres especiais, por exemplo, os sinais <
(menor que) e > (maior que) são exemplos. Para que não ocorram problemas no processo
de análise do seu script, você deve evitar utilizá-los para outras finalidades que não as
reservadas pela própria linguagem, portanto, deve recorrer a tabela de entidades pré-
definidas apresentada a seguir:
O Projeto
Um arquivo XML deve conter todo o seu projeto de automação, este, por sua vez, é
composto das seguintes TAGs XML de projeto:
Importante!
<project>
REQUERIDA: Sim.
OCORRÊNCIA: Uma por arquivo.
FILHA DE: Ninguém (TAG ancestral de todas as outras).
ATRIBUTO(S) SIGNIFICADO REQUERIDO
name Nome do projeto Sim
version Versão da linguagem (esquema) de definição do projeto. Não
Valor(es) permitido(s) até o momento:
• 1.0
CONTEÚDO: Todas as demais TAGs.
Exemplo
Importante!
• Todo script de programação, deve iniciar com a declaração XML exibida na linha 1.
<datasource>
Esta TAG define uma fonte de dados externa (servidor de dados). Esta fonte
de dados será utilizada tanto para o envio de dados coletados, como
também na validação de uma entrada (digitação).
REQUERIDA: Não.
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <project>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
name Nome da fonte de dados. Sim
type Tipo da fonte de dados. Sim
Valor(es) permitido(s) até o momento:
• http, e;
• sapiens (integração com ERP Sapiens)
CONTEÚDO: <host>
Exemplo
<host>
REQUERIDA Sim.
OCORRÊNCIA Várias por arquivo.
FILHA DE: <datasource>
ATRIBUTO(S) SIGNIFICADO REQUERIDO
port Número da porta HTTP de conexão. Não
username Nome do usuário para autenticação. Não
password Senha do usuário para autenticação. Não
params Define o formato dos parâmetros passados na URL de Não
conexão.
Valores permitidos:
• query (parâmetros passados no formato query
params. Exemplo: ?par1=var1&par2=var2)
• rest (parâmetros passados em formato
semântico. Exemplo: /par1/var1/par2/var2)
Quando esse parâmetro for omitido o formato rest será
assumido.
CONTEÚDO: Identificação do host na rede, podendo ser o IP, nome
do domínio e nome NetBIOS.
Exemplo
<terminal>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <project>
ATRIBUTO(S) SIGNIFICADO REQUERIDO
name Nome de identificação do terminal Sim
ip IP único que identifica o terminal na rede Sim
program Programa associado ao terminal Sim
model Indica o modelo do equipamento controlado. Sim
Valor(es) permitido(s) até o momento:
• COLLETER_TC100
CONTEÚDO: TAG vazia
Exemplo
<program>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <project>
ATRIBUTO(S) SIGNIFICADO REQUERIDO
name Nome único de identificação do programa. Sim
datasource Fonte de dados associado ao programa. Não
session Define o nome da sessão de inicialização quando na Não
execução do projeto. Se ausente, a primeira sessão
definida, será a sessão executada.
CONTEÚDO: Uma ou mais TAGs <session>
Exemplo
Exemplo
Importante!
<say>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTO(S) SIGNIFICADO REQUERIDO
beep Valor numérico que indica a quantidade de sinais Não
sonoros que acompanha a informação enviada ao
equipamento.
wait Valor numérico que indica quantos segundos de espera Não
será aguardado após envio da informação ao
equipamento.
get Recupera informação do DataList (vide sessão Não
específica), processando-a e exibindo-a,
concomitantemente, no display do equipamento. Este
atributo suporta cálculos aritméticos básicos (somas,
subtrações, multiplicações e divisões).
store Aguarda informação do equipamento (digitação ou Não
leitura), armazenando-a na variável definida por esse
atributo.
CONTEÚDO: Dado a ser exibido no display do equipamento.
Exemplo
<store>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
name Nome da variável cujo valor será armazenado no Sim
DataList.
CONTEÚDO: Dado a ser armazenado no DataList.
Exemplo
Esta TAG define o início de um bloco de TAGs cuja execução deve repetir.
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
CONTEÚDO: TAGs componentes do laço de repetição.
Exemplo
<clear>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
CONTEÚDO: TAG sem conteúdo.
Exemplo
Importante!
<calc>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
store Nome da variável que será atribuído o resultado. Sim
CONTEÚDO: Uma expressão aritmética válida.
Exemplo
<jump>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
to Nome de uma variável definida no atributo store Sim
de uma TAG <say>
say Mensagem a ser exibida no display do equipamento. Não
CONTEÚDO: Uma expressão lógica válida. O desvio ocorrerá se
a expressão for avaliada como verdadeira.
Exemplo
Importante!
• Esta TAG é uma alternativa para a estratégia padrão de validação dos dados a cada
entrada (digitação), permitindo ao programador, solicitar nova entrada de acordo com
os dados retornados do servidor.
• Note que esta TAG também reduz o número de chamadas ao servidor
<if>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
session Nome da sessão a ser executada, caso a expressão Não
seja avaliada como verdadeira.
break Abandona a laço <repeat> atual caso a Não
expressão seja avaliada como verdadeira.
error Mensagem de erro a ser exibida, caso a expressão Não
seja avaliada como falsa.
CONTEÚDO: Uma expressão lógica válida.
Exemplo
<get>
REQUERIDA: Não
OCORRÊNCIA: Várias por arquivo.
FILHA DE: <session>
ATRIBUTOS(S) SIGNIFICADO REQUERIDO
ns Namespace(prefixo) atribuído aos dados válidos Sim
recebidos do servidor. Útil para evitar conflito de
nomes.
url URL da fonte de dados no servidor. Sim
CONTEÚDO: TAG vazia.
Exemplo
<put>
Exemplo
O DataList
O CPM define o DataList como uma área para armazenar as variáveis do script de
programação. Os valores presentes no DataList são eliminados a cada início de sessão e
atualizados nas seguintes situações:
• O DataList armazena seus dados em “fila”, portanto, o primeiro que entra é o primeiro
que sai quando na “montagem” de uma requisição HTTP. Observe o trecho de
programa abaixo:
http://meudominio.com/service/cep/n/12943390
Note que, “service=cep” (linha 9), foi introduzido no DataList antes de “n=12943390” (linha
10), portanto - graças à organização em fila do DataList - sairá também antes, quando na
formação da requisição.
Fonte de dados
O diagrama abaixo define o protocolo utilizado pelo CPM quando na comunicação com um
servidor WEB (HTTP/HTTPS). Neste formato, a comunicação se dá através da formatação e
envio dos dados presentes no DataList. Em resposta, uma String JSON será recebida,
avaliada e, caso uma condição de erro não seja encontrada, os dados recebidos serão
prefixados e inseridos no DataList, ficando assim, disponíveis para uso como se digitado
pelo operador eles fossem..
O diagrama a seguir, esclarece o fluxo lógico para tratamento da mesma requisição, só que
desta vez, do lado do servidor WEB.
Expressões aritmética e lógicas
O CPM suporta os seguintes operadores:
• Aritméticos
SÍMBOLO SIGNIFICADO
+ Soma
- Subtração
* Multiplicação
/ Divisão
Importante!
Os parênteses são aceitos em expressões aritméticas para efeito de mudança na prioridade
de avaliação dos operadores.
• Lógicos
SÍMBOLO SIGNIFICADO
ne Diferente (not equal)
eq Igual (equal)
lt Menor que (less than)
gt Maior que (great than)
le Menor ou igual (less or equal)
ge Maior ou igual (great or equal)
Projeto Calculadora
Abaixo você encontrará um exemplo completo de script CPM de projeto. Esse script faz uso
das principais TAGs XML de projeto e programação para desenvolver uma calculadora
simples de 4 operações para duas entradas de dados: “a” e “b”.
----