Chapter 7. Scenario: Data transformation and security 207
7.6.4 VerifyCredit message flow
Figure 7-39 shows the VerifyCredit message flow.
Figure 7-39 VerifyCredit message flow
The message flow has two input nodes. An HTTPInput node called
HTTPs_SOAP_Input is the production node. The import component in
WebSphere Process Server has a Web service binding that uses the URL of this
node. An MQInput node called
MQ_SOAP_Input was used for testing.
Every time the service requestor, which in this case is WebSphere Process
Server, initiates the VerifyCredit message flow, a protocol selection occurs inside
the flow. When the broker receives a request, it uses a message tree structure to
route the flow to the appropriate nodes (Figure 7-40 on page 208) depending on
the incoming request protocol (HTTP or MQ).
208 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
Figure 7-40 Dynamic routing and switching of protocol
HTTPs_SOAP_Input node
The HTTPs_SOAP_Input HTTPInput node receives the message from
WebSphere Process Server. The incoming message is parsed using the MRM
domain with the SOAP envelope message type. This configuration is defined
directly on the HTTPInput node and is necessary for the correct creation of the
message structure (Figure 7-41).
Figure 7-41 HTTPInput node message parsing definition
The Use HTTPS option is enabled as discussed in 7.6.3, “Enabling the
HTTPInput node for SSL” on page 205.
HTTPInputHeader …
(or)
• Save the HTTPRequestIdentifier
• Creates the MQMD header for a later
process
• Routes the message to a empty body
response using HTTPReply node
• Route the message to an unplugged
node terminal
Root
Properties MQMD
…
Root
Properties
Chapter 7. Scenario: Data transformation and security 209
RemoveSOAPHeaders JavaCompute node
When the message arrives from the input node, the SOAP envelope elements
must be removed from the original structure. This is done by using a
JavaCompute node (Example 7-10).
Example 7-10 Removing the SOAP envelope part from the message structure
...
// Copy all headers excluding the MRM message structure
BankUtils.copyHeaders(inMessage, outMessage, new String[]{"MRM"});
MbElement inRootElement = inMessage.getRootElement();
MbElement outRootElement = outMessage.getRootElement();
// Select all the chields of body from the InputRoot
String bodyChields = "/MRM/Body";
MbElement parser = outRootElement.createElementAsLastChild("MRM");
// Retrives the soap body chields from the InputRoot //
MbElement element = inRootElement.getFirstElementByPath(bodyChields);
// Copy all the chields of the body element to the output message //
if (element!=null)
parser.copyElementTree(element);
// Just copy everything...
else
outRootElement.copyElementTree(inRootElement);
...
Compute and RouteToLabel nodes
After removing the SOAP envelope elements (Header/Body), the message is
routed using a RouteToLabel node to a the Legacy_Banks secondary flow. This
routing is configured using a simple Compute node that adds a new labelname
attribute (Example 7-11) in the LocalEnvironment structure. The RUNTDS label
identifies the Legacy_Banks Label node.
Example 7-11 Compute node
...
SET OutputLocalEnvironment = InputLocalEnvironment;
-- Go to the label called RUNTDS
SET
OutputLocalEnvironment.Destination.RouterList.DestinationData[1].labeln
ame = 'RUNTDS';
...
210 Using IBM WebSphere Message Broker as an ESB with WebSphere Process Server
The Compute mode property must be set to LocalEnvironment and Message
(Figure 7-42).
Figure 7-42 Compute node configuration
FlowOrder node
This secondary flow uses a FlowOrder node to sequence the incoming message
to two different endpoints, Legacies 1 and 2.
The first execution goes to a JavaCompute node called
Transform_TDS. When
processing is complete, the message is sent to another JavaCompute node
called
Transform_X12. These two nodes prepare the message for delivery to the
enterprise information systems.
Transform_TDS JavaCompute node
The Transform_TDS JavaCompute node transforms the incoming message to a
format that is expected by Legacy 1 using the XML_2_TDS.mxsd message
definition (Figure 7-43).
Figure 7-43 VerifyCredity to data type message transformation
Chapter 7. Scenario: Data transformation and security 211
The transformation is done using XPath (Example 7-12).
Example 7-12 XPath transformation on a JavaCompute node: Transform_TDS code
...
// Prepare the MQMD header if it doesn't exist //
BankUtils.createMQMD(outRootElement);
// Creates the parser //
MbElement parser = outRootElement.createElementAsLastChild("MRM");
// Creates the data message that will be used by the message set //
MbElement dataElement =
parser.createElementAsLastChild(MbElement.TYPE_NAME, "data", null);
// Define the TDS element structure using XPath //
MbXPath xpName =
new MbXPath("/?$Name[set-value($client_name)]", dataElement);
MbXPath xpLName =
new MbXPath("/?$LastName[set-value($client_lname)]",
dataElement);
MbXPath xpSSN =
new MbXPath("/?$SSN[set-value($ssn)]", dataElement);
MbXPath xpAddr =
new MbXPath("/?$Address[set-value($addr)]", dataElement);
// Populate the variables defined above //
xpName.assignVariable("client_name", ...);
xpLName.assignVariable("client_lname", ...);
xpSSN.assignVariable("ssn", ...);
xpAddr.assignVariable("addr", ...);
// Evaluate the XPath definitions //
outMessage.evaluateXPath(xpName);
outMessage.evaluateXPath(xpLName);
outMessage.evaluateXPath(xpSSN);
outMessage.evaluateXPath(xpAddr);
...
The following actions occur in the Transform_TDS code:
1. The code creates the root message structure that is expected by the
MessageSet /Root/MRM/data/.
2. The XPath expressions are defined by using the “data” element in the
message as the root element for the new message structure (set in the
dataElement variable). The second argument of the MbXpath constructor
defines dataElement as the root element.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.