Using Dynamic Transformations

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The ESB Guidance supports three mechanisms for dynamic transformation:

  • A dynamic transformation agent implemented as an orchestration
  • A dynamic transformation Web service included with the core Web services
  • A transformation executed by ESB pipeline components

This section of the documentation focuses on the transformation agent. For a description of the transformation Web service, see Using the ESB Guidance Web Services. For a description of the ESB Dispatcher pipeline components, see Using the Pipeline Support Components.

The transformation delivery agent is an orchestration that subscribes to messages where the Name attribute of the current ServiceInstance element in the itinerary is "Microsoft.Practices.ESB.Services.Transform". The agent performs the following sequence of operations:

  1. It receives an un-typed message (System.Xml.XmlDocument).
  2. If the name of the map is available as a static value in the itinerary, it attempts to resolve the name of the map using the resolver manager.
  3. It applies the appropriate map to the inbound source message.
  4. It publishes the map output to the BizTalk Message Box database.

The ESB dynamic transformation mechanism will create and publish an ESB fault message in the following cases:

  • The resolver component cannot determine which map to apply.
  • The specified map is not available (for example, you specified an incorrect map type or a map not yet deployed within BizTalk).
  • A failure occurs during mapping (for example, the source document is not of the correct source type or the map references a custom functoid in an external assembly not deployed to BizTalk).
  • An exception occurs during JIT resolution of the map type.
  • No subscriber exists for the output message.
  • Any system exception occurs.

It is the developer’s responsibility to provide the context information used to populate the exception messages and create handlers to react to the exception. Some of the data is automatically available, and a generic handler will pick up the exception message if no target handler is specified or available. For more information, see ESB Exception Management.