Serializer Design

In this section, we will design a custom serializer that we will implement in the next section. To this point, we have covered the architecture of the BizTalk channel in which custom functoids, parsers, and serializers have a role. The preceding few sections implemented a custom functoid and custom parser. The test driver for the custom parser accepted non-XML data and input XML data to the channel. In a real application, the XML data would exit the channel and provide input to an application such as an XLANG schedule. In our sample, the resultant XML exited the channel by e-mail or by file. In this section and the next, non-XML data will exit the channel.

A serializer operates generally as follows. It accepts from BizTalk a stream into which to place output. BizTalk hands the serializer a series of documents to be added to the output stream. BizTalk then allows the serializer to impose a grouping on the documents already output. First, BizTalk asks the serializer how many, if any, groups there are. Next, it asks which documents are in which group.

A serializer design requires the following specifications:

• Format of the XML data in the channel

• Format of the data, possibly non-XML, output by the serializer

• Support for grouping

Format of XML Data in the Channel

The format of the data in the channel is already specified with the document definition, definitionBroker_ch18. That format is output by our parser. In our case, the format of the XML data in the channel does not change. In general, however, the XML format can change using a map. The result is that the inbound XML format is not always the outbound format.

Repeated here is an example document output by the parser:

<broker-item> 
   <broker>Alpha Financials</broker>
   <stock>ABC</stock>
   <quantity>10</quantity>
   <min-price>5.00</min-price>
</broker-item>

Format of Data Output by the Serializer

The output of the serializer has no restrictions. In particular, it does not have to be XML. Examples are spreadsheets, PDF files, proprietary binary files, or industry standard specifications such as the message format in the financial protocol FIX.

For simplicity, we will choose a binary format that is easy to confirm, an image. Figure 18.17 shows the image for the XML data shown previously.

The image serves as a visual receipt for the information that entered the channel. It is easy to validate that the information entering the channel made it into the binary format.

The image leaving the channel will arrive by file or e-mail depending on the port configuration chosen earlier.

Support for Grouping

BizTalk does not currently support grouping. However, the API allows for its future use, and we will examine that API in the implementation. For our design, however, we are forced to select no grouping even though we had grouping in the interchanges submitted to the channel.