- This topic has 3 replies, 1 voice, and was last updated 8 years, 3 months ago by
.
-
Posts
-
-
Hey guys,
Does anyone know if there is a way to determine how many items were processed in an interchange without creating a custom pipeline component to "count" all the items in the disassembler's GetNext() method. I had a nice elegant solution planned but while there is a InterchangeSequenceNumber, which is promoted for each message in an interchange, there doesn't seem to be one for the total number of messages published as part of the interchange. For instance, it would be wonderful to have InterchangeMessageCount property. The lack of this property almost seems like an oversight because it would be extremely useful in convoy situations where you don't want to worry about zombies due to "timeouts". Having a property like InterchangeMessageCount would allow you to create a nice loop for receiving all items in an interchange.
With BT2k6's interchange recovery an interchange item count property should probably be named something like "InterchangeMessagesPublished", to be clear as to what it represents.
I highly doubt there is an interchange message count available, but if there is, I would love to know about it.
Thanks in advance,
Joel
-
Joel,
I'm not aware of any such property, at least that I can remember. My guess is that it's not there because that would mean the disassembler would need to hold on to all generated messages from the debatching until it read them all before it could return them (i.e. it would need to break the entire message and read it all the way though before returning a single message from GetNext()), which would completely hose up the streaming [goodness] nature of the debatching process.
-
But would it really? It has been awhile since I've cracked open Reflector to look at the XmlDasmComp class but aren't message streams wrapped in XmlDasmStreamWrapper classes? From what I recall from previous experiences, BizTalk doesn't read the message stream, promote properties, and do validation (if enabled), until the XmlDasmStreamWrapper instance is read. At least this is what we experienced when creating a derived FFDasmComp class that counted messages in GetNext(). I think the default implementations of GetNext() just return these stream wrappers; obviously there must be some reading done to parse out items from an envelope / flat-file header/trailer combo etc, but I think each individual item is wrapped and unread until the wrapper stream is drained (by the message box or a component in the Validate stage.)
Does that sound right?
I guess for now I'll just stick to creating an "enhanced" XmlDasmComp class.
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.