[3.3][CORE] foreach message processor feedback

[Santiago Vacas]

Hi devs,

We are working on a new message processor for Mule 3.3 to ease the
iteration over collections present in the current message.
You can find the details of the foreach proposal in the following page:

http://www.mulesoft.org/documentation/display/MULECDEV/Foreach+MP

Any feedback will be appreciated.

thanks,
Santiago

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ken Yagen]

Santiago,

A few questions.

Does the expression attribute need to be expression for consistency, else could I suggest we call it expressionFilter to be clearer about what it does?

Are the results the same as the originalpayload before or after the expression is applied? What if the original payload is xml, it's filtered using xpath and the results transformed into something other then XML in the foreach block?

Is there any state to foreach and does it create any unique use cases when used within a cluster? What about with split-aggregate?

Can you have an async block inside a foreach and process the batches in parallel? Otherwise, are the all processed synchronously by default? If it's possible to do async, I'd like to see a specific use case scenario for this. And, if this is true - same question regarding the cluster, what if there is a failure in a clustered scenario?

For testing, would like to see some testing with very large collections being split.

Are there use cases when any filtering of the results are done or does the result always have the same number of items as the original payload?

Thanks,

ken

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Santiago Vacas]

Post by Ken Yagen
Santiago,
A few questions.
Does the expression attribute need to be expression for consistency, else could I suggest we call it expressionFilter to be clearer about what it does?

we keep it as "expression" for consistency; its used that way in every
element that takes an expression, like splitter that is similar to
this one, we can document it better.

Post by Ken Yagen
Are the results the same as the originalpayload before or after the expression is applied? What if the original payload is xml, it's filtered using xpath and the results transformed into something other then XML in the foreach block?

Those changes will not be present in the next processor, the same
original message instance is sent down the flow. If you want to get
the transformed results you need to use a splitter/aggregator pair or
use split-aggregate once it is implemented.

Post by Ken Yagen
Is there any state to foreach and does it create any unique use cases when used within a cluster? What about with split-aggregate?

There's nothing particular in foreach that will require any specific
consideration in a cluster.

Post by Ken Yagen
Can you have an async block inside a foreach and process the batches in parallel? Otherwise, are the all processed synchronously by default? If it's possible to do async, I'd like to see a specific use case scenario for this. And, if this is true - same question regarding the cluster, what if there is a failure in a clustered scenario?

By default the processors inside foreach are processed synchronously,
but you can use async to have them processed in parallel. The
salesforce connector for instance could leverage the batch processing
in combination with its bulk API. The cluster case should be the same
as when working with splitters.

Post by Ken Yagen
For testing, would like to see some testing with very large collections being split.

this needs to be addressed

Post by Ken Yagen
Are there use cases when any filtering of the results are done or does the result always have the same number of items as the original payload?

The result is always the same instance as the original message, so it
should keep the same items unless you explicitly remove them using the
message reference.


Santiago

Post by Ken Yagen
Thanks,
ken
---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pablo La Greca]

Santiago,

Attribute name expression makes sense for instance in expression-transformer element, since the element name already tells you what's the expression for.

I think it's a good idea to call it splitterExpression. The same is done for idempotent-redelivery-policy, the attribute idExpression is to set the expression for the id generation. Having attribute names like those makes mule configuration easier to understand.

Pablo.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

Foreach encapsulates a splitter yes, but I don't think we should expose the name "splitter" anywhere, want to keep things as simple as possible and not allow any confusion. Most non-advanced users will see foreach and splitter as two completely different things.

If i had to give it a more specific name it would be iterableExpression or listToIterateExpression or something like that consistent with the foreach concept.

But IMO just expression is fine, I think its fairly obvious that its there to select what you want to iterate over and especially when accompanied with documentation.

Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in expression-transformer element, since the element name already tells you what's the expression for.
I think it's a good idea to call it splitterExpression. The same is done for idempotent-redelivery-policy, the attribute idExpression is to set the expression for the id generation. Having attribute names like those makes mule configuration easier to understand.
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Ross Mason]

Thanks for the demos today guys. I want o comment on the ForEach and
Split-agregate spec, but comments are not enabled on the wiki (which is
annoying), so posting here:

My pushback on ForEach is all around giving the use a clear mental model of
when to use ForEach and when to split -aggregate. The separation is not
clear right now, which makes it hard to say whether ForEach is the right
implementation as it stands. I'm not sure yet if ForEach is suitable for
iteration and enrichment, but consider this use case:

Since ForEach is ByRef I can't change the outer structure of the message,
but I can still change the inner structure with ForEach, so in theory I can
do enrichment and maintain structure in the message. I do think this type
of enrichment is common. Take the order example:

<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
</item>
<item>
<sku>59677477372722</sku>
</item>
</order-items>
</PO>
I can iterate over each item, but there are many scenarios where I want to
enrich the data, ie. to look up product description based on SKU.

<foreach expression="#[xpath:/PO/order-items/item]">

<enricher target="#[variable:description]">

<foo:get-item-description sku="#[xpath:/item/sku]"/>

</enricher>

<mxml:add-element name="description" value="#[variable:description]"/>

</enricher>

</foreach>


This would create:


<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
<description>A sprocket</description>
</item>
<item>
<sku>59677477372722</sku>
<description>A gromit</description>
</item>
</order-items>
</PO>


You can see a user thinking this should work as a way of doing enrichment
using ForEach. I'm not saying this should be possible or not, we just need
to see the use cases side by side to order to understand how we give the
user the right mental model for working with ForEach.

Also, where does data mapper come into this? If
<foo:get-item-description> calls
out to a db, this might just be a mapping look up. If this is a web
service call, DM doesn't make as much sense.

All the use cases need to be defined up front and then assessed against
what we think ForEach, Splitter - Aggregate and DM should be used for. We
can't make good decisions considering just a subset of use cases. Bear in
mind we don't need to support every use-case we can think of and should be
striking out the edge cases (avoid feeding the software monster).

Cheers,

Ross Mason
CTO, Founder
MuleSoft Inc.
@rossmason <http://bit.ly/tw-ros>

Try iON: integration Platform as a Service http://muleion.com

http://mulesoft.com | http://blogs.mulesoft.org

Post by Daniel Feist
Foreach encapsulates a splitter yes, but I don't think we should expose
the name "splitter" anywhere, want to keep things as simple as possible and
not allow any confusion. Most non-advanced users will see foreach and
splitter as two completely different things.
If i had to give it a more specific name it would be iterableExpression or
listToIterateExpression or something like that consistent with the foreach
concept.
But IMO just expression is fine, I think its fairly obvious that its there
to select what you want to iterate over and especially when accompanied
with documentation.
Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in

expression-transformer element, since the element name already tells you
what's the expression for.

Post by Ken Yagen
I think it's a good idea to call it splitterExpression. The same is done

for idempotent-redelivery-policy, the attribute idExpression is to set the
expression for the id generation. Having attribute names like those makes
mule configuration easier to understand.

Post by Ken Yagen
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Daniel Feist]

Hi Ross,

This example should work as long as xpath-node expression evaluator is used instead of xpath, we haven't tried this though. Also there are currently no elements to add/remove XML attributes/elements declaratively in your configuration file.

The first thing we'll do is attempt to implement this type of use case with foreach, because you are right I'd expect to be able to do the same.

Split-aggregate would be used if I wanted to do something similar but for each item create an object and then aggregate these new objects into a result. Split-aggregate is really the same as using a splitter/aggregator pair, just simpler to understand/use.

Dan

Post by Ross Mason
<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
</item>
<item>
<sku>59677477372722</sku>
</item>
</order-items>
</PO>
I can iterate over each item, but there are many scenarios where I want to enrich the data, ie. to look up product description based on SKU.
<foreach expression="#[xpath:/PO/order-items/item]">
<enricher target="#[variable:description]">
<foo:get-item-description sku="#[xpath:/item/sku]"/>
</enricher>
<mxml:add-element name="description" value="#[variable:description]"/>
</enricher>
</foreach>
<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
<description>A sprocket</description>
</item>
<item>
<sku>59677477372722</sku>
<description>A gromit</description>
</item>
</order-items>
</PO>
You can see a user thinking this should work as a way of doing enrichment using ForEach. I'm not saying this should be possible or not, we just need to see the use cases side by side to order to understand how we give the user the right mental model for working with ForEach.
Also, where does data mapper come into this? If <foo:get-item-description> calls out to a db, this might just be a mapping look up. If this is a web service call, DM doesn't make as much sense.
All the use cases need to be defined up front and then assessed against what we think ForEach, Splitter - Aggregate and DM should be used for. We can't make good decisions considering just a subset of use cases. Bear in mind we don't need to support every use-case we can think of and should be striking out the edge cases (avoid feeding the software monster).
Cheers,
Ross Mason
CTO, Founder
MuleSoft Inc.
@rossmason
Try iON: integration Platform as a Service http://muleion.com
http://mulesoft.com | http://blogs.mulesoft.org
Foreach encapsulates a splitter yes, but I don't think we should expose the name "splitter" anywhere, want to keep things as simple as possible and not allow any confusion. Most non-advanced users will see foreach and splitter as two completely different things.
If i had to give it a more specific name it would be iterableExpression or listToIterateExpression or something like that consistent with the foreach concept.
But IMO just expression is fine, I think its fairly obvious that its there to select what you want to iterate over and especially when accompanied with documentation.
Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in expression-transformer element, since the element name already tells you what's the expression for.
I think it's a good idea to call it splitterExpression. The same is done for idempotent-redelivery-policy, the attribute idExpression is to set the expression for the id generation. Having attribute names like those makes mule configuration easier to understand.
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Santiago Vacas]

We've been thinking a bit how to work out the foreach enrichment use
cases keeping the current logic of continuing the flow with a message
of the same type as the one that arrived to foreach.

The idea is to transform the payload to something that can be mutated,
so for instance if the splitting expression has an xpath evaluator and
the payload is a String, then before performing the splitting the
payload is converted to DOM. This allows operating on the nodes and
reflecting the changes on the original message. The message is
converted to string again when foreach ends.
This makes the following use case feasible:

<foreach expression="#[xpath:/PO/order-items/item]">
<enricher target="#[variable:description]">
<foo:get-item-description sku="#[xpath:./sku]"/>
</enricher>
<mxml:add-element name="description" value="#[variable:description]"/>
</foreach>


as we do not currently have dom manipulation elements we need some
groovy code to have it working,
so the follwing line:

<mxml:add-element name="description" value="#[variable:description]"/>

can be implemented as:

<script:component>
<script:script engine="groovy">
use(groovy.xml.dom.DOMCategory)
{
payload.appendNode('description',
message.getInvocationProperty("description"))
}
</script:script>
</script:component>


Something similiar can be implemented for the JSON enrichment case.

Let me know your thoughts.

Santiago

Post by Daniel Feist
Hi Ross,
This example should work as long as xpath-node expression evaluator is used
instead of xpath, we haven't tried this though.  Also there are currently no
elements to add/remove XML attributes/elements declaratively in your
configuration file.
The first thing we'll do is attempt to implement this type of use case with
foreach, because you are right I'd expect to be able to do the same.
Split-aggregate would be used if I wanted to do something similar but for
each item create an object and then aggregate these new objects into a
result.   Split-aggregate is really  the same as using a splitter/aggregator
pair, just simpler to understand/use.
Dan
Thanks for the demos today guys.  I want o comment on the ForEach and
Split-agregate spec, but comments are not enabled on the wiki (which is
My pushback on ForEach is all around giving the use a clear mental model of
when to use ForEach and when to split -aggregate. The separation is not
clear right now, which makes it hard to say whether ForEach is the right
implementation as it stands. I'm not sure yet if ForEach is suitable for
Since ForEach is ByRef I can't change the outer structure of the message,
but I can still change the inner structure with ForEach, so in theory I can
do enrichment and maintain structure in the message.  I do think this type
<PO>
    <customer>
    .....
    </customer>
    <order-items>
        <item>
             <sku>34934938498934</sku>
        </item>
        <item>
             <sku>59677477372722</sku>
        </item>
     </order-items>
</PO>
I can iterate over each item, but there are many scenarios where I want to
enrich the data, ie. to look up product description based on SKU.
<foreach expression="#[xpath:/PO/order-items/item]">
 <enricher target="#[variable:description]">
       <foo:get-item-description sku="#[xpath:/item/sku]"/>
</enricher>
<mxml:add-element name="description" value="#[variable:description]"/>
   </enricher>
</foreach>
<PO>
    <customer>
    .....
    </customer>
    <order-items>
        <item>
             <sku>34934938498934</sku>
             <description>A sprocket</description>
        </item>
        <item>
             <sku>59677477372722</sku>
             <description>A gromit</description>
        </item>
     </order-items>
</PO>
You can see a user thinking this should work as a way of doing enrichment
using ForEach.  I'm not saying this should be possible or not, we just need
to see the use cases side by side to order to understand how we give the
user the right mental model for working with ForEach.
Also, where does data mapper come into this?
If <foo:get-item-description> calls out to a db, this might just be a
mapping look up.  If this is a web service call, DM doesn't make as much
sense.
All the use cases need to be defined up front and then assessed against what
we think ForEach, Splitter - Aggregate and DM should be used for.  We can't
make good decisions considering just a subset of use cases.  Bear in mind we
don't need to support every use-case we can think of and should be striking
out the edge cases (avoid feeding the software monster).
Cheers,
Ross Mason
CTO, Founder
MuleSoft Inc.
@rossmason
Try iON: integration Platform as a Service http://muleion.com
http://mulesoft.com | http://blogs.mulesoft.org

Post by Daniel Feist
Foreach encapsulates a splitter yes, but I don't think we should expose
the name "splitter" anywhere, want to keep things as simple as possible and
not allow any confusion.  Most non-advanced users will see foreach and
splitter as two completely different things.
If i had to give it a more specific name it would be iterableExpression or
listToIterateExpression or something like that consistent with the foreach
concept.
But IMO just expression is fine, I think its fairly obvious that its there
to select what you want to iterate over and especially when accompanied with
documentation.
Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in
expression-transformer element, since the element name already tells you
what's the expression for.
I think it's a good idea to call it splitterExpression. The same is done
for idempotent-redelivery-policy, the attribute idExpression is to set the
expression for the id generation. Having attribute names like those makes
mule configuration easier to understand.
Pablo.
---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Feist]

Hi Santiago,

Interesting. Can you provide a clear config of how I would enrich an xml document with n orders and what the behavior would be?

What if the message before the foreach is a string and not a DOM document, would the foreach transform it, or would I need to, what would happen if I didn't?

Also, is the enricher really needed in your example? I don't really understand it.

thanks.
Dan

Post by Santiago Vacas
We've been thinking a bit how to work out the foreach enrichment use
cases keeping the current logic of continuing the flow with a message
of the same type as the one that arrived to foreach.
The idea is to transform the payload to something that can be mutated,
so for instance if the splitting expression has an xpath evaluator and
the payload is a String, then before performing the splitting the
payload is converted to DOM. This allows operating on the nodes and
reflecting the changes on the original message. The message is
converted to string again when foreach ends.
<foreach expression="#[xpath:/PO/order-items/item]">
<enricher target="#[variable:description]">
<foo:get-item-description sku="#[xpath:./sku]"/>
</enricher>
<mxml:add-element name="description" value="#[variable:description]"/>
</foreach>
as we do not currently have dom manipulation elements we need some
groovy code to have it working,
<mxml:add-element name="description" value="#[variable:description]"/>
<script:component>
<script:script engine="groovy">
use(groovy.xml.dom.DOMCategory)
{
payload.appendNode('description',
message.getInvocationProperty("description"))
}
</script:script>
</script:component>
Something similiar can be implemented for the JSON enrichment case.
Let me know your thoughts.
Santiago

Post by Daniel Feist
Hi Ross,
This example should work as long as xpath-node expression evaluator is used
instead of xpath, we haven't tried this though. Also there are currently no
elements to add/remove XML attributes/elements declaratively in your
configuration file.
The first thing we'll do is attempt to implement this type of use case with
foreach, because you are right I'd expect to be able to do the same.
Split-aggregate would be used if I wanted to do something similar but for
each item create an object and then aggregate these new objects into a
result. Split-aggregate is really the same as using a splitter/aggregator
pair, just simpler to understand/use.
Dan
Thanks for the demos today guys. I want o comment on the ForEach and
Split-agregate spec, but comments are not enabled on the wiki (which is
My pushback on ForEach is all around giving the use a clear mental model of
when to use ForEach and when to split -aggregate. The separation is not
clear right now, which makes it hard to say whether ForEach is the right
implementation as it stands. I'm not sure yet if ForEach is suitable for
Since ForEach is ByRef I can't change the outer structure of the message,
but I can still change the inner structure with ForEach, so in theory I can
do enrichment and maintain structure in the message. I do think this type
<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
</item>
<item>
<sku>59677477372722</sku>
</item>
</order-items>
</PO>
I can iterate over each item, but there are many scenarios where I want to
enrich the data, ie. to look up product description based on SKU.
<foreach expression="#[xpath:/PO/order-items/item]">
<enricher target="#[variable:description]">
<foo:get-item-description sku="#[xpath:/item/sku]"/>
</enricher>
<mxml:add-element name="description" value="#[variable:description]"/>
</enricher>
</foreach>
<PO>
<customer>
.....
</customer>
<order-items>
<item>
<sku>34934938498934</sku>
<description>A sprocket</description>
</item>
<item>
<sku>59677477372722</sku>
<description>A gromit</description>
</item>
</order-items>
</PO>
You can see a user thinking this should work as a way of doing enrichment
using ForEach. I'm not saying this should be possible or not, we just need
to see the use cases side by side to order to understand how we give the
user the right mental model for working with ForEach.
Also, where does data mapper come into this?
If <foo:get-item-description> calls out to a db, this might just be a
mapping look up. If this is a web service call, DM doesn't make as much
sense.
All the use cases need to be defined up front and then assessed against what
we think ForEach, Splitter - Aggregate and DM should be used for. We can't
make good decisions considering just a subset of use cases. Bear in mind we
don't need to support every use-case we can think of and should be striking
out the edge cases (avoid feeding the software monster).
Cheers,
Ross Mason
CTO, Founder
MuleSoft Inc.
@rossmason
Try iON: integration Platform as a Service http://muleion.com
http://mulesoft.com | http://blogs.mulesoft.org

Post by Daniel Feist
Foreach encapsulates a splitter yes, but I don't think we should expose
the name "splitter" anywhere, want to keep things as simple as possible and
not allow any confusion. Most non-advanced users will see foreach and
splitter as two completely different things.
If i had to give it a more specific name it would be iterableExpression or
listToIterateExpression or something like that consistent with the foreach
concept.
But IMO just expression is fine, I think its fairly obvious that its there
to select what you want to iterate over and especially when accompanied with
documentation.
Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in
expression-transformer element, since the element name already tells you
what's the expression for.
I think it's a good idea to call it splitterExpression. The same is done
for idempotent-redelivery-policy, the attribute idExpression is to set the
expression for the id generation. Having attribute names like those makes
mule configuration easier to understand.
Pablo.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Santiago Vacas]

Post by Daniel Feist
Hi Santiago,
Interesting.  Can you provide a clear config of how I would enrich an xml document with n orders and what the behavior would be?

I'll try to create a more enlightening example.
Suppose we have the following order:

<PO>
<customer>
<name>Tim</name>
<email>tim-***@public.gmane.org</email>
</customer>
<items>
<item>
<price>12.00</price>
<giftwrap>true</giftwrap>
</item>
<item>
<price>25.00</price>
<giftwrap>false</giftwrap>
</item>
</items>
</PO>

And we want to send the items to different endpoints depending on the
giftwrap value and also add a 10% to the price in case it is true:

<foreach expression="#[xpath:/PO/items/item]">
<choice>
<when expression="#[xpath:giftwrap/text()='true']">
<script:component>
<script:script engine="groovy">
use(groovy.xml.dom.DOMCategory)
{

payload.price[0].setValue(payload.price.text().toDouble() * 1.1 + '')
}
</script:script>
</script:component>
<jms:outbound-endpoint queue="giftwrap.queue"
exchange-pattern="one-way"/>
</when>
<otherwise>
<jms:outbound-endpoint queue="regularwrap.queue"
exchange-pattern="one-way"/>
</otherwise>
</choice>
</foreach>


After the foreach we have the updated xml, so we could send an email
to the customer with the updated total price like this:

<message-properties-transformer scope="invocation">
<add-message-property key="email_to" value="#[xpath://email]"/>
</message-properties-transformer>
<smtp:outbound-endpoint host="localhost" from="store-***@public.gmane.org"
to="#[variable:email_to]" subject="Your order details">
<expression-transformer expression="#[string:Dear #[xpath://name],
your order total is #[xpath:sum(//price)].]" />
<email:string-to-email-transformer/>
</smtp:outbound-endpoint>

Post by Daniel Feist
What if the  message before the foreach is a string and not a DOM document, would the foreach transform it, or would I need to, what would happen if I didn't?

The idea is that foreach will automatically transform the message to a
DOM object in case the splitting expression uses xpath evaluator and
the payload is a String, but if it is too much magic we could document
that an xml-to-dom-transformer is required before foreach in case
enrichment is desired.

Post by Daniel Feist
Also, is the enricher really needed in your example?  I don't really understand it.

Current example does not use an enricher, that will depend on the use case.

Post by Daniel Feist
thanks.
Dan

Post by Santiago Vacas
We've been thinking a bit how to work out the foreach enrichment use
cases keeping the current logic of continuing the flow with a message
of the same type as the one that arrived to foreach.
The idea is to transform the payload to something that can be mutated,
so for instance if the splitting expression has an xpath evaluator and
the payload is a String, then before performing the splitting the
payload is converted to DOM. This allows operating on the nodes and
reflecting the changes on the original message. The message is
converted to string again when foreach ends.
 <foreach expression="#[xpath:/PO/order-items/item]">
     <enricher target="#[variable:description]">
         <foo:get-item-description sku="#[xpath:./sku]"/>
     </enricher>
     <mxml:add-element name="description" value="#[variable:description]"/>
 </foreach>
as we do not currently have dom manipulation elements we need some
groovy code to have it working,
   <mxml:add-element name="description" value="#[variable:description]"/>
   <script:component>
     <script:script engine="groovy">
       use(groovy.xml.dom.DOMCategory)
       {
           payload.appendNode('description',
message.getInvocationProperty("description"))
       }
     </script:script>
   </script:component>
Something similiar can be implemented for the JSON enrichment case.
Let me know your thoughts.
Santiago

Post by Daniel Feist
Hi Ross,
This example should work as long as xpath-node expression evaluator is used
instead of xpath, we haven't tried this though.  Also there are currently no
elements to add/remove XML attributes/elements declaratively in your
configuration file.
The first thing we'll do is attempt to implement this type of use case with
foreach, because you are right I'd expect to be able to do the same.
Split-aggregate would be used if I wanted to do something similar but for
each item create an object and then aggregate these new objects into a
result.   Split-aggregate is really  the same as using a splitter/aggregator
pair, just simpler to understand/use.
Dan
Thanks for the demos today guys.  I want o comment on the ForEach and
Split-agregate spec, but comments are not enabled on the wiki (which is
My pushback on ForEach is all around giving the use a clear mental model of
when to use ForEach and when to split -aggregate. The separation is not
clear right now, which makes it hard to say whether ForEach is the right
implementation as it stands. I'm not sure yet if ForEach is suitable for
Since ForEach is ByRef I can't change the outer structure of the message,
but I can still change the inner structure with ForEach, so in theory I can
do enrichment and maintain structure in the message.  I do think this type
<PO>
    <customer>
    .....
    </customer>
    <order-items>
        <item>
             <sku>34934938498934</sku>
        </item>
        <item>
             <sku>59677477372722</sku>
        </item>
     </order-items>
</PO>
I can iterate over each item, but there are many scenarios where I want to
enrich the data, ie. to look up product description based on SKU.
<foreach expression="#[xpath:/PO/order-items/item]">
    <enricher target="#[variable:description]">
       <foo:get-item-description sku="#[xpath:/item/sku]"/>
    </enricher>
    <mxml:add-element name="description" value="#[variable:description]"/>
   </enricher>
</foreach>
<PO>
    <customer>
    .....
    </customer>
    <order-items>
        <item>
             <sku>34934938498934</sku>
             <description>A sprocket</description>
        </item>
        <item>
             <sku>59677477372722</sku>
             <description>A gromit</description>
        </item>
     </order-items>
</PO>
You can see a user thinking this should work as a way of doing enrichment
using ForEach.  I'm not saying this should be possible or not, we just need
to see the use cases side by side to order to understand how we give the
user the right mental model for working with ForEach.
Also, where does data mapper come into this?
If <foo:get-item-description> calls out to a db, this might just be a
mapping look up.  If this is a web service call, DM doesn't make as much
sense.
All the use cases need to be defined up front and then assessed against what
we think ForEach, Splitter - Aggregate and DM should be used for.  We can't
make good decisions considering just a subset of use cases.  Bear in mind we
don't need to support every use-case we can think of and should be striking
out the edge cases (avoid feeding the software monster).
Cheers,
Ross Mason
CTO, Founder
MuleSoft Inc.
@rossmason
Try iON: integration Platform as a Service http://muleion.com
http://mulesoft.com | http://blogs.mulesoft.org

Post by Daniel Feist
Foreach encapsulates a splitter yes, but I don't think we should expose
the name "splitter" anywhere, want to keep things as simple as possible and
not allow any confusion.  Most non-advanced users will see foreach and
splitter as two completely different things.
If i had to give it a more specific name it would be iterableExpression or
listToIterateExpression or something like that consistent with the foreach
concept.
But IMO just expression is fine, I think its fairly obvious that its there
to select what you want to iterate over and especially when accompanied with
documentation.
Dan

Post by Ken Yagen
Santiago,
Attribute name expression makes sense for instance in
expression-transformer element, since the element name already tells you
what's the expression for.
I think it's a good idea to call it splitterExpression. The same is done
for idempotent-redelivery-policy, the attribute idExpression is to set the
expression for the id generation. Having attribute names like those makes
mule configuration easier to understand.
Pablo.
---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
   http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email