BizTalk doesn’t allow multiple maps with the same source schema to be
mapped at the port level and I really want to do this.  Can anyone
help me figure out how to or why I shouldn’t?  Let me explain.

Say I have an Orchestration that communicates several times with a
service (or Database for that matter).  Each request has a different
message type as does each response.  Since I don’t like to let
external dependencies get into my applications I always make (nearly)
matching internal schemas and map at the port anyway.  But this leaves
me still mapping in my Orchestration (to get to my internal format).
I just don’t really like this and when I do it I put these maps in an
Internal Maps project to separate them out from internal to external
maps (I’m picky about dependencies:
http://www.novaenterprisesystems.com/Blog/post/BizTalk-Visual-Studio-...).

Basically I’d like to be able to send a canonical message out from the
Orchestration and be able to drive the mapping on the Operation.  I’ve
thought about using a pipeline for this, but then I need to setup a
place to store these operation-to-map configurations and I need to
execute the map, which seems fraught with danger (lot’s of smart
people spent a lot of time to make it work right, I don’t want to mess
it up).  This just leads to more layers and it keeps getting deeper.
The only easy solution I’ve seen is to use a different port for each
request and then use a map in each, but I don’t like having many ports
that all lead to the same service.

Anyone have any ideas?

Kind Regards,
-Dan

Why does no one answer my posts :(  I spend so much time answers
others.
-Dan

Hi Dan,

I'm afraid it's because you know more than the rest of us.  So if you
can't figure it out, the rest of us have next to no chance.

Bummer!

Peter

'Fraid not, but I am interested.  Seems to me your choice is to
duplicate ports or to duplicate schemas: neither of which is very elegant.

How can your port determine which map to use from amongst the choices?
Is there something in the message context, for example, that can be used
to differentiate?

I always thought that that was why ports behaved in the way you
describe.  If there is a choice of maps, it doesn't know which one to
apply: so it gives a strange message saying that none apply IIRC.

You probably already explained this in your post, and I just failed to
understand what you were saying.

Cheers

Peter

Dan,

The basic idea of using the mappings inside a port is well described
in your post. However I still don't understand your problem very well.

Here is what I understood.
- You want to have multiple mappings inside a port? ok faire enough
- You want that these mappings match the same schema? Why?, I mean if
you were BizTalk, what would you do with the received message? apply
all the mappings? no way, what would be the exit of the receive
location?

According to my experience here is what I used to do:
- Apply mappings to the same receive port (only if the schema of the
received messages is different)
- Many things could be done in the receive pipeline considering that
the schemas are different: you could for instance define in you
receive pipeline all the possibilities of the received schemas: you
could define many XML schemas, as well as many FlatFile Schemas inside
your single recieve pipeline. At the exit of the pipeline, you would
have your correct schema that corresponds to your message, and this
schema could be mapped to any of your predefined mappings, all this
used in a single received port.

Hope I was clear enough

Regards,
Stefan
http://www.itsconsulting.fr
http://www.itsconsulting.fr/blog

Thank you everyone for the feedback, I really do appreciate it.  As
Stefan pointed out the receive side works exactly how I expect (and
love) from BizTalk.  The issue is really on the send side and as Peter
pointed out I seem to either have to duplicate ports or schemas and
neither is very attractive.  Ultimately I’d like to use the BTS
Operation property to drive which map is used.  The only ways I can
see this happening would be Pipeline component or a separate
Orchestration, neither of which appeal very much to me.  I’ll keep
kicking around ideas and keep everyone posted with what I find.

Kind Regards,
-Dan