Leia estas informações, se estiver usando fluxos de mensagens HTTP para interagir com aplicativos HTTP, incluindo serviços da Web e serviços RESTful.
Talvez você ache útil ler
estas informações com a seção Cenários de Serviços da Web.
É necessário decidir qual listener
os nós HTTP usarão:
- O listener do broker (o componente httplistener) possui um HTTPConnector
para manipular mensagens HTTP e um HTTPSConnector para manipular mensagens
HTTPS (HTTP sobre SSL). Cada conector possui sua própria porta designada.
Por
padrão, todos os nós HTTPInput e HTTPReply usam o listener do broker inteiro,
que faz interface com os nós HTTP usando uma fila do WebSphere MQ.
- Um listener integrado faz parte de cada grupo de execução. O listener
integrado possui um HTTPConnector e um HTTPSConnector e cada conector
possui sua própria porta designada.
É possível configurar um ou mais grupos de execução
para que todos os HTTPInput e HTTPReply implementados nesse grupo de execução usem o listener integrado.
Para ver uma discussão das vantagens de cada listener, consulte
Listeners HTTP.
É possível usar ProxyConnectHeaders apenas
com conexões HTTPS (SSL); esses cabeçalhos não funcionam com conexões
HTTP.
- Usando conexões seguras com o HTTPS
- Para obter informações sobre como configurar conexões HTTPS, consulte Implementando a Autenticação SSL.
- Usando solicitação-resposta assíncrona de HTTP
- Para fazer uma solicitação de HTTP e receber uma resposta de forma assíncrona,
use os nós HTTPAsyncRequest e HTTPAsyncResponse em seu fluxo de mensagens. O nó HTTPAsyncRequest processa a próxima mensagem sem
aguardar pela resposta, que é recebida pelo nó HTTPAsyncResponse
em um encadeamento diferente e em uma nova transação. Isso significa que várias outras solicitações podem ser processadas usando menos encadeamentos.
Para obter informações adicionais, consulte Usando Solicitação-resposta Assíncrona de HTTP.
- 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:
- Configure seu código de status no campo Destination.HTTP.ReplyStatusCode
na árvore de ambiente local (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. Esta opção é útil se você incluir
um nó HTTPRequest antes
do nó HTTPReply em seu
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 a partir da resposta no nó HTTPReply, os valores para
o cabeçalho de resposta serão configurados 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 configura o campo de ambiente local
Destination.HTTP.RequestIdentifier com um valor exclusivo que identifica
o cliente de serviço 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 Broker 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 usar
esta técnica, você não deverá alterar os dados e deverá reter
os dados como um BLOB.
O nó HTTPReply extrai o
valor do identificador da árvore de ambiente local e configura a resposta
para que ela seja enviada ao cliente específico. Entretanto, se
você estiver usando um nó HTTPReply
em um fluxo que não possui um nó HTTPInput, e este campo
tiver sido excluído ou configurado 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á configurado no ambiente local pelo nó HTTPInput, mas o nó HTTPReply não o usará. Portanto, se seu fluxo de mensagens incluir nós HTTP e um nó Compute no mesmo fluxo,
você não precisará incluir a árvore de ambiente local quando especificar
quais componentes da árvore de mensagens são copiados da mensagem de entrada
para a mensagem de saída pelo nó Compute
(a propriedade Modo de Cálculo).
- Configurando a URL da solicitação de HTTP dinamicamente
- É possível configurar a propriedade URL de Serviço da Web Padrão no nó HTTPRequest ou HTTPAsyncRequest para determinar a URL de destino para uma solicitação de serviço da web. É possível configurar um nó Compute antes do nó
HTTPRequest ou HTTPAsyncRequest dentro do fluxo de mensagens
para substituir o valor configurado na propriedade.
Codifique o ESQL
que armazena uma cadeia URL no LocalEnvironment.Destination.HTTP.RequestURL;
o nó recupera
e usa a cadeia URL no lugar do valor da propriedade do nó.
Embora
também seja possível configurar 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 outras configurações) em um nó Compute, use o
conteúdo da árvore de ambiente local para este propósito para maior flexibilidade.
- Configurando Gerar cabeçalhos HTTP padrão
a partir da resposta para o nó HTTPReply
- Se você selecionar Gerar cabeçalhos
HTTP padrão a partir da resposta nas propriedades do nó HTTPReply,
o nó incluirá um conjunto mínimo de cabeçalhos na resposta que é
enviada ao cliente de serviço da Web.
Para
configurar cabeçalhos explicitamente, crie-os em um cabeçalho HTTPReplyHeader. Por
exemplo, um nó
Compute
propaga uma mensagem no domínio XMLNSC e modifica Content-Type,
conforme a seguir:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
Não utilize a propriedade ContentType
para definir o Content-Type, a menos que você esteja trabalhando no domínio MIME. A propriedade ContentType destina-se a configurar o
valor de Content-Type usado no MIME.
O conjunto completo
de cabeçalhos HTTP usados na resposta é criado selecionando os cabeçalhos
usando o algoritmo definido nas seguintes etapas:
- Selecione um ou mais cabeçalhos em um cabeçalho HTTPReplyHeader.
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um usando
um valor não vazio na propriedade ContentType.
- Selecione um ou mais cabeçalhos em um cabeçalho HTTPResponseHeader (um
cabeçalho HTTPResponseHeader é propagado no retorno de um nó HTTPRequest).
- Se nenhum cabeçalho Content-Type tiver sido definido ainda, crie um com o
valor-padrão text/xml; charset=ccsid of the message
body.
- Crie ou sobrescreva o cabeçalho Content-Length.
Atenção: O nó HTTPReply sempre regrava
o cabeçalho Content-Length, mesmo se você tiver limpo Gerar cabeçalhos HTTP padrão a partir
da resposta. Essa ação assegura que o conteúdo esteja
correto.
Se
uma seção do cabeçalho HTTPReplyHeader existia na mensagem recebida
pelo nó HTTPReply,
e o terminal Output do nó HTTPReply estiver conectado,
a seção do cabeçalho HTTPReplyHeader será atualizada com todos os valores alterados ou
incluídos.
- Configurando Gerar cabeçalhos HTTP padrão a partir
da entrada para o nó HTTPRequest ou HTTPAsyncRequest
- Se você selecionar Gerar cabeçalhos HTTP padrão a partir da
entrada nas propriedades do nó HTTPRequest ou HTTPAsyncRequest, o nó incluirá um conjunto mínimo de cabeçalhos na solicitação que é enviada ao servidor.
Para definir cabeçalhos
explicitamente, crie-os em um cabeçalho HTTPRequestHeader. Por exemplo, um nó
Compute propagando uma mensagem no domínio XMLNSC pode modificar Content-Type, conforme a seguir:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNSC = InputRoot.XMLNSC;
Não utilize a propriedade ContentType
para definir o Content-Type, a menos que você esteja trabalhando no domínio MIME. A propriedade ContentType destina-se a configurar o
valor de Content-Type usado no 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 um ou mais cabeçalhos em um cabeçalho HTTPRequestHeader.
- Se nenhum cabeçalho Content-Type estiver definido ainda, crie um usando
um valor não vazio na propriedade ContentType.
- Selecione um ou mais cabeçalhos em um cabeçalho HTTPInputHeader (um cabeçalho HTTPInputHeader
é criado automaticamente por um nó HTTPInput).
- Se nenhum cabeçalho Content-Type tiver sido definido ainda, crie um com o
valor-padrão text/xml; charset=ccsid of the message
body
- 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 ou HTTPAsyncRequest
sempre regrava o cabeçalho Content-Length, mesmo se você tiver desmarcado a opção Gerar cabeçalhos HTTP padrão a partir da entrada ou da
solicitação. Essa ação assegura que o
conteúdo esteja correto.
Se existir um cabeçalho HTTPRequestHeader na mensagem recebida,
o cabeçalho HTTPRequestHeader será atualizado com todos os valores
alterados ou incluídos.