- Content based routing by using parties and role links. In some cases the recipient is specified by for example vendor-ID, so that has been used as a key to create the correct party. This doesn’t necessarily require any specific envelope-structures for holding the context properties. Also new recipients can be added very easily, specially if common business document structures are used. Also quite simple to implement, when the business case itself is not very complicated.

- Parametrized routing, the parameters for the recipient is stored in parameters, and could be based on several rules on how to act. This uses Orchestrations to call the routing rules from the storage. This can also hold some business logic, for example certain set of messages go to one recipient, and another set for another through the same processing.

- Loose coupled Routing, where each party publishes it’s message to messagebox with envelope that contains the identification of the data inside of it and the business process. The recipients then subscribe with this information. This supports both many-to-one and one-to-many-cases, but only with asynchronic messaging as it is implemented currently. Same thing could be done to some degree with port groups, but those are not an option when more complicated logic is required, and the receiving systems work very differently. The recipient orchestration can’t change source on the fly though, so routing based on a rule set is more appropriate on some occasions.

- Similar approach as with Patrick: Separate layers for each of the systems, that handles the system-wise processing logic and structures, and separate functions for routing (with a routing rule storage). Subscription is made based on the recipient system claimed by the routing function. This can adapt very well for changing environment when there are several backend systems, that work in a different way based on the message-type, and new client systems are implemented in a regular manner. The downside of this is the need for orchestrations, and therefore this is not the best solution performance-wise.

I agree with Patrick with the use of the Biztalk Properties. In most cases there will be separate people running the environment, so it is easier to transfer the solution to production when there is no hidden logic, and the message itself carries the relevant information with it.

The business Service posts messages to the messagebox, The SIS gets the message from the messagebox and post it to the endpoint. Then the SIS will post a response back to the messagebox, The Business Service is still listening for this response. After the BS has received the Response back it will inform the caller.

So the SIS is subscribed to specific messages (typed) and some predefined context properties.

And the BS does some correlation.

But we don’t have to worry about those, we have a software factory set up that generates all those things, so indeed there is a lot of routing going on, but you don’t have to worry as a programmer.

Furtermore.. the routing proeprties are always the same. We have a custom envelope with th e following fields.

SourceService
DestinationService
DestinationOperation
ConversationID

So we don’t use all those obscure BizTalk properties (exept from messagetype) but everything is done in understandable properties, where is it coming from and where should it go to….

I guess the only thing one the downside is that you still will have a lot of routing information in the form of filters spread a round on different send ports – right?

I will explain..

We have three kinds of services

1. RIS ( Rreceiving Integration Service) takes care of mapping from external systems to CDM)
2. BS (Business Service) Is a Callable orchestration that exposes the CDM on the bus.
3. SIS ( Sending Integration Service ) takes care of Mapping CDM to External Systems

Then we can have Several systems delivering invoices and each can have their own format.
For each system we create a RIS that takes care of transformation to the CDM. Then we simply call the BS.

The BS will do some validation (remember it was a callable orchestration called by the RIS) and if everything is fine it will post the message to the messagebox

A SIS is listening on the messagebox and will deliver the message to the endpoint.

For sure you will have to standardise on a default Routing Slip ( Read context property schema )

But by doing it this way you get all the benefits of Broker Based Integration with the versioning problem solved. ( A RIS calls a specific version of a BS)