Este tópico contém as seguintes seções:
Utilize o nó HTTPInput para receber pedidos de serviços da Web para processamento por um fluxo de mensagens. Utilizando o nó HTTPInput com os nós HTTPReply e HTTPRequest, o intermediário pode agir como um intermediário para serviços da Web e os pedidos de serviços da Web podem ser transformados e roteados da mesma forma que outros formatos de mensagens suportados pelo .
Se você incluir um nó HTTPInput em um fluxo de mensagens, também deverá incluir um nó HTTPReply no mesmo fluxo ou transmitir a mensagem para outro fluxo que inclua um nó HTTPReply (por exemplo, por meio de um nó MQOutput para um segundo fluxo que se inicie com um nó MQInput). No último caso, o pedido do cliente e a resposta para o cliente são coordenados pelo identificador de pedidos armazenado no Ambiente Local (descrito a seguir).
O nó HTTPInput identifica mensagens nos seguintes domínios de mensagens:
Quando o nó HTTPInput recebe uma mensagem de um cliente de serviço da Web, ele chama os analisadores apropriados para interpretar os cabeçalhos e o corpo da mensagem e para criar a árvore de mensagens que é utilizada internamente pelo fluxo de mensagens. O nó cria um identificador único para a mensagem de entrada e o armazena como uma matriz binária de 24 bytes na árvore Ambiente Local no LocalEnvironment.Destination.HTTP.RequestIdentifer. Esse valor é utilizado pelo nó HTTPReply e não deve ser modificado de forma alguma.
As mensagens HTTP são sempre não persistentes e não possuem ordem associada.
As mensagens HTTP são não transacionais. No entanto, se o fluxo de mensagens interagir com um banco de dados ou outro recurso externo, tal como, uma fila do , estas interações serão executadas de forma transacional.O nó HTTPInput fornece consolidação ou reversão, dependendo de como o fluxo de mensagens foi finalizado e como ele está configurado para tratamento de erros (como os terminais failure são conectados, por exemplo). Se o fluxo de mensagens for revertido por este nó, uma mensagem de Falha do SOAP será gerada e retornada ao cliente de serviços da Web.
Se ocorrer uma exceção downstream neste fluxo de mensagens e não for capturada, mas retornada a este nó, o nó construirá uma resposta de erro para o cliente da chamada. Essa resposta é uma mensagem de Falha do SOAP derivada da própria exceção.
Se você incluir um nó de saída em um fluxo de mensagens que começa com um nó HTTPInput, ele poderá ser qualquer um dos nós de saída suportados (incluindo os nós de saída definidos pelo usuário). Você pode criar um fluxo de mensagens que receba mensagens de clientes de serviços da Web e gere mensagens para clientes que utilizam todos os transportes suportados para conexão com o intermediário, porque é possível configurar o fluxo de mensagens para solicitar que o intermediário forneça qualquer conversão necessária.
Se você criar um fluxo de mensagens para usar como um subfluxo, não será possível utilizar um nó de entrada padrão; será necessário utilizar uma instância do nó Input como o primeiro nó para criar um terminal de entrada para o subfluxo.
Se seu fluxo de mensagens não receber pedidos de serviços da Web, você poderá escolher um destes nós de entrada:
O nó HTTPInput é representado no pelo seguinte ícone:
Você pode utilizar este nó em dois cenários diferentes:
O cliente de serviços da Web gera um pedido de serviço da Web. Ele é direcionado para o nó HTTPInput de um fluxo de mensagens em execução no intermediário. Você projeta o fluxo de mensagens para processar a mensagem de alguma forma e para gerar uma resposta que esteja no formato de uma resposta de serviço da Web. O intermediário envia a resposta ao cliente de serviços da Web, através do nó HTTPReply do fluxo de mensagens.
Por exemplo, você possui clientes de serviços da Web que interagem com um serviço da Web que fornece informações específicas sobre um determinado assunto (preços de ações ou taxas de câmbio, por exemplo). Você substitui esse serviço por uma solução de consulta de banco de dados interna, mas não deseja fazer mudanças aos aplicativos de seus clientes. Você projeta um fluxo de mensagens incluindo um nó HTTPInput que recebe pedidos de seus clientes. Esse nó conecta-se a um nó Compute que recupera as informações requeridas do banco de dados e gera uma nova mensagem de saída, no formato de uma resposta do serviço da Web incluindo esses novos dados. O nó Compute transmite a mensagem para o nó HTTPReply, que gera a resposta para o cliente de serviços da Web.
O cliente de serviços da Web gera um pedido de serviço da Web. Ele é direcionado para o nó HTTPInput de um fluxo de mensagens em execução no intermediário. Você projeta o fluxo de mensagens para processar a mensagem de alguma forma e para interagir com o serviço da Web com o qual o aplicativo de cliente acredita estar conectado. Você inclui um nó HTTPRequest no fluxo de mensagens para enviar um pedido para o serviço da Web e para receber a resposta. O fluxo de mensagens também gera uma resposta para o cliente, com base em toda ou em parte da resposta recebida no nó HTTPRequest, no formato de uma resposta do serviço da Web. O intermediário envia a resposta ao cliente de serviços da Web, através do nó HTTPReply do fluxo de mensagens.
Por exemplo, você possui um aplicativo cliente que interage com um serviço da Web que envia informações para outro aplicativo que requer informações em outro formato. Você projeta um novo fluxo de mensagens que inclui um nó HTTPInput, um nó HTTPRequest e um nó HTTPReply. O nó HTTPInput recebe a entrada do cliente de serviços da Web e transmite a mensagem para o nó HTTPRequest, que interage com o serviço da Web.
Quando a resposta é recebida, o nó HTTPRequest propaga a mensagem para um nó Calcular, que cria uma mensagem de saída em formato legado a partir do conteúdo da resposta do serviço da Web. O fluxo de mensagens é finalizado com um nó MQOutput, que entrega a mensagem transformada para o aplicativo legado, seguido por um nó HTTPReply que fornece a resposta apropriada para o cliente de serviço da Web.
Em um segundo exemplo, seus clientes interagem com um serviço da Web e você deseja manter informações sobre os pedidos para o serviço da Web para finalidades de auditoria. Você projeta um fluxo de mensagens que inclui um nó HTTPInput conectado a um nó Warehouse. A mensagem de entrada recebida do cliente de serviços da Web é armazenada no banco de dados, e o nó Warehouse transmite a mensagem para um nó HTTPRequest, que interage com o serviço da Web. Quando a resposta for recebida, o nó HTTPRequest propagará a resposta no nó HTTPReply, que irá gerar a resposta para o cliente de serviço da Web.
Quando tiver colocado uma instância do nó HTTPInput em um fluxo de mensagens, será possível configurá-lo. Clique com o botão direito na visualização do editor clique em Propriedades. As propriedades básicas do nó serão exibidas no diálogo de propriedades.
Todas as propriedades mandatórias, para as quais é necessário inserir um valor (aquelas que não possuem um valor padrão definido) são marcadas com um asterisco no diálogo das propriedades.
Configure o nó HTTPInput da seguinte forma:
Deixe o campo Conjunto de Mensagens vazio para os analisadores XML, XMLNS, JMS e BLOB.
Deixe o campo Tipo de Mensagem vazio para os analisadores XML, XMLNS, JMS e BLOB.
Deixe o campo Formato de Mensagem vazio para os analisadores XML, XMLNS, JMS e BLOB.
Os destinos de defeitos se comportam como os da saída do nó Trace. Portanto se, por exemplo, Rastreio do Usuário estiver selecionado, as entradas de rastreio serão gravadas, independentemente da definição do sinalizador de rastreio do usuário para o fluxo de mensagens.
Clique em Cancelar para fechar o diálogo e descartar todas as alterações feitas nas propriedades.
O HTTPInput encaminha cada mensagem recebida com êxito para o terminal de saída. Se a validação da mensagem falhar, a mensagem será roteada para o terminal failure; você poderá conectar nós nesse terminal para identificar essa condição. Se você não conectou o terminal failure, a mensagem será descartada, o Tempo de Espera Máximo do Cliente expirará e o listener TCP/IP retornará um erro ao cliente. Não há outras situações em que a mensagem será roteada para o terminal failure.
Se a mensagem for capturada por este nó após o lançamento de uma exceção no fluxo de mensagens, a mensagem será roteada para o terminal da captura. Se você não conectou o terminal catch, a mensagem será descartada, o Tempo de Espera Máximo do Cliente expirará e o listener TCP/IP retornará um erro ao cliente.
Os terminais do nó HTTPInput são descritos na tabela a seguir.
Terminal | Descrição |
---|---|
Defeito | O terminal de saída para o qual a mensagem é encaminhada se um ocorrer erro. |
Saída | O terminal de saída para o qual a mensagem será roteada se for recuperada com êxito. |
Capturar | O terminal de saída para o qual a mensagem será roteada se for emitida uma exceção downstream e capturada por este nó. |
As tabelas a seguir descrevem as propriedades do nó; a coluna com cabeçalho M indica se a propriedade é mandatória (marcado com um asterisco no diálogo de propriedades caso seja necessário digitar um valor quando nenhum padrão for definido), a coluna com cabeçalho C indica se a propriedades é configurável (você poderá alterar o valor quando incluir o fluxo de mensagens no arquivo bar para implementá-lo).
As propriedades Básicas do nó HTTPInput são descritas na tabela a seguir.
Propriedade | M | C | Padrão | Descrição |
---|---|---|---|---|
Seletor URL | Sim | Sim | O local a partir do qual os pedidos de serviços
da Web são recuperados. Você deve fornecê-lo em um dos seguintes
formatos: http://<nome_do_host>[:<porta>]/[<caminho>]ou /<fragmento de caminho>/*em que * é um caractere curinga que pode ser utilizado para significar qualquer correspondência. |
|
Tempo de Espera Máximo do Cliente | Sim | Não | 180 | O tempo no qual o listener aguarda, em segundos, antes de retornar uma mensagem de erro ao cliente. O intervalo válido é de zero (que significa uma espera indefinida) a (231)-1. |
As propriedades Padrão do nó HTTPInput são descritas na tabela a seguir.
Propriedade | M | C | Padrão | Descrição |
---|---|---|---|---|
Domínio de Mensagens | Não | Não | O domínio da mensagem de entrada. | |
Conjunto de Mensagens | Não | Não | O conjunto de mensagens da mensagem de entrada. | |
Tipo de Mensagem | Não | Não | O tipo de mensagem de entrada. | |
Formato de Mensagem | Não | Não | O formato da mensagem de entrada. |
As propriedades Validação do nó HTTPInput estão descritas na tabela a seguir.
Propriedade | M | C | Padrão | Descrição |
---|---|---|---|---|
Validar | Sim | Não | Nenhum | Determina se a validação ocorrerá. Os valores válidos são Nenhum e Conteúdo e Valor. |
Ação de Defeito | Sim | Não | Rastreio do Usuário | O que acontece se a validação falha. Você pode definir esta propriedade somente se você tiver definido Validar para Conteúdo e Valor. Os valores válidos são Rastreio do Usuário, Log de Erros Local, e Exceção. |
Sincronização | Sim | Não | Adiado | Quando uma validação ocorre. Você pode definir esta propriedade somente se você tiver definido Validar para Conteúdo e Valor. Os valores válidos são Adiado, Imediato e Concluído. |
Incluir Todas as Restrições de Valores | Sim | Não | Selecionada | Não é possível alterar esta propriedade. |
Corrigir | Sim | Não | Nenhum | Não é possível alterar esta propriedade. |
As propriedades de Descrição do nó HTTPInput são descritas na tabela a seguir.
Propriedade | M | C | Padrão | Descrição |
---|---|---|---|---|
Descrição Breve | Não | Não | Uma breve descrição do nó. | |
Descrição Longa | Não | Não | Texto que descreve a finalidade do nó no fluxo de mensagens. |
Conceitos relacionados
Fluxos de Mensagem
Extensões Definidas pelo Usuário
Tarefas relacionadas
Decidindo Quais Nós Utilizar
Utilizando Mais de Um Nó Input
Tratando Erros em Fluxos de Mensagens
Editando Propriedades Configuráveis
Referências relacionadas
Nó Compute
Nó HTTPReply
Nó HTTPRequest
Nó Input
Nó MQeInput
Nó MQInput
Nó MQOutput
Nó Real-timeInput
Nó SCADAInput
Avisos |
Marcas |
Downloads |
Biblioteca |
Suporte |
Feedback
![]() ![]() |
ac04565_ |