TESTANDO WEB SERVICES

Transcrição

1 TESTANDO WEB SERVICES 1 CONCEITOS 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 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 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 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

2 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: 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:

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 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).

4 É 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 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.

5 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 [email protected] 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.

6 Chamada do WebService: <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 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> 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.

7 3 - CHAMADA DE UM WEBSERVICE PADRÃO OU PERSONALIZADO 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 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.

8 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 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 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.

9 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) 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.

10 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 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 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.

11 Estrutura da regra LSP Definir Alfa acodemp; Definir Alfa aretobs; Definir Alfa asitped; Definir Alfa Declaração da variável identificando o Definir interno.com.senior.g5.co.int.padrao.documentos.pedido Cria nova linha para o cabeçalho do SrvPedido.Pedido.CriarLinha(); SrvPedido.Pedido.OpeExe = "I"; SrvPedido.Pedido.CodEmp = 1; SrvPedido.Pedido.CodFil = 1; SrvPedido.Pedido.CodCli = 1; SrvPedido.Pedido.VlrOut = "10,50"; SrvPedido.Pedido.DatPrv = Cria nova linha para Campo de Usuario do SrvPedido.Pedido.Usuario.CriarLinha(); SrvPedido.Pedido.Usuario.CmpUsu = "Usu_CodTeste"; SrvPedido.Pedido.Usuario.VlrUsu = Cria nova linha para cada SrvPedido.Pedido.Produto.CriarLinha(); SrvPedido.Pedido.Produto.OpeExe = "I"; SrvPedido.Pedido.Produto.CodPro = "1101"; SrvPedido.Pedido.Produto.CodDer = " "; SrvPedido.Pedido.Produto.QtdPed = "1000"; SrvPedido.Pedido.Produto.CodTpr = " "; SrvPedido.Pedido.Produto.PreUni = "10,65"; Declaração do Web Service para ser utilizado na regra Criação da linha da tabela do parâmetro Pedido Criação da linha da tabela do parâmetro Pedido.Usuario Criação da linha da tabela do parâmetro Cria nova linha para Campo de Usuario do SrvPedido.Pedido.Produto.Usuario.CriarLinha(); SrvPedido.Pedido.Produto.Usuario.CmpUsu = "Usu_NCodTeste"; SrvPedido.Pedido.Produto.Usuario.VlrUsu = Define o modo de execução SrvPedido.ModoExecucao = Executa o web SrvPedido.Executar(); fim; Executa o Web Service Criação da linha da tabela do parâmetro Pedido.Produto.Usuario Define o Modo de Execução 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 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

12 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 a quantidade de linhas de retorno dos pedidos@ iqtdlinhasretornopedidos = SrvPedido.RespostaPedido.QtdLinhas; iqtdped = 0; enquanto (iqtdped < iqtdlinhasretornopedidos) no primeiro registro da tabela de retorno@ SrvPedido.RespostaPedido.LinhaAtual = os dados do retorno da inserção do pedido na linha atual@ acodemp = SrvPedido.RespostaPedido.CodEmp; icodfil = SrvPedido.RespostaPedido.CodFil; inumped = SrvPedido.RespostaPedido.NumPed; asitped = SrvPedido.RespostaPedido.SitPed; aretobs = SrvPedido.RespostaPedido.Retorno; Retorno da tabela a quantidade de linhas de retorno do produto do pedido da linha atual@ iqtdlinhasretornoprodutos = SrvPedido.RespostaPedido.GridPro.QtdLinhas; iqtdpro = 0; enquanto (iqtdpro < iqtdlinhasretornoprodutos) inicio SrvPedido.RespostaPedido.GridPro.LinhaAtual = iqtdpro; aseqipd = SrvPedido.RespostaPedido.GridPro.SeqIpd; aretobs = SrvPedido.RespostaPedido.GridPro.Retorno; iqtdpro = iqtdpro + 1; fim; Retorno da tabela de Produtos do Pedido 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.

13 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 Montagem do servivo para inclusão do título SrvGerCtaRec.CodEmp = Codigo da SrvGerCtaRec.CodFil = Codigo da SrvGerCtaRec.EntradaTitulos.CriarLinha(); SrvGerCtaRec.EntradaTitulos.CodFil = Codigo da SrvGerCtaRec.EntradaTitulos.NumTit = Número do título a SrvGerCtaRec.EntradaTitulos.CodTpt = Código do tipo de título a SrvGerCtaRec.EntradaTitulos.CodTns = Código da transação que gerou o título a SrvGerCtaRec.EntradaTitulos.DatEmi = Data de emissão do título a SrvGerCtaRec.EntradaTitulos.DatEnt = Data de entrada do título a SrvGerCtaRec.EntradaTitulos.CodCli = Código do cliente do título a SrvGerCtaRec.EntradaTitulos.CodRep = Código do representante do título a SrvGerCtaRec.EntradaTitulos.VctOri = Data do SrvGerCtaRec.EntradaTitulos.VctPro = Data do vencimento SrvGerCtaRec.EntradaTitulos.VlrOri = Valor original do título a SrvGerCtaRec.EntradaTitulos.CodFpg = Código da forma de SrvGerCtaRec.EntradaTitulos.DatPpt = Data do provável SrvGerCtaRec.EntradaTitulos.CodPor = Código do portador do SrvGerCtaRec.EntradaTitulos.CodCrt = Código da carteira do título a SrvGerCtaRec.EntradaTitulos.CodMoe = Código da SrvGerCtaRec.EntradaTitulos.CriarLinha(); SrvGerCtaRec.EntradaTitulos.CodFil = Codigo da SrvGerCtaRec.EntradaTitulos.NumTit = Número do título a SrvGerCtaRec.EntradaTitulos.CodTpt = Código do tipo de título a SrvGerCtaRec.EntradaTitulos.CodTns = Código da transação que gerou o título a SrvGerCtaRec.EntradaTitulos.DatEmi = Data de emissão do título a SrvGerCtaRec.EntradaTitulos.DatEnt = Data de entrada do título a SrvGerCtaRec.EntradaTitulos.CodCli = Código do cliente do título a SrvGerCtaRec.EntradaTitulos.CodRep = Código do representante do título a SrvGerCtaRec.EntradaTitulos.VctOri = Data do SrvGerCtaRec.EntradaTitulos.VctPro = Data do vencimento SrvGerCtaRec.EntradaTitulos.VlrOri = Valor original do título a SrvGerCtaRec.EntradaTitulos.CodFpg = Código da forma de SrvGerCtaRec.EntradaTitulos.DatPpt = Data do provável SrvGerCtaRec.EntradaTitulos.CodPor = Código do portador do SrvGerCtaRec.EntradaTitulos.CodCrt = Código da carteira do título a SrvGerCtaRec.EntradaTitulos.CodMoe = Código da 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; }

14 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 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 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 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: 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;

15 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.

16 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=" <S:Body> <ns2:gravarclientesresponse xmlns:ns2=" <result> <erroexecucao xsi:nil="true" xmlns:xsi=" <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>

17 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 Particularidades desta forma de execução 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> 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.

18 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 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 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 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 Identificando a URL do provedor e o contexto Acessar a WSDL do Web Service: A URL do provedor é o trecho do endereço até a primeira barra / : 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 Localizando o Identificador Universal O Identificador Universal é o namespace informado na WSDL do Web Service targetnamespace=" Identificando a Ação do Web Service: A ação do Web Service é publicada na TAG "soapaction" da Porta do Web Service soapaction="

19 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=" <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

20 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.