Topic
  • 6 replies
  • Latest Post - ‏2005-08-02T19:31:48Z by SystemAdmin
SystemAdmin
SystemAdmin
4179 Posts

Pinned topic PROPAGATE Statement

‏2004-07-25T03:51:12Z |
I did a small test on PROPAGATE statement. It looks strange to me when I see the result. Here is the example.

I have an input message like this:
<Message><Number>1</Number></Message>

My message flow structure is
Input node -> Compute node1 -> Compute node2 -> Output node

My target is to get two output messages as follows:
<Message><Number>2</Number></Message>
<Message><Number>3</Number></Message>
Compute node1 has the following ESQL:
SET OutputRoot = InputRoot;
SET OutputRoot.XML.Message.Number = 2;
PROPAGATE;
SET OutputRoot = InputRoot;
RETURN TRUE;

Compute node2 has following ESQL
SET OutputRoot = InputRoot;
SET OutputRoot.XML.Message.Number = 3;
RETURN TRUE;

I got the following output:
<Message><Number>3</Number></Message>
<Message><Number>3</Number></Message>

Why PROPAGATE Statement navigating to downstream nodes?
And Why is it trying to execute the code which is under
downstream compute nodes?

Is this the way it works? Strange to me!

I am about to start a big message flow development which may contain bunch of PROPAGATE Statements. I appreciate if someone clarifies the PROPAGATE Statement behavior.

I know one alternative solution to this. I can cheat the downstream compute nodes. I do not want do in this way in case if there is a legitimate solution. Thanks for your help.
Updated on 2005-08-02T19:31:48Z at 2005-08-02T19:31:48Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2004-07-25T21:11:41Z  
    First, this is working the way it was designed. The purpose of PROPAGATE
    is to allow a message to be built in a compute node, then sent out the OUT
    node and process by all down stream nodes.

    In your ESQL, in the second compute node, you set the Message.Number to 3
    • regardless of what it was before.

    Try this instead:

    SET SET OutputRoot.XML.Message.Number =
    CAST(CAST(InputRoot.XML.Message.Number AS INT) + 1 AS CHAR;

    in both compute nodes.

    This should give you a value of 3 and 2

    What the compute node avoids is having to have a loop made up of compute
    nodes and filter nodes and lots of special checking code to process the
    loop.

  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2004-07-26T11:46:57Z  
    Compute Node 1 is giving you 2 messages -
    <Message><Number>1</Number></Message>
    <Message><Number>2</Number></Message>
    Compute node 2 is receiving these one after the other and performing the
    ESQL on them both giving you
    <Message><Number>3</Number></Message>
    <Message><Number>3</Number></Message>
    "ksvpras" <prasad26@hotmail.com> wrote in message
    news:8590957.1090727508561.JavaMail.wasadmin@swg3ws006...
    > I did a small test on PROPAGATE statement. It looks strange to me when I
    see the result. Here is the example.
    >
    > I have an input message like this:
    > <Message><Number>1</Number></Message>
    >
    > My message flow structure is
    > Input node -> Compute node1 -> Compute node2 -> Output node
    >
    > My target is to get two output messages as follows:
    > <Message><Number>2</Number></Message>
    > <Message><Number>3</Number></Message>
    >
    >
    > Compute node1 has the following ESQL:
    > SET OutputRoot = InputRoot;
    > SET OutputRoot.XML.Message.Number = 2;
    > PROPAGATE;
    > SET OutputRoot = InputRoot;
    > RETURN TRUE;
    >
    > Compute node2 has following ESQL
    > SET OutputRoot = InputRoot;
    > SET OutputRoot.XML.Message.Number = 3;
    > RETURN TRUE;
    >
    > I got the following output:
    > <Message><Number>3</Number></Message>
    > <Message><Number>3</Number></Message>
    >
    > Why PROPAGATE Statement navigating to downstream nodes?
    > And Why is it trying to execute the code which is under
    > downstream compute nodes?
    >
    > Is this the way it works? Strange to me!
    >
    > I am about to start a big message flow development which may contain bunch
    of PROPAGATE Statements. I appreciate if someone clarifies the PROPAGATE
    Statement behavior.
    >
    > I know one alternative solution to this. I can cheat the downstream
    compute nodes. I do not want do in this way in case if there is a legitimate
    solution. Thanks for your help.
    >
    >

  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2004-07-27T21:07:46Z  
    First, this is working the way it was designed. The purpose of PROPAGATE
    is to allow a message to be built in a compute node, then sent out the OUT
    node and process by all down stream nodes.

    In your ESQL, in the second compute node, you set the Message.Number to 3
    • regardless of what it was before.

    Try this instead:

    SET SET OutputRoot.XML.Message.Number =
    CAST(CAST(InputRoot.XML.Message.Number AS INT) + 1 AS CHAR;

    in both compute nodes.

    This should give you a value of 3 and 2

    What the compute node avoids is having to have a loop made up of compute
    nodes and filter nodes and lots of special checking code to process the
    loop.

    Thanks for the information.

    The example I presented here is to understand the behavior of PROPAGATE statement. As I mentioned earlier, I will be developing a message flow which contains more than 6 compute nodes and one of the middle compute node will be having PROPAGATE statement. The middle compute node prepares the required output message and propagates it.
    But unfortunately the downstream nodes modifies the
    output message before it reaches to the Queue.

    My question is.. Why propagate statement go to the downstream nodes? And Why should it execute the downstream
    compute nodes "code" before it reaches to MQOUT?

    I can put some cheat code in downstream nodes when PROPAGATE is going on. But I am just looking for other easy
    way to do this. Thanks.
  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2004-07-28T09:50:12Z  
    Thanks for the information.

    The example I presented here is to understand the behavior of PROPAGATE statement. As I mentioned earlier, I will be developing a message flow which contains more than 6 compute nodes and one of the middle compute node will be having PROPAGATE statement. The middle compute node prepares the required output message and propagates it.
    But unfortunately the downstream nodes modifies the
    output message before it reaches to the Queue.

    My question is.. Why propagate statement go to the downstream nodes? And Why should it execute the downstream
    compute nodes "code" before it reaches to MQOUT?

    I can put some cheat code in downstream nodes when PROPAGATE is going on. But I am just looking for other easy
    way to do this. Thanks.
    The way I would consider avoiding this is rather than having additional
    compute nodes futher down the flow can you include the SQL below the
    propagate statement prior to the return true?
    http://att1.html
  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2004-07-28T14:22:24Z  
    The way I would consider avoiding this is rather than having additional
    compute nodes futher down the flow can you include the SQL below the
    propagate statement prior to the return true?
    http://att1.html
    I appreciate your idea. Yes. It is possible to avoid rest of the compute nodes and put ESQL statements beneath the
    PROPAGATE statement. But my message flow is bit complex. The downstream nodes are not only just compute nodes there are bunch of other nodes(Filter, check, Httprequest, etc.,)
    How to control all of them?
  • SystemAdmin
    SystemAdmin
    4179 Posts

    Re: PROPAGATE Statement

    ‏2005-08-02T19:31:48Z  
    as has been stated, the propogate is doing what it is designed to do. I am not 100% what your intention is - where did you want the message to go that you propgated???- if I understand what you want to do, maybe setting a label would work - and then have a route to label after the compute node and you could send it to where you want to go.