Biztalk Interview Questions and Answers
Question - 131 : - Is it possible to create a custom data type and use it in a schema?
Answer - 131 : -
Yes, it’s possible to create custom data types and it can be used across the schema.
Question - 132 : - Can schema have two nodes with the same name and different datatypes?
Answer - 132 : -
Yes, as long as they are not in the same scope.
Question - 133 : - Can schema have multiple root nodes?
Answer - 133 : -
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.
Question - 134 : - Is it possible to include and import in a single schema?
Answer - 134 : -
Yes, it is possible, both are the ways to utilize already existing schema. The only condition is the schema which is included should have same Target Namespace or no namespace.
Question - 135 : - What are different types of binding modes in BizTalk Server?
Answer - 135 : -
BizTalk offers four binding models, each with different characteristics. Each model is really a set of higher level abstractions of the basic BizTalk subscription mechanisms. One of these models is called ‘Direct Binding’. The term ‘direct binding’ is used to suggest that the techniques involved are all about binding one orchestration port directly to another. In fact, this is just one possibility when using this model. I find the term confusing, myself, as other binding models are used to ‘directly’ bind orchestration ports to messaging Send ports. Binding models are really differentiated by the following characteristics:
- Support for external binding configuration
- Use of static and dynamic messaging Send ports. NB., Receive ports do not support a dynamic model.
- Auto-generation of configured messaging ports at deployment time
Question - 136 : - What is Custom Pipeline stages?
Answer - 136 : -
- IBaseComponent: It Defines properties that provide basic information about the component.
- IPersistPropertyBag: It Works with IPropertyBag and IErrorlog to define an individual property-based persistence mechanism.
- IComponentUI: It Defines methods that enable pipeline components to be used within the Pipeline Designer environment.
- IComponent: It is responsible for providing any execution functionality.
Question - 137 : - What is Send Pipeline and their stages?
Answer - 137 : -
A send pipeline is responsible for processing documents before sending them to their final destinations. The send pipeline takes one message and produces one message to send.
Send pipelines have three stages:
- Pre-assemble: It prepares the message for the outbound process.
- Assemble: It’s responsible for combining multiple messages into one large message with the format that will be sent over the wire (Aggregating multiples messages in a batch). In this step, we can change XML format of a message into a flat file, or possible adding envelopment to the XML message. In this stage, you can also demote the properties (those properties promoted in the Disassemble stage of the Receive pipeline and used for the routing of the message) from the context message.
- Encode: It’s responsible for writing the outgoing message in a fashion way in order to be understood by the target system. It involves encoding, compression, encrypting, and signing the message.
Question - 138 : - What is BizTalk Pipeline?
Answer - 138 : -
BizTalk is a message-based system receiving and sending data inside messages. Sometimes the incoming and outgoing messages must be processed to fit to external formats. Pipelines, attached to send ports and receive locations, are the components through which the messages pass; then the data format is recognized and can be validated or changed if necessary; as well as the metadata is extracted and added to the message context.
Question - 139 : - What are Difference between an Isolated host and an In-Process host?
Answer - 139 : -
- The difference between an Isolated host and an In-Process is that an Isolated host must run under another process, in most cases IIS, and an In-Process host is a complete BizTalk service alone. Additionally, since In-Process hosts exist outside of the BizTalk environment, the BizTalk Administration Tools are not able to determine the status of these hosts (stopped, started or starting).
- Security is also fundamentally different in an Isolated host versus an In-Process host. In-Process hosts must run under an account that is within the In-Process host’s Windows group, and do not maintain security context within the Messagebox. Isolated hosts are useful when a service already exists that will be receiving messages either by some proprietary means or by some other transport protocol such as HTTP. In this case, the Isolated host only runs one instance of the End Point Manager, and is responsible for receiving messages from its transport protocol and sending them to the Messagebox through the EPM.
Question - 140 : - What is BizTalk MessageBox Database?
Answer - 140 : -
The heart of the publish/subscribe engine in BizTalk Server is the MessageBox database. The MessageBox is made up of two components: one or more Microsoft SQL Server databases and the Message Agent. The SQL Server database provides the persistence store for many things including messages, message properties, subscriptions, orchestration states, tracking data, and host queues for routing.