- This topic has 13 replies, 1 voice, and was last updated 9 years, 2 months ago by
.
-
Posts
-
-
Hello guys!
I’ve created an orchestration to process a message that will be sent through an As2 channel. I’m also receving an asychcronous MDN of this transaction but with the receiving of the MDN y want to continue processing my orchestration to affect some records.
I’m not sure how I can correlate the ASN with the MDN, I see some option on the receive ports (HTTP) to return correlation handle but I don’t know if this will make my correlation continue.
I’ve an HTTP port to receive the async MDN and I have configured mi orchestration to expect an Any Message on this port.
Also since is an asynchronous MSN I’ve created a send port and a receive port which force me to create a correlation set (i supose that I should use the BTS.MessageId as the correlation definition). Right now I’m receivning the MDN on the receive location but BTS is suspending the message because there’s no subscription.
Do this make sense? am I missing something?
Bests!!
-
I’ve never done any EDI work, but I have used correlation quite a bit. I don’t think the BTS.MessageID will work for correlation because it is different for every message. You need to pick a field that is the same in the outgoing and incoming messages.
-
Yes that was one big mistake. I was looking for the EDIInt.MessageId property but I had to make reference to EDI base artifacts dll to use that property as a correlation ser definition.
The problem right now is that if I use EDIInt.MessageId or EDIInt.OriginalMessageId the orchestration stops working because the message doesn’t have that property (the AS2 properties are attached after the pipeline process the message, I think) so I’m promoting that property using MyMessage(EDIInt.OriginalMessageId) = XXX and MyMessage(EDIInt.MessageId) = XXX
So this forces that my returning MDN has as returning OriginalMessageId = XXX (so basically if my correlation set is set to use the OriginalMessageId and in both messages I have the same then the message should be correlated right?
Also I don’t now if this a problem but I’m receiving the mdn message in my orchestration as a Xlang.Any type (not sure the complete namepspace) becasue I don’t know how MDN should be created. Heres were I get the info (http://killustar.blogspot.com/2008/01/receiving-as2-mdn-in-biztalk.html). Should this be a problem? should I create an schema for the MDN?
Thanks for your time
-
That correlation should work. You can probably get by without an MDN schema. You can use xpath to pull data out of the message without having a schema. If you need to pull out lots of different fields, then it might be advantageous to define a schema with some distinguished fields and use those to extract the data. If you want to validate the MDN, then that would be a reason to have a schema. Otherwise, no schema is fine.
-
I would advise against creating a schema for an MDN. MDN data is not that structured and is likely to vary by VAN and/or trading partner.
Thanks,
-
Thank you for advice.
I’ve tryed with that correlation set but no luck on continuing my orchestration when MDN arrives. Is there a way (through administration or HAT) to know exactly why an orchestration and a message can’t be correlated?
-
The best way I have found to debug correlation is to use the admin console to run a query for all subscriptions. When your orchestration dehydrates to wait for the MDN, it should create an instance subscription based on the values on the correlation set. You can view these values and the exact filter expression using the admin console. When the MDN arrives, it should be suspended due to no subscribers found, and you should be able to check all of the context properties against the subscription.
-
What if my correlation property is suspended on the messagebox and the correlation property is “not promoted”. Is there a way to promote that? I think I need to build a Custom Pipeline component to do that. Am i right?
-
-
Yeap, you were right… you rock man.
Thank you for the idea!!! I had a lot of time without coding for Biztalk solutions and this was getting me crazy.
Thank you again.
-
-
-
-
The 2009 Issue #2 of the BizTalk HotRod has a good article on AS2 that describes correlating MDNs: http://biztalkhotrod.com/Documents/BizTalk_HotRod_Issue6_Q2_2009.pdf.
Thanks,
-
-
-
-
-
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.