Biztalk Adapter Interview Questions And Answers

No. The adapter only writes data in the context of the message which is further interrogated by another component of BizTalk.

Content-based routing provides flexibility for users who want to route messages based on envelope properties or on receive port configuration properties. Routing can be performed based on information contained in the envelope of the document or even configuration information from the receive location.

A BizTalk Server business process involves receiving, processing, and sending messages. Some messages do not require intensive processing in an orchestration. They can benefit from a simpler and more efficient solution called Content-based routing.

☛ The process of saving your running orchestration state at certain point is called persistence.
☛ Orchestration engine persist a running instance which is based on the design of orchestration.
☛ There are few events or stages, which triggers the persistence operation called persistence points.

Checking the subscription table is the First thing when messages come in MessageBox and a copy of the message is sent to the subscriber.

When we run MSI packages, it will register the application with Windows Operating System and then load any related assemblies in the Global Assembly Cache.

We can use webservices where we need to get data from multiple sources in one go. For e.g. getting price quote from 10 different vendors. You make one orchestration and use WS inside it.

Host is nothing but the logical container of host instance. from which we can create host instance. Host instance is a Win-NT service.

A BizTalk Server Host is a logical set of zero or more BizTalk Server run-time processes in which you deploy items such as adapter handlers, receive locations (including pipelines), and orchestrations.

A host instance is the process where the message processing, receiving, and transmitting occurs You install a host instance on each server running BizTalk Server 2006 that has one or more hosts mapped to that server.

To route binary data you can use pass-through pipelines on the receive location and send port. BizTalk will route (copy) the data from the source (receive location) to the destination (send port). If you want to route the binary data based on some information in the binary data then you write a custom Disassembler to promote the properties you need from the incoming message to route the binary data.

A disassembling pipeline component receives one message on input and produces zero or more messages on output. Disassembling components are used to split interchanges of messages into individual documents. Disassembler components must implement the following interfaces:

☛ IBaseComponent.
☛ IDisassemblerComponent.
☛ IComponentUI.
☛ IPersistPropertyBag.

☛ An adapter is a software component (COM or .NET-based) that enables you to easily send messages out of or receive messages in BizTalk Server with a delivery mechanism that conforms to a commonly recognized standard, such as SMTP, POP3, FTP, or Microsoft Message Queuing (MSMQ).
☛ As Microsoft BizTalk Server has evolved, the need for adapters that quickly enable connectivity with commonly used applications and technologies has increased.
☛ BizTalk Includes over 25 multi-platform adapters that simplify the integration with Line of Business (LOB) Applications (such as Siebel, SAP, JD Edwards, Oracle, and Dynamics CRM), database (Microsoft SQL Server, Oracle, DB2) and other technologies (Tibco, Java EE).

☛ An adapter handler is an instance of a BizTalk host in which the adapter code runs.
☛ When you specify a send or receive handler for an adapter you are specifying which host instance the adapter code will run in the context of.
☛ An adapter handler is responsible for executing the adapter and contains properties for a specific instance of an adapter.
☛ A default BizTalk Server configuration will create adapter handlers for all of the installed adapters, but you may want to create additional adapter handlers for purposes of load balancing or to provide process isolation for a particular adapter handler.

Information worker can set parameters for an orchestration that implements a business process, which a business analyst may not be able to create.
Developer creating an orchestration can define parameters for an orchestration to enable information workers configure it. An information worker sets those parameters using the TPM service by specifying their values in the partner’s agreement

Rules engine is provided as component of a business rules management system, which provides the abilities such as define, register, classify and manage all rules, verifies consistency of rules definitions, defining relationships among rules and relates them to IT applications which are effected by one or more rules.

☛ Right-click Messages in the Orchestration View tab to create a new message, you have four choices for the Message Type property.
☛ Expand Multi-part Message Types and then choose Create New Multi-part Message Type.
☛ Name your multi-part message type then expand it so you can see its Message-part_1 member (Biz-talk suggested name)
☛ Set the Message Body Part property to True so that it acts just like a regular message.

☛ Native adapters are those that are shipped with the product and there are more than 25 multi-platform adapters.
☛ But in some cases a BizTalk Server may need to transport messages to a specific custom application or use a protocol for which a native adapter does not exist.
☛ If you are unable to locate an adapter to support your communication requirements, BizTalk Server provides a framework for developers so that you can develop your own custom adapter.

The reason for having multiple receive locations inside one Receive port is to have the ability to receive different messages from different locations and having BizTalk treat them as if they were received from the same place and/or had the same message type.

When a group of correlated messages could potentially be received at the same time, a race condition could occur in which a correlation set in a particular orchestration instance must be initialized by one of the messages before the other messages can be correlated to that orchestration instance. To ensure that all of the correlated messages will be received by the same orchestration instance, BizTalk detects the potential for such a race condition and treats these messages as a convoy.

Convoy is a term which we use to describe a class of application protocols, specifically it is a set of application protocols which have a race condition as described above. Let’s take an example. Say you are a hospital and want to have a service which handles all information about each patient. For a given patient you have three types of messages, an admittance message, status messages, and a discharge message. If you look at your protocol, you will have built a service which just receives. Now let’s think about what could happen. Let’s say you send the patient admittance message and it goes through the system using maybe a synchronous protocol like HTTP. That means when you get the 202 back, you know the message has been delivered. But what if the BizTalkServer host which is actually supposed to process the message hasn’t started yet (ie the nt service is stopped). Maybe you had a power outage, maybe some intern decided to “hit this button”, who knows. So the orchestration instance which is supposed to handle all messages for patient X has not physically started. The message is in the database (MessageBox) and if you look in HAT you will see the orchestration is marked as ready to run, but it can’t start cause there is no where for it to start.

☛ • Schemas and Maps in its own project
☛ • Or Schemas and Maps together in its own project
☛ • Orchestrations in its own project
☛ • Pipelines in it own project

A link specifies the basic function of copying data from an element or attribute in an input instance message to an element or attribute in an output instance. You create links between records and fields in the source and destination schemas at design time. This drives the creation, at run time, of an output instance message conforming to the destination schema from an input instance message conforming to the source schema.

"Native" or "integrated" adapters in BizTalk are: FILE, FTP, HTTP, MQSeries, MSMQ, POP3, SMTP, SOAP, Windows Sharepoint Services, and the seven WCF adapters (WCF-WSHttp, WCF-BasicHttp, WCF-NetTcp, WCF-NetMsmq, WCF-NetNamedPipe, WCF-Custom, and WCF-CustomIsolated)

☛ • Add a reference to that class.
☛ • Make sure your Orchestration is Long Running transactional.
☛ • Add an Atomic scope.
☛ • Create an Orchestration variable of that class inside the scope.
☛ • Create an instance on that object inside the scope.
☛ • Call the method.
☛ • Bonus: Mention the class must be strongly signed and in the GAC.

I want to put a definition around BizTalk to make it easier to compare to Windows Workflow. BizTalk Server is an enterprise level workflow and message processing environment. This environment is tried and tested (extremely rigorously over the last many years). BizTalk also includes many adapters to connect to a variety of back end system. Out of the box, BizTalk provides scalability, manageability, tracking, logging & administration tools.

Windows Workflow is an SDK for creating workflow based applications. The tools are there to build a host and to render a graphical workflow environment. Scalability is possible with Windows Workflow but it is up to the developer to create a truly scalable solution. In addition, there are administrative functions through runtime and tracking visibility but there is not an out of the box administration tool as this is also up to the host developer to create.

The message that I tell people is to use BizTalk when you want to target users/clients that want to span multiple applications whereas Windows Workflow would be used when you want to target users/clients that want workflow within an application.

So, to summarize, Windows Workflow is great for workflow within an application whereas BizTalk is great for workflow across applications.

Two types of subscription
☛ 1. Activation
☛ 2. Instance

Instance subscriptions are removed from the message box while Activation subscriptions remain active as long as the orchestration or send port is enlisted.

Instance subscriptions are removed from the message box while Activation subscriptions remain active as long as the orchestration or send port is enlisted.

Business data and process milestones are captured by Business Activity Monitoring(BAM), which is a module in BizTalk . Business decisions makers are allowed by BAM for gaining insight for their in-flight process.

☛ BizTalk is a product while Web Services are a standard.
☛ BizTalk Server is a Microsoft product whereas Web Services have been developed by many organizations including Microsoft, IBM, etc.
☛ BizTalk Server application has been built to enable the internal business processes of organizations, operate with ease. Web Services are small applications published using UDDI to enable all the people find them.
☛ Web services are that they are platform neutral. BizTalk can leverage Web services.