Biztalk Schema Interview Questions And Answers

The schema is basically a contract of your message and defines it. The XML Schema definition (XSD) language defines the structure of an XML instance message, and this is the intended purpose of XSD, such schemas use XSD in a straightforward way.

A schema is a term borrowed from the database world to describe the structure of data in relational tables. In the context of XML, a schema describes a model for a whole class of documents.

Target Namespace is to schema what a namespace is to .Net Object and root node as a class name.

Use the BlockDefault property to prevent or restrict the types of derivations that can be used in instance messages for all data types defined by the schema being edited.

Each message in BizTalk Server is considered a multi-part message and is made up of zero or more parts. Each message with one or more parts has one of these parts identified as the body part. Each part consists of a binary chunk of data which can represent an XML document, a flat file, a serialized .NET class, or other binary stream of data. You use the body part of the message to identify the type of the message that can be used for routing.

No. To promote XML record its ContentType property should be set SimpleContent.

By default, BizTalk Server will examine only the namespace and the root node name of a message to identify and validate the schema, and will not detect extra elements in the message body. To perform a deep validation of a message format, you have to create a Custom Pipeline with the XML Disassembler component.

☛ XSD are written in XML.
☛ XSD support data types.
☛ XSD support namespaces.
☛ XSD is extensible to future additions.
☛ XSD is richer and more powerful than DTDs.

Specifies the minimum number of times that the underlying group content of the selected All Group node can occur.

Specifies the minimum number of times that the element corresponding to the selected Record node can occur.

Specifies the maximum number of times that to the underlying group content of the selected All Group node can occur.

Specifies the maximum number of times that the element corresponding to the selected Record node can occur.

BizTalk Server architecture is asynchronous for scalability reasons. However, the architecture of the BizTalk Messaging Engine enables exposing a synchronous message exchange pattern on top of these asynchronous exchanges. To do this, the engine handles the complex task of correlating the request and response messages across a scaled-out architecture by linking together a number of asynchronous message exchanges to expose a synchronous interface.

It can be of any length, no limits.

Custom Date/time property is only available for flat file schema.

A canonical schema is a design pattern, which is applied within a service oriented paradigm, and within BizTalk server context establish the loose coupling between systems. Through performing the transformation of messages from one system to canonical schema and from the canonical schema to message of another system, systems have no direct relation with each other. The canonical schema can also be viewed as an internal schema in BizTalk and aid you in structuring your solution through best practice of creating separate projects for maps, orchestrations, internal and external schemas. Another advantage of using a canonical schema is that it reduces the number of transformations you need. If you need a to map a few types of inbound message coming from different parties to a few outbound messages, you can create a map to your canonical schema for each inbound schema and then a map from your canonical schema to each outbound schema. If for example you have three types of incoming that needs to be mapped to three types of outgoing messages you will only need to build and maintain six maps instead of nine.

Yes, a schema (XSD) can have multiple root nodes. In case you have a schema with multiple root nodes you will end up with multiple message types declared in BizTalk, one for every root node. So when you want to create a message you will need to specify exactly which message type you are going to use!

An envelope schema is a special type of XML schema. Envelope schemas are used to define the structure of XML envelopes, which are used to wrap one or more XML business documents into a single XML instance message. When you define an XML schema to be an envelope schema, a couple of additional property settings are required, depending on such factors as whether there is more than one root record defined in the envelope schema.

xs:string

Yes, we can have a schema without target namespace and it's message type will be the Root node.

255 characters

Yes. http://schemas.microsoft.com/BizTalk/2003 and http://www.w3.org/2001/XMLSchema are added by BizTalk when creating a schema.

When a message is received, or else when a timeout has expired, the orchestration engine can be automatically triggered to rehydrate the instance – it is at this point that the orchestration engine loads the saved instance of the orchestration into memory, restores the state, and runs it’s from the point it left off.

It follows full ACID properties Atomicity, Consistency, Isolation and Durability. If you require full ACID properties on the data for example, when the data must be isolated from other transactions. You must use atomic transactions exclusively. When an atomic transaction fails, all states are reset as if the orchestration instance never entered the scope.

When an orchestration has been idle for a while, the orchestration engine will save the state information of the instance and free up memory resources.

A flat file schema defines the structure of a class of instance messages that use a flat file format, either delimited or positional or some combination thereof. Because the native semantic capabilities of XSD do not accommodate all of the requirements for defining the structure of flat file instance messages—such as the various types of delimiters that might be used for different records and fields within the flat file. BizTalk Server uses the annotation capabilities of XSD to store this extra information within an XSD schema. BizTalk Server defines a rich set of specific annotation tags that can be used to store all of the required additional information.