introduction : ibm® websphere® message broker has built-in … · 2019. 6. 14. · introduction :...

14
Introduction : IBM® WebSphere® Message Broker has built-in Aggregation Control, Aggregation Request, and Aggregation Reply nodes to facilitate Fan-in/Fan-out message aggregation. Aggregation Nodes: AggregateControl, AggregateRequest nodes (Used in Fan-Out to broadcast the request message to multiple destinations ),AggregateReply (Used in Fan-In to collect responses) * ‘ Aggregate Name’ property of AggregateControl & AggregateReply nodes should be the same. * ‘Folder Name’ property of the AggregateRequest node decide how the input will be structured in Fan-Out flow. The AggregateReply node creates a folder in the combined message tree below Root, called ComIbmAggregateReplyBody. Below this folder, the node creates a number of subfolders using the names that you set in the AggregateRequest nodes. These subfolders are populated with the associated reply messages. Broker internally maintains aggregation state in following queues: SYSTEM.BROKER.AGGR.REQUEST SYSTEM.BROKER.AGGR.CONTROL SYSTEM.BROKER.AGGR.REPLY SYSTEM.BROKER.AGGR.UNKNOWN SYSTEM.BROKER.AGGR.TIMEOUT The aggregation function is provided by the following three nodes: The AggregateControl node marks the beginning of a fan-out of requests that are part of an aggregation. It sends a control message that is used by the AggregateReply node to match the different requests that have been made. The information that is propagated from the Control terminal includes the broker identifier, the aggregate name property, and the timeout property. You must not change the aggregation information that is added to the message Environment by the AggregateControl node. The AggregateRequest node records the fact that the request messages have been sent. It also collects information that helps the AggregateReply node to construct the aggregated reply message. You must preserve the information that is added to the message Environment by the AggregateControl node, otherwise the aggregation fails. The AggregateReply node marks the end of an aggregation fan-in. It collects replies and combines them into a single aggregated reply message. Local Queues used in this Scenario are: 1) IN Page: 1 of 14

Upload: others

Post on 01-Feb-2021

4 views

Category:

Documents


0 download

TRANSCRIPT

  • Introduction :IBM® WebSphere® Message Broker has built-in Aggregation Control, Aggregation Request,

    and Aggregation Reply nodes to facilitate Fan-in/Fan-out message aggregation.

    Aggregation Nodes:

    AggregateControl, AggregateRequest nodes (Used in Fan-Out to broadcast the request message to multiple destinations ),AggregateReply (Used in Fan-In to collect responses)

    * ‘Aggregate Name’ property of AggregateControl & AggregateReply nodes should be the same.

    * ‘Folder Name’ property of the AggregateRequest node decide how the input will be structured in Fan-Out flow.

    The AggregateReply node creates a folder in the combined message tree below Root, calledComIbmAggregateReplyBody. Below this folder, the node creates a number of subfolders using thenames that you set in the AggregateRequest nodes. These subfolders are populated with the associated reply messages.

    Broker internally maintains aggregation state in following queues:

    SYSTEM.BROKER.AGGR.REQUEST

    SYSTEM.BROKER.AGGR.CONTROL

    SYSTEM.BROKER.AGGR.REPLY

    SYSTEM.BROKER.AGGR.UNKNOWN

    SYSTEM.BROKER.AGGR.TIMEOUT

    The aggregation function is provided by the following three nodes:

    The AggregateControl node marks the beginning of a fan-out of requests that are part of an aggregation. It sends a control message that is used by the AggregateReply node to match thedifferent requests that have been made. The information that is propagated from the Control terminal includes the broker identifier, the aggregate name property, and the timeout property. You must not change the aggregation information that is added to the message Environment by the AggregateControl node.

    The AggregateRequest node records the fact that the request messages have been sent. It also collects information that helps the AggregateReply node to construct the aggregated reply message. You must preserve the information that is added to the message Environment by the AggregateControl node, otherwise the aggregation fails.

    The AggregateReply node marks the end of an aggregation fan-in. It collects replies and combines them into a single aggregated reply message.

    Local Queues used in this Scenario are:1) IN

    Page: 1 of 14

  • 2) OUT3) OUT14) Q15) IQ

    Step 1: Creating Integration Project :

    Step 2: Project Name As : Aggregation_Nodes.

    Step 3: Creating Message Flow Name as : FANOUT_MESSAGEFLOW

    Page: 2 of 14

  • After Creating Message Flow Click Finish.

    Required Nodes for FANOUT_MESSAGEFLOW are 1) MQINPUT Node

    2) Aggregate Control Node3) Compute Node4) MQOUT Node5) Aggregate Request Node.6) Aggregate Reply Node.

    Step : 4

    Under WebSphere MQ drag MQ Input node and give Queue Name as IN.

    Select Message domain as XMLNSC under Input Message Parsing properties in for all MQ Input nodes.

    Step : 5

    Page: 3 of 14

  • Under Routing-->Drag Aggregate Control Node in the Aggregate Name Give as “TRA”

    Step : 6Drag Compute Node two times ,the flow is as shown bellow

    Step 7: The input for the MQ Input node is

    MiracleSoftware

    Step 8: Open first compute node and create Output Structure for “name” tag. Write code as between Begin and End; block shown in below

    Page: 4 of 14

  • Step 9: Open Second compute node and create Output Structure for “Company” tag. Write code asbetween Begin and End; block shown in below

    Step 10:

    Under WebSphere MQ drag “MQOutput” Node Two times and Flow as shown in Below.

    Page: 5 of 14

  • Step 11: MQ output queue under Request Properties set Reply-to Queue as “Q1” as shown in below

    Step 12:

    ///ly MQ Ouput1 node also give Queue name as “OUT1” and under Request properties set Reply to Queue as “Q1” as shown in below.

    Page: 6 of 14

  • Step 13:

    Under Routing Nodes use Aggregate Request Node two times and set Folder name under Basic properties as K1 and K2 as shown in below.

    Page: 7 of 14

  • Step 14:

    Use Two MQ Input nodes and Set Queue Names which comes under Basic Properties, as OUT and OUT1 as Shown in Below.

    Page: 8 of 14

  • Step 15: Drag MQ Reply Node which is present in WebSphere MQ Nodes,the flow as shown in below.No need to set any properties for MQ Reply Node.

    Page: 9 of 14

  • Step 16: Drag MQ Input node which is present in Websphere MQ Nodes,Under Basic properties set Queue name as “Q1”,here in the MQ Output node we set Reply to Queue name as “Q1” we use the same name in the MQ input node.

    Step 17 : Drag Aggregate Reply node which is present in Routing nodes,and set Aggregate name as “TRA”.Here in earlier we set Aggregate name as “TRA” in the Aggregate Control node. We use the same name here.

    Page: 10 of 14

  • Step 18: Drag Compute node which is present in Transform nodes and flow as shown in below.

    Step 19:

    Page: 11 of 14

  • Double click on the compute node and write the following code between Begin and End; block.

    BEGIN-- CALL CopyMessageHeaders();-- CALL CopyEntireMessage();SET OutputRoot.XMLNSC.RESULT.FINAL=

    InputRoot.ComIbmAggregateReplyBody.K1.XMLNSC.SDeta.S_NAME||InputRoot.ComIbmAggregateReplyBody.K2.XMLNSC.SDeta.S_COLLG;

    RETURN TRUE;END;

    Step 20 :

    Drag MQ Output node which is present in Websphere MQ Nodes and Set Queue name as “IQ” as shown in below.

    Step 21: Add Break Points to the flow and Deploy the fllow.

    Step 22 : Give input as MiracleSoftware to the Local Queue “IN” in the Websphere MQ as shown in below.

    Page: 12 of 14

  • Step 23:

    The Output structure created observe in the following screen

    Step 24: The Final result stored in the IQ Queue in the Websphere MQ ,as shown in below

    Page: 13 of 14

  • Page: 14 of 14