WebSphere Message Broker, Versão 8.0.0.5 Sistemas operacionais: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte as informações sobre a versão mais recente do produto em IBM Integration Bus, Versão 9.0

Trabalhando com Fluxos HTTP

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:
  1. Selecione um ou mais cabeçalhos em um cabeçalho HTTPReplyHeader.
  2. Se nenhum cabeçalho Content-Type estiver definido ainda, crie um usando um valor não vazio na propriedade ContentType.
  3. Selecione um ou mais cabeçalhos em um cabeçalho HTTPResponseHeader (um cabeçalho HTTPResponseHeader é propagado no retorno de um nó HTTPRequest).
  4. 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.
  5. 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:
  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 um ou mais cabeçalhos em um cabeçalho HTTPRequestHeader.
  3. Se nenhum cabeçalho Content-Type estiver definido ainda, crie um usando um valor não vazio na propriedade ContentType.
  4. Selecione um ou mais cabeçalhos em um cabeçalho HTTPInputHeader (um cabeçalho HTTPInputHeader é criado automaticamente por um nó HTTPInput).
  5. 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
  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 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.

Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última atualização:
        
        Última atualização: 2015-02-28 18:28:27


Tópico de TarefaTópico de Tarefa | Versão 8.0.0.5 | ac20450_