Try passing the path and its value as a query parameter. Their documentation suggests this should work:
Thanks, that approach makes more sense now.
As far as locking goes there isn’t anything in the product that would function like you were thinking at this point.
What Naveen mentioned is right. Is there any way to possibly preprocess the data so that you’d only have one instance of a place across your incoming documents (could be dangerous, if the one with the data fails)?
I’m not sure how your SOAP endpoint functions, are you just publishing flat employee records in one soap call or are you making multiple soap calls per incoming document to write pieces of the employee record to different places?
Is there any danger from your side having the duplicate data overwrite for your application?
Thanks, in our case, we have to make multiple soap calls per incoming document. There’s no other choice to do that.
But anyway. I somehow organize the data a little bit, removed the duplicate location from the data.
Now I am able to leverage the pool size of Pipeline Execute without worrying about the race condition.
Thanks again
I think I was not clear.
Basically, I would need to Union to happen with adding a separation of level between the 2 elements unioned.
Such as:
{
field1: val1
field2: val2
}
Union to
{
content: val
}
Is generating the result as:
{
{field1: val1
field2: val2
}
{content:val}
}
So I could refer to the first part with $.1 independantly from $.2
Does this make more sense?
Thanks,
Hi Eric,
Might below pipeline help you what you are trying to achieve.
testJoin_2019_04_10 (1).slp (8.3 KB)
Regards,
Ajay
Hi Ajay,
Thanks for your idea. However, this join is extending the size of the row with 2 more fields, whereas I would not like to add them carried over all the 1st generator data, as this will repeat and is useless.
The idea is more to go with Union but to separate isolated data from 1st generator and 2nd.
