@lex at Siebel Essentials has a great article on Named Subsystems so I won't repeat what he said best.
However there are few things that will still cause to you pull your hair out: Advanced parameters - these aren't visible in the UI and can only be managed using the command line tool. Get to know srvrmgr.exe it is your friend - really.
- To work effectively with the tool, make sure you spool out the results and then use an external editor to view the query results. I use BareTail as it automatically scrolls. One can also limit the columns that are emitted, but that requires remembering each column specifically and then adding those to the command when executing.
list advanced parameters for named subsystem MSMQReceiver
- If using a dispatch ruleset (highly recommended), this is where you set the name of the ruleset
change parameter RollbackOnDispatchError=False for named subsystem MSMQDataSubsys
- Xml Converter service - when working with the dispatch service ensure that the ConverterService parameter is set to "EAI XML Converter"
change parameter ConverterService="EAI XML Converter" for named subsystem MSMQDataSubsysOnce your Subsystems are configured you can create (or modify the existing) background component to use these subsystems:
- "Receiver Data Handling Subsyst" parameter
- "Receiver Connection Subsystem parameter
I used ReceiveDispatch as I wanted to use a rules based routing approach (the workflow process/BS is specified in the rule) with a separate return path. One can also specify ReceiveDispatchSend to use same connection parameters for a response.