Trabalhando com Fluxos HTTP

Este tópico fornece informações que podem ser úteis se você estiver utilizando os fluxos de mensagens HTTP para interagir com os serviços da Web. Talvez seja útil ler esta seção junto com a seção Cenários de Serviços da Web subseqüente.

HTTPS
Para obter ajuda sobre como utilizar HTTPS, consulte Implementando a Autenticação SSL.
Definindo o Código de Status de HTTP para uma Resposta
O Código de Status HTTP padrão é 200, que significa sucesso. Se você deseja que um código de status diferente seja retornado:
  • Configure seu código de status no campo Destination.HTTP.ReplyStatusCode no LocalEnvironment (nome de correlação OutputLocalEnvironment). Isso substitui qualquer código de status configurado em um HTTPResponseHeader conforme descrito abaixo.
  • Se um nó HTTPRequest preceder o nó HTTPReply em seu fluxo, um HTTPResponseHeader terá sido criado na árvore lógica, representando os cabeçalhos HTTP na resposta a partir de outro serviço da Web. Por conveniência, se a propriedade de nó HTTPReply Gerar Cabeçalhos HTTP Padrão a partir da Resposta estiver selecionada, os valores para esse cabeçalho serão utilizados como padrões na criação da mensagem de resposta, permitindo que você configure seu código de status no campo X-Original-HTTP-Status-Code no HTTPResponseHeader. Você também pode configurar esse campo em um HTTPReplyHeader, mas recomenda-se que utilize o LocalEnvironment em vez da maneira como está descrito acima.
Utilizando o LocalEnvironment.Destination.HTTP.RequestIdentifier
Quando o nó HTTPInput recebe uma mensagem de pedido de entrada, ele define o campo LocalEnvironment, Destination.HTTP.RequestIdentifier, com um valor exclusivo que identifica o cliente de serviços da Web que enviou o pedido. É possível se referir a esse valor e salvá-lo em outro local, se apropriado.

Por exemplo, se você projetar um par de fluxos de mensagens que interagem em um aplicativo WebSphere MQ existente (conforme descrito em O Intermediário Chama um Serviço da Web Existente), poderá salvar esse valor no fluxo de pedidos e restaurá-lo no fluxo de resposta para garantir que o cliente correto receba a resposta. Se você fizer isso, será necessário alterar os dados e mantê-los como um BLOB.

O nó HTTPReply extrai esse valor do Ambiente Local e configura a resposta para que ela seja enviada ao cliente específico.

Se você projetar um fluxo de mensagens que inclui um nó HTTPInput e um nó HTTPReply, o valor será definido no Ambiente Local pelo nó HTTPInput, mas o nó HTTPReply não o utilizará. Portanto, se o fluxo de mensagens inclui ambos os nós e um nó Compute no mesmo fluxo, você não terá que incluir a árvore Ambiente Local ao especificar os componentes da árvore de mensagem que serão copiados da mensagem de entrada para a mensagem de saída pelo nó Compute (a propriedade Modo Calcular).

Definindo o URL do Nó HTTPRequest Dinamicamente
Você pode configurar a propriedade URL do Serviço da Web Padrão no nó HTTPRequest para determinar a URL de destino para um pedido de serviço da Web. Você pode configurar um nó Compute antes que o nó HTTPRequest no fluxo de mensagens substitua o valor definido na propriedade. O ESQL de codificação que armazena uma cadeia de URL em LocalEnvironment.Destination.HTTP.RequestURL; ele é recuperado pelo nó HTTPRequest e utilizado no lugar do valor de propriedade do nó.

Embora seja possível definir a URL do pedido no cabeçalho especial X-Original-HTTP-URL na seção HTTPRequestHeader da mensagem de pedido (que substitui todas as outras definições) em um nó Compute, recomendamos que você utilize o conteúdo Ambiente Local para esse propósito.

Configurando Gerar Cabeçalhos HTTP Padrão da Resposta para o nó HTTPReply
Se você selecionar a caixa de opções Gerar Cabeçalhos HTTP Padrão da Resposta no diálogo de propriedades do nó HTTPReply, o nó incluirá um conjunto mínimo de cabeçalhos na resposta que é enviada ao cliente do serviço da Web.
Se você quiser configurar quaisquer cabeçalhos explicitamente, crie-os em um HTTPReplyHeader. Por exemplo, um nó Compute propagando uma mensagem no domínio XMLNS e desejando modificar o Content-Type poderia fazer isso da seguinte forma:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader." Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;

No caso específico de Content-Type, não configure esse cabeçalho utilizando a propriedade ContentType, a menos que você esteja trabalhando no domínio MIME. A propriedade ContentType é direcionada especificamente para a configuração do valor de Content-Type utilizado em MIME.

O conjunto completo de cabeçalhos HTTP utilizados no pedido é construído através da seleção de cabeçalhos utilizando o seguinte algoritmo:
  1. Selecione quaisquer cabeçalhos em um HTTPReplyHeader.
  2. Se nenhum cabeçalho Content-Type estiver definido até o momento, crie um utilizando qualquer valor não vazio na propriedade ContentType.
  3. Selecione quaisquer cabeçalhos em um HTTPResponseHeader (um HTTPResponsHeader é propagado em retorno de um nó HTTPRequest).
  4. Se nenhum cabeçalho Content-Type estiver definido até o momento, crie um com o valor padrão text/xml; charset=utf-8
  5. Crie ou sobrescreva o cabeçalho Content-Length.
Atenção: O nó HTTPReply sempre sobrescreve o cabeçalho Content-Length, mesmo se você limpar a caixa de opções Gerar Cabeçalhos HTTP Padrão da Resposta. Isso é para assegurar que o conteúdo está correto.

Se houver uma seção HTTPReplyHeader na mensagem recebida pelo nó HTTPReply e se o terminal Saída do nó HTTPReply estiver conectado, a seção HTTPReplyHeader será atualizada com qualquer valor alterado ou incluído.

Definindo Gerar Cabeçalhos HTTP Padrão da Entrada ou Resposta para o nó HTTPRequest
Se você selecionar a caixa de opções Gerar Cabeçalhos HTTP Padrão da Entrada ou Resposta do diálogo de propriedades do nó HTTPRequest, o nó incluirá um conjunto mínimo de cabeçalhos na resposta que é enviada ao servidor.
Se você quiser configurar quaisquer cabeçalhos explicitamente, crie-os em um HTTPRequestHeader. Por exemplo, um nó Compute propagando uma mensagem no domínio XMLNS e desejando modificar o Content-Type poderia fazer isso da seguinte forma:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
No caso específico de Content-Type, não configure esse cabeçalho utilizando a propriedade ContentType, a menos que você esteja trabalhando no domínio MIME. A propriedade ContentType é direcionada especificamente para a configuração do valor de Content-Type utilizado em MIME.
O conjunto completo de cabeçalhos HTTP utilizados no pedido é construído através da seleção de cabeçalhos utilizando o seguinte algoritmo:
  1. Configure o cabeçalho Host, com base na URL do pedido ou na seção de entrada HTTPRequestHeader da mensagem.
  2. Selecione quaisquer cabeçalhos em um HTTPRequestHeader.
  3. Se nenhum cabeçalho Content-Type estiver definido até o momento, crie um utilizando qualquer valor não vazio na propriedade ContentType.
  4. Selecione quaisquer cabeçalhos em um HTTPInputHeader (um HTTPInputHeader é criado automaticamente por um nó HTTPInput).
  5. Se nenhum cabeçalho Content-Type estiver definido até o momento, crie um com o valor padrão text/xml; charset=utf-8
  6. Se nenhum cabeçalho SOAPAction estiver definido até o momento, crie um com o valor padrão ''
  7. Crie ou sobrescreva o cabeçalho Content-Length.
Atenção: O nó HTTPRequest sempre sobrescreve o cabeçalho Content-Length, mesmo se você limpar a caixa de opções Gerar Cabeçalhos HTTP Padrão da Entrada ou Pedido. Isso é para assegurar que o conteúdo está correto.

Se houver um HTTPRequestHeader na mensagem recebida, ele será atualizado com os valores alterados ou incluídos.

Início da mudançaColetando Rastreio do HTTPListener se Você Tiver Problemas com HTTPFim da mudança
Início da mudançaSe tiver problemas com HTTP, você pode fazer rastreio do HTTPListener:
  1. Inicie o rastreio utilizando o comando mqsichangetrace.
  2. Visualize o registro de rastreio do HTTPListener utilizando o comando mqsireadlog com o qualificador HTTPListener para o parâmetro -b.
Fim da mudança
Conceitos relacionados
WebSphere MQ Web Services Transport
Gerar WSDL
Tarefas relacionadas
Criação de um Fluxo de Mensagens
Implementando
Verificando os Resultados da Implementação
Referências relacionadas
Nó HTTPInput
Nó HTTPReply
Nó HTTPRequest
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac20450_