- This topic has 5 replies, 1 voice, and was last updated 6 years, 11 months ago by
.
-
Posts
-
-
Hello,
My solution is broken up into different phases. I was trying to build 1 orchestrtion per phase. Problem is 1 of the phases has 2 different schemas. I wanted to know if there is a way to have an orchestration receive 2 different message types. Either one would start the orchestration and follow a different logical path to completion. Is this possible?
I have read about parallel convoy, but that sounded like all message types needed to be received before processing can continue, thats not what my scenario calls for.
I also read about receiving untyped messages (xml document) then I could branch on a distinguished propery & do what i needed, but unsure if that is good design or not.
I’m kinda looking to split the orchestration down the middle, having the orchestration subscribe to both of my message types. I can just build another orchestration, but I’m just trying to simplify the project by having 1 orch fo each phase.
Any info is greatly appreciated!
-
This is exactly what i was looking for. Thank you!
I still have a problem though, the left branch works fine, but the right branch gets dehydrated and never completes. Any ideas what I am doing wrong? I tried a few different configurations to no avail.
You mention…
[quote:2f86586f50]Both receives will need to subscribe to the same port, butr you can multiple receive locations.[/quote:2f86586f50]This may be where I’m going wrong. We were planning on having all messages come in to the same file location.
-
All files will be comming into an FTP location, I am under the impression we can identitfy them by either part of the file name or the targetnamespace in the xml file. I may have to wait until unit testing with the client to make sure that is the case. The specs are a tad vaigue 🙁
Also wanted to validate the schemas in a pipeline so I thought I may need different locations for each schema comming in. If that ends up being the case I will have to ask for that, unless i can pull tricks in the pipeline, or we end up not validating the schemas. Our schemas were built to lose so even if they validate ok we could still end up with issues inseting the data into the db:( I didnt have control over the schema creation & it is our first time doing this so we will surely learn from our mistakes for next time.
Good info though thanks.
As for the orchestration, I’m not sure why it is dehydrating with schema 2 (the right branch of the orch), both workflows are doing the same, schema in, map to updategram, get response back from sql adapter and send it to an folder. When i went into the orchestration debugger it looked like the schema 2 was recived by the wrong receive shape (the left side) and it kept retrying and retrying and retrying, never left the receive shape. Then eventially dehydrated i guess. I better double check all my properties on everything again. My branches never merge back together. I also noticed I was using default passthrough for the receivehandler, instead of xmlreceive. Think that has anything to do with it?
I’ll recheck everything again & then try to narrow things down with the debugger. Thanks for your response.
-
Errrr – you dont even want to know.
I wasnt restarting the host instance 🙁I’ll never ignore that warning again in my life!
Thanks once again Greg for pointing me in the right direction, I really appreciate it!
-
Use a listen shape, with two receive shapes, one for each message. Both receives will need to subscribe to the same port, butr you can multiple receive locations.
-
Different receive locations may be required if you need different pipelines or even different adapters. If you can receive and identify the different message types with one receive location, then there is no problem with that.
If you are able to initiate the orchestration with two different message types, then that should be the forst problem solved.
The listen shape will follow the path of which ever message was received. The other path will be ignored.
An orchestration being dehydrated just means it is waiting for something.
What is happening after the activate receive on the path that results in the orchestration dehydrating
-
-
-
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.