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:
- Selecione qualquer cabeçalho em um cabeçalho HTTPReplyHeader.
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um utilizando qualquer
valor não vazio na propriedade ContentType.
- Selecione qualquer cabeçalho em um cabeçalho HTTPResponseHeader (um cabeçalho
HTTPResponseHeader é propagado no retorno de um nó HTTPRequest).
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um com o valor padrão
text/xml; charset=utf-8.
- 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:
- Defina o cabeçalho Host, com base na URL do pedido ou na seção do cabeçalho
HTTPRequestHeader de entrada da mensagem.
- Selecione qualquer cabeçalho em um cabeçalho HTTPRequestHeader.
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um utilizando qualquer
valor não vazio na propriedade ContentType.
- Selecione qualquer cabeçalho em um cabeçalho HTTPInputHeader (um cabeçalho
HTTPInputHeader é criado automaticamente por um nó HTTPInput).
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um com o valor
padrão text/xml; charset=utf-8
- Se nenhum cabeçalho SOAPAction estiver definido ainda, crie um com o valor padrão
''.
- 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:
- 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.
- Recupere o log de rastreio do HTTPListener utilizando o comando
mqsireadlog com o qualificador HTTPListener para o
parâmetro -b.
- Formate o log de rastreio utilizando o comando
mqsiformatlog para que você possa visualizar seu
conteúdo.