Flat-file Support In One-Way Bridge
Important
Microsoft Azure BizTalk Services (MABS) is being retired, and replaced with Azure Logic Apps. If you currently use MABS, then Move from BizTalk Services to Logic Appsprovides some guidance on moving your integration solutions to Logic Apps.
If you're brand new to Logic Apps, then we suggest getting started here:
-
Create your first logic app, or quickly get started using a pre-built template
-
View all the available connectors you can use in your logic apps
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 .
Flat File Support: What’s In and What’s Not?
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:
|
|
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. |
How Does an XML One-Way Bridge Handle Flat File 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.
Receiving Flat-file Messages
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.
Note
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.
Sending Out Flat-file Messages
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.
Processing Multiple Flat Files Using a Single XML One-Way Bridge
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 https://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.
Important
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.
More Information about Flat File Messages
For more information on flat-file messages, refer to Structure of a Flat File Message.