Apostila - Web Services Na G5

Tecnologia – Web Services
Tecnologia – Web Services na G5
Copyright© 2017 Todos os direitos reservados.

2
Todos os direitos reservados e protegidos pela Lei nº 9.610, de 19/02/1998.

Nenhuma parte deste material, sem a prévia e expressa autorização da Senior, poderá
ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrônicos,
mecânicos, fotográficos, gravação ou quaisquer outros, sob pena de constituir violação
aos direitos autorais”.
1ª Edição deste material – 25 de agosto de 2017.

3
Apresentação
Este material tem como objetivo capacitar o profissional com relação aos conceitos
ligados ao assunto web service dos sistemas G5 nas atividades de criação, manutenção e
configuração destes.
Está baseado em tecnologias internas da Senior e também em tecnologias de
mercado.
Estão apresentadas a seguir informações sobre:
 Conceitos e Pré-requisitos.
 Configurações iniciais.
 Editor de Serviços.
 Sistemas Senior chamando web services.
 Sistemas Senior expondo web services.

4
Sumário
O QUE É WEB SERVICE .................................................................................................................. 7
COMO FUNCIONA UM WEB SERVICE ............................................................................................ 8
Se são linguagens diferentes, como conseguem comunicar?................................................... 8
Quais os benefícios dos Web Services? ..................................................................................... 9
Web Service: uma solução prática. ......................................................................................... 10
ENTIDADES ENVOLVIDAS NO PROCESSO .................................................................................... 11
POR QUE USAR WEB SERVICES ................................................................................................... 12
ARQUITETURA DO SISTEMA ........................................................................................................ 14
MODOS DE EXECUÇÃO ................................................................................................................ 15
CONFIGURAÇÕES INICIAIS ........................................................................................................... 16
EDITOR DE WEB SERVICES ........................................................................................................... 18
MENU .......................................................................................................................................... 19
BARRA DE FERRAMENTAS ........................................................................................................... 19
ARVORE DE RECURSOS ................................................................................................................ 19
LISTA DE RECURSOS .................................................................................................................... 20
LOCALIZAR ................................................................................................................................... 21
PARAMETRIZAÇÃO DE WEB SERVICE .......................................................................................... 21
PARAMETROS DE ENTRADA E SAIDA .......................................................................................... 22
CONCEITO DE GRID (TABELA) NOS WEB SERVICES ..................................................................... 23
CAMPOS DE USUÁRIOS ............................................................................................................... 26
PROTOCOLOS E VERSÕES SUPORTADAS ..................................................................................... 28
MAPEAMENTO DE SERVIÇOS DE OUTROS SISTEMAS ................................................................. 29
Mapeamento de WSDL para Editor de Serviços ..................................................................... 29
Tipos de autenticação ............................................................................................................. 45
MAPEAMENTO ENTRE SISTEMAS SENIOR................................................................................... 47
Provedor Senior de mesma base ............................................................................................ 47
Provedores Senior de bases diferentes................................................................................... 49
Atualização dos web services .................................................................................................. 52
INVOCAÇÃO DE WEB SERVICES VIA LSP ...................................................................................... 53
Estrutura da regra LSP ............................................................................................................. 53
Modos de execução ................................................................................................................ 54
Obtendo retorno da execução (Grids) .................................................................................... 54

5
Particularidades desta forma de execução ............................................................................. 55

VISAO BÁSICA DA ARQUITETURA DOS SERVIÇOS SENIOR .......................................................... 58
PROCESSOS DE DEPLOY ............................................................................................................... 60
Acessando a ferramenta ......................................................................................................... 60
CRIAÇÃO DE WEB SERVICES CUSTOMIZADOS............................................................................. 63
GERAÇÃO DE DOCUMENTAÇÃO ................................................................................................. 70
CONSOLE DE WEB SERVICES ....................................................................................................... 73
Console de Administração Multicamada ................................................................................ 73
Configuração do Console de Administração Multicamada ..................................................... 75
Colunas Visíveis ................................................................................................................... 76
Filtros ................................................................................................................................... 77
REFERENCIAS ............................................................................................................................... 78

6
CAPÍTULO 01
Conceitos
Objetivos Específicos
 Saber o que é Web Service, sua arquitetura de funcionamento e protocolos utilizados.

7
O QUE É WEB SERVICE
WebService é uma solução utilizada na integração de sistemas e na comunicação entre

aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com
aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam
compatíveis (Wikipedia).
Utilizando a tecnologia WebService, uma aplicação pode invocar outra para efetuar
tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e
escritas em linguagens diferentes. Por outras palavras, os WebServices fazem com que os seus
recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os
recursos fornecidos pelo WebService. Ou seja, são inúmeras aplicações para WebServices e não
somente integração entre sistemas.
Os Web Services são identificados por um URI (Uniform Resource Identifier), descritos e
definidos usando XML (Extensible Markup Language). Um dos motivos que tornam os
WebServices atrativos é o fato deste modelo ser baseado em tecnologias standards, em
particular XML e HTTP (Hypertext Transfer Protocol). Os WebServices são utilizados para
disponibilizar serviços interativos na Web, podendo ser acessados por outras aplicações.
Figura 1

8
COMO FUNCIONA UM WEB SERVICE
Tendo em conta as operações disponíveis no Web Service, a aplicação solicita uma

dessas operações. O Web Service efetua o processamento e envia os dados para a aplicação que
requereu a operação. A aplicação recebe os dados e faz a sua interpretação, convertendo-os
para a sua linguagem própria.
Se são linguagens diferentes, como conseguem comunicar?
É necessária uma linguagem intermédia que garanta a comunicação entre a linguagem

do Web Service e o sistema que faz o pedido ao Web Service. Para tal, existem protocolos de
comunicação como o SOAP (Simple Object Access Protocol) e o REST (Representational State
Transfer).
O protocolo SOAP utiliza XML para enviar mensagens e, geralmente, serve-se do

protocolo HTTP para transportar os dados. Associado ao protocolo SOAP está o documento
WSDL (Web Service Definition Language) que descreve a localização do Web Service e as
operações que dispõe. Além disso, fornece a informação necessária para que a comunicação
entre sistemas seja possível. De acordo com o W3Schools, a estrutura da mensagem SOAP é
definida em um documento XML que contém os seguintes elementos:
Figura 2
O REST é um protocolo de comunicação mais recente que surgiu com o objetivo de

simplificar o acesso aos Web Services. Este baseia-se no protocolo HTTP e permite utilizar vários
formatos para representação de dados, como JSON, XML, RSS, entre outros.
Assim, uma das grandes vantagens do REST é a sua flexibilidade, já que não limita os
formatos de representação de dados. O protocolo REST é também utilizado quando a
performance é importante, uma vez que é um protocolo ágil e com a capacidade de transmitir
dados diretamente via protocolo HTTP.

9
Figura 3
Quais os benefícios dos Web Services?
A utilização de Web Services traz vários benefícios tanto a nível tecnológico, como a nível
do negócio. Seguem-se os mais relevantes:
– Integração de informação e sistemas: uma vez que o funcionamento do Web Service

necessita apenas de tecnologia XML/JSON e protocolos HTTP, a comunicação entre sistemas e
aplicações é bastante simplificada. Com um Web Service é possível trocar informação entre dois
sistemas, sem necessidade de recolher informação detalhada sobre o funcionamento de cada
sistema. Os Web Services permitem ligar qualquer tipo de sistema, independentemente das
plataformas (Windows, Linux, entre outras) e linguagens de programação (Java, Perl, Python,
etc.) utilizadas.
– Reutilização de código: um Web Service pode ser utilizado por várias plataformas com
diferentes objetivos de negócio. O código do Web Service é feito uma vez e pode ser utilizado
vezes sem conta por diferentes aplicações.
– Redução do tempo de desenvolvimento: é mais rápido desenvolver com Web Services,

porque os sistemas não são totalmente construídos a partir do zero e facilmente são incluídas
novas funcionalidades. O tempo de implementação de sistemas com a utilização de Web
Services é mais reduzido, sendo uma boa opção no desenvolvimento de software à medida.

10
– Maior segurança: o Web Service evita que se comunique diretamente com a base de
dados. Assim, a segurança do sistema que fornece os dados está salvaguardada.
– Redução de custos: Com a utilização de Web Services não é necessário criar aplicações
à medida para a integração de dados, algo que pode ser bastante caro. Os Web Services tiram
partido de protocolos e da infraestrutura Web já existente na organização, requerendo por isso
pouco investimento.
IMPORTANTE
Os Web Services providos pelos sistemas G5 da Senior têm endereços WSDL que apresentam
as definições de login do Web Service e endereços XSD com as informações dos parâmetros do
Web Service.
Web Service: uma solução prática.
Numa organização coexistem várias aplicações que organizam e trocam dados, muitas
vezes, de formas distintas. Assim, nem sempre garantem a comunicação entre sistemas. Por
outro lado, é cada vez mais comum a necessidade de trocar dados entre diferentes sistemas,
seja dentro de uma organização ou entre organizações.
Uma solução prática e de baixo custo para solucionar a incompatibilidade de sistemas e

garantir a sua comunicação são os Web Services. Estes permitem ligar diferentes aplicações que
integram um sistema, ultrapassando barreiras como o tipo de plataforma ou linguagens de
programação utilizadas.

11
ENTIDADES ENVOLVIDAS NO PROCESSO
Provedor: 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: 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: 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.
Figura 4

12
POR QUE USAR WEB SERVICES
Quando há descentralização dos dados: Cada departamento ou órgão pode ter seus
próprios dados disponíveis para os outros. Os dados poderão estar disponíveis assim que forem
atualizados.
Também é muito usado quando há necessidade de automatização de processos nos

serviços fornecidos. Os sistemas se tornaram especialistas e complexos: E-commerce, finanças
e bancos, serviços de saúde e etc. Sistemas complexos não podem ser construídos numa única
aplicação.
Sistemas complexos requerem:
 Aplicações distribuídas
 Interoperabilidade
 Transparência da localização
 Facilidade de programação
Para as empresas, os Web Services podem trazer agilidade para os processos e eficiência
na comunicação entre cadeias de produção ou de logística. Toda e qualquer comunicação entre
sistemas passa a ser dinâmica e principalmente segura, pois não há intervenção humana.
Essencialmente, o Web Service faz com que os recursos da aplicação do software

estejam disponíveis sobre a rede de uma forma normalizada (padronizada).
Figura 5

13
CAPÍTULO 02
Configurações Iniciais
 Configurar o sistema para o uso de Web Services e identificar os recursos disponíveis

para criar e manipular os mesmos.

14
ARQUITETURA DO SISTEMA
A Senior disponibiliza ferramentas e recursos de tecnologia agregadas em todos os seus

produtos. Essas ferramentas são responsáveis por auxiliar na customização dos aplicativos
(Implementações), disponibilizar recursos que facilitam as implantações e configurações do
ambiente do cliente (Middleware) e integrar aplicativos Senior ou de terceiros.
A arquitetura das soluções é formada pelo conjunto de elementos que constituem a

infraestrutura, composta por hardwares e softwares. A arquitetura da solução Senior é dividida
em quatro camadas distintas. Essas camadas são formadas por ferramentas, que podem estar
incorporadas diretamente nos aplicativos da Senior ou apresentar-se como um programa
independente.
Para facilitar a visualização da Tecnologia Senior, a ilustração abaixo divide as quatro

camadas:
• Camada cliente
• Middleware Java EE
• Middleware base
• Camada de infraestrutura
Figura 6

15
MODOS DE EXECUÇÃO
Modo Síncrono: O processamento da requisição será direcionado ao Middleware

Senior. É necessário que o Middleware Senior esteja instalado e configurado para uso dos Web
Services. 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á direcionado ao Middleware

Senior. É necessário que o Middleware Senior esteja instalado e configurado para uso dos Web
Services. 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.

16
CONFIGURAÇÕES INICIAIS
Depois de fazer a instalação do sistema e do Glassfish, o primeiro passo para a utilização

dos Web Services nos sistemas Senior é verificar as configurações. Para tal, carregue o
SeniorConfigCenter e entre na opção Middleware > Web Services. A tela abaixo será mostrada.
Figura 7
Os campos devem ser preenchidos conforme segue:
URL do servidor Java EE: Já vem preenchida automaticamente pelo instalador com o
endereço do servidor que contém os serviços já publicados.
Tempo máximo de espera: Este é o tempo máximo que um Web Service pode demorar
para responder a uma requisição. Se ele demorar mais do que este tempo, será lançada uma
exceção de timeout. Caso você possua algum processo que leve mais tempo executando do que
o máximo permitido, este processo deve ser chamado de forma assíncrona ou agendada, que
não possuem esta limitação de tempo.
Os sistemas possuem um console de Webservices, disponível no menu Recursos > Web

Services > console. Os dois parâmetros abaixo são para definir o funcionamento deste console.
Tempo de atualização: Se o console estiver com a atualização de tela automática ligada,

este é o tempo entre cada atualização da tela.
Limpar informações de status: O console de Web Services armazena os logs de execução

de um período. Este parâmetro informa quantos dias você quer usar como período neste
console. Quanto mais dias, mais espaço em disco e mais tempo pode levar para abrir a tela do
console, pois, mais informações serão mostradas.

17
CAPÍTULO 03
Editor de Web Services
 Realizar as parametrizações necessárias dos Web Services.

18
EDITOR DE WEB SERVICES
O Editor de Web Services é um recurso que permite integrar diversos serviços em

diferentes servidores, ou até mesmo criar novos serviços implementados utilizando regras LSP,
unindo Web Services e regras LSP, que serão disponibilizados pelo próprio sistema para serem
chamados externamente. Através deste editor é possível configurar: Provedores de Serviços,
Serviços, Porta de Serviços e Parâmetros.
Figura 8
IMPORTANTE
O caminho do menu tem diferença de um sistema para outro.
ERP: Recursos > Implementações > WebServices > Editar
RH e Acesso: Recursos > Implementações > Editor Web Services

19
MENU
Esta tela possui um menu com opções para todas as suas funcionalidades, conforme
detalhado abaixo:
Figura 9
a) Menu Arquivo: As funcionalidades deste menu serão vistas por partes mais adiante,
cada uma no contexto em que é utilizada.
b) Menu Editar: Contém as opções genéricas para utilização durante a edição.
c) Menu Exibir: Permite alterar a forma de visualização da lista de recursos,
semelhante aos modos de visualização do Explorer do Windows.
d) Menu Ajuda: Chama o arquivo de ajuda do sistema e posiciona no item
correspondente ao Editor de Serviços.
A disponibilidade de cada ação acessível via menu depende do tipo de item está
selecionado na árvore de recursos à esquerda da tela.
BARRA DE FERRAMENTAS
A barra de ferramentas da tela permite acesso rápido às opções disponíveis no menu da

tela. Cada botão corresponde a algum item de menu, e alguns possuem um menu pop-up com
ações correspondentes aos sub-menus dos menus que cada um representa.
Figura 10
ARVORE DE RECURSOS
À esquerda da tela podemos ver uma árvore que exibe todos os recursos, tratando
exclusivamente de Web Services, disponíveis no sistema.

20
Figura 11
Selecionando um item nesta árvore e clicando com o botão direito do mouse,

será exibido um menu pop-up com as opções disponíveis para o item em questão, cujas
ações correspondem aos itens do menu da tela.
LISTA DE RECURSOS
À direita da tela pode-se ver uma lista que exibe todos os recursos de acordo com o
item selecionado na árvore da esquerda. Esta lista possui um menu pop-up que mostra quais
são as opções disponíveis para o item nela selecionado, cujas ações correspondem à itens do
menu da tela.
Figura 12

21
LOCALIZAR
Ao acessar o menu Editar->Localizar, será exibida uma tela que permite a busca por
textos específicos na árvore de recursos à esquerda da tela.
Figura 13
PARAMETRIZAÇÃO DE WEB SERVICE
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).
Figura 14
As portas de comunicação são os métodos do Web Service. 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).
Figura 15

22
É 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.
Figura 16
PARAMETROS DE ENTRADA E SAIDA
Dentro de cada Web Service poderá haver parâmetros de entrada e saída. 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. É importante que sejam verificados os parâmetros
obrigatórios do Web Service para sua execução correta.
Para identificar se o parâmetro é de Entrada e Saída do Web Service deve-se avaliar

pelo lado do provedor do Web Service.

23
Figura 17
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
compararmos 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.

24
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 à 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 Web Service:
<GravarPedidos>
<Pedido>
Empresa: 1
Filial: 1
Pedido: 1
Cliente: 10
Fecha Pedido: S
<Produto>
Seq. Item: 1
Pedido: 1
Produto: 1101
</Produto>
<Produto>
Seq. Item: 2
Pedido: 1
Produto: 1102
</Produto>
</Pedido>
<Pedido>
Empresa: 1
Filial: 1
Pedido: 2
Cliente: 20
Fecha Pedido: N
<Produto>
Seq. Item: 1
Pedido: 2
Produto: 1501
</Produto>
<Produto>
Seq. Item: 2

25
Pedido: 2
Produto: 1502
</Produto>
</Pedido>
</GravarPedidos>
Retorno do Web Service:
<GravarPedidos>
<RespostaPedido>
Empresa: 1
Filial: 1
Pedido: 1
Retorno: Inserido com Sucesso
<Produto>
Seq. Item: 1
Pedido: 1
Retorno: OK
</Produto>
<Produto>
Seq. Item: 2
Pedido: 1
Retorno: OK
</Produto>
</RespostaPedido>
<RespostaPedido>
Empresa: 1
Filial: 1
Pedido: 2
Retorno: Pedido Inserido Parcialmente
<Produto>
Seq. Item: 1
Pedido: 2
Retorno: OK
</Produto>
<Produto>
Seq. Item: 2
Pedido: 2
Retorno: Falta Estoque
</Produto>
</RespostaPedido>
</GravarPedidos>

26
CAMPOS DE USUÁRIOS
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.
Figura 18

27
CAPÍTULO 04
Sistema Senior Chamando Web Services
 Realizar as ações necessárias para que o sistema chame Web Services.

28
PROTOCOLOS E VERSÕES SUPORTADAS
A comunicação dos Web Services baseia-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.

29
MAPEAMENTO DE SERVIÇOS DE OUTROS SISTEMAS
Mapeamento de WSDL para Editor de Serviços
O mapeamento de serviços de outros sistemas é referente a 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 do Sistema
Senior.
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.
Para acessar o WSDL do Web Service que será utilizado, vamos acessar o seguinte
endereço: https://www.w3schools.com/xml/tempconvert.asmx?WSDL
Este Web Service faz a conversão de graus Celsius para Fahrenheit e vamos mapeá-lo no
sistema Gestão Empresarial | ERP ficando disponível para a utilização no sistema. Na imagem
abaixo temos o WSDL do web service.

30
Figura 19
No Gestão Empresarial | ERP vamos abrir o editor de web services, conforme figuras
abaixo.
Figura 21
Figura 20

31
Para iniciar o mapeamento do web service precisamos primeiramente adicionar um

provedor, pois este tipo de web service não é adicionado no provedor interno, conforme
comentado anteriormente.
Existem quatro formas de acessar a tela que adiciona um provedor, através do menu
“Arquivo > Servidor > Adicionar” ou ainda no ícone na barra de ferramentas e também com
duplo clique sobre o item “Adicionar provedor” na lista de provedores, conforme mostra as
figuras abaixo:
 Através do menu “Arquivo > Servidor > Adicionar”;
Figura 22
 Através no ícone na barra de ferramentas;
Figura 23

32
 Com duplo clique sobre o item “Adicionar provedor” na lista de provedores;
Figura 24
 Através dos atalhos do teclado (Insert, Enter e Delete) correspondentes a cada

item e menu de contexto (popup) no menu de navegação e da lista:
Figura 25

33
Clicando em Adicionar o editor vai exibir a tela abaixo para informar os parâmetros do
provedor que será adicionado.
Figura 26
Levando em consideração a URL do web service vamos definir os parâmetros a serem

informados: https://www.w3schools.com/xml/tempconvert.asmx.
 Tipo do provedor: marcar a opção “Provedor de serviços de terceiros”.
 Nome do provedor: informar um nome qualquer. Ex: Treinamento.
 Timeout: o valor é em minutos. Ex: 30.
 URL do servidor: informar “https://www.w3schools.com”.
 Contexto: informar “xml”.
 Separador do contexto: informar “/”.
Figura 27

34
A configuração deve ficar conforme imagem abaixo.
Figura 28
Após clicar em OK precisamos adicionar um serviço ao provedor que irá executar o

método responsável por fazer a conversão da temperatura. Para adicionar um serviço existem
três formas alternativas de se fazer:
 Através do menu Arquivo > Serviço > Adicionar;
Figura 29

35
 Através das opções do menu do botão de Serviço;
Figura 30
 Com um duplo clique em Adicionar Serviço;
Figura 31
Em seguida será exibida uma tela para informar o nome do serviço desejado, este
nome refere-se ao nome do web service e deve ser único dentro do provedor ao qual ele
pertence, não podendo conter espaços ou caracteres especiais. No caso de um serviço de um
provedor de web services terceiro, a tela exiba terá mais opções, conforme a imagem abaixo:
Figura 32
Esta tela é diferente para os serviços de provedores de web services terceiros porquê
alguns podem conter caracteres especiais em seus nomes, como por exemplo
“webConverter?action=Web&param=1”.

36
Estes nomes com caracteres especiais não podem ser cadastrados no campo Nome, pois
não seria possível criar regras LSP para a chamada destes web services.
Desta forma é possível cadastrar neste campo um nome diferente do nome real do web
service, no exemplo da figura está sendo cadastrado o nome "webConverter".
Já o nome real do web service, o nome presente na URL completa do provedor que
possua caracteres especiais, pode ser cadastrado no campo Nome do serviço presente na URL.
No exemplo da figura está sendo cadastrado "webConverter?action=Web&param=1".
Desta forma, quando o nome presente na URL cadastrado for diferente do nome, o web
service chamado terá o nome do campo “Nome do serviço presente na URL”.
Então nesta tela vamos informar no campo Nome a informação “tempconvert” e no
campo “Nome do serviço presente na URL” a informação “tempconvert.asmx”, conforme consta
na URL do web service que vamos utilizar. Após informar clique em OK.
Figura 33
O próximo passo é adicionar a porta e seus parâmetros de entrada e saída. Para

adicionar portas a um serviço, existem três formas distintas:
 Selecionando o serviço desejado, através do menu “Arquivo > Porta >

Adicionar”;
Figura 34

37
 Através da seta ao lado do botão “Portas” no item “Adicionar”;
Figura 35
 Selecionando o serviço desejado e dado duplo clique no item “Adicionar Porta”;
Figura 36
Após selecionar qualquer uma das opções o editor exibirá a tela abaixo:
Figura 37

38
Nome: Esse campo definirá o nome da porta, é um campo obrigatório. Este nome deve
ser único dentro do serviço ao qual a porta pertence e não pode conter espaços ou caracteres
especiais. O nome não pode terminar com “_n”, onde “n” representa qualquer número inteiro,
se extraindo o “_n” do nome ele fique igual ao nome de uma porta nativa do mesmo serviço.
Por exemplo, há uma porta nativa com nome "Calcular" no serviço "Teste". No serviço
"Teste" não pode ser inserida uma porta com o nome "Calcular_1", "Calcular_2"... "Calcular_n".
Como estamos mapeando um web service de terceiro precisamos identificar a porta ou
as portas, no WSDL do web service. Então temos que procurar a tag “portType” e identificar qual
porta queremos utilizar, conforme imagem abaixo:
Figura 38
Utilizaremos a porta “CelsiusToFahrenheit” para este caso.
Descrição: Esse campo permite adicionar informações relevantes para a identificação

da porta do serviço, como sua funcionalidade, por exemplo.

39
Ação: Identifica o propósito da requisição do serviço. Esta informação deve ser obtida
da WSDL do serviço (tag soapAction) e está disponível apenas para portas de serviços de
terceiros.
Figura 39
Identificador universal: Identificador único da porta. Esta informação deve ser obtida
da WSDL do serviço (targetNamespace) e está disponível apenas para portas de serviços de
terceiros.
Figura 40
Estilo de codificação: Estilo de codificação da porta. Esta informação deve ser obtida da
WSDL do serviço (tag encodingStyle) e está disponível apenas para portas de serviços de
terceiros. O estilo de codificação deve ser informado apenas quando a forma de construção da
chamada é "encoded", e não "literal".
Enviar tipo de dado dos parâmetros: Indica se o tipo de dado dos parâmetros será
enviado no XML de requisição. Este tipo é indicado por um atributo dentro da tag de cada
parâmetro.

40
A configuração deve ficar conforme imagem abaixo:
Figura 41
Agora precisamos informar os parâmetros de entrada e saída da porta que acabamos

de configurar. Vamos identifica-los da seguinte forma: no WSDL do web service no mesmo local
onde encontramos a porta que vamos utilizar existem as tags “wsdl:input” e “wsdl:output” que
definem os parâmetros de entrada e saída.
Figura 42

41
Agora precisamos identificar o “tns:CelsiusToFahrenheitSoapIn” e o

“tns:CelsiusToFahrenheitSoapOut”. Conforme imagem abaixo:
Figura 43
Agora precisamos identificar o “tns:CelsiusToFahrenheit” e o

“tns:CelsiusToFahrenheitResponse”. Conforme imagem abaixo:
Figura 44
Então temos um parâmetro de entrada chamado “Celsius” do tipo “string” e também

um parâmetro de saída chamado “CelsiusToFahrenheitResult” do tipo “string”.
Com essas informações em mãos precisamos informar esses parâmetros na tela onde
configuramos a porta que será utilizada.
Na tela de adicionar porta de serviço clique em “Adicionar” para abrir a tela “Adicionar
parâmetro”, conforme imagem abaixo.

42
Figura 45
Agora vamos informar os parâmetros, iniciando pelo “Celsius” que ficará da seguinte
forma. Após clique em OK e informar o segundo parâmetro “CelsiusToFahrenheitResult”.

43
Figura 46
Figura 47

44
As configurações da porta ficam da seguinte forma.
Figura 48
Após todas as configurações devemos salvar e testar o web service para assegurar que
está funcionado corretamente.
Figura 49

45
Para testar de duplo clique na porta “CelsiusToFahrenheit” para abrir a tela com as
configurações da porta e clique em “Testar”. Informe o parâmetro de entrada que é em graus
Celsius e o web service deverá retornar o valor correspondente em Fahrenheit.
Figura 50
Desta forma configuramos ou mapeamos um web service de terceiro no sistema Senior,

neste caso o Gestão Empresarial | ERP.
Tipos de autenticação
Com relação a usuários para execução de serviços, para provedores de serviços Senior,
indica qual o usuário padrão a ser utilizado para a execução dos serviços quando o usuário não
for informado explicitamente no momento que o serviço é chamado, podendo-se optar por
usar sempre o usuário que estiver logado no sistema.
No caso de provedores de serviços de terceiros, este usuário será utilizado para fazer
autenticação HTTP ou SOAP, caso o servidor exija tal autenticação. Se a opção for autenticação
SOAP, deverá ser informado o nome do nó de autenticação (TAG authentication), o nome dos
atributos de nome e senha do usuário e se necessário, o identificador universal
(targetNameSpace), conforme imagem:

46
Figura 51
Quando utilizadas as configurações de autenticação, será gerada uma sessão de

cabeçalho (header) no XML de acordo com a opção separar os parâmetros em nós.
Se a opção separar os parâmetros em nós estiver selecionada, a sessão de cabeçalho
utilizado para autenticação no XML será gerada da seguinte forma:
Figura 52
Se a opção separar os parâmetros em nós não estiver selecionada, a sessão de cabeçalho

utilizado para autenticação no XML será gerada da seguinte forma:
Figura 53

47
MAPEAMENTO ENTRE SISTEMAS SENIOR
Provedor Senior de mesma base
Provedor que contém os serviços de sistemas Senior que estão no mesmo servidor, e
usando a mesma base, do sistema em execução.
Ao adicionar um provedor deste tipo, as configurações referentes ao servidor serão

obtidas automaticamente das configurações de serviços, restando ao usuário informar apenas
o nome do provedor e o usuário para execução de serviços.
Para cadastrar um provedor Senior de mesma base devemos clicar no menu “Arquivo
> Provedor > Adicionar” do editor de serviços.
Figura 54
Ao marcar a opção “Mesma base”, serão assumidas as configurações de web services

padrões do sistema. No campo “Nome do provedor” podemos informar um nome ou um
formato de nome que será utilizado caso mais de um sistema for selecionado. Podemos utilizar

48
“%s”, este valor será substituído pelo nome do sistema que contém os web services. Por
exemplo, se colocarmos “teste_%s” será atribuído ao nome do provedor “teste_tr”.
Na seção “Usuário para execução dos serviços” podemos deixar a opção padrão de
utilizar o usuário logado no sistema ou especificar um usuário e senha que será sempre
utilizado para executar os web services desse provedor no servidor.
O “Timeout” deve ser informado em minutos.
Clicando em “Avançar”, será exibida uma lista com todos os sistemas disponíveis no
servidor que utilizam a mesma base que o sistema que está sendo utilizado.
Figura 55
Podemos selecionar quais aplicações iremos integrar. Ao clicar em OK será criado um

provedor para cada sistema selecionado, utilizando as mesmas configurações para todos.
Vamos trazer os web services do módulo TR para dentro do Administração de Pessoal. Então
selecionamos a opção “tr” na tela e clicamos em OK. Com isso os serviços ficam disponíveis,
conforme mostra a imagem abaixo.

49
Figura 56
Provedores Senior de bases diferentes
Este recurso é utilizado quando se deseja integrar sistemas que não utilizem a mesma
base. Eles podem estar disponíveis no mesmo servidor ou em servidores diferentes.
Para cadastrar um provedor Senior devemos clicar no menu “Arquivo > Provedor >
Adicionar” do editor de serviços. Neste caso, não vamos marcar a opção “Mesma base”.

50
Figura 57
As opções são exatamente as mesmas que as utilizadas para criar um provedor de

mesma base, porém nesta modalidade elas devem ser informadas manualmente.
No campo “URL do servidor” devemos informar a URL que será utilizada para acessar o
servidor onde os web services estão disponíveis.
Na seção “Configurações de proxy” pode-se informar os dados para autenticação no

servidor de proxy caso seja necessário para acessar a URL do servidor.
Clicando em “Avançar”, será exibida uma lista com todos os sistemas disponíveis no
servidor que está sendo cadastrado. Selecionado os sistemas que se deseja integrar, ao clicar
em “Ok” será criado um provedor para cada sistema selecionado, todos com as mesmas
configurações.
Neste exemplo, estamos trazendo para o Gestão Empresarial | ERP os serviços do

Administração de Pessoal (rubi). Conforme mostra as imagens abaixo.

51
Figura 58
Figura 59

52
Atualização dos web services
Após uma customização, podem ser criados novos serviços. Para que um sistema
consiga acessar estes novos serviços criados em outros sistemas, é necessário recarregar o
Catálogo de Serviços, que traz as definições de todos os serviços atualizadas. Para isso, deve-se
acessar o “Editor de Serviços” e utilizar a opção “Atualizar todos do servidor” disponível ao
clicar com o botão direito do mouse sobre o nó “Provedores”, conforme imagem abaixo.
Figura 60

53
INVOCAÇÃO DE WEB SERVICES VIA 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.
Estrutura da regra LSP
Definir Alfa aCodEmp;

Definir Alfa aRetObs;
Definir Alfa aSitPed;
Definir Alfa aSeqIpd; Declaração do Web Service
para ser utilizado na regra
@ Declaração da variável identificando o serviço @
Definir interno.com.senior.g5.co.int.padrao.documentos.Pedido SrvPedido;
@ Cria nova linha para o cabeçalho do pedido @
SrvPedido.Pedido.CriarLinha();
SrvPedido.Pedido.OpeExe = "I"; Criação da linha da tabela
SrvPedido.Pedido.CodEmp = 1;
do parâmetro Pedido
SrvPedido.Pedido.CodFil = 1;
SrvPedido.Pedido.CodCli = 1;
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 tabela
SrvPedido.Pedido.Usuario.CmpUsu = "Usu_CodTeste";
do parâmetro
SrvPedido.Pedido.Usuario.VlrUsu = "1";
@ Cria nova linha para cada produto @ Pedido.Usuario
SrvPedido.Pedido.Produto.CriarLinha();
SrvPedido.Pedido.Produto.OpeExe = "I";
SrvPedido.Pedido.Produto.CodPro = "1101"; Criação da linha da tabela
SrvPedido.Pedido.Produto.CodDer = " ";
SrvPedido.Pedido.Produto.QtdPed = "1000"; do parâmetro Produto
SrvPedido.Pedido.Produto.CodTpr = " ";
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 tabela
SrvPedido.Pedido.Produto.Usuario.CmpUsu = "Usu_NCodTeste"; do parâmetro
SrvPedido.Pedido.Produto.Usuario.VlrUsu = "2";
@ Define o modo de execução local @ Pedido.Produto.Usuario
SrvPedido.ModoExecucao = 1;
@ Executa o web service @ Define o Modo de Execução
SrvPedido.Executar();
fim;
Executa o Web Service

54
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
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.
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)
Retorno da tabela de
Produtos do Pedido

55
inicio
SrvPedido.RespostaPedido.GridPro.LinhaAtual = iQtdPro;
aSeqIpd = SrvPedido.RespostaPedido.GridPro.SeqIpd;
aRetObs = SrvPedido.RespostaPedido.GridPro.Retorno;
iQtdPro = iQtdPro + 1;
fim;
iQtdPed = iQtdPed + 1;
fim;
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. Exemplo:
definir alfa acodemp;

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

56
SrvGerCtaRec.EntradaTitulos.DatEmi = dDatEmi; @ Data de emissão do título a receber @

SrvGerCtaRec.EntradaTitulos.DatEnt = dDatEnt; @ Data de entrada do título a receber @
SrvGerCtaRec.EntradaTitulos.CodCli = 1; @ Código do cliente do título a receber @
SrvGerCtaRec.EntradaTitulos.CodRep = 1; @ Código do representante do título a receber @
SrvGerCtaRec.EntradaTitulos.VctOri = dVctOri; @ Data do vencimento @
SrvGerCtaRec.EntradaTitulos.VctPro = dVctPro; @ Data do vencimento Prorrogado @
SrvGerCtaRec.EntradaTitulos.VlrOri = 100; @ Valor original do título a receber @
SrvGerCtaRec.EntradaTitulos.CodFpg = 001; @ Código da forma de pagamento @
SrvGerCtaRec.EntradaTitulos.DatPpt = dDatPpt; @ Data do provável pagamento @
SrvGerCtaRec.EntradaTitulos.CodPor = "9999"; @ Código do portador do título @
SrvGerCtaRec.EntradaTitulos.CodCrt = "99"; @ Código da carteira do título a receber @
SrvGerCtaRec.EntradaTitulos.CodMoe = "01"; @ 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;
}

57
CAPÍTULO 05
Sistema Senior Expondo Web Services
 Realizar as ações necessárias para que o sistema exponha Web Services.

58
VISAO BÁSICA DA ARQUITETURA DOS SERVIÇOS SENIOR
Para prover o Web Services o Middleware Senior contém os seguintes componentes:
Figura 61
Cliente: Pode ser um sistema Senior ou qualquer sistema que utilize a tecnologia de Web
Services.
Glassfish: Servidor de aplicativos JEE. Para cada Web Service G5 são expostos 3 Web
Services JEE no momento em que é realizado o deploy. São eles:
 Um para o serviço ser chamado de forma síncrona. Esse serviço será executado
imediatamente irá retornar uma resposta;
 Um para o serviço ser chamado de forma assíncrona. Esse será postado em uma
fila JMS e não terá uma resposta imediata;
 Um para o serviço ser chamado de forma agendada. Esse será agendado por
nossas rotinas de agendamento e irá executar no período determinado.
Gerenciador do Middleware: Camada responsável por intermediar a comunicação

entre as aplicações do Middleware e o Glassfish (no caso de Web Services). Também é
responsável por fazer o balanceamento de carga das aplicações e controlar seu ciclo de vida. É

59
representado pelo aplicativo SeniorMiddleware.exe no modo Gerenciador de Middleware.

Apenas existirá um Gerenciador de Middleware em um ambiente.
Gerenciador de aplicativos: Camada responsável por gerenciar as aplicações do
Middleware na máquina servidora. Esse irá executar em cada servidor que deseja prover
aplicações do Middleware. É responsável por iniciar as aplicações, conforme solicitado pelo
Gerenciador do Middleware. Também é responsável por checar a "saúde" da aplicação,
verificando o consumo de memória e checando se aplicação ainda está respondendo.
Aplicação: Aplicação G5 Senior que provê os serviços para serem executados. Para Web
Service essa aplicação é a principal de cada módulo (Ex.: Rubi.exe, Rs.exe, Sapiens.exe...).

60
PROCESSOS DE DEPLOY
O deploy dos web services acontece durante uma instalação ou atualização do produto
ou através da ferramenta de deploy.
A ferramenta de deploy é utilizada após realizar customizações em web services, não

sendo necessário atualizar todo o sistema para aplicar a customização, apenas realizando o um
novo deploy do web service customizado.
Os web services são disponibilizados pelos sistemas e são utilizados na integração,

fazendo a comunicação entre aplicações diferentes. Permitem que aplicações novas interajam
com antigas, mesmo que desenvolvidas em plataformas diferentes, enviando e recebendo
dados no formato XML. Como cada aplicação pode ter a sua própria linguagem, o XML traduz
as informações em uma linguagem universal.
Características principais:
 Acesso web, permitindo o deploy dos recursos customizados Senior;

 Login integrado ao servidor GlassFish, onde a ferramenta é instalada;
 Automatização do deploy, basta selecionar os itens customizados que a ferramenta
realiza o deploy;
 Nomes dos aplicativos cadastrados no Instalador são disponibilizados para seleção;
 Validação da disponibilidade e integridade dos recursos necessários para deploy logo
no início do processamento e também a validação dos dados e tratamento dos erros;
 Mensagem de erros com detalhes técnicos para suporte e desenvolvimento;
 Mensagens de log armazenadas no log do próprio GlassFish, facilitando a obtenção e
leitura dos logs.
Acessando a ferramenta
Para acessar a ferramenta de deploy, acesse um navegador web e informe o endereço

onde a ferramenta foi disponibilizada, que é composto do nome do servidor juntamente com a
porta e o contexto "SeniorDeployTool".
Exemplo: http://nome-do-servidor:numero-da-porta/SeniorDeployTool
Ao acessar a ferramenta, será exibida a tela de login, onde devem ser informados os
dados do ambiente que se deseja iniciar (previamente configurado no Instalador), além do
Usuário e Senha do administrador do servidor Java EE, nesse caso, o mesmo usuário do
console de administração do GlassFish. Após informar os dados de acesso, clique em Entrar
para visualizar a tela principal da ferramenta.

61
Figura 62
Esta funcionalidade tem por objetivo disponibilizar os recursos do instalador na

ferramenta e permitir realizar o deploy em uma única etapa, selecionando todos os recursos,
desde que o Middleware Senior do ambiente esteja iniciado.
Para efetuar o deploy de vários web services, eles devem ser selecionados na listagem
de itens, podem ser selecionados somente alguns, ou todos clicando sobre a primeira caixa de
seleção representada pelo :
Figura 63

62
Ao clicar no botão Iniciar deploy dos recursos selecionados o processo é iniciado. Ao

final do procedimento os recursos estarão disponíveis no servidor Java EE.
É possível efetuar o re-deploy de recursos, selecionando os recursos desejados e

clicando no botão Iniciar deploy dos recursos selecionados, todo o processo de deploy será
efetuado novamente.
IMPORTANTE
Caso já exista algum web service agendado para execução no servidor Java EE e, novamente for
realizado o deploy dos web services, o agendamento será mantido com a mesma sequência
(ID) gerada no deploy anterior.
Os sistemas Senior que utilizam esse ID para controle interno dos agendamentos não perderão

63
CRIAÇÃO DE WEB SERVICES CUSTOMIZADOS
Os sistemas Senior contêm alguns web services que são padrões, os quais são
disponibilizados com a cópia do sistema. Estes web services já estão disponíveis a partir do
momento que o recurso de web services é habilitado no sistema e são expostos utilizando o
protocolo SOAP.
Todos os web services disponibilizados pelo sistema estão disponíveis no provedor

“interno”, e por isso são chamados de “serviços internos”.
IMPORTANTE
Web services padrões que são disponibilizados pelo sistema não podem ser editados, apenas
consultados ou desabilitados.
Além dos web services padrões, é possível desenvolver novos web services que serão
disponibilizados pelo sistema, cuja funcionalidade deve ser implementada em regra LSP.
Para criar um novo serviço, devemos selecionar o provedor interno e clicar no menu
“Arquivo > Serviço > Adicionar”.
Abrirá uma tela onde deve ser informado o nome do serviço que será criado. Este
nome não deve conter espaços, acentuações ou caracteres especiais.
Figura 64
DICA
Sugerimos que seja utilizado o mesmo padrão de nomenclatura dos serviços padrões do
sistema, pois se houver mais de um sistema no mesmo servidor com serviços de mesmo nome
e funcionalidades diferentes, poderá haver conflito no momento de carregar o serviço e ele
poderá não funcionar.

64
Para criar uma nova porta, devemos selecionar o serviço onde ela será criada e clicar no
menu “Arquivo > Porta > Adicionar”.
Abrirá uma tela onde devem ser preenchidas as informações da porta.
Figura 65
1. Nome: Deve ser informado o nome da porta, o qual será utilizado por quem for
utilizar essa funcionalidade do web service em questão. Esse nome não deve conter
espaços, acentuações ou caracteres especiais.
2. Descrição: Deve ser informada uma breve descrição para a porta.
3. Autenticação: Podemos informar se esta funcionalidade necessita ou não de um

usuário válido para ser executada. Se optar-se por “Fazer logon”, quando algum
sistema executar o web service ele deverá passar um usuário e senha válido, o qual
deve estar cadastrado no SGU. É importante ressaltar que quando a execução do
web service é anônima, não haverá nenhum usuário logado no sistema servidor,
portanto não deve-se utilizar nenhum recurso que depende de permissão ou
qualquer configuração de usuário.

65
4. Timeout: Informamos o tempo que um sistema Senior G5 aguarda pela resposta do

servidor antes de retornar um erro de timeout. Como este campo é opcional, se for
mantido o valor 0 (zero), será considerado o timeout do provedor, que por padrão
é de 30 minutos.
5. Parâmetros: Devemos informar quais são os parâmetros de entrada e saída da

porta. Para criar um parâmetro de uma porta podemos utilizar os botões de edição
da lista de parâmetros da tela de edição da porta ou então através do menu
“Arquivo>Parâmetro>Adicionar” (deve-se estar com a porta selecionada na árvore
de recursos). Será aberta uma tela onde deverão ser preenchidas as informações do
parâmetro.
Figura 66

66
a) Tipo de dado: Selecionar qual vai ser o tipo do dado (valor) que vai ser transportado no
parâmetro, conforme descrito abaixo:
- Alfanumérico: pode ser passado qualquer valor com qualquer tipo de caracter;
- Inteiro: pode ser passado qualquer valor numérico inteiro;
- Decimal: pode ser passado qualquer valor numérico decimal;
- Hora: pode ser passado qualquer texto que represente uma hora qualquer;
- Data e hora: pode ser passado qualquer texto que represente uma data e hora
qualquer, ou apenas uma data;
- Texto: pode ser passado qualquer texto. A diferença do tipo texto para o tipo
alfanumérico é que no campo texto o valor é passado no formato binário e pode ser bem
maior do que se fosse passado no campo alfanumérico. Como o valor trafega no formato
binário, podem ser passadas inclusive imagens, por exemplo.
- Tabela: tipo de dado mais complexo. Neste caso pode ser passada uma tabela
(grade) através do parâmetro. Após criar um parâmetro do tipo Tabela é necessário definir
suas colunas, como será visto mais abaixo.
IMPORTANTE
A validação dos valores dos parâmetros dos tipos Alfanumérico, Inteiro, Decimal, Hora
e Data e hora deve ser feia por quem implementa o serviço (na regra LSP).
b) Tipo de parâmetros: Temos parâmetros de entrada e de saída, conforme abaixo:

- Entrada: o chamador do serviço informa um valor que vai ser transportado e lido
no servidor (na implementação da regra);
- Saída: o servidor (implementação da regra) escreve no parâmetro e o chamador
lê esse valor na resposta do web service;
- Entrada e Saída: o parâmetro assume as duas funcionalidades acima descritas.
c) Nome: Deve ser informado o nome do parâmetro. Este nome não deve conter espaços,
acentuações ou caracteres especiais.

67
d) Ajuda: Pode ser informado um breve texto com a descrição do parâmetro e os valores
esperados, por exemplo. Esse texto de ajuda será visualizado no editor de serviços e na
documentação gerada pela ferramenta de deploy.
e) Colunas: Se o tipo do parâmetro for “Tabela” devemos informar as colunas neste

campo. Para criar uma coluna podemos utilizar os botões de edição da lista de colunas
da tela de edição de parâmetros ou então o menu “Arquivo>Coluna>Adicionar” (é
necessário que o parâmetro esteja selecionado na árvore de edição de recursos).
A edição de uma coluna é idêntica à edição de um parâmetro, exceto pelo tipo (Entrada
ou Saída) que é assumido igual ao tipo do parâmetro.
Figura 67

68
Podemos observar que o tipo de dado de uma coluna pode ser outra Tabela, permitindo
que possam ser criados relacionamentos mestre/detalhe dentro da implementação do
web service. Por exemplo, podemos ter um web service que retorne as informações de
um pedido, contendo uma tabela que represente os itens do pedido que, por sua vez,
tem uma coluna tipo tabela que representa subitens de cada item.
IMPORTANTE
O sistema limita ao máximo de 10 níveis de tabelas inseridas uma dentro da outra.
6. Regra: Botão que chama a tela para desenvolvermos a regra LSP que será executada
quando algum sistema invocar esta funcionalidade do novo web service.
Figura 68
IMPORTANTE
Todos os parâmetros definidos na Porta são declarados implicitamente para serem
utilizados na edição da regra.
Após salvar e fechar o editor da regra, voltando à tela de edição da porta. Clicar no botão
“Testar” para executar a porta localmente e ver se ela foi implementada corretamente.

69
Figura 69
Após ter concluído a edição da porta basta clicar em “Ok” para voltar à tela principal do
editor. É importante ressaltar que, até o momento, nenhuma configuração foi salva. Na tela do
editor podemos observar que foram habilitadas as opções descritas abaixo:
- Salvar: salva todas as alterações feitas no item selecionado na árvore de recursos

(inclusive os subitens);
- Salvar tudo: salva todas as alterações pendentes;
- Desfazer tudo: desfaz todas as alterações pendentes (que ainda não foram salvas).

70
GERAÇÃO DE DOCUMENTAÇÃO
Para gerar a documentação dos web services customizados, ou seja, criados pelo
cliente ou qualquer outro profissional é necessário acessar a ferramenta de deploy, conforme
já vimos em Processos de Deploy. O processo para gerar a documentação é semelhante ao
processo de deploy, a diferença é que para a documentação utilizamos o botão Gerar
Documentação. O botão Gerar Documentação exporta apenas as informações de web services
customizados (implementados pelo cliente). Ou seja, os que são nativos da solução Senior tem
a documentação diferenciada, que pode ser acessada no Portal de Documentação de acordo
com o produto e versão, ou diretamente no Editor de Web Services.
Clicando em Gerar Documentação o sistema exibe a tela abaixo com algumas opções.
Neste caso vamos gerar a documentação do web service que criamos:
Figura 70
Após clicar no botão Gerar o sistema vai gerar os seguintes arquivos no caminho
informado no campo Diretório de destino, conforme imagem abaixo:

71
Figura 71
Executando o arquivo é exibido o conteúdo conforme imagem abaixo. Note que já é

gerado também os endereços dos WSDLs.
Figura 72

72
Executando o endereço do WSDL teremos a especificação do web service que acabamos

de criar, conforme mostra a imagem abaixo.
Figura 73
DICA
Para os web services padrões a documentação e o endereço dos WSDLs são encontrados no
Portal de Documentação de acordo com o produto e versão de cada um.

73
CONSOLE DE WEB SERVICES
Console de Administração Multicamada
É uma ferramenta usada para gerenciar requisições assíncronas e agendadas e

execução de processamentos síncronos, assíncronos e agendados. Pode ser usado por usuários
(usuários comuns) ou por Administradores (usuários com permissão de gerenciar ambiente
multicamada). É ativada via menu dentro dos sistemas G5.
Figura 74
Os processos síncronos e assíncrono podem ser visualizados na primeira guia e apenas

serão apresentados por período. Por padrão a tela irá iniciar com os processos executados na
data atual.
Na segunda guia estão os processos agendados. Só serão exibidos os processos ainda
agendados no servidor de aplicação. Caso o agendamento tenha sido encerrado, os processos
já executados serão encontrados na primeira guia.
O Console permite que sejam realizadas as tarefas de gerenciamento do ambiente de
multicamada. O usuário precisa ter uma permissão específica para ter acesso a esta visão. Todas
as visualizações abaixo apresentam os parâmetros de entrada e retorno de cada requisição. As
operações disponíveis no console de administração são aplicáveis as todas requisições e
execuções de todos os usuários, quando o usuário for administrador. Para usuários comuns (não
administradores) somente são visualizadas as tarefas dele mesmo e, consequentemente, ele só
poderá cancelar e reagendar tarefas provindas do mesmo.

74
IMPORTANTE
O Console não é suportado nas seguintes formas de acesso: WindowsAccess,
BrowserAccess e Web 5.0.
As operações permitidas são:

 Visualizar processamentos assíncronos na fila;
 Visualizar processamentos agendados;
 Visualizar processamentos em execução (assíncronos, agendados e síncronos)
com informações avançadas:
o Uso de CPU;
o Uso de memória;
o Duração;
o Percentual de conclusão;
o Previsão de término;
 Visualizar processamentos assíncronos e agendados já executados e os seus

respectivos resultados;
 Cancelar processamentos assíncronos na fila;
 Cancelar processamentos agendados;
 Alterar o momento de execução de processamentos agendados;
 Cancelar processamentos síncronos, assíncronos e agendados em execução;
 Excluir o resultado de processamentos terminados e agendados selecionando
itens ou usando algum critério de pesquisa;
 Agendar os processamentos da fila de assíncronos para postergar a execução;
 Gerar relatórios estatísticos sobre os processamentos já executados.
 Visualizar log dos processos executados. Quando o estado de uma execução de
uma requisição é "execução com erros" o menu popup apresenta uma opção
através da qual o usuário tem acesso a mensagem do erro capturada durante a
tentativa de executar a requisição.
 Executar novamente processos já executados.

75
 Visualizar dados de entrada da execução do processo, quando os Status do

processo for diferente de Agendado.
 Na guia Síncronos e Assíncronos é possível realizar as seguintes buscas:
o Por período: os campos início e fim, indicam que somente os processos
com data inicia igual a início até processos com data inicial igual ao fim,
serão apresentados;
o Por nome: no campo nome pode ser adicionados nomes parciais e todos
os processos que contiverem aquele valor e período serão apresentados.
Configuração do Console de Administração Multicamada
Nesta tela de configuração é possível definir quais os campos que estarão disponíveis
no console para visualização, aplicar filtros e habilitar a opção de limpeza automática dos
processos executados.
Figura 75

76
Colunas Visíveis
Atualizar a cada x segundos: Esta opção serve para definir o intervalo de tempo
(segundos) em que as informações enviadas ao console serão atualizadas.
Visualizar logs de usuários excluídos: Essa configuração permite adicionar à lista de

execução de logs, os web services que foram executados por usuários já excluídos.
DICA
Por padrão, esta opção sempre estará desabilitada, caso seja necessário, a sua
visualização deve ser selecionada novamente. Caso o usuário que executou o serviço
seja excluído durante a execução da aplicação que irá acessar o console, o usuário em
questão continuará sendo exibido nos logs, ele só irá identificar a exclusão do usuário
após a abertura de uma nova aplicação.
Campos disponíveis: São listados todos os campos disponíveis possíveis de serem

visualizados no console de administração.
Campos selecionados: Pode-se selecionar os campos a serem vistos no console.
Figura 76

77
Filtros
Visualizar requisições do usuário: A opção de filtro tem a finalidade de filtrar apenas

os usuários que deseja visualizar as requisições de processos. Caso deseje visualizar de todos
os usuários a opção Todos deve ser selecionada.
Atenção: Isto apenas é válido para usuários Administradores. Usuários que não são
administradores apenas poderão visualizar suas próprias requisições e esta guia não estará
visível para configuração.

78
REFERÊNCIAS
https://pt.wikipedia.org/wiki/Web_service
http://www.soawebservices.com.br/como-funciona.aspx
http://www.opensoft.pt/web-service/
https://documentacao.senior.com.br/

79

Apostila - Web Services Na G5

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - Web Services Na G5

Enviado por

Direitos autorais:

Formatos disponíveis

Tecnologia – Web Services

Tecnologia – Web Services na G5

Copyright© 2017 Todos os direitos reservados.

Todos os direitos reservados e protegidos pela Lei nº 9.610, de 19/02/1998.

1ª Edição deste material – 25 de agosto de 2017.

Copyright© 2017 Todos os direitos reservados.

Copyright© 2017 Todos os direitos reservados.

Copyright© 2017 Todos os direitos reservados.

Particularidades desta forma de execução ............................................................................. 55

Copyright© 2017 Todos os direitos reservados.

 Saber o que é Web Service, sua arquitetura de funcionamento e protocolos utilizados.

Copyright© 2017 Todos os direitos reservados.

O QUE É WEB SERVICE

WebService é uma solução utilizada na integração de sistemas e na comunicação entre

Copyright© 2017 Todos os direitos reservados.

COMO FUNCIONA UM WEB SERVICE

Tendo em conta as operações disponíveis no Web Service, a aplicação solicita uma

Se são linguagens diferentes, como conseguem comunicar?

É necessária uma linguagem intermédia que garanta a comunicação entre a linguagem

O protocolo SOAP utiliza XML para enviar mensagens e, geralmente, serve-se do

O REST é um protocolo de comunicação mais recente que surgiu com o objetivo de

Copyright© 2017 Todos os direitos reservados.

Quais os benefícios dos Web Services?

– Integração de informação e sistemas: uma vez que o funcionamento do Web Service

– Redução do tempo de desenvolvimento: é mais rápido desenvolver com Web Services,

Copyright© 2017 Todos os direitos reservados.

Web Service: uma solução prática.

Uma solução prática e de baixo custo para solucionar a incompatibilidade de sistemas e

Copyright© 2017 Todos os direitos reservados.

ENTIDADES ENVOLVIDAS NO PROCESSO

Consumidor: Responsável por obter o documento WSDL do serviço desejado. Posteriormente,

Registrador: Entidade responsável por armazenar as informações disponibilizadas pelos

Copyright© 2017 Todos os direitos reservados.

POR QUE USAR WEB SERVICES

Também é muito usado quando há necessidade de automatização de processos nos

Sistemas complexos requerem:

Essencialmente, o Web Service faz com que os recursos da aplicação do software

Copyright© 2017 Todos os direitos reservados.

 Configurar o sistema para o uso de Web Services e identificar os recursos disponíveis

Copyright© 2017 Todos os direitos reservados.

A Senior disponibiliza ferramentas e recursos de tecnologia agregadas em todos os seus

A arquitetura das soluções é formada pelo conjunto de elementos que constituem a

Para facilitar a visualização da Tecnologia Senior, a ilustração abaixo divide as quatro

Copyright© 2017 Todos os direitos reservados.

Modo Síncrono: O processamento da requisição será direcionado ao Middleware

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

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

Copyright© 2017 Todos os direitos reservados.

Depois de fazer a instalação do sistema e do Glassfish, o primeiro passo para a utilização

Os campos devem ser preenchidos conforme segue:

Os sistemas possuem um console de Webservices, disponível no menu Recursos > Web

Tempo de atualização: Se o console estiver com a atualização de tela automática ligada,

Limpar informações de status: O console de Web Services armazena os logs de execução

Copyright© 2017 Todos os direitos reservados.

 Realizar as parametrizações necessárias dos Web Services.

Copyright© 2017 Todos os direitos reservados.

EDITOR DE WEB SERVICES

O Editor de Web Services é um recurso que permite integrar diversos serviços em

Copyright© 2017 Todos os direitos reservados.

A barra de ferramentas da tela permite acesso rápido às opções disponíveis no menu da

Copyright© 2017 Todos os direitos reservados.

Selecionando um item nesta árvore e clicando com o botão direito do mouse,

Copyright© 2017 Todos os direitos reservados.