Отвечая на мой собственный вопрос ... короче говоря, ключ в том, чтобы изменить контекст исходного сообщения и продвинуть свойство контекста MessageType.В следующих параграфах я воспроизвожу предстоящий пост на моем блоге :
Служба маршрутизации оркестровки 101
После попыток заставить это работать и попытокразличные решения, мне наконец удалось с набором простых правил для подражания.В этой статье я хотел бы обрисовать, что представляет собой хорошо организованную оркестровку ESB Toolkit 2.0, которая может использоваться в качестве службы маршрутов и в то же время использовать Resolver Business Rules Engine для динамического преобразования, основанного на типе контекста сообщения..
Контекстная подписка для маршрутной службы
Во-первых, оркестрация, предназначенная для использования в качестве маршрутной службы, должна иметь логический порт с прямой связью, связанный сполучить форму, которая определяет ESB-дружественную подписку, например, так:
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceName == "MyCustomItineraryService" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceState == "Pending" And
Microsoft.Practices.ESB.Itinerary.Schemas.ServiceType == "Orchestration"
Документация не упоминает об этом, но это дает понять, что операции порта с прямой связью должны быть сопоставлены с сообщениями типа System.Xml.XmlDocument.Действительно, если это не так, оркестровка не будет выполнена, и сообщение об ошибке Routing Failure будет зарегистрировано в Message Box .
Кстати,это означает, что сам тип сообщения вообще не учитывается.И это во многом объясняет, почему после выполнения оркестровки распознаватель Business Rules Engine не может определить правильное преобразование.
Начало маршрута
Следующий код вФорма выражения в начале оркестровки помогает получить текущий шаг маршрута:
// Retrieve the current itinerary step.
itinerary.Itinerary = Microsoft.Practices.ESB.Itinerary.ItineraryOMFactory.Create(InboundMessage);
itineraryStep.ItineraryStep = itinerary.Itinerary.GetItineraryStep(InboundMessage);
Сохранение контекста исходного сообщения
Далее контекст контекстаИсходное сообщение должно быть сохранено (по большей части) на каждом этапе оркестровки.Это особенно важно, когда в оркестрации есть несколько промежуточных конструктивных форм для выполнения конкретного сценария под рукой.
OutboundMessage(*) = SourceMessage(*)
Обратите внимание, что я написал «по большей части» в предложении выше.Фактически, как мы увидим через минуту, тип получающегося сообщения должен присутствовать в контексте в конце оркестровки.Скорее всего, это будет другой тип , чем исходное входящее сообщение.И поскольку присвоение только для чтения BTS.MessageType невозможно, иногда это может быть довольно сложно достичь.
Возможно, вам придется прибегнуть к выполнению пользовательского конвейера внутри оркестровкиили другие экзотические методы для этого.Однако в большинстве случаев приведенный выше синтаксис должен работать.
Продвижение маршрута
Следующий очень простой код не должен быть забыт в конце оркестровки:
itinerary.Itinerary.Advance(OutboundMessage, itineraryStep.ItineraryStep);
Повышение свойств контекста
Документация не дает четкого объяснения, какие именно шаги должны быть выполнены, или даже если свойстванеобходимо повышать от такой оркестровки, но, взглянув на примеры, представленные в качестве исходного кода, можно обнаружить, что в механизме разрешения участвуют следующие свойства:
Повышение свойств http://public.blu.livefilestore.com/y1pLURN1zH2vdRuLcF5yyAiHZQQ9rkdlrqG-QH01Nn8hEY5zH1W9TjjtNc0Z9421eFC2gUVG-srs2-NdcliI3XD1w/orchestration_service_promoting_properties.png?psid=1
Однако в сценарии, описанном в этом посте, этого явно недостаточно.
Чтобы контекстно-зависимые правила работали после оркестрации, необходимо также повысить свойство BTS.MessageType.Это может быть легко достигнуто путем инициализации корреляции формы отправки в конце оркестровки.
Корреляция типов сообщений http://public.blu.livefilestore.com/y1pQb-dkmbNBcur7CwdyudiIE9EMKGnZ0LoGuFpfDLseAWsiUz9C1EC1ZR5pn0gI4tgr3syEN2y-cfPB9EgEzlgtA/message_type_correlation.png?psid=1
И это работает!
Повышение типа сообщения в контексте полученного сообщения было тем, чего не хватало в моей первоначальной попытке.Как только это было определено, маршрут работал как очарование!
Правило ведения журнала http://public.blu.livefilestore.com/y1pGVViJM7SFbopcnYODHkqGUbkgS1RQR8a7ASVsNVDu8Krdhb_Vyj4PugbMPSFcfMEZ1P_3a7It0QQpXdF_dnvDg/rule_firing_log.png?psid=1
Хотя решение может показаться очевидным после факта, оно наверняка помогло бы мне, если бы я знал это раньше. Я надеюсь, что этот пост поможет тем, кто сталкивается с той же проблемой.