 Forum main
page
Most
active member
Login page
Register
Log out
Search page
Information Online
View our event calendar
Add general event such as an upcoming
software release or conference
View all birthdays
Public image gallery
Upload your images in your profile
Profile editing page
Subscription list page
Address book page
Member list page
View the
most active member
User groups listing
Private message page
|
|
Users viewing this topic: none
|
|
Login  | |
|
Finding last iteration of repeating block - 18 January 2008
|
|
|
Nick
Posts: 2
Score: 0
Joined: 18 January 2008
Status: offline
|
I have a similar if not the exact same problem that occurred in another post here
http://secure.topxml.com/BizTalk/rn-209897_Record-count-for-inner-loop-in-schema.aspx
I have just started getting into Biztalk Mapping so have only had basic experience with organizing functoids and working with pre-existing custom scripts. I’m trying to update an old 2004 Biztalk project. Similar to the post above, I receive a source message that looks like this; with the <member> having several sub elements.
<MyNode>
<record>
<header>
<member1>
<member2>
</record>
<record>
<header>
<member1>
<member2>
<member3>
</record>
<MyNode>
Previously, each record only received one member and we mapped individual sub elements from that ‘member’ to our destination (we did not copy the entire member block). However recently I started receiving multiple ‘members’ in each record which our current map doesn’t handle properly. I do not have the ability to change the source or destination schemas in the map because they come from other sources, so I must make a mapping change.
We determined that we only want to grab elements out of the last member in each record, regardless of how many members there are in each record (at least one with no known maximum), and use those elements to continue mapping as we always have.
If this were a perfect world I would simply find all of the current spots where it maps elements from that member to the destination; and then add functoid logic that says only map those elements when the member = last iteration.
However it dosent look like it will be all that easy. I’ve read that Record Count returns the number of members in the entire message as appose to all of the members in a specific record. The post I originally referenced only solved the problem because they could rely on receiving a specific message format which we do not have the luxury of, otherwise I've heard other solutions would possibly involve custom xslt or setting up global variables out side the map which I am not familiar with. I was surprised there wasn’t more control or information on finding specific iterations elsewhere.
I would appreciate any help or advice on this issue. Let me know if there is something I could explain better.
|
|
|
|
|
RE: Finding last iteration of repeating block - 25 January 2008
|
|
|
Nick
Posts: 2
Score: 0
Joined: 18 January 2008
Status: offline
|
I've been looking at this problem with a few other people and it does not look good.
First, it seems that Record Count will just not scope as expected. It will not return the number of 'member's in a specific 'record', only the number of 'members' in the whole message. There are still some people on other forums who believe that record count should scope, if you set looping pointing from the parent of the initial repeating block ('record') but I have never seen it behave this way. It doesn’t help that we aren't passing the entire block of 'member' data, we are merely picking individual elements out of it and putting them into the destination schema in scattered places.
I was able to generate a xslt template script that could grab the correct data from the last leg in each record. This would work if we were just mapping the individual sub elements of 'member' directly to the destination schema; however the matter is further complicated in that I am trying to update an existing map where all of these sub elements first go through other Inline VB and mapping method script logic before they are mapped to the destination. The xslt template script that can generate a destination node is not capable of generating the data into a format that could be seamlessly input into the existing script logic. As a consequence, I would most likely have to completely rewrite the other script logic for all of the 20 elements into each of the xslt scripts, if that is even possible. (At which point, why are we even using a map if everything is going to be hardcoded)
The bottom line is that it looks like Biztalk simply dose not support managing nested repeating blocks of data. At least in so far as finding a specific block when the format is inconsistent (max unbounded).
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
 Locked w/ New Messages |
 Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts
|
|
|
Printable Version
Email TopXML