- This topic has 5 replies, 1 voice, and was last updated 8 years, 4 months ago by
.
-
Posts
-
-
Hi,
Here is my scenario for BTS implementation. I have orchestration O1 which receives a msg from thrid party and dumps that msg in the MsgBox using direct binding. I have another orchestration O2 which picks this msg from MsgBox and does the processing. What i want to acheive is to transform the msg before O2 receives it.
Say Msg1 is received by O1 and dumped in MsgBox now, O2 will receive a Msg of type Msg1 and transform it to Msg2. I want to do this is port itself and dont want to use the transform shape in orchestration.
I am using direct binding in O2 to receive the Msg. How can i acheive this, i know if the port is other then direct binding i can do it through admin console using Inbound Maps, but how can i define map in direct binding port which reads msg from MsgBox.
Thanks
-
“but how can i define map in direct binding port which reads msg from MsgBox” – You can’t unfortunately.
I can see two possible options here:
1. You don’t mention what you need Orch1 to do, so is it possible to remove it, map on the Receive Port and still use Direct Message binding in Orch2 to subscribe to messages?
2. When you publish from Orch1 to the MsgBox, rather than subscribe directly from Orch2, subscribe to the message via a Send Port which pushes the message onto an MSMQT Receive Location, do the map on the Receive Port and publish back to the MsgBox. Once the message is re-published (in the mapped format), subscribe to it via Orch2.
Hope this helps?
Nick.
-
Thanks Nick. Just to confirm if i understand your solution well.
1. You don’t mention what you need Orch1 to do, so is it possible to
remove it, map on the Receive Port and still use Direct Message binding
in Orch2 to subscribe to messages?My Orch1 responsibility is ONLY to pull message(of their type) from third party and dump in MsgBox.What you are saying is, i need to receive Msg1 from the receive port of the third party and transform the msg there itself to my canonical format and then dump that canonical format to MsgBox. So my Orch2 will subscribe to this canonical format and i still can use direct binding. In this scenario i have to transform msg in my receive port itself when receiving Msg from third party. What if, i get transformation error, will i loose the original message which the client send me. I dont want them to be notified with any errors. All i have to do is just receive msg and if I’m transforming and get error i should not loose that original message.
2. When you publish from Orch1 to the MsgBox, rather than subscribe
directly from Orch2, subscribe to the message via a Send Port which
pushes the message onto an MSMQT Receive Location, do the map on the
Receive Port and publish back to the MsgBox. Once the message is
re-published (in the mapped format), subscribe to it via Orch2.You mean to say my Orch1 should not publish the Msg to MsgBox but should send it to MSMQ queue and my another Orch3 will subscribe to this Msg and transform it and dump in MsgBox and from there my Orch2 will subscribe to this canonical msg from MsgBox.
Appreciate your response.
-
To clarify:
Option 1: Receive messages from trading partners in their format (validating and disassembling on the Receive Pipeline) and map on the Receive Port into you canonical format. Subscribe to that Message Type in ‘Orch2’ using direct message binding and have Orch2 do the work it needs to do (so in reality you’d just have one orchestration, even though were calling it Orch2 in this scenario).
I’ve used this approach myself and yes you can receive bad messages from trading partners, however this is normally picked-up in your Xml Validator before passing to the map. Where this happens, the message will be suspended. Save the message locally and amend it, or subscribe to failed messages and push them to some web-app / win-forms app where the Xml can be corrected (or get the trading partner to send you correct data!! 🙂 If you’re concerned about losing messages, I implemented an archiving component that can be used in the Decode Stage of a Receive Pipelineto archive the message to the file-system before any work is performed (if you search CodePlex for BizTalk Archiving Component you should find it).
Option 2: You need to perform a translation (i.e. map) between Orch1 and Orch2, but you don’t have a Receive or Send Port in which to do it because you are doing direct message binding. I therefore suggest that you subscribe to messages coming from Orch1 in a Send Port which pushes the message to an MSMQT queue (which is actually a BizTalk receive location exposed as an MSMQ queue!!); the Receive Port exposing the MSMQT queue can then perform the translation and publish back to the message box (you could alternatively use a standard MSMQ queue so you require a persistent message-store). The translated message can then be subscribed to by Orch2 (in a Direct Binding manner). Its a long winded way to acheive a transformation, but a necessary evil if you don’t want to put a map in either of your orchestrations.
If you can get rid of Orch1 in your original post, I would suggest Option 1 above – its much cleaner and far less complicated to implement IMHO.
Regards, Nick.
-
Thanks Nick – TheOption 1 really worked for me and implemented in same fashion. Now i have another query which resembles some what in the same way. I have an Orch1 which is exposed as webservice to the client. Now Orch1 exposes a msessage(MSG1). How when the client consumes it, he will be sending details in format of MSG1. What i want to acheive is can i have map defined in my receive port and transform MSG1 to MSG2. But still my orch should have a receive shape with MSG1 since i dont want the client to send msg in MSG2 format. How can i acheive this. Can i use receive shape and port to have MSG1 and then use map in port and transform it to MSG2. Can i still receive message of type MSG2 in my orchestration. if not what would be good alternative. Since i need to dump this MSG2 in message box.
-Thanks again for all your help – AK
-
AK,
I would recommend exposing your MSG1 schema as a web-service (see http://iaimtomisbehave.org/2007/12/12/how-to-expose-your-schemas-as-web-services-in-biztalk/) and on the receive port of that web-service use an inbound map to transform MSG1 to MSG2 which is then subscribed to by your orchestration. The response message would need to be transformed back to the MSG1 response message on an outbound map in the receive port (don’t forget your receive port will be solicit-response, not one-way).
So, you’re not exposing the orchestration as a web-service but the schema that represents MSG1.
Hope this helps, Nick.
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.