Use o nó HTTPAsyncRequest com o nó HTTPAsyncResponse para construir um par de fluxos de mensagens que interage com um serviço da web de forma assíncrona.
O nó HTTPAsyncRequest envia um pedido de serviço da Web, mas o nó não aguardo o recebimento de uma resposta do serviço da Web associado. A resposta do serviço da web é recebida pelo nó HTTPAsyncResponse, que pode estar em um fluxo de mensagens separado, mas deve estar no mesmo grupo de execução. Os nós são usados como um par e correlacionam respostas com relação às solicitações originais usando um identificador exclusivo. O nó HTTPAsyncRequest passa o soquete de solicitação para o nó HTTPAsyncResponse do servidor de backend a ser usado para a resposta. Se a latência do servidor de backend for alta, ele poderá não responder dentro do tempo limite do soquete.
Passar o soquete de HTTP para o nó HTTPAsyncResponse permite que o fluxo de mensagens recupere a próxima mensagem da fila sem aguardar pela resposta e, portanto, usa encadeamentos e armazenamento de forma mais eficiente do que um fluxo de mensagens síncrono.
Dependendo da configuração, esse nó constrói um pedido de HTTP ou HTTPS sobre SSL (HTTPS) do conteúdo especificado da mensagem de entrada e envia esse pedido ao serviço da Web. O nó HTTPAsyncResponse recebe a resposta do serviço da web e analisa a resposta para inclusão em sua árvore de saída. O nó HTTPAsyncRequest gera cabeçalhos de HTTP se eles forem necessários pela sua configuração.
O nó HTTPAsyncRequest está contido na gaveta HTTP da paleta e é representado no WebSphere Message Broker Toolkit pelo seguinte ícone:
A URL tem o formato http://<address>[:<port>]/<function>; por exemplo, http://localhost:7080/request. Essa URL pode ser especificada estaticamente nos parâmetros do nó HTTPAsyncRequest como um campo na própria mensagem, ou dinamicamente como um campo no ambiente local.
Os dados devem estar no formato CCSID 1208 para a maioria dos pedidos. Se a solicitação for bem-sucedida, a HTTPResponse será retornada ao nó HTTPAsyncResponse com par.
É possível usar um proxy HTTP para rotear uma solicitação por meio de um site intermediário. É possível executar ferramentas como um proxy para ver a solicitação e a resposta e com isso depurar seus fluxos. O destino HTTP é como visto pelo proxy; se você especificar o destino HTTP do host local e seu proxy HTTP estiver em execução em um computador diferente, a solicitação será roteada para o computador proxy remoto, não para o computador do qual a solicitação original foi emitida.
É possível especificar um intervalo de tempo limite, para que se a operação inteira de solicitação-resposta levar mais tempo do que a duração especificada, a solicitação seja propagada para o terminal de Falha em um dos nós com par. O intervalo do tempo limite se aplica ao intervalo que inicia com a solicitação sendo enviada pelo nó HTTPAsyncRequest e termina com a resposta sendo completamente recebida pelo nó HTTPAsyncResponse.
Para cada solicitação que o nó HTTPAsyncRequest processa, ele usa uma conexão para enviar a solicitação e passa a conexão para o nó HTTPAsyncResponse com par para a resposta. Se o intervalo de tempo limite for especificado, o soquete será fechado se o intervalo expirar. Esse fechamento assegura que um pedido obtenha apenas a resposta correta, e todos os dados de resposta a um pedido que tiver o tempo limite esgotado são descartados.
O processamento da solicitação-resposta é dividido entre o nó HTTPAsyncRequest e o nó HTTPAsyncResponse. Se ocorrer um tempo limite durante a fase de processamento da solicitação, a solicitação e uma exceção serão propagadas para o terminal de Falha do nó HTTPAsyncRequest. Da mesma forma, se ocorrer um tempo limite durante a fase de processamento da resposta, uma exceção será propagada para o terminal de Falha do nó HTTPAsyncResponse.
Na maioria dos casos, o tempo limite ocorreria ao aguardar por uma resposta do servidor e, nesse caso, o terminal de Falha do nó HTTPAsyncResponse será usado. Em casos raros, pode ocorrer um tempo limite quando o nó da solicitação envia dados ao servidor. Nesse caso, o terminal de Falha do nó HTTPAsyncRequest é usado.
O nó HTTPAsyncRequest pode ser usado em qualquer fluxo de mensagens que deve enviar uma solicitação de HTTP e receber uma resposta de forma assíncrona. O exemplo mais comum é um fluxo de mensagem que chama o serviço da Web.
Para obter informações adicionais sobre como trabalhar com HTTP, consulte Processando Mensagens HTTP.
O nó interage diretamente com um serviço externo usando TCP/IP; portanto, ele pode ter erros que são gerados pelo TCP/IP. Por exemplo, sem rota para o host ou conexão recusada. Se o nó detectar esses erros, ele gerará uma exceção, preencherá a lista de exceções com as informações de erro recebidas e roteará a mensagem de entrada inalterada para o terminal de falha (Failure).
Os terminais do nó HTTPAsyncRequest são descritos na tabela a seguir.
Terminal | Descrição |
---|---|
In | O terminal de entrada que aceita a mensagem para processamento pelo nó. |
Falha | O terminal de saída para o qual a mensagem será roteada se for detectado um defeito durante o processamento no nó. |
Out | O terminal de saída para o qual a mensagem será roteada se representar a conclusão bem-sucedida do pedido de serviço da web e for requerido processamento adicional nesse fluxo de mensagens. |
As tabelas a seguir descrevem as propriedades do nó. A coluna com cabeçalho M indica se a propriedade é obrigatória (marcado com um asterisco no painel caso seja necessário digitar um valor quando nenhum padrão for definido); a coluna com cabeçalho C indica se a propriedade é configurável (você poderá alterar o valor quando incluir o fluxo de mensagens no arquivo broker para implementá-lo).
As propriedades Descrição do nó HTTPAsyncRequest são descritas na tabela a seguir.
Propriedade | M | A | O padrão | Descrição |
---|---|---|---|---|
Nome de nó | Não | Não | O tipo de nó, HTTPAsyncRequest | O nome do nó. |
Descrição curta | 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. |
As propriedades Básicas do nó HTTPAsyncRequest são descritas na tabela a seguir.
Propriedade | M | A | O padrão | Descrição | Propriedade do Comando mqsiapplybaroverride |
---|---|---|---|---|---|
Identificador exclusivo | SIM | Não | Essa propriedade é o identificador exclusivo que vincula um par de nós HTTPAsyncRequest e HTTPAsyncResponse. | asyncResponseCorrelator | |
URL de serviço da Web | SIM | SIM | A URL do serviço da Web. É necessário fornecer isso no formato http://nome do host[:porta]/[caminho], em que
O nó HTTPAsyncRequest determina a URL para o serviço da web para o qual ele envia um pedido. Defina uma das três opções a seguir; o nó as verifica na ordem mostrada (ou seja, a primeira sempre substitui a segunda, a segunda substitui a terceira):
As duas primeiras opções fornecem métodos dinâmicos de definição de uma URL para cada mensagem de entrada à medida que passam pelo fluxo de mensagens. Para utilizar uma dessas opções, inclua um nó Compute no fluxo de mensagens, antes do nó HTTPAsyncRequest, para criar e inicializar o valor exigido. A terceira opção fornece um valor fixo para cada mensagem recebida nesse nó. Defina essa propriedade para conter uma configuração padrão utilizada se os outros campos não tiverem sido criados ou contiverem um valor nulo. Se um dos campos contiver um valor, a definição dessa propriedade será ignorada. A propriedade URL do serviço da Web deve conter uma URL válida ou a implementação falhará. Assegure que o valor configurado em X-Original-HTTP-URL ou LocalEnvironment.Destination.HTTP.RequestURL também seja uma URL válida; se não for, o nó utiliza a configuração padrão da propriedade URL do Serviço da Web. |
URLSpecifier | |
Tempo limite de pedido (seg) | SIM | SIM | 120 | O valor do tempo de espera para o servidor da web remoto para enviar uma resposta ao nó HTTPAsyncResponse. O intervalo válido é de 1 a (231)-1. Não é possível inserir um valor que representa uma espera ilimitada. Para obter informações adicionais sobre o comportamento do tempo limite, consulte Tempos Limite. |
timeoutForServer |
As propriedades Configurações HTTP do nó HTTPAsyncRequest são descritas na tabela a seguir.
Propriedade | M | A | O padrão | Descrição | Propriedade do Comando mqsiapplybaroverride |
---|---|---|---|---|---|
Local de proxy HTTP(S) | Não | SIM | O servidor proxy para o qual os pedidos são enviados. Esse valor deve estar na forma hostname:port. | httpProxyLocation | |
Método HTTP | Não | Não | POST | O método HTTP. Os valores válidos são POST, GET, PUT, DELETE e HEAD. Por padrão, o nó HTTPAsyncRequest usa o método HTTP POST quando se conecta ao servidor da Web remoto. HEAD é usado para determinar se um serviço está disponível - por exemplo, por um Dispatcher de Rede tentando descobrir quais servidores estão disponíveis - e irá enviar de volta os cabeçalhos corretos (incluindo conteúdo-comprimento) mas sem dados de corpo. | |
Use compactação | Não | SIM | Nenhum | Esta propriedade controla se o conteúdo do pedido HTTP é compactado. É possível escolher um valor de nenhum, gzip, zlib (deflate) e deflate. Se o pedido for compactado, o cabeçalho de Codificação de Conteúdo será configurado para indicar que o conteúdo está compactado. zlib (deflate) representa RFC 1950 + RFC 1951 combinados. deflate representa RFC 1951 somente. O valor padrão é none, isto é, o conteúdo da solicitação não é compactado. |
requestCompressionType |
As propriedades SSL do nó HTTPAsyncRequest são descritas na tabela a seguir.
Propriedade | M | A | O padrão | Descrição | Propriedade do Comando mqsiapplybaroverride |
---|---|---|---|---|---|
Protocolo | Não | SIM | TLS | Especifique a propriedade Protocolo SSL
a ser usado ao fazer uma solicitação de HTTPS. Ambas as extremidades de uma conexão SSL
devem concordar com o protocolo a utilizar. Portanto, o protocolo selecionado
deve ser um que seja aceito pelo servidor remoto. As opções
a seguir estão disponíveis:
|
protocol |
Cifras SSL permitidas | Não | SIM | Uma lista de cifras separadas por vírgulas a ser utilizada ao fazer um pedido SSL. Utilize esta configuração para especificar um único código (como SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) ou uma lista de códigos que são os únicos utilizados pela conexão. Esse conjunto de cifras deve incluir uma ou mais copiadas pelo servidor remoto. Uma vírgula é utilizada como um separador entre as cifras. O valor padrão é uma cadeia vazia, que permite ao nó utilizar qualquer uma ou todas as cifras disponíveis durante o protocolo de reconhecimento de conexão SSL. Esse método permite maior escopo para estabelecer uma conexão SSL bem-sucedida. |
allowedCiphers | |
Ativar verificação de nome do host do certificado SSL | Não | SIM | Sim | Essa propriedade especifica se o nome do host do servidor que está recebendo a solicitação deve corresponder ao nome do host no certificado SSL. | hostnameChecking |
Alias de chave de autenticação de cliente SSL | Não | SIM | "" (sequência vazia) | Esta propriedade especifica um alias de autenticação SSL para o lado do cliente de uma conexão HTTPAsyncRequest. Tomar o valor padrão significa que a primeira chave apropriada é escolhida para você automaticamente. | keyAlias |
As propriedades Avançadas do nó HTTPAsyncRequest são descritas na tabela a seguir.
Propriedade | M | A | O padrão | Descrição | Propriedade do Comando mqsiapplybaroverride | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Gerar Cabeçalhos HTTP Padrão na Entrada | Não | Não | Selecionados | Se você selecionar essa caixa de opções, um HTTPRequestHeader será
gerado. Se você limpar esta caixa de opções,
um HTTPRequestHeader válido deverá existir na mensagem de entrada. Para controlar o conteúdo de HTTPRequestHeader incluso na mensagem de pedido, inclua um nó Compute que tem um HTTPRequestHeader na mensagem de entrada antes desse nó HTTPAsyncRequest no fluxo de mensagens e desmarque a caixa de opção.
Se você selecionou Usar Compactação ou Aceitar Respostas Compactadas por Padrão,
os campos de cabeçalho HTTP Content-Encoding e Accept-Encoding serão preenchidos
independentemente de você ter selecionado Gerar
Cabeçalhos HTTP Padrão na Entrada:
|
|||||||||
Aceitar respostas compactadas por padrão | Não | SIM | Desmarcada | Essa propriedade indica se o nó HTTPAsyncResponse manipula respostas compactadas por padrão. Se o cabeçalho da solicitação não contiver um cabeçalho Accept-Encoding e essa opção estiver selecionada, o nó configurará o cabeçalho
Accept-Encoding como "gzip, deflate" e qualquer resposta compactada que seja recebida será
descompactada pelo nó de resposta. Se a mensagem propagada para o nó HTTPAsyncResponse incluir um cabeçalho Accept-Encoding, o fluxo de mensagens ou o aplicativo cliente deverá manipular qualquer resposta compactada. Portanto, selecionar essa opção não afetará nesse caso. |
acceptCompressedResponses |
Propriedade | M | P | Default | Descrição |
---|---|---|---|---|
Eventos | Não | Não | Nenhum | Eventos definidos para o nó são exibidos nesta guia. Por padrão, nenhum evento de monitoramento é definido em um nó do fluxo de mensagens. Utilize Incluir, Editar,
e Excluir para criar, alterar ou excluir eventos de monitoração no nó; consulte Configurando fontes de eventos de monitoramento utilizando propriedades de monitoramento para detalhes. É possível ativar e desativar eventos mostrados aqui selecionando ou desmarcando a caixa de opções Ativado. |
Configuração | Descrição |
---|---|
Compactação | Substitui a propriedade Usar
compactação no nó. Por exemplo:
Para configurar um tamanho mínimo (em bytes)
no qual a compactação é aplicada, use a seguinte substituição:
|
ProxyConnectHeaders | Especifica
cabeçalhos adicionais que serão utilizados caso o pedido de saída seja uma conexão SSL
através de um proxy. Estes cabeçalhos adicionais são enviados juntamente com
o pedido inicial CONNECT ao proxy. Por exemplo, você poderá enviar
informações sobre autenticação de proxy para um servidor proxy quando estiver utilizando o
SSL. Múltiplos cabeçalhos podem ser enviados mas cada um deve ser separado
por um retorno de carro e um avanço de linha (ASCII 0x0D 0x0A) de acordo com o
RFC2616; por exemplo:
Esta configuração é utilizada apenas se for um pedido SSL
através de um servidor proxy. Para enviar informações sobre autenticação de proxy para um
pedido não-SSL, especifique os cabeçalhos individuais na pasta HTTPRequestHeader,
conforme mostrado nos exemplos a seguir:
|
ProxyURL | Substitui a propriedade Local do
proxy HTTP(S) no nó. Por exemplo:
|
QueryString | Permite a configuração dos parâmetros de cadeia de consulta
de saída. Cada parâmetro deve ser definido individualmente. Por exemplo:
O
ESQL acima resulta na seguinte cadeia de consultas sendo codificada (de acordo
com http://tools.ietf.org/html/rfc3986) e enviada
com o pedido de saída:
Se
a URL de destino já tiver um ou mais parâmetros de consulta, parâmetros
adicionais especificados aqui serão anexados à lista existente. |
QueryStringCCSID | Especifica que, antes da codificação, os parâmetros de sequência
da consulta devem ser convertidos em um conjunto de caracteres diferente do padrão,
que é UTF-8. Qualquer parâmetro de sequência de consulta é convertido primeiro
no CCSID especificado antes da sequência resultante ser codificada, de acordo
com a RFC3986.
Por exemplo:
O
ESQL acima resulta em qualquer parâmetro QueryString sendo convertido na
página de códigos 943 antes de ser codificado. Nota: Qualquer parâmetro de sequência de
consulta deve conter os dados em unicode. |
RequestLine.RequestURI | Substitui a RequestURI, que é o caminho
após a URL e a porta. Por exemplo:
|
RequestLine.HTTPVersion | Substitui a propriedade Versão de
HTTP no nó. Por exemplo:
|
RequestLine.Method | Substitui a propriedade método
HTTP no nó. Por exemplo:
|
RequestURL | Substitui a propriedade URL do
serviço da Web no nó. Por exemplo:
|
SSLProtocol | Substitui o SSLProtocol.
Por exemplo:
Os valores válidos são: SSL, SSLv3 e TLS. |
SSLCiphers | Substitui a propriedade Cifras
SSL Permitidas no nó. Por exemplo:
|
UserContext | É possível armazenar dados de contexto BLOB no seguinte local no ambiente local. O nó HTTPAsyncResponse pode ser recuperado posteriormente nesses dados.
Os dados armazenados no UserContext devem estar no formato BLOB. |
WrittenDestination = (
HTTP = (
RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
Compactação = (
OriginalSize = 53 (INTEGER)
CompressedSize = 71 (INTEGER)
)
)
)