Trabalhando com Fluxos HTTP

Leia estas informações se você estiver utilizando fluxos de mensagens HTTP para interagir com serviços da Web. Você poderá achar útil ler isto em conjunto com a seção subseqüente Cenários de Serviços da Web.

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 indica sucesso. Se você quiser que um código de status diferente seja retornado, tome uma das seguintes ações:
  • Defina seu código de status no campo Destination.HTTP.ReplyStatusCode na árvore LocalEnvironment (nome de correlação OutputLocalEnvironment). Esse campo substitui todo código de status definido em um cabeçalho HTTPResponseHeader. Essa ação é a opção preferencial, pois fornece maior flexibilidade.
  • Defina seu código de status no campo X-Original-HTTP-Status-Code no cabeçalho HTTPReplyHeader.
  • Defina seu código de status no campo X-Original-HTTP-Status-Code no cabeçalho HTTPResponseHeader. Essa opção em geral será útil se você incluir um nó HTTPRequest antes do nó HTTPReply no fluxo, porque o cabeçalho HTTPResponseHeader é criado para você. Nesse cenário, um cabeçalho HTTPResponseHeader foi criado na árvore lógica, representando os cabeçalhos HTTP na resposta de outro serviço da Web. Se você tiver selecionado a propriedade Gerar cabeçalhos HTTP padrão de resposta (Generate default HTTP headers from reply or response) no nó HTTPReply, os valores para o cabeçalho de resposta serão definidos como valores padrão quando a mensagem de resposta for criada.
Utilizando 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 consultar esse valor e salvá-lo em outro local, se apropriado.

Por exemplo, se você projetar um par de fluxos de mensagens que interagem com um aplicativo WebSphere MQ existente (conforme descrito em O Intermediário Chama um Serviço da Web Existente), poderá salvar o valor do identificador no fluxo de pedidos e restaurá-lo no fluxo de respostas para garantir que o cliente correto receba a resposta. Se você utilizar essa técnica, não deverá alterar os dados e deverá reter os dados como um BLOB.

O nó HTTPReply extrai o valor do identificador da árvore LocalEnvironment e configura a resposta para que ela seja enviada ao cliente específico. Entretanto, se você estiver utilizando um nó HTTPReply em um fluxo que não tem um nó HTTPInput, e esse campo tiver sido excluído ou definido incorretamente, a mensagem BIP3143S será emitida.

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

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. Codifique o ESQL que armazena uma cadeia URL no LocalEnvironment.Destination.HTTP.RequestURL; o nó HTTPRequest recupera e utiliza a cadeia URL no lugar do valor de propriedade do nó.

Embora você também possa definir a URL de pedido no cabeçalho especial X-Original-HTTP-URL na seção do cabeçalho HTTPRequestHeader da mensagem de pedido (que substitui todas as demais configurações) em um nó Cálculo, utilize o conteúdo da árvore LocalEnvironment para esse propósito a fim de obter maior flexibilidade.

Configurando Gerar Cabeçalhos HTTP Padrão da Resposta para o nó HTTPReply
Se você selecionar Gerar cabeçalhos HTTP padrão da resposta nas propriedades do nó HTTPReply, o nó incluirá um conjunto mínimo de cabeçalhos na resposta enviada ao cliente de serviço da Web.
Para definir qualquer cabeçalho explicitamente, crie-o em um cabeçalho HTTPReplyHeader. Por exemplo, um nó Compute propaga uma mensagem no domínio XMLNS e modifica o Content-Type da seguinte forma:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader." Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;

Não utilize a propriedade ContentType para definir o Content-Type, 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 usados no pedido é construído selecionando os cabeçalhos com o uso do algoritmo definido nas etapas a seguir:
  1. Selecione qualquer cabeçalho em um cabeçalho HTTPReplyHeader.
  2. Se nenhum cabeçalho Content-Type estiver definido ainda, crie um utilizando qualquer valor não vazio na propriedade ContentType.
  3. Selecione qualquer cabeçalho em um cabeçalho HTTPResponseHeader (um cabeçalho HTTPResponseHeader é propagado no retorno de um nó HTTPRequest).
  4. Se nenhum cabeçalho Content-Type estiver definido ainda, 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 regrava o cabeçalho Content-Length, mesmo que você limpe Gerar cabeçalhos HTTP padrão da resposta. Essa ação assegura que o conteúdo esteja correto.

Se uma seção do cabeçalho HTTPReplyHeader existir na mensagem recebida pelo nó HTTPReply, e o terminal de saída do nó HTTPReply estiver conectado, a seção do cabeçalho 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 Gerar cabeçalhos HTTP padrão da entrada nas propriedades do nó HTTPRequest, o nó incluirá um conjunto mínimo de cabeçalhos no pedido que é enviado ao servidor.
Para definir cabeçalhos explicitamente, crie-os em um cabeçalho HTTPRequestHeader. Por exemplo, um nó Compute que propaga uma mensagem no domínio XMLNS pode modificar o Content-Type da seguinte forma:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
Não utilize a propriedade ContentType para definir o Content-Type, 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 usados no pedido é construído selecionando os cabeçalhos com o uso do algoritmo definido nas etapas a seguir:
  1. Defina o cabeçalho Host, com base na URL do pedido ou na seção do cabeçalho HTTPRequestHeader de entrada da mensagem.
  2. Selecione qualquer cabeçalho em um cabeçalho HTTPRequestHeader.
  3. Se nenhum cabeçalho Content-Type estiver definido ainda, crie um utilizando qualquer valor não vazio na propriedade ContentType.
  4. Selecione qualquer cabeçalho em um cabeçalho HTTPInputHeader (um cabeçalho HTTPInputHeader é criado automaticamente por um nó HTTPInput).
  5. Se nenhum cabeçalho Content-Type estiver definido ainda, crie um com o valor padrão text/xml; charset=utf-8
  6. Se nenhum cabeçalho SOAPAction estiver definido ainda, crie um com o valor padrão ''.
  7. Crie ou sobrescreva o cabeçalho Content-Length.
Atenção: O nó HTTPRequest sempre regrava o cabeçalho Content-Length, mesmo que você limpe Gerar cabeçalhos HTTP padrão da entrada ou pedido. Essa ação assegura que o conteúdo esteja correto.

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

Coletando Rastreio do HTTPListener se Você Tiver Problemas com HTTP
Se tiver problemas com HTTP, você pode fazer rastreio do HTTPListener:
  1. Utilize o comando mqsichangetrace para iniciar o rastreio com as seguintes opções:
    mqsichangetrace component -t -b
    em que component é o nome do intermediário.
  2. Recupere o log de rastreio do HTTPListener utilizando o comando mqsireadlog com o qualificador HTTPListener para o parâmetro -b.
  3. Formate o log de rastreio utilizando o comando mqsiformatlog para que você possa visualizar seu conteúdo.
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

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:52

ac20450_