Running the EAIProcess
The EAIProcess
orchestration can be started by binding the logical RequestPort port to a
physical port configured to receive files from a folder. Once the
project is built and deployed, ensure that there is a subscriber (send
port) built for the Fault message and that it is enlisted and stopped;
otherwise a persistence exception will be reported. Post a sample file
into the folder being monitored, execute the orchestration, and generate
the exception, thereby publishing the Fault message. You can inspect
the properties of the generated Fault message using the BizTalk Server
2006 Administration Console as displayed in Figure 6.
Each message added to the
Fault message in the exception handler gets persisted as dynamic message
parts to the original Fault message. The Message Details dialog box
illustrates some of the niceties resulting from the use of the Failed
Orchestration Routing API. First, the message published from the
exception handler is still defined as the Fault message derived from
your FaultMessage.xsd schema as shown by the message type context
property. However, notice two additional message parts listed in the
left-hand pane. In the EAIProcess orchestration, the FaultMsg
message variable was set to a multipart message type of one part, body.
The API dynamically adds the individual messages as message parts to
the current Fault message.
If you examine the context properties of the Fault message (as shown in Figure 7),
you can see all of the fault properties you set in the Message
Assignment shape, as well as some that the API sets for you (i.e., ServiceName and ServiceInstanceID).
Figures 8, 9, and 10 show the Message Details dialog box displaying the content of the original ApprovedRequest and DeniedRequest messages.
