Flat-file Support In One-Way Bridge


Updated: November 27, 2015

Flat file message transfer is a key requirement in BizTalk Services scenarios. Many enterprise applications receive flat file messages from client applications, such as SAP IDOCs. To enable flat-file processing over the cloud, you can use bridges available as part of BizTalk Services .

The following table lists the flat-file processing features available with BizTalk Services:

What’s In

What’s Not

Receive flat-file messages. You can configure a bridge to receive flat-file messages either over HTTP or FTP.

Support for XML Request-Reply Bridge. You cannot configure an XML Request-Reply Bridge to process flat file messages. You cannot have an XML Request-Reply Bridge sending flat file messages to the message receiving entity or back to the client that sent the original flat file message.

Sending out flat-file messages. You can configure a bridge to send out flat-file messages, which makes the following scenarios possible:

  • Flat file in, Flat file out

  • Flat file in, XML out

  • XML in, Flat file out

  • XML in, XML out

Support for XML One-Way Bridge. You can configure a XML One-Way Bridge to receive and send flat-file messages.

Support for receiving messages of different flat-file schemas using the same bridge. You can configure a XML One-Way Bridge bridge to receive flat-file messages of more than one schema.

Support for receiving flat-file and XML messages using the same bridge. You can configure the same XML One-Way Bridge to receive both flat-file messages as well as XML messages.

With the flat-file support, an XML One-Way Bridge can process both flat-file and XML messages at the same endpoint. So, you don’t need to configure and deploy two separate bridges on the Service Bus to process different message types; a single bridge does both for you.

While receiving a message, the bridge detects the message format (flat file or XML) based on the content-type HTTP header. This header is mandatory for all incoming messages to be processed by the bridge. If the header is not present, it results in a runtime error. If the message is coming over HTTP, the content-type is set by default. If the message is coming over FTP, this header is set by the FTP source entity that posts data to the bridge endpoint.


You can configure an FTP source entity on the Bridge Configuration surface that defines the FTP location from where the message is picked. For more information, see Add a Message Source to the Bridge.

Bridges support the following message types:

  • Application/xml

  • Application/soap+xml

  • Text/xml

  • Text/plain

Of these, the content-type “text/plain” maps to flat file messages. To process text/plain messages, a bridge includes a ‘Decode’ stage that is the first stage in the bridge before the Validate, Enrich, Transform, and Enrich (post-Transform) stages.

  • If a bridge receives a message of ‘text/plain’ content type, the decode stage decodes the message and converts it to an XML message. Rest of the processing at each stage within the bridge happens on the XML message and not the flat file message.

  • If a message with the any of the other content types is received by the bridge, the decode stage is not activated and no flat-file decoding happens. The incoming message is then passed over to the other stages, where it is processed based on the stage configuration.

While sending out messages from a bridge, you can configure a bridge to send out flat-file messages using the Flat File Encode activity within the Encode stage. If you enable the stage, the bridge can send out flat-file messages and XML messages. If you disable the stage, the bridge only sends out XML messages. As mentioned earlier, even if a flat-file message is received by the bridge, it gets converted to XML message at the decode stage and is then processed as an XML message by the other stages of a bridge. Once the XML message reaches the Encode stage, the message type of the XML message is matched with the schema specified as part of the Flat File Encode activity. If a match occurs, the schema is used to convert the XML message to a flat-file message. The content-type for such messages is set to “text/plain”. If no match is found, the XML message is sent out of the bridge as-is. For more information, see Configure the Encode stage.

For XML messages, bridges support processing messages of more than one message type using the same bridge endpoint. They do so by identifying a message using the message type, which is a combination of the target namespace and the schema root node name, for example http://IntegrationServices.Schema#RootNode. The same cannot be true for flat file messages because there is no target namespace. So, to provide the ability to process flat-file messages of more than one type at the same bridge endpoint, bridges use the concept of ‘tags’. Following are some considerations with respect to tags:

  • All flat-file schemas should have tags defined as part of schema definition.

  • At most, there can be only one flat-file schema that does not have an associated tag with it. If you add more than one untagged schema, it results in a build error.

When a flat-file message is received by the bridge, it matches the tag in the incoming message with the tags in all the flat-file schemas, in the order in which they were added to the bridge configuration. If a match happens, that schema is used to validate the incoming message. The only exception to this rule is that if there is one schema without a tag, it is evaluated at the end.


You can have schemas that have tags defined both at the root level as well as the child record level. For schema validation, only the tags at the root level are considered.

For more information on flat-file messages, refer to Structure of a Flat File Message.