Biztalk
web-service-message-formats

BizTalk: Thoughts on Adapters, Pipelines, WebService

  1. web-service-message-formatsLoose coupling applications, makes them easy to scale out, expand and maintain, and decreases the cost to change them in future. Messaging is one of the ways of doing loose coupling.
  2. Messaging enables solutions to be scalable, queues acting as a load buffer, each application can work at its own speed.
  3. To differentiate messages, engine determines and stores a set of contextual property values for the message and then interrogates a rule store to determine a set of matching subscriptions.
  4. Adapters: manage communication between integration services and application, sending & receiving messages over a particular transport.
  5. BAF: Since every business model has their own transport type, they need to create their own adapters to connect to different app. To help this massive investment by other companies, MS provides an advanced framework, that enables development, configuration and management of all adapters in a consistent manner. Important thing is that MS uses same set of interfaces internally to implement OOTB adapters.
  6. Parsing/disassembling: takes incoming msg regardless of format & creates XML representation. Parsing is done by executing business logic against msg with user-defined schema that describes its metadata. Important properties from document are extracted separately from message in property bag called message context.
  7. Message Transmission through pipeline: is done in form of stream, rather than passing msg as a whole.
  8. Statless vs Stateful Messaging: BizTalk messaging separates stateful part of messaging, messages and their context information, from stateless part, the actual processing and devlivery of messages.
  9. In addition to standard context data provided by BizTalk, a msg designer can specify, or promote, additional properties form body of msg into context.
  10. SOAP Timeout: Default SOAP timeout, is 120 seconds. If you have application running more than that, you need to change it in machine.config in “executionTimeout” attribute in <httpRuntime> element.
  11. SOAP Exception: Whenever, an orchestration is exposed as a webservice and is imported in a win/web app, it will throw a SOAP exception, unless ASP.NET user is added in ‘Isolated Users group’.
  12. Pipeline: divides processing into categories of work called stages. Biztalk contains pipeline template, pipeline components and default pipelines.
    – Receive pipelies: decode, disassemble, validate, and resolve party.
    – Send pipeline: preassemble, assemble, encode.
    – Default pipeline: Passthrough and Xml.
    – Each pipeline stage can have zero to 255 components. Exception is assemble stage which can have 0 to 1 components.
    – Standard pipeline schemas use message type to retrieve appropriate schema from database.
  13. Components: Each component has a ‘stage affinity’ meaning that they are created for use within a particular stage. Messaging engine acts as a supervisor, transferring the msg, from one component to another.
    Types of components:
    1. General: ones take one message, process it, produce zero or more messages.
    2. Assembling: ones wrap the message with a header. Framework, flat file or xml are default ones that come with BizTalk.
    3. Disassembling: complete many tasks to split up message according to envelope and document schemas, since BizTalk supports the concept of batching multiple messages together, within in a single envelope. First, disassembling convert non-xml to xml, then into singular messages sent to separate orchestrations. Framework, flat file and xml dissassembler are default ones.
    4. Probing: check first portion of message to see; if it is in format that component understands. Probing components can enable a pipeline to be generic by queuing those components in a stage. Each component on arrival of message would probe to see if this is what he was waiting for, if not then it will pass the message on, without modifying it. If there is non-probe component mixed with probing ones, then BizTalk on non-probe component’s turn would think it’s appropriate component and invoke it.
    5. Consuming: components are those who accept message but don’t return messages.
  14. Pipeline Template: two default templates come along with BizTalk, receive and send. Each template has an associated policy file. Stages can’t be reordered in a policy file. It speicifies number of components allowed per stage and execution mode of stage.
  15. Execution mode: Pipeline stage have execution mode. When it’s ‘All’, all components within a stage are run in configured sequence. A runtime error occurs, if any components fails. When it’s ‘firstMatch’, only first components that recognizes is run. If no component recognizes, a runtime error occurs.
  16. Pipeline interfaces: are IComponent, IAssemblerComponent, IDisassemblerComponent.
    – For probing components, IProbMessage interface should be implemented. IProbMessage exposes a single method, probe(), which enables component to check beginning part of msg.
    – IPipelineContext contain ambient properties and message factories.
    – IComponent allows to retrieve msgz from biztalk and then pass msg back, through Execute() method.
    – IBaseComponent communicates basic descriptive info to operating environment.
    – IComponentUI provides services needed to allow component to function in design-time environment.
    – IPropertyBag is used to store configuration information.
    – IPersistPropertyBag permits persistence of custom properties for a component.
    – Pipeline components can expose their own custom properties at design time. Custom components must implement IPersistPropertyBag.
    – To report an error, we throw an exception, and messaging system catches it.
  17. Compilation: pipelines are compiled and deployed as part of solution build/deploy process. Compiler calls Validate() method on each component, allowing component to return compiler errors on configured info.
  18. Custom Pipeline: Whenever you great any object that has to be passed along with the Message from a component, after some processing; do remember to put it in PipeLineContext.ResourceTracker, so that biztalk can clean it up later.
  19. Adapters: All adapters perform transport normalization i.e. taking message from BizTalk and delivering it to target using specific target-dependent protocol.
  20. Adapter Handler vs Port:
    – A handler is a way of associating an adapter with a host. Handlers allow send ports and receive locations to be partitioned across multiple machine.
  21. Static vs Dynamic Adapter:
  22. Dynamic send ports: When target of adapter is set at port binding, it is termed as static. If the adapter uses message properties to route that message, it becomes dynamic. Dynamic send port help, when you want to use one send port but still want to do routing to different targets.
  23. MetaData Harvesting:
  24. Adapter’s Design-time development: involves,
    1. Creating xsd config schemas
    2. Modify add adapter wizard to show correct schema
    3. Creating a registration file
    4. Modifying adapter management project to get correct resources
  25. What happens when adapter works:
    1. Adapter creates a message, connecting data stream to message.
    2. Requests a new batch from messaging engine via it’s Transport proxy, and adds a message to batch to be submitted.
    3. Batch is committed, which causes it to be posted to messaging engine’s thread pool, and it starts processing the new batch.
    4. Message is processed by receive pipeline. Zero or more msgz will be produced by pipeline.
    5. Messaging engine will call back the adapter to notify it of the outcome of that back of work.
  26. Interfaces: Messaging engine has three public interfaces used by adapters IBTTransportProxy, IBTTransportBatch and IBTDTCCommitConfirm. Adapters must implement IBaseComponent, IBTTransport and IBTBatchCallback. IBTTransmitter is a mandatory interface to implement, no matter adapter is receive/send.
  27. IBTTransmitterBatch vs IBTBatchTransmitter ??

Author

Muhammad Omer

Muhammad Omer is the founding partner at Allied Consultants. Areas of interest for him are entreprenuership in organizations, IT Management, Integration and Business Intelligence.