TESTANDO WEB SERVICES

1 – CONCEITOS
1.1 - O que é um WebService

Web Service é uma solução utilizada para integrar Sistemas e na comunicação entre
aplicações de plataformas diferentes. Com este recurso é possível que novas aplicações
possam ser integradas com aplicações já existentes e que Sistemas desenvolvidos em
plataformas distintas sejam compatíveis.

Os Web Services são componentes que permitem as aplicações enviar e receber dados no
formato XML. Cada aplicações pode ter sua linguagem, que será traduzida para o XML,
fazendo com que em certo ponto utilizem a mesma linguagem para comunicação.

1.2 - Como Funciona um WebService

A comunicação dos Web Services baseiam-se no protocolo SOAP (Simple Object Access
Protocol). O protocolo SOAP utiliza geralmente o HTTP para transferência das informações.

Com isto, em vez de usar HTTP para pedir uma página HTML para ser visualizada em um
navegador, o SOAP envia uma mensagem de XML através do pedido HTTP e recebe uma
resposta, se existir, através da resposta do HTTP.

Utilizando o Web Service internamente no Sistema, via Regra LSP ou via MCDebug, como
veremos mais a frente, a comunicação ocorre internamente no Sistema. Assim, quando é
efetuada uma chamada de Web Service internamente pelo Sistema, o Web Service chama
diretamente a rotina que irá efetuar o processamento, não necessitando de camadas
intermediárias para direcionar o processamento do Web Service.

1.3 - Quais Web Services estão disponíveis e onde encontrá-los

A lista dos Web Services disponíveis em cada Sistema deve ser obtida no Editor de Serviços,
dentro de cada Sistema, nos caminhos abaixo:

ERP: Recursos > Implementações > WebServices > Editar

Regente: Diversos > Serviços > Editor
RH e Acesso: Recursos > Implementações > Editor Web Services

Importante: Os Web Services padrões do Sistema iniciam seu nome em com.senior.g5,

continuando com a sigla do Sistema.Módulo.Gestão.Rotina

Exemplo. com.senior.g5.co.mcm.est.estoques

1.4 - Diferença entre WS Padrão, de Terceiros e Personalizados

Dentro dos Web Services disponíveis para uso nos Sistemas Senior temos 3 tipos de Web
Services, sendo eles:
- Web Services Padrões:
- Web Services Personalizados:
- Web Services de Terceiros
1.4.1 - Web Services Padrões

São disponibilizados juntamente com o Sistema, sendo programado pela área de

Desenvolvimento. Não é possível alterar seu comportamento padrão ou personalizar as
portas (métodos) liberadas;
É possível adicionar novas portas (métodos) dentro de um WebService Padrão, criando
assim uma porta personalizada, com a mesma estrutura de um Web Service personalizado.

Os Web Services padrões são identificáveis conforme o ícone abaixo:

1.4.2 - Web Services Personalizados

São Web Services criados ou customizados de acordo com a necessidade do Cliente. Todas
as portas de entrada e saída de informações são customizadas.
O comportamento e processamento deste tipo de Web Service é controlado via regra LSP,
programada dentro do próprio Web Service.

Os Web Services Customizados são identificáveis conforme o ícone abaixo:

1.4.3 - Web Services de Terceiros

São Web Services disponibilizados por outros Sistemas, não Senior, e são “importados” para
o Sistema Senior. Não é possível alterar seu comportamento ou personalizar suas portas
(métodos). O Sistema Senior somente irá efetuar a chamada do Web Service sendo que o
processamento ocorrerá no outro Sistema.

Um Web Service de Terceiros será adicionado dentro de um provedor diferente do provedor

interno, onde estão disponíveis os Web Services Padrões e Personalizados.

Importante: O cadastramento de um Provedor de Terceiros deve ser efetuado

manualmente dentro do Sistema Senior, verificando as informações constantes na
documentação do Web Service ou no WSDL do mesmo.

2 – FUNCIONAMENTO

2.1 - A estrutura de um WebService

Um Web Service é composto basicamente 2 itens principais. Sendo os itens 2 e 3 descritos

abaixo. Estes itens irão compor o Web Service (1).

1– Web Service;

2– Portas de Comunicação
3– Parâmetros de Entrada e Saída

As portas de comunicação são os métodos do WebService. Ou seja, é a rotina que irá ser
executada pelo Sistema. Os parâmetros desta porta são as entradas de dados para
processamento e a saída que será devolvida após o processamento da rotina pelo Sistema.

Um Web Service pode ter mais de uma porta (método), conforme a área do WebService. O
exemplo abaixo ilustra um Web Service que possui mais de uma porta (método) para a
mesma rotina do Sistema (Pedidos).
É possível também que o Web Service possua somente parâmetros de entrada ou somente
parâmetros de saída.
Havendo somente parâmetros de entrada o Web Service não devolverá nenhuma
informação sobre o processamento. Caso houver somente parâmetros de saída, não será
necessário informar nenhuma informação para execução do Web Service, bastando somente
invocá-lo para obter o resultado.

2.2 - Parâmetros de Entrada e Saída

Dentro de cada Web Service poderá haver parâmetros de entrada e saída. Alguns destes
parâmetros de entrada podem ser obrigatórios. A informação da obrigatoriedade dos
parâmetros de entrada pode ser verificada dentro do editor de Serviços. Após clicar sobre a
porta ou parâmetro tabela do Web Service será apresentada uma tabela com os parâmetros
e informações sobre o tipo e obrigatoriedade.

É importante que sejam verificados os parâmetros obrigatórios do Web Service para sua
execução correta.
 2.3 - Conceito de Grid (tabela) nos Web Services

A grande vantagem no uso dos Web Services é o conceito de múltiplos registros dentro da
mesma chamada do Serviço. Ou seja, pode-se inserir uma grande quantidade de
informações distintas dentro da mesma execução, onde o Sistema irá “decompor” esta
mensagem e irá processar os vários registros enviados.

Esta diferença fica visível se comparar-mos a inclusão de um Pedido via Ação SID e via Web
Service.

- Para a inclusão de um Pedido simples via ação SID por exemplo, é necessário a execução
das seguintes ações:

SID.Ped.Gravar
SID.Ped.GravarProduto ou SID.Ped.GravarServico
SID.Ped.GravarObservacao
SID.Ped.Fechar

- Para a inclusão de um Pedido Simples via Web Service é necessário a execução do Web
Service com.senior.g5.co.mcm.ven.pedidos@GravarPedidos.Pedido

Neste caso, o parâmetro “Pedido” é do tipo tabela, onde podemos inserir vários pedidos
dentro desta tabela.
Dentro da tabela “Pedido” estão disponíveis as tabelas “Produto”, “Servico” e “Observação”.
Assim, pode-se criar uma tabela contendo vários pedidos e dentro deste pedido vários
produtos para cada pedido, conforme exemplo abaixo:

Como os pedidos serão tratados de forma separada ao chegarem no Sistema, pode-se

controlar o comportamento do pedido individualmente. Como por exemplo, um pedido pode
ser fechado ao ser inserido e outro pedido pode ser mantido em aberto.

O retorno do processamento também será devolvido em uma tabela, contendo as

informações de cada pedido e de cada item do pedido. Assim, quando ocorrer um problema
na inclusão de um Pedido por exemplo, pode-se verificar em que item do pedido o problema
ocorreu.

Importante: Os Web Services que possuem retorno em tabela retornam a informação do

processamento no retorno “mais externo” e o retorno sobre o processamento de cada item
nos retornos de cada tabela. É importante verificar todos os campos de retorno quando
ocorre alguma situação adversa na execução do Web Service.
Chamada do WebService: Retorno do Web Service:

<GravarPedidos> <GravarPedidos>
<Pedido> <RespostaPedido>
Empresa: 1 Empresa: 1
Filial: 1 Filial: 1
Pedido: 1 Pedido: 1
Cliente: 10 Retorno: Inserido com Sucesso
Fecha Pedido: S <Produto>
<Produto> Seq. Item: 1
Seq. Item: 1 Pedido: 1
Pedido: 1 Retorno: OK
Produto: 1101 </Produto>
</Produto> <Produto>
<Produto> Seq. Item: 2
Seq. Item: 2 Pedido: 1
Pedido: 1 Retorno: OK
Produto: 1102 </Produto>
</Produto> </RespostaPedido>
</Pedido> <RespostaPedido>
<Pedido> Empresa: 1
Empresa: 1 Filial: 1
Filial: 1 Pedido: 2
Pedido: 2 Retorno: Pedido Inserido Parcialmente
Cliente: 20 <Produto>
Fecha Pedido: N Seq. Item: 1
<Produto> Pedido: 2
Seq. Item: 1 Retorno: OK
Pedido: 2 </Produto>
Produto: 1501 <Produto>
</Produto> Seq. Item: 2
<Produto> Pedido: 2
Seq. Item: 2 Retorno: Falta Estoque
Pedido: 2 </Produto>
Produto: 1502 </RespostaPedido>
</Produto> </GravarPedidos>
</Pedido>
</GravarPedidos>

2.4 - Campos de Usuário

Alguns Web Services possibilitam que sejam inseridas informações nos campos de usuário
presentes na tabela envolvida no processo.
Para verificar se o Web Service possui este recurso, deve-se verificar se o Web Service
possui uma tabela chamada “Usuario”, conforme imagem abaixo. É possível informar mais
de um campo de usuário dentro de cada tabela, inserindo assim vários registros nos
campos de usuário de uma única vez.
3 - CHAMADA DE UM WEBSERVICE PADRÃO OU
PERSONALIZADO
3.1 - Chamando um WebService via MCDEBUG
Os Sistemas Senior possuem um modo de execução chamado “Modo Depuração de Web
Services”. Este recurso possibilita executar um Web Service internamente no Sistema, sem
a necessidade de Sistemas Externos ou componentes do Middleware Senior instalado.

A interface de execução do Web Service é composta de uma tela com os parâmetros de

entrada e os campos de saída, bastando o usuário informar os parâmetros obrigatórios,
verificamos no Editor de Serviços.

3.1.1 - Como executar o Sistema com o -MCDEBUG

Para executar o Sistema em modo de Depuração de Web Service, deve-se adicionar o

parâmetro –MCDEBUG no atalho do executável do Sistema.

Exemplos:
C:\Senior\Sapiens\Sapiens.exe –MCDEBUG
C:\Senior\Regente\Regente.exe -MCDEBUG
C:\Senior\Vetorh\Rubi.exe -MCDEBUG

Ao iniciar o Sistema, estará disponível somente o Menu Diversos, conforme imagem abaixo:

Para acessar os Web Services disponíveis, deve-se acessar o caminho:

Diversos > Multicamada, onde será aberta uma tela com a listagem dos Web Services.
3.1.2 - Encontrando o WebService

Diferente da listagem dos Web Service disponível no Editor de Serviços, a lista dos Web
Services disponível via MCDebug traz a descrição do Web Service e não o seu nome.

MCDebug: Mercado - Gestão de Vendas - Pedidos - Gravar Pedidos

Editor: com.senior.g5.co.mcm.ven.pedidos@GravarPedidos

MCDebug: Mercado - Gestão de Vendas - Pedidos - Exportar Pedidos

Editor: com.senior.g5.co.mcm.ven.pedidos@ExportarPedidos

Há também uma separação por método (porta), onde no MCDebug são listados vários Web
Services pela Descrição, mesmo estes pertencendo a mesma rotina. Exemplo:

Web Service Editor: com.senior.g5.co.mcm.ven.pedidos

Web Service MCDebug:
Mercado - Gestão de Vendas - Pedidos – Calcular Valores Item Pedido ECF
Mercado - Gestão de Vendas - Pedidos – Exportar Pedidos
Mercado - Gestão de Vendas - Pedidos – Gravar Pedidos
Mercado - Gestão de Vendas - Pedidos – Gravar Pedidos em Grade

3.1.3 - Tela de Entrada do WebService

Ao selecionar um Web Service disponível na lista, será aberta uma tela para entrada de
valores que serão enviados ao Web Service. Com isto, não há necessidade de alterar o XML
do Web Service manualmente, podendo então inserir os dados do Web Service via tela.

Tabelas do Web Service

Campos de Usuário

Retorno da Execução

3.1.4 - Manipulando XMLs

A partir da tela de entrada do Web Service é possível importar um XML previamente salvo
ou salvar os dados digitados na tela para um arquivo XML. Com isso, pode-se salvar os
dados de um teste para novo uso futuramente.

Este XML gerado pelo MCDebug é interpretado somente por este recurso. Este XML não
possui o envelope SOAP, necessário para a comunicação do Web Service entre Sistemas.
Devido a este comportamento, não é possível importar um XML gerado pelo soapUI ou
outro Sistema por exemplo, diretamente para o editor do MCDebug.

XML gerado via soapUI (Aplicação Externa)

XML gerado via MCDebug (Aplicação Senior)

3.1.5 - Modos de Execução

No modo de Depuração de Serviços há 4 formas de execução de um Web Service. Local,

Síncrono, Assíncrono e Agendado.

Modo Local: O processamento da requisição irá ocorrer na mesma instância do aplicativo,

diretamente dentro do Sistema. Não haverá a necessidade de outros recursos para a
execução do Web Service, como o Middleware Senior.
O processamento ocorre no mesmo momento da chamada do Web Service.

Modo Síncrono: O processamento da requisição será direcionada ao Middleware Senior. É

necessário que o Middleware Senior esteja instalado e configurado para uso dos
WebServices. Será enviada uma solicitação do Servidor Glassfish que irá solicitar uma
instância do Sistema Senior para processar a requisição.
O processamento tem início no momento da chamada do Web Service, e o retorno será
devolvido pelo Servidor Glassfish.

Modo Assíncrono: O processamento da requisição será direcionada ao Middleware

Senior. É necessário que o Middleware Senior esteja instalado e configurado para uso dos
WebServices. Será enviada uma solicitação do Servidor Glassfish que irá solicitar uma
instância do Sistema Senior para processar a requisição.
O processamento tem início no momento da chamada do Web Service, e não haverá retorno
sobre o processamento da requisição.

Modo Agendado: A solicitação de execução será direcionada ao Middleware Senior,

porém não ocorrerá no momento da requisição. A solicitação será Agendada para execução
no Middleware. Neste modo de execução não há retorno da execução para o Solicitante.
3.1.6 - Depurando uma regra ligada a rotina do Web Service

O MCDebug permite que sejam depuradas as regras ligadas as rotinas dos Web Services,
quando a execução é efetuada em modo Local. Este meio de execução permite tal
funcionalidade, pois pode-se abrir telas de interação com o usuário. Os demais meios de
execução não possibilitam tal funcionalidade, visto que não é possível a abertura de telas do
Sistema.

Regra com o Depurador ativo

Retorno da Execução

3.1.7 - Particularidades desta Forma de execução

- Não é possível efetuar a reordenação dos dados da Grid.
- Não é possível salvar o XML de retorno do Web Service. Caso for necessário, deve-se
habilitar a geração de LOGs nas configurações dos WebServices, aba Monitoramento.

3.2 - Chamando um WebService via Regra LSP

Diferente da execução do Web Service via MCDebug, as informações enviadas ao Web
Service via regra LSP devem ser tratadas manualmente. É necessário declarar a variável do
Web Service na regra para que ele fique disponível para chamada.

Para parâmetros do tipo tabela, deve-se obrigatoriamente inserir linhas na tabela do

parâmetro para que o processamento seja efetuado corretamente. Caso não sejam
adicionadas linhas para o parâmetro do tipo tabela, os valores informados podem ser
sobrescritos.
3.2.1 - Estrutura da regra LSP

Definir Alfa aCodEmp;

Definir Alfa aRetObs;
Definir Alfa aSitPed;
Definir Alfa aSeqIpd; Declaração do Web
Service para ser
@ Declaração da variável identificando o serviço @
Definir interno.com.senior.g5.co.int.padrao.documentos.Pedido SrvPedido;
utilizado na regra

@ Cria nova linha para o cabeçalho do pedido @

SrvPedido.Pedido.CriarLinha();
SrvPedido.Pedido.OpeExe = "I"; Criação da linha da
SrvPedido.Pedido.CodEmp = 1; tabela do parâmetro
SrvPedido.Pedido.CodFil = 1;
SrvPedido.Pedido.CodCli = 1; Pedido
SrvPedido.Pedido.VlrOut = "10,50";
SrvPedido.Pedido.DatPrv = "19/03/2012";

@ Cria nova linha para Campo de Usuario do Pedido @

SrvPedido.Pedido.Usuario.CriarLinha(); Criação da linha da
SrvPedido.Pedido.Usuario.CmpUsu = "Usu_CodTeste"; tabela do parâmetro
SrvPedido.Pedido.Usuario.VlrUsu = "1";
Pedido.Usuario
@ Cria nova linha para cada produto @
SrvPedido.Pedido.Produto.CriarLinha();
SrvPedido.Pedido.Produto.OpeExe = "I";
SrvPedido.Pedido.Produto.CodPro = "1101";
Criação da linha da
SrvPedido.Pedido.Produto.CodDer = " ";
SrvPedido.Pedido.Produto.QtdPed = "1000"; tabela do parâmetro
SrvPedido.Pedido.Produto.CodTpr = " "; Produto
SrvPedido.Pedido.Produto.PreUni = "10,65";

@ Cria nova linha para Campo de Usuario do Produto @

SrvPedido.Pedido.Produto.Usuario.CriarLinha(); Criação da linha da
SrvPedido.Pedido.Produto.Usuario.CmpUsu = "Usu_NCodTeste"; tabela do parâmetro
SrvPedido.Pedido.Produto.Usuario.VlrUsu = "2";
Pedido.Produto.Usuario
@ Define o modo de execução síncrono @
SrvPedido.ModoExecucao = 1;
Define o Modo de Execução
@ Executa o web service @
SrvPedido.Executar();

fim; Executa o Web Service

3.2.2 - Modos de Execução

Os modos de execução de Web Service via regra LSP seguem o mesmo padrão utilizado
via MCDebug, porém são tratados por numeração na regra, conforme abaixo:

1 – Local
2 – Síncrono
3 – Assíncrono
4 - Agendado

Caso a variável “ModoExecucao” não seja declarada na execução do Web Service via regra
LSP, por padrão o Web Service será executado Localmente.
Nesta situação, executando o Web Service localmente na regra LSP o Web Service terá o
mesmo comportamento de uma função de programador, sendo executado diretamente no
mesmo aplicativo que está executando a regra.

3.2.3 - Obtendo retorno da execução (Grids)

Após a execução do Web Service em modo Local ou Síncrono, é possível obter os dados de
retorno da execução do Web Service e os dados de retorno das tabelas, quando disponíveis.
O retorno das informações geralmente ocorre em uma tabela. Com isso, é necessário ler
os dados das linhas desta tabela para obter o retorno de cada linha da tabela. Caso
contrário não será possível verificar o retorno de todos os Itens da tabela e verificar
possíveis problemas.
Abaixo há um exemplo de regra para obter o retorno de cada linha das tabelas de retorno
da tabela de Pedido e Produto.

@verifica a quantidade de linhas de retorno dos pedidos@

iQtdLinhasRetornoPedidos = SrvPedido.RespostaPedido.QtdLinhas;

iQtdPed = 0;
enquanto (iQtdPed < iQtdLinhasRetornoPedidos)
inicio
@posiciona no primeiro registro da tabela de retorno@
SrvPedido.RespostaPedido.LinhaAtual = iQtdPed;

@busca os dados do retorno da inserção do pedido na linha atual@

aCodEmp = SrvPedido.RespostaPedido.CodEmp; Retorno da tabela Pedido
iCodFil = SrvPedido.RespostaPedido.CodFil;
iNumPed = SrvPedido.RespostaPedido.NumPed;
aSitPed = SrvPedido.RespostaPedido.SitPed;
aRetObs = SrvPedido.RespostaPedido.Retorno;

@verifica a quantidade de linhas de retorno do produto do pedido da linha atual@

iQtdLinhasRetornoProdutos = SrvPedido.RespostaPedido.GridPro.QtdLinhas;

iQtdPro = 0;
enquanto (iQtdPro < iQtdLinhasRetornoProdutos)
inicio Retorno da tabela de
SrvPedido.RespostaPedido.GridPro.LinhaAtual = iQtdPro; Produtos do Pedido
aSeqIpd = SrvPedido.RespostaPedido.GridPro.SeqIpd;
aRetObs = SrvPedido.RespostaPedido.GridPro.Retorno;
iQtdPro = iQtdPro + 1;
fim;

iQtdPed = iQtdPed + 1;
fim;

3.2.4 - Particularidades desta forma de execução

- Se o retorno for do tipo tabela e não foram lidos todos os registros, o retorno será
apresentado de forma incompleta.
3.2.5 - Exemplo

definir alfa acodemp;

definir alfa acodfil;
definir alfa anumtit;
definir alfa aTitLog;
definir alfa aCodTpt;
definir alfa amensagem;
definir alfa aresultado;
Definir data dDatEmi;
Definir data dDatEnt;
Definir data dVctOri;
Definir data dVctPro;
Definir data dDatPpt;

dDatEmi = CodData(24,01,2013);
dDatEnt = CodData(24,01,2013);
dVctOri = CodData(01,02,2013);
dVctPro = CodData(01,02,2013);
dDatPpt = CodData(01,02,2013);

definir interno.com.senior.g5.co.mfi.cre.titulos.EntradaTitulosLoteCR SrvGerCtaRec;

@ Montagem do servivo para inclusão do título substitulo @

SrvGerCtaRec.CodEmp = 1; @ Codigo da empresa @
SrvGerCtaRec.CodFil = 1; @ Codigo da filial @

SrvGerCtaRec.EntradaTitulos.CriarLinha();
SrvGerCtaRec.EntradaTitulos.CodFil = 1;
SrvGerCtaRec.EntradaTitulos.NumTit = "TIT001";
SrvGerCtaRec.EntradaTitulos.CodTpt = "DM";
SrvGerCtaRec.EntradaTitulos.CodTns = "90300";
SrvGerCtaRec.EntradaTitulos.DatEmi = dDatEmi;
SrvGerCtaRec.EntradaTitulos.DatEnt = dDatEnt;
SrvGerCtaRec.EntradaTitulos.CodCli = 1;
SrvGerCtaRec.EntradaTitulos.CodRep = 1;
SrvGerCtaRec.EntradaTitulos.VctOri = dVctOri;
SrvGerCtaRec.EntradaTitulos.VctPro = dVctPro;
SrvGerCtaRec.EntradaTitulos.VlrOri = 100;
SrvGerCtaRec.EntradaTitulos.CodFpg = 001;
SrvGerCtaRec.EntradaTitulos.DatPpt = dDatPpt;
SrvGerCtaRec.EntradaTitulos.CodPor = "9999";
SrvGerCtaRec.EntradaTitulos.CodCrt = "99";
SrvGerCtaRec.EntradaTitulos.CodMoe = "01";
@ Codigo da filial @
@ Número do título a receber @
@ Código do tipo de título a receber @
@ Código da transação que gerou o título a receber @
@ Data de emissão do título a receber @
@ Data de entrada do título a receber @
@ Código do cliente do título a receber @
@ Código do representante do título a receber @
@ Data do vencimento @
@ Data do vencimento Prorrogado @
@ Valor original do título a receber @
@ Código da forma de pagamento @
@ Data do provável pagamento @
@ Código do portador do título @
@ Código da carteira do título a receber @
@ Código da moeda @

SrvGerCtaRec.EntradaTitulos.CriarLinha();
SrvGerCtaRec.EntradaTitulos.CodFil = 1;
SrvGerCtaRec.EntradaTitulos.NumTit = "TIT002";
SrvGerCtaRec.EntradaTitulos.CodTpt = "DM";
SrvGerCtaRec.EntradaTitulos.CodTns = "90300";
SrvGerCtaRec.EntradaTitulos.DatEmi = dDatEmi;
SrvGerCtaRec.EntradaTitulos.DatEnt = dDatEnt;
SrvGerCtaRec.EntradaTitulos.CodCli = 1;
SrvGerCtaRec.EntradaTitulos.CodRep = 1;
SrvGerCtaRec.EntradaTitulos.VctOri = dVctOri;
SrvGerCtaRec.EntradaTitulos.VctPro = dVctPro;
SrvGerCtaRec.EntradaTitulos.VlrOri = 100;
SrvGerCtaRec.EntradaTitulos.CodFpg = 001;
SrvGerCtaRec.EntradaTitulos.DatPpt = dDatPpt;
SrvGerCtaRec.EntradaTitulos.CodPor = "9999";
SrvGerCtaRec.EntradaTitulos.CodCrt = "99";
SrvGerCtaRec.EntradaTitulos.CodMoe = "01";
@ Codigo da filial @
@ Número do título a receber @
@ Código do tipo de título a receber @
@ Código da transação que gerou o título a receber @
@ Data de emissão do título a receber @
@ Data de entrada do título a receber @
@ Código do cliente do título a receber @
@ Código do representante do título a receber @
@ Data do vencimento @
@ Data do vencimento Prorrogado @
@ Valor original do título a receber @
@ Código da forma de pagamento @
@ Data do provável pagamento @
@ Código do portador do título @
@ Código da carteira do título a receber @
@ Código da moeda @

SrvGerCtaRec.ModoExecucao = 1;
SrvGerCtaRec.Executar();

nQtdLin = SrvGerCtaRec.GridResult.QtdLinhas;

Para (i = 0; i < nqtdlin;i++)

{
SrvGerCtaRec.GridResult.LinhaAtual = i;
aNumTit = SrvGerCtaRec.GridResult.NumTit;
aResultado = SrvGerCtaRec.Resultado;
aMensagem = "Título: " + aNumTit + " = " + SrvGerCtaRec.GridResult.TxtRet;

}
3.3 - Chamando um WebService via Sistema Externo
(soapUI)
É possível chamar um Web Service padrão do Sistema ou Personalizado a partir de
Sistemas de Terceiros.
Isto é possível ao publicar os Web Services no Servidor Glassfish (deploy), onde este irá
disponibilizar os Web Services para outros Sistemas, criando uma “ponte” entre os Sistemas
de Terceiros e os Sistemas Senior. Esta ponde pode ser chamada de “Registrador”.

3.3.1 - Entidades envolvidas no processo

Provedor (Sistema Senior): Responsável pela descrição do serviço. Esta descrição é um

documento WSDL que contém várias informações do serviço, como por exemplo,
informações sobre parâmetros, endpoints, dados do criador. Também é encarregado de
publicar os serviços em uma entidade registradora.

Consumidor (Sistema Terceiros): Responsável por obter o documento WSDL do serviço

desejado. Posteriormente, utilizar as informações fornecidas por este documento fazer a
ligação com o provedor, invocando um Serviço Web.

Registrador (Servidor Glassfish): Entidade responsável por armazenar as informações

disponibilizadas pelos provedores em um repositório. É nesta entidade que o consumidor
procura por um serviço com base no endereço disponibilizado.

3.3.2 - WSDL (Web Service Description Language)

Podemos descrever o WSDL como a definição do Web Service. O WSDL é um documento

XML disponível de forma on-line para qualquer aplicação ou usuário que tenha acesso ao
seu endereço. Neste documento XML estão disponíveis todas as informações do Web
Service como parâmetros, tipos de dados, endereços dos Serviços, Provedores. Está
disponível também em alguns WSDLs o endereço do XSD do Web Service, que contém a
definição de todos os parâmetros do Web Service.

Assim, temos o WSDL como uma “capa” das definições do Web Service e o XSD com todas
as informações detalhadas sobre o Web Service.

Basicamente, quando o cliente deseja enviar uma mensagem para um determinado Web
Service, ele obtém a descrição do serviço (através da localização do respectivo documento
WSDL), e em seguida constrói a mensagem, passando todos os parâmetros de acordo com
a definição encontrada no documento.
Em seguida, a mensagem é enviada para o endereço onde o serviço está localizado, a fim
de que possa ser processada. O Web Service, quando recebe esta mensagem valida-a
conforme as informações contidas no documento WSDL.
À partir de então, o serviço remoto sabe como tratar a mensagem, sabe como processá-la
(possivelmente enviando-a para outro programa) e como montar a resposta ao cliente.

3.3.3 - Obtendo o EndPoint do WSDL do Webservice

Para os Web Services padrões Senior ou Personalizados, o WSDL pode ser obtido no
endereço do Web Service, adicionando o parâmetro ?WSDL no final do endereço.

Exemplo:
http://servidor:9090/g5-senior-services/sapiens/Synccom_senior_g5_co_mcm_ven_pedidos?wsdl

Acessar o console de Administração do Glassfish;

Abrir o item “Web Services” do menu a esquerda;
Procurar o Web Service na lista aberta a direita
Utilizar os Web Service do modo “SynConn” que são os Web Service do modo Síncrono;
Clicar no item “View WSDL”;
Copiar o endereço do WSDL;
3.3.4 - Criando um projeto WSDL no soapUI

Após obter o endereço do WSDL do Web Service, será necessário criar um novo projeto
dentro do soapUI. O soapUI irá “ler” as definições contidas no WSDL e no XSD do Web
Service para montar a chamada do Serviço e disponibilizar os campos do Web Service em
forma de XML na tela do soapUI.

- Acessar o menu File > New SoapUI Project

- Informar o endereço do WSDL no campo “Initial WSDL/WADL”

- Será criado um novo projeto com o nome definido na importação do WSDL

- Dentro do Projeto está o Web Service importado e as portas de entrada.

- Ao clicar na opção “Request 1”, serão apresentados os parâmetros de entrada da porta do
Web Service.

A partir deste momento é possível inserir as informações necessárias para execução do Web
Service via Middleware Senior.
3.3.5 - Verificando os parâmetros do WebService

Com a importação do WSDL do Web Service, o SoapUI irá importar todos os parâmetros de
entrada da porta selecionada.
Importante: Não há como importar somente os parâmetros obrigatórios. Caso não for
necessário utilizar determinado parâmetro, deve-se deixar com a informação original, sem
alteração.

É possível também, para melhor visualização e padronização remover os parâmetros não

utilizados do Web Service.

É possível verificar que há mais de uma informação de retorno, sendo: mensagemRetorno,

retorno e tipoRetorno

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:GravarClientesResponse xmlns:ns2="http://services.senior.com.br">
<result>
<erroExecucao xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<mensagemRetorno>Processado com Sucesso.</mensagemRetorno>
<retornosClientes>
<cgcCpf>0</cgcCpf>
<codCli>0</codCli>
<codFor>9</codFor>
<ideExt>?</ideExt>
<retorno>Informação do tipo de cliente requerida.</retorno>
</retornosClientes>
<tipoRetorno>1</tipoRetorno>
</result>
</ns2:GravarClientesResponse>
</S:Body>
</S:Envelope>
mensagemRetorno: Mensagem de retorno do processamento do Web Service.
retorno: Mensagem de retorno do processamento do item do Web Service.
tipoRetorno: 1 = Processado, 2 = Erro na Solicitação

3.3.6 - Particularidades desta forma de execução

3.3.6.1 - Java Case Sensitive

A linguagem JAVA é Case Sensitive, ou seja, o parâmetro <user> é diferente de do
parâmetro <User>. É obrigatório manter o mesmo nome do parâmetro que o soapUI
importou no projeto.
Caso seja definido um parâmetro com diferença entre letras maiúsculas e minúsculas do
que está definido no WSDL, o Sistema Senior não interpretará este parâmetro pois o JAVA
irá abstraí-lo, conforme exemplo:

Definição do Web Service na WSDL:

<soapenv:Header/>
<soapenv:Body>
<ser:AuthenticateJAAS>
<user> </user>
<password> </password>
<encryption></encryption>
<parameters>
<pmUserName> </pmUserName>
<pmUserPassword> </pmUserPassword>
</parameters>
</ser:AuthenticateJAAS>
</soapenv:Body>

Mensagem enviada ao Servidor Glassfish com o parâmetro alterado:

<soapenv:Header/>
<soapenv:Body>
<ser:AuthenticateJAAS>
<user>senior</user>
<password>senior</password>
<encryption>0</encryption>
<parameters>
<pmUserName>Usuario</pmUserName>
<pmuserpassword>Senha</pmuserpassword>
</parameters>
</ser:AuthenticateJAAS>
</soapenv:Body>

Mensagem recebida pelo Sistemas Senior (G5):

<soapenv:Header/>
<soapenv:Body>
<ser:AuthenticateJAAS>
<user>senior</user>
<password>senior</password>
<encryption>0</encryption>
<parameters>
<pmUserName>Usuario</pmUserName>
</parameters>
</ser:AuthenticateJAAS>
</soapenv:Body>

3.3.6.2 - Função Mensagem(Retorna,xxx)

Os Web Services executados por outras formas que não seja via regra LSP em modo local,
não permitem a utilização da função “Mensagem(Retorna,xxx)” nas regras ligadas a rotina
do Web Service.

Quando o Web Service é executado de forma Síncrona, Assíncrona ou Agendada, não é

possível utilizar nenhum recurso que necessite de interação do usuário, como a função
Mensagem(Retorna,xxx). Isto ocorre pois, nestes meios de execução, não há como
confirmar uma mensagem gerada para o usuário e prosseguir com a execução da regra.
Esta situação pode ocorrer quando é utilizado um identificador de regras atrelado a uma
regra LSP, sendo que esta regra possui uma ocorrência da função Mensagen(Retorna,xxx).
Quando esta situação for constatada, o Sistema irá retornar a seguinte mensagem no
campo de retorno do Web Service:

Regra XXX: Não é permitido executar nas regras o comando "Mensagem" com "Retorna"
quando a instância da aplicação é de serviço.

3.3.6.3 - Janelas via Serviço

Constatamos em alguns situações que a rotina do Sistema tenta abrir uma “tela” do
Sistema quando é executada a rotina do Web Service. Por exemplo, ao executar um Web
Service ou ação SID via Web Service, é gerada uma tela com uma barra de progresso.

Nesta situação, quando o Web Service ou ação SID via Web Service for executada via
Middleware Senior, a sua execução será “abortada” não chegando a ser processado pelo
ERP. Isto pode ocorrer quando utiliza-se um Web Service personalizado e algum Web
Service ou ação SID na regra LSP do Web Service.

3.3.6.4 - XML gerado pelo MCDebug e via soapUI (incompatibilidade)

Conforme item 3.1.4, não é possível importar um XML gerado pelo MCDebug no SoapUI,
devido a ausência do envelope SOAP no XML do MCDebug.

3.3.6.5 - Campos data (não informados)

Em alguns Web Services, pode haver um campo do tipo Data que é opcional. Nesta
situação, se não for informada nenhuma informação para este campo, o mesmo deve ser
retirado do XML do Web Service.
Isto é necessário pois o SoapUI adiciona o valor ? para todos os campos, fazendo com que
ele se torne “em branco” quando enviado para exeução.
Porém para os campos do tipo data, há uma validação desta informação, retornando que a
data não está no formato correto.

4 – Provedores de Terceiros
4.1 - Identificando a URL do provedor e o contexto

Acessar a WSDL do Web Service:

http://www.w3schools.com/webservices/tempconvert.asmx?WSDL

A URL do provedor é o trecho do endereço até a primeira barra “/”:

http://www.w3schools.com

O contexto é tudo o que está entre a URL do provedor e o nome do serviço:

webservices

O Web Service é o trecho após o contexto

tempconvert.asmx

4.2 - Localizando o Identificador Universal

O Identificador Universal é o “namespace” informado na WSDL do Web Service

targetNamespace="http://tempuri.org/"

4.3 - Identificando a Ação do Web Service:

A ação do Web Service é publicada na TAG "soapAction" da Porta do Web Service

soapAction="http://tempuri.org/FahrenheitToCelsius"
4.4 - Parâmetros de Entrada e Saída

Os parâmetros de entrada e saída são publicado no WSDL ou no XSD do Web Service.

Exemplo:

<wsdl:types>
<s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
<s:element name="FahrenheitToCelsius">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Fahrenheit" type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
<s:element name="FahrenheitToCelsiusResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="FahrenheitToCelsiusResult"
type="s:string"/>
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</wsdl:types>

5 – Exemplo de Web Service Personalizado

Entrada: Campo de Entrada.

Tipo: AlfaNumérico

Saida: Campo de Saída dos dados

Tipo: AlfaNumérico
Regra do Web Service

Definir alfa entrada;

Definir alfa aRetorno;
Definir alfa aNomCli;
Definir cursor Cur_E085CLI;

entrada = msg.entrada;

Cur_E085CLI.SQL "Select NomCli \

from E085CLI \
where CodCli =:entrada";
Cur_E085CLI.AbrirCursor();
Se (Cur_E085CLI.Achou)
inicio
aNomCli = Cur_E085CLI.NomCli;
msg.saida = aNomCli;
fim;
Senao
inicio
msg.saida = "Cliente não encontrado";
fim;

Cur_E085CLI.FecharCursor();

No exemplo acima, “msg” é o nome da porta do Web Service. Sempre que for necessário ler ou devolver um dado
para um dos parâmetros do Web Service, deve-se inserir o nome da porta antes do parâmetro.