OK... it can be done by adding all of the items to a list first. This is OK except for the fact that, if the source had a lot more fields, you would soon be adding many, many fields to the list and any hierarchy would be difficult to reconstruct
from the list.
Here's what the successful map looks like:
Marked As Answer byRob HenwoodThursday, April 26, 2012 9:26 AM
I still don't think this is optimal and I have to jump through too many hoops to get a simple operation done. I still think that, despite the new mapper being able to do the work as shown above, it could be made simpler somehow.
Thinking about other ways and technologies:
In XSLT you could select /Drivers/* in a foreach to get any node under drivers. Then you could get the sequential index using a position() function. That's quick and easy. If you use XSLT though, you don't need the mapper, and that's what a lot of advanced
BizTalk devlopers do. As soon as you don't need the mapper, some people start to question the whole platform and why they're spending so much on it - believe me, they do!
In the BizTalk map to solve this problem, the mapping was done in 2 stages:
1. The first to ordered everything in the correct sequence using mass copy to copy all of the sub nodes across. This created a sequential drivers structure. The map became a shared map to solve this kind of problem that appeared in about 30% of the integration
2. The second map was then able to get the position of the sequential drivers so that sequential ids could be generated.
In the new mapper, stage 1 would be harder because there is no mass copy.
I think that the new mapper would benefit from being able to generate a sequential id. Since the new mapper is no longer based on XSLT, it must be easier to hold state and decide how many Driver nodes, for example, have been generated.
Another solution would be to allow the MapEach to be scoped on more than one node, but that would be harder, I suspect.
Lastly, mass copy needs to be reintroduced too.
XAML vs XLST
I fear that, because MSFT have started again, creating their own mapping technology around XAML, that they may miss some of the features that allowed XSLT to become so prevalent and useful. Don't get me wrong though, the new mapper feels better than
the BizTalk mapper but it does have a way to go to become a compelling offering and ensure that developer productivity is very high.
Thanks for the screenshot of your map. I do think it seems pretty complicated for what you are actually accomplishing.
Personally, I would look at the new mapper and think it would be nice if we could use a LINQ to Xml query to build that list and then loop on the results of that. Some of the same synergies with XSLT you get with LINQ to Xml, and both are absent currently
from the new mapper.
If this answers your question, please use the "Answer" button to say so | Ben Cline
The list solution is a workaround, we had started thinking about supporting a sequential id generation functoid, which will solve this problem cleanly. Also since we will be providing
a scripting functoid, this problem can be solved using that as well.