http nodes introduction - this site is to learn the ibm integration … · 2019. 6. 13. · if you...

HTTP Nodes introduction:

Http input node:

Use the HTTP Input node to receive an HTTP message from an HTTP client forprocessing by a message flow.

Using the HTTP Input node with the HTTP Reply and HTTP Request nodes, the brokercan act as an intermediary for Web services, and Web service requests can betransformed and routed in the same way as other message formats that are supportedby Web Sphere Message Broker. Web service requests can be received either instandard HTTP (1.0 or 1.1) format, or in HTTP over SSL (HTTPS) format. Set the UseHTTPS property to choose whether to handle HTTP or HTTPS requests.

A broker can support multiple HTTP Input nodes. In the HTTP Input node you mustspecify the requests to which the node listens. If the broker is listening on addresshttp://localhost: 7080, for a request http://localhost: 7080/Joe/Mary, the HTTPlistener removes the HTTP address leaving the request (Joe/Mary). The listener thenmatches the request with the information that is specified in the URL selector of theHTTP Input node; this match is done from the most specific to the most generic data.For example, if the following values were specified in HTTP Input nodes:

/Joe /Joe/Mary /Joe/* /*

The HTTP Input node is contained in the HTTP drawer of the palette, and is represented inthe workbench by the following icon:

Terminals:

Failure: The output terminal to which the message is routed if an error occurs. Out: The output terminal to which the message is routed if it is successfully retrieved. Catch: The output terminal to which the message is routed if an exception is thrown

downstream and caught by this node.

Http Reply node: C:\Users\nyendada\Downloads\MB\WebService\Http_Nodes_And_SOAP_Nodes_Scenarios.doc Page 1 of 50

Use the HTTP Reply node to return a response from the message flow to an HTTP

client. This node generates the response to an HTTP client from which the inputmessage was received by the HTTP Input node, and waits for confirmation that it hasbeen sent.

The HTTP Reply node can be used in any message flow that needs to accept HTTP orHTTPS messages. The most common example of this is a message flow thatimplements a Web service.

If you include an HTTP Reply node in a message flow, you must either include an HTTPInput node in the same flow, or the message must be received from another flow thatis running in the same broker, and that started with an HTTP Input node. The responseis associated with the reply by a request identifier that is stored in Local Environmentby the HTTP Input node.

This node constructs a reply message for the Web service client from the entire inputmessage tree, and returns it to the requestor.

The HTTP Reply node is contained in the HTTP drawer of the palette, and is represented inthe workbench by the following icon:

Terminals:

In: The input terminal that accepts a message for processing by the node. Failure: The output terminal to which the message is routed if a failure is detected

when the message is propagated. Out: The output terminal to which the message is routed if it has been propagated

successfully, and if further processing is required within this message flow.

C:\Users\nyendada\Downloads\MB\WebService\Http_Nodes_And_SOAP_Nodes_Scenarios.doc Page 2 of 50

Http Request Node:

Use the HTTP Request node to interact with a Web service, using all or part of theinput message as the request that is sent to that service.

You can also configure the node to create a new output message from the contents ofthe input message, augmented by the contents of the Web service response, beforeyou propagate the message to subsequent nodes in the message flow.

Depending on the configuration, this node constructs an HTTP or an HTTP over SSL(HTTPS) request from the specified contents of the input message, and sends thisrequest to the Web service. The node receives the response from the Web service, andparses the response for inclusion in the output tree. The node generates HTTP headersif these are required by your configuration.

You can use this node in a message flow that does or does not contain an HTTP Inputor HTTP Reply node.

The HTTP Request node is contained in the HTTP drawer of the palette, and is represented inthe workbench by the following icon:

Terminals:

In: The input terminal that accepts a message for processing by the node. Failure: The output terminal to which the message is routed if a failure is detected

during processing in the node. Out: The output terminal to which the message is routed if it represents successful

completion of the Web service request, and if further processing is required within thismessage flow.

Error: The output terminal to which messages that include an HTTP status code that isnot in the range 200 through 299, including redirection codes (3xx) if you have not setproperty Follow HTTP redirection.

Step 1: Crate the Message flow Project, the name is Webservices_using_HTTP_Nodes.


Step 2: Create the Message Flow the name is HTTP_Nodes_Flow.


Step 3: Now design the Flow by using MqInput node, MqOutput node, Compute node, HTTPInput node, HTTP Reply node and HTTP Request node.


Step 4: Give the correct Queue name in Basic of Mqinput node Properties and give the inputmessage parsing is XMLNS For XML messages (namespace aware).


Step 5: Now open ESQL of the Compute node and then remove the comments of CALL CopyEntireMessage() and set the output local environment C:\Users\nyendada\Downloads\MB\WebService\Http_Nodes_And_SOAP_Nodes_Scenarios.doc Page 7 of 50

SET OutputLocalEnvironment.Destination.HTTP.RequestURL=InputRoot.XMLNS.ROOT.URL


Step 6: Give the any url in web service URL of the HTTP request node. This is the mandatory-filed .In blow screen we are giving like this value is http://www.miraclesoft.com/dummy1

Step 7: Give the Path suffix for URL in HTTP Input Properties.


Example: /SERVICE1 this path suffix for URL must be same in the input messagebecause in this scenario set the URL in outputLocalenvironment so the input message is

http://localhost: 7080/SERVICE1

Step 8: Now open the open ESQL of Compute1 then remove the comments of C:\Users\nyendada\Downloads\MB\WebService\Http_Nodes_And_SOAP_Nodes_Scenarios.doc Page 10 of 50

CALL CopyMessageHeaders (); and set the output rootSET OutputRoot.XML.data='Hello';

Step 9: Now open the Open ESQL of Compute node2 then remove the comments of


CALL CopyEntireMessage (); then set the output root of http response header and create theNext sibling of Properties. SET OutputRoot.HTTPResponseHeader=NULL;CREATE NEXTSIBLING OF OutputRoot.Properties DOMAIN 'MQMD';


Step 10: Give the output queue name in MQOutput node of properties this node connects fromError and failure terminals of the HTTP Request node. Give another output queue name inMQOutput1 this node connects from Compute node.


Step 11: Go to the Broker Administrator Perspective then add the flow into the BAR file. AndDeploy into the BROKER topology.


Step 12: Now open the RFH utile and Write the Message into the Queue. The input message is

http://localhost:7080/SERVICE1


Step 13: Now Read the Message in to the Queue. That we set in MQOutput1.


SOAP Nodes introduction:

SOAP Input Node:

Use the SOAP Input node to process client SOAP messages, thus enabling the brokerto be a SOAP Web services provider.

The SOAP Input node is typically used in conjunction with the SOAP Reply node.

The SOAPInput node is contained in the Web Services drawer of the message flow nodepalette, and is represented in the workbench by the following icon:

Terminals:

Failure: The output terminal to which a message is routed if a failure is detected whenthe message is propagated to the Out flow (such as a message validation failure).Failures routed to this terminal include those caused by the retry processing occurringbefore the retry propagates the message to the Out flow.

Out: The output terminal to which the message is routed if it has been successfully putto the output queue, and if further processing is required within this message flow. Ifno errors occur within the input node, a message received from an external resource isalways sent to the Out terminal first.

Catch: The output terminal to which the message is routed if an exception is throwndownstream and caught by this node.

Mandatory Properties:

WSDL file name: This property type is String. This property must specify the WSDL file that wasimported into the message set. It can be set by using the following methods:

Click Browse to select a WSDL file from the list of imported WSDL files. Drag a WSDL file from a message set onto the node. Type in a file name that is relative to the message set project in which the imported WSDL file

exists.

Port type: This property type is String. This field lists all of the port types defined by the specifiedWSDL file. By default, the first port type found in the WSDL file that has an associated HTTP binding isselected.

Error Conditions:

Selected Port type does not contain at least one operation.

Imported binding: This property type is String. The Imported-binding box lists all of the SOAPbindings associated with the selected port type. Only HTTP transport is supported. Bindings are listed inthe order that they are displayed in the WSDL file. By default, the first binding that implements theoperation and has an associated service port, is selected. This property is updated every time the Porttype value changes.


Error Conditions:

No SOAP bindings (with HTTP transport) in the WSDL file are associated with the Port type. Selected binding does not have any operations.

Service port: This property type is String. The Service port box lists all of the service ports that pointto the selected binding. The first service port for the binding is selected by default. This property isupdated every time the selected binding value changes.

Error Conditions:

No ports point to the selected binding.

SOAP Reply Node:

Use the SOAP Reply node to send SOAP messages from the broker to the originatingclient in response to a message received by a SOAPInput node.

The SOAP Reply node is contained in the Web Services drawer of the message flow nodepalette, and is represented in the workbench by the following icon:

Terminals:

Failure: The output terminal to which a message is routed if a failure is detected whenthe message is propagated to the Out flow (such as a message validation failure).Failures routed to this terminal include those caused by the retry processing occurringbefore the retry propagates the message to the Out flow.



SOAP Request Node:

Use the SOAP Request node to send a SOAP request to the remote Web service.The node is a synchronous request and response node and blocks after sending therequest until the response is received.

The SOAP Request node is contained in the Web Services drawer of the message flow nodepalette, and is represented in the workbench by the following icon:

Terminals:

Failure: The output terminal to which a message is routed if a failure isdetected when the message is propagated to the Out flow (such as a messagevalidation failure). Failures routed to this terminal include those caused by theretry processing occurring before the retry propagates the message to the Outflow.

Out: The output terminal to which the message is routed if it has beensuccessfully put to the output queue, and if further processing is requiredwithin this message flow. If no errors occur within the input node, a messagereceived from an external resource is always sent to the Out terminal first.

Catch: The output terminal to which the message is routed if an exception isthrown downstream and caught by this node.


SOAP AsyncRequest node:

Use the SOAPAsyncRequest node in conjunction with the SOAPAsyncResponse node toconstruct a pair of message flows that call a Web service asynchronously.

The SOAPAsyncRequest node sends a Web service request, but the node does not waitfor the associated Web service response to be received. However, theSOAPAsyncRequest node does wait for the HTTP 200 acknowledgement beforecontinuing with the message flow, and the SOAPAsyncRequest node blocks if theacknowledgement is not received. The SOAPAsyncResponse node receives the Webservice response, which can be in a separate message flow. The nodes are used as apair, and correlate responses against the original requests.

The SOAPAsyncRequest node is the first half of the asynchronous request andresponse node pair. The SOAPAsyncRequest node calls a remote SOAP-based Webservice. The SOAPAsyncRequest node sends the request, but the SOAPAsyncRequestnode does not receive the response. The response is received by aSOAPAsyncResponse node that is running on a different thread. TheSOAPAsyncResponse node is typically at the beginning of a different message flow.

The SOAP role for this node is set to RequestingSOAPNode. Although theSOAPAsyncRequest node is similar to the input side of the HTTPRequest node, theSOAPAsyncRequest node does not have the advanced properties for selecting whichpart of the message is sent to the remote Web server because the SOAPAsyncRequestnode expects to send a fully formed SOAP message in the SOAP domain. The messagethat leaves the Out terminal is the same as the message that arrived at the Interminal.


The SOAPAsyncRequest node is WSDL-driven, in a similar manner to the SOAPRequest node.

The SOAPAsyncRequest node is contained in the Web Services drawer of the palette, and isrepresented in the workbench by the following icon:

Terminals:

In: The input terminal that accepts a message for processing by the node. Failure: The output terminal to which a message is routed if a failure is detected when

the message is propagated to the Out flow (such as a message validation failure).Failures routed to this terminal include those caused by the retry processing occurringbefore the retry propagates the message to the Out flow.


SOAPAsyncResponse node:

Use the SOAPAsyncResponse node in conjunction with the SOAPAsyncRequest node toconstruct a pair of message flows that call a Web service asynchronously.

The SOAPAsyncRequest node sends a Web service request, but the node does not waitfor the associated Web service response to be received. However, theSOAPAsyncRequest node does wait for the HTTP 200 acknowledgement beforecontinuing with the message flow, and the SOAPAsyncRequest node blocks if theacknowledgement is not received. The SOAPAsyncResponse node receives the Webservice response, which can be in a separate message flow. The nodes are used as apair, and correlate responses against the original requests.

The SOAPAsyncResponse node is contained in the Web Services drawer of the palette, and isrepresented in the workbench by the following icon:


Terminals:

Failure: The output terminal to which a message is routed if a failure is detected whenthe message is propagated to the Out flow (such as a message validation failure). Failures routed to this terminal include those caused by the retry processing occurring before the retry propagates the message to the Out flow.

Out: The output terminal to which the message is routed if it has been successfully putto the output queue, and if further processing is required within this message flow. If no errors occur within the input node, a message received from an external resource isalways sent to the Out terminal first.

Fault: SOAP fault messages will be directed down the Fault terminal. Catch: The output terminal to which the message is routed if an exception is thrown

downstream and caught by this node.

SOAP Envelope node:

Use the SOAP Envelope node to add a SOAP envelope onto an existing message. This node is designed to be used with the SOAP Extract node.

The default behavior of the SOAP Envelope node is to attach the SOAP envelope from astandard location ($Local Environment/SOAP/Envelope) in the Local Environment tree;you can specify an explicit location by using an XPath expression.

The SOAP Envelope node is contained in the Web Services drawer of the palette, and is represented in the workbench by the following icon:

Terminals:

In: The input terminal that accepts a SOAP message for processing by the node. Out: The output terminal that outputs the SOAP message that was constructed from

the SOAP message body and a SOAP envelope. Failure: The output terminal to which the message is routed if a failure is detected

during processing.


SOAP Extract node:

Use the SOAP Extract node to remove SOAP envelopes, allowing just the body of a SOAP message tobe processed. It can also route a SOAP message based on its operation name. Both functions areoptional; they are contained within one node because they are often used together.

The SOAP Extract node can perform two functions:

Extract function

The default behavior is to detach the SOAP envelope to a standard location($LocalEnvironment/SOAP/Envelope) in the Local Environment tree. Alternatively, you can specify anexplicit location using an XPath expression. Any existing SOAP envelope at the chosen location isreplaced.

Routing function

The SOAP message is routed to a Label node within the message flow as identified by the SOAPoperation within the message. The SOAP Operation is identified within the SOAP body tag.

The SOAP Extract node is contained in the Web Services drawer of the palette, and is represented in the workbench by the following icon:

Terminals:

In: The input terminal that accepts SOAP message for processing by the node. Out: The output terminal that outputs the SOAP message body (without the envelope

if the Remove envelope check box is selected on the node properties). Failure: The output terminal to which the message is routed if a failure is detected

during processing.


Step1: Open the Message broker tool kit and go to the File menu then click on new and click on Message set. Then open the New message set window Check the Web service SOAP check box Click on Next and Finish.


When will create the Message set then the message definition file create automatically that is SOAP.mxsd. Here below screens are one is message set and SOAP.mxsd.


Step 2: Now create the Message Definition file from IBM Supplied Message. The Window shows like this then Select the Soap 1.1 Envelope and Click on Finish button.


After click on finish the definition file create like this. Here name of Definition file is soapenv11.mxsd.


Step 3: Now create the Message Definition file. Give some name of that file.


Step4: Now Open the Definition file then add two Messages one is submitPOResponse in that add Local Elements are

OrderStatus OrderAmt PartNo PartQuantity

Second one is submitPORequest in that add Local Elements are PartNo PartQuantity PersonName

PersonName lastName

address street city Zip Code.


Step5: Now Right click on message set then click on Generate and click on WSDL Definition. Here Creation of WSDL file from exiting Definition file. Follow the below screens


Here we set the names of input and output of the WSDL file then click on next and finish.


Step 6: After finishes of Creation of WSDL file it shows like this.


Step 7: After completion of the Message set then Create the Message Flow Project.


At creation of the message flow project it should be set the Message set, which we created Earlier

After Creating the Message Flow Project then creating the Flow.


Step 8: This is the Flow of Consumer here using MQinput node, compute node, sub flow and MQOut put node.


This is the Flow design of Sub flow in Consumer side flow. Here using SOAP Request node, SOAP Extract node input node, out put node and Label node.


Here set the WSDL file in SOAP Request node. And give the name in Label node.


Step 9: Create another flow for Provider, Here using SOAP Input node, Sub Flow, Compute node and SOAP Reply node.


This is the Flow design of Sub flow in Consumer side flow. Here using SOAP Request node, SOAP Extract node input node, out put node and Label node.


Step 10: Now open the Compute node of Consumer flow then set Output root of submitPORequestnaming space.

SET OutputRoot.XMLNSC.ns:submitPORequest.partNo = InputRoot.XMLNSC.OrderMessage.localElement.PartNumber;

SET OutputRoot.XMLNSC.ns:submitPORequest.partQuantity = InputRoot.XMLNSC.OrderMessage.localElement.Quantity;

SET OutputRoot.XMLNSC.ns:submitPORequest.personName.firstName = InputRoot.XMLNSC.OrderMessage.localElement.FirstName;

SET OutputRoot.XMLNSC.ns:submitPORequest.personName.lastName = InputRoot.XMLNSC.OrderMessage.localElement.LastName;

SET OutputRoot.XMLNSC.ns:submitPORequest.address.street = InputRoot.XMLNSC.OrderMessage.localElement.Street;

SET OutputRoot.XMLNSC.ns:submitPORequest.address.city = InputRoot.XMLNSC.OrderMessage.localElement.City;

SET OutputRoot.XMLNSC.ns:submitPORequest.address.zipCode = InputRoot.XMLNSC.OrderMessage.localElement.ZipCode;


Step 11: Now open the Compute node of Provider’s flow then set Output root of submitPOResponse naming space.

SET OutputRoot.XMLNSC.ns:submitPOResponse.orderStatus = 'AVAILABLE';

SET OutputRoot.XMLNSC.ns:submitPOResponse.orderAmt = 50;

SET OutputRoot.XMLNSC.ns:submitPOResponse.partNo = InputRoot.XMLNSC.ns:submitPORequest.partNo;

SET OutputRoot.XMLNSC.ns:submitPOResponse.partQuantity = InputRoot.XMLNSC.ns:submitPORequest.partQuantity;


Step12: Now go to the Broker Administrative Perspective then add the Two Flows and one Message set.


Step 13: Now Deploy the Flows in to the Broker.


Setp14: Open the RFH Utile and Write the input in to this Queue input Queue.

The input is:

Message Broker IBM IBM IBM Some Part 1


Now read the Output from this Queue output Queue .

This is the Output of this Scenario:

HTTP/1.1 200 OK..Content-Type: text/xml;charset=utf-8..Content-Length: 373..Date: Fri, 12 Dec 2008 14:42:23 GMT..Server: Apache-Coyote/1.1....

AVAILABLE 50 Some Part 1


Terminals:Step 3: Now create the Message Definition file. Give some name of that file.The input is:

http nodes introduction - this site is to learn the ibm integration … · 2019. 6. 13. · if you...

Documents