Introduction to BizTalk Server 2010

Editor's Notes

• #14: Enterprise Connectivity and ProcessingEvent Driven ArchitectureData flow and Data warehouse ETLMaster Data Management and Data QualityHigh throughput and low latencyCloud and inter-enterprise ConnectivityData Access from a Unified User InterfaceBurst scenarios & Sometimes connected clients/scenariosIntegration as a service
• #16: An organization may follow a software with different configuration for a process and another software with entirely different configuration to take care of another processBoth processes may depend on each other’s dataFor example a company’s attendance system need to be connected with payroll systemOr a purchase order need to be communicated to invoice generating system
• #21: Para começar tenho de perguntar aqui quem sabe o que é o BizTalk Server?Podíamos começar por definir o BizTalk, de uma forma simples, como um router/broker de mensagensPara fazer uma analogia com o mundo real, como uma plataforma logística de troca de mercadorias.As matérias primas entram nas empresas, são armazenadas, processadas, transformadas e enviadas aos clientes. E da mesma forma as mensagens electrónicas são…
• #22: Recebidas, validadas, arquivadas, transformadas e enviadas para outros sistemas.Nestes processos, o problema é a quantidade de novas ligações que é preciso manter a funcionar durante muitos anos.Ao mesmo tempo novos processos são adicionados e os existentes vão sofrendo pequenas melhorias, tudo sem perder o rasto ao que está a acontecer em produtivo.O BizTalk ajuda-nos a resolver muitos destes problemas, resolvendo automaticamente questões como a persistência, tracking de todas as mensagens, tratamento e recuperação de erros, suporte a transacções, encriptação e assinaturas digitais, os processos asyncronos de workflow, etc…Para além disto tudo, esta plataforma já tem mais de 10 anos (Microsoft BizTalk Server 2010 é a sétima versão do produto) e portanto é uma plataforma madura e com muitos componentes 3rd-Party (mais de 25 adaptadores multiplataforma) para ligação a sistemas como o SAP, Oracle, Siebel, SQL, etc…Gostava de frisar aqui um ponto: um dos desafios que se colocam nestes cenários é exactamente a transformação de documentos…
• #23: BizTalk Server is Microsoft’s Integration and connectivity server solutionConnects disparate systems togetherCommunication among systems are established through messagesAll messages inside BizTalk are XML dataSince XML can be interpreted in any system, BizTalk helps in connectivityIncludes over 25 multi-platform adapters and a robust messaging infrastructureProvides strong durable messaging, a rules engine, EDI connectivity, Business Activity Monitoring (BAM), RFID capabilities and IBM Host/Mainframe connectivity
• #24: Allows organizations to more easily connect disparate systemsIncludes over 25 multi-platform adapters and a robust messaging infrastructureProvides strong durable messaging, a rules engine, EDI connectivity, Business Activity Monitoring (BAM), RFID capabilities and IBM Host/Mainframe connectivity
• #25: Common ComplaintsAs empresas muitas vezes adquirem múltiplos sistemas e/ou aplicações de diferentes fornecedores para atender as necessidades de seus negócios. Isso resulta em uma variedade de aplicações que correm em plataformas dedicadas e que não foram projectados para trabalhar em conjunto. Isso porque cada aplicação geralmente é projectado de forma isolada para cumprir um propósito específico, como estoques, recursos humanos ou gestão de relacionamento com clientes (CRM).Consider the following common integration complaints:Disparate applications. “It is too difficult to integrate dissimilar applications within my company.”Programming overruns. “It takes too long to develop integrated applications for my company’s enterprise resource plan with our existing development tools.”Time-consuming deployment. “Deploying a business process to integrate with my trading partner’s system takes practically as long as developing the process in the first place.”Dissimilar reports. “There is no way to generate integrated, timely reports from my various applications, because the data is stored in so many places.”Modification difficulties. “Once my internal applications are integrated, changing them is arduous and expensive.”Lack of set procedures. “My company does not have a consistent method for implementing our critical business processes.”Limited tracking. “I have no way of extracting usable, real-time data from a running business process.”Changing partners. “If another business offers me a better deal, it is too difficult to take advantage of it because of all of the IT infrastructure changes that it would require.”
• #26: If some Service is down, we can set Retry Mechanism, Alternate Transport Mechanism. It even supports service windows. We can take advantage of enlist and stop features andprevent losing even a single Message
• #30: Microsoft BizTalk Server 2010 is available in five editions designed to meet the needs of organizations of different sizes and needs:Enterprise Edition. BizTalk Server 2010 Enterprise Edition is targeted to large organizations and trading hubs as well as digital marketplaces. Enterprise Edition offers the complete set of BizTalk Server 2010 features. It supports an unlimited number of internal applications running on multiple processors, and it supports clustered deployments. Microsoft also offers a specialized edition of BizTalk Server 2010 named the RFID Enterprise Edition that offers only RFID capability for integration of remote RFID sensors.Standard Edition. BizTalk Server 2010 Standard Edition is designed for small and medium-sized organizations. It offers the same set of features as BizTalk Server 2010 Enterprise Edition, but the number of internal applications is limited to five. This is a decrease of 5 internal applications, but there is no longer a limit to the number of trading partners. Standard Edition will run on 2 CPUs on a single server.Branch Edition. BizTalk Server 2010 Branch Edition is a new licensing option. Branch Edition is designed for intra-enterprise hub and spoke scenarios. You can use Branch Edition to integrate 1 internal application with a BizTalk Server “hub” that coordinates/aggregates events across multiple Branch Editions. It is a subset of BizTalk Server 2010 functionality that includes the technology adapters, RFID, mobile support and Host Integration Server. Branch Edition does not include the application adapters, the BizTalk Adapter Pack or any of the BizTalk accelerators. Branch Edition is limited to 2 CPUs on a single server with a single message box.Developer Edition. BizTalk Server 2010 Developer Edition is available as a free download from the Microsoft web-site. It provides the same set of features as Enterprise Edition, but it is not licensed for production use. Developers can use this edition of BizTalk Server 2010 in a development environment for application development and testing, and for deploying applications to a full production environment.
• #32: Messaging: Inbound, Outbound, DurableMessaging,MessageSecurity, MessageAssembly/Disassembly, PluggableAdapters, MessageSecurity, MessageAssembly/Disassembly, PluggableAdapters, Enterprise Single Sign-On, ServiceEnablement • Web Servicesbasedmessaging (WS* standards)Windows® Communication Foundation (WCF) Adapters • WCF-BasicHttp • WCF-WsHttp • WCF-NetTcp • WCF-NetMsmqOrchestration: FlowControl,PortBindings, Scopes, Design Patterns • Asynchronous Response Correlation • Aggregator • ComposedMessageProcessor • Dynamic Router • ParallelConvoy • ScatterandGather • SequentialConvoy • SplitterBusiness to Business Integration: TradingPartner Management, EDI Support, AS2 Support, IndustryAccelerators • SWIFT • HL7 • RosettaNetBusiness Rule Framework: Business Rule Engine, Business Rule AuthoringBusiness ActivityMonitoring: ObservationModel Design, EventObservationEngine, ReportingManagement & Operations: Application Management, Tracking Configuration & Reporting, Host Management, Application Deployment, Best Practices Analysis, MOM Monitoring, Data ManagementAppFabric Connect Integration: Line of Business Applications (LOB) activities (Consume LOB operations as Windows Workflow Foundation (WF) activities), Mapper Activity (Transformation as a WF activity)RFID PlatformTools• Schema Editor• Flat File SchemaWizard• Mapper• Pipeline Designer• Orchestration Designer• WCF ServicePublishingWizard• Administration Console• MOM Management Pack• BestPracticesAnalyzer• Business Rule Composer• PolicyDeploymentWizard• Orchestration Designer for Business Analysts• ObservationModel Designer• TrackingProfile Editor• BAM Portal• BAM Manager• EDI UserFriendlySchemaViewer• EDI DocumentInstanceGeneration/Validation• TradingPartner Portal• RFID Manager• RFID Tray• RFID Event Simulator• RFID Client Console
• #33: Neste cenário, um aplicativo de inventário, talvez a correr num mainframe, determina que o stock de um item é baixa e emite um pedido para pedir mais desse item. Ocorrem as seguintes etapas:The request is sent to a BizTalk Server 2010 applicationThe BizTalk application requests a purchase order (PO) from the organization’s Enterprise Resource Planning (ERP) application.The ERP application, which might be running on a UNIX system, sends back the requested PO.The BizTalk application informs a fulfillment application, built on the Microsoft .NET Framework, that the item should be orderedNeste exemplo, cada aplicação comunica por meio de um protocolo diferente, utilizando os formatos de mensagens específicas de cada aplicação. Isto significa que o mecanismo de mensagens do BizTalk deve ser capaz de se comunicar com cada aplicativo no seu protocolo de comunicação e formato nativo e também converter as mensagens para o protocolo e formato exigido pelos demais sistemas.
• #34: The two main services in BizTalk Server 2010, the messaging engine and the orchestration engineO objetivo do BizTalk é processar mensagens. Toda a comunicação dentro e entre um servidor de BizTalk são baseados na troca de mensagens. Por esse motivo, o mecanismo de mensagens é essencial para todas as operações do BizTalk.The BizTalk messaging engine performs the following tasks:Receives inbound messagesParses inbound documents to identify their specific formatsExtracts key identifiers and identifies applicable routing rulesDelivers documents to their respective destinations including ports or orchestrationsTracks documentsMessage databaseThe MessageBox database is a Microsoft SQL Server™ database that is used by BizTalk to store and route messages to orchestrations and send ports. When a message arrives in the MessageBox database, the metadata associated with the message is matched and evaluated to determine the services that subscribe to messages of this type.Publish-Subscribe ModelBizTalk Server implements a publish-subscribe model for the routing of messages. In the publish-subscribe model, message providers (publishers) submit messages to a central store (the MessageBox), where subscribers (send ports and orchestrations) can subscribe to specific messages. After a message of interest is received by the MessageBox, it is sent to all subscribers
• #37: Empty BizTalk Server Project. Use the Empty BizTalk Server Project template when you want to create a new application that runs on BizTalk Server 2010. This is the most common BizTalk project type.BizTalk Server BPEL Import Project. Use the BizTalk Server Business Process Execution Language (BPEL) Import Project template to launch the BPEL Import Wizard. This wizard will guide you through the necessary steps to import BPEL, WSDL, and XSD files into a BizTalk Project.
• #38: BizTalk Editor helps you define schemas, which are used to describe the format of messages that are used within organizations and between trading partners and which will be processed by BizTalk Server 2010.BizTalk Mapper presents source schemas and destination schemas side by side, making it possible to define transformations between data fields in messages.Pipeline Designer is used create custom pipelines that are used to process incoming and outgoing messages. The pipelines implement such operations as encryption and decryption, compression, reformatting, and validation.Orchestration Designer enables you to create orchestrations that are used to model business processes. The orchestration designer offers a toolbox of components to model business processes.
• #40: BizTalk Server was one of the first applications specifically designed to work with data in XML format. All documents (messages) that will be internally processed by BizTalk must first be converted to XML. All XML artifacts that are created by BizTalk are fully World Wide Web Consortium (W3C) compliant. This means that schemas created using other tools can generally be used by BizTalk and vice versa.Namespace. An XML namespace is a W3C standard for providing uniquely named elements and attributes in an XML instance. An XML instance may contain element or attribute names from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved.Element. An XML element is a construct used to organize information in a hierarchical manner. XML elements can either be simple data types (such as strings, decimals, and unsigned bytes) as defined in W3C standards, or they may be a complex type containing other elements and/or attributes. Elements and attributes are case sensitive; that is, Customer is not the same element name as customer or CUSTOMER.Attribute. An XML attribute is a construct used to associate additional information contained with an XML element. Unlike elements, attributes cannot be nested. Attributes can be associated with any of the simple data types, but because they cannot be nested, they cannot be a complex type.In the following example, Customer is an element with a value of Contoso. ID is an attribute of the Customer element and has a value of 12345.  <Customer ID=”12345”>Contoso</Customer> XML Schema Definition Language (XSDL). The XML schema definition language is used to create schemas that represent the message formats that BizTalk will process. Schemas define nodes such as required and optional fields, recurring fields, and order. An instance message can be validated against an XSD to verify that the format is valid.XML Path Language (XPath). A language used for navigating through the hierarchy of an XML document. For example, XPath can be used to select data in an XML document that matches a certain criterion or to perform comparisons on retrieved data.Extensible Style Sheet Language Transformation (XSLT). A language definition for XML data presentation and data transformations. Data presentation refers to how data is formatted for display purposes in a specific format or style. Data transformation refers to how data is transformed and exchanged. For example, a purchase order could be converted from the format submitted by a trading partner to the format required for your internal processes.Document Object Model (DOM). The DOM provides a mechanism for navigating through a message. When working with XML documents, the DOM is often used to manipulate and query XML data. In BizTalk, when references are made to the XML DOM, it is usually presumed that the message is being loaded into memory, which results in slower processing than would be experienced if the data were simply being streamed.Web Services Description Language (WSDL). An XML format that describes the capabilities and characteristics of a Web service. BizTalk can both publish and consume Web services. That will be discussed in module 12.Simple Object Access Protocol (SimpleSOAP). Defines a simple way of sending XML messages across the Internet. SOAP is used in BizTalk Server in conjunction with Web services.
• #41: XML NamespacesXML messages (instances) may contain elements or attributes from more than one XML vocabulary. If each vocabulary is given a namespace, the ambiguity between identically named elements or attributes can be resolved. Element names within a namespace must be unique.
• #42: When an XML message is received by BizTalk, the default namespace and root node name are extracted from the message. These values are concatenated (targetNamespace#rootNodeName) and are referred to as the Message Type. It is important that the Message Type be unique so that BizTalk can non-ambiguously determine the correct schema to be applied to the instance.For non-XML message instances, a property defined in the pipeline will specify the schema to be applied. Schemas used for flat file processing will have a root node name and a target namespace and will therefore have a message type. These values should provide for uniqueness but are not as critical. More information about these properties will be provided later in this module.
• #43: Schema TypesBizTalk Server 2010 can natively process messages in XML flat file and EDI message formats. BizTalk is extensible, and custom message types can be created in addition to those supported out of the box.XML SchemaAn XML schema defines the structure of XML messages. XML messages are arranged in a hierarchical format that is defined by the schema. Messages are identified and validated against their associated schema.Flat File SchemaA flat file schema defines the structure of messages that use a flat file format. Flat files can be either delimited or positional. Because XSD does not natively support the flat file structure, BizTalk uses the annotation capabilities of XSD to store this extra information within the XSD schema. BizTalk defines a rich set of specific annotation tags that can be used to store all of the required additional information.EDI SchemaBizTalk supports the creation and use of schemas that represent various EDI document formats such as EDIFACT and X12. An EDI message is a variation of a text message and does not use typical delimiters such as carriage returns and linefeeds. As with flat file schemas, BizTalk uses the annotation capabilities of XSD to store the extra information related to the format of the EDI messages.EDI messages are beyond the scope of this course. Refer to the BizTalk help files for additional information on EDI schemas and their uses.
• #44: Delimited FilesA delimited file contains one or more fields separated by a delimiter character. This character is frequently a comma (,) or pipe symbol (|) but could be any character. Positional Flat FilesA positional flat file is made up of records that have a common end-of-record terminator (delimiter), for example, a carriage return, and fields that have a fixed length.
• #46: The Flat File Schema Wizard provides a series of steps that allow you to quickly generate an XSD for even quite complex flat file messages. Once this base XSD has been created, it can then be opened by using either the BizTalk Schema Editor or another schema design tool and edited further if necessary.
• #47: The Flat File Schema Wizard provides a series of steps that allow you to quickly generate an XSD for even quite complex flat file messages. Once this base XSD has been created, it can then be opened by using either the BizTalk Schema Editor or another schema design tool and edited further if necessary.
• #49: Map. You create a map when you want to transform or translate data between message formats.BizTalk Mapper. A visual tool, hosted within Microsoft Visual Studio®, for constructing BizTalk maps, which define data transformations.Data transformation. The process of converting an XML document that conforms to one schema into an XML document that conforms to another schema. A transformation can simply change the formatting applied to the data, but more often, data transformation results in some kind of structural change to the document. For example, a system that automates purchase order processing will typically transform purchase order records into one or more invoices.BizTalk map. A file that defines the correspondence between the records and fields in one schema and the records and fields in another schema. BizTalk maps are implemented in XML Extensible Stylesheet Language Transformations (XSLT).Extensible Stylesheet Language Transformations (XSLT). An industry-standard specification defined by the World Wide Web Consortium (WC3) for expressing transformations between two documents. The XSLT generated by BizTalk is fully W3C compliant.Data translation. A special case of data transformation that involves changing the format of an instance message, typically from non-XML (EDI or flat-file) to XML format, or vice versa. For example, if your internal processes utilize XML data, but your trading partner needs to receive messages in a flat-file format, you can perform the necessary translation before you send such messages to the trading partner. Data translation can be especially helpful in solving enterprise application integration problems by rendering a given type of message into alternative formats required by existing systems.Functoid. An executable module that performs a specific calculation or data manipulation. Functoids provide BizTalk map developers with the ability to create richer transformations than what is provided by XSLT on its own.
• #50: The BizTalk Mapper tool, which is integrated into Visual Studio 2010, starts automatically when you either add a new map to a BizTalk project or open an existing map (a .btm file). To create a map, you must specify the source schema and the destination schema. The source and destination schemas must either be part of the current BizTalk project or be in a referenced assembly.BizTalk Mapper ViewsThe BizTalk Mapper view consists of three panes within the Visual Studio interface:Source schema pane. Displays the schema of incoming instance messages. The links that define the mapping originate from the source schema tree view, passing through the map zone and ultimately to the destination schema tree view.Map grid view pane. Shows the links and functoids that control how data in a source instance message is transformed to the destination schema. You work actively in this view to construct your map. The map grid can have multiple pages, which can also be named. This is helpful as maps become more complex.Destination schema pane. Provides a tree view of an instance message as it will look after being processed by a BizTalk Server destination schema.
• #51: You can specify each individual link between two schemas yourself, or you can allow the BizTalk Mapper to specify links automatically. When you allow the BizTalk Mapper to automatically specify links, you must still choose between two options: Link by Name, or Link by Structure.BizTalk Mapper Link TypesThe BizTalk Mapper supports the following types of linking:Simple linking. Use simple linking between individual nodes. To create a simple link, drag a node from the source schema, and then drop it onto the target node in the destination schema.Structure linking. Use structure linking when the structure of the records being linked in your source and destination schemas are the same or very similar. Structure linking can be applied to the entire schemas or just to parts of each. By performing a structure link from a record in a source to a record in a destination schema, the subordinate nodes will automatically be linked. To create a structure link between portions of your source and destination schemas that have matching structures, hold the SHIFT key while linking the relevant records. After you link the records, links are automatically created for all of the subordinate records and fields for which a match is found.Name-matching linking. Use name-matching linking when the structure of the records being linked in your source and destination schemas are somewhat similar and have matching record and field names, but have more structural exceptions than would be practicable for structure linking. The new BizTalk 2010 Mapper employs a new predictive name matching algorithm that creates links between nodes that have similar names, and are likely matches, even though the names may not be exact matches.
• #52: Basic MappingBasic mapping is the most common type of mapping. It involves copying a value from an element or attribute that occurs once in an input instance message to an element or attribute that occurs once in an output instance messageComplex MappingComplex mapping involves records or fields that can occur multiple times for a single instance of the Record or Field Element node in the schema tree. This type of variable count mapping is called looping.
• #54: A functoid is an executable module that performs a specific calculation or data manipulation. A functoid can be used graphically when constructing BizTalk Server maps to provide the basis for richer transformations than what is provided by XSLT on its own.The BizTalk functoids allow you to extend the functionality of the map to perform a variety of operations on data as the data is being transformed from the source message to the destination message.
• #56: Maps for many types of business documents can require large numbers of links and functoids, rendering the map grid complex and difficult to understand. For improved readability, you can create separate map grid pages to isolate logical groupings of mapping operations into separate pages. You can then view and work with each grouping individually.Note: All functoids that are connected together must reside on the same page. Also, if you delete a grid page, you delete all the links and functoids on that page. The new BizTalk 2010 Mapper allows you to cut/copy and paste links and functoids from one map page to another.
• #59: PipelinesPipelines are software components that can process messages, either as the messages are received or just before they are sent out through a send port. A pipeline divides processing into categories of work called processingstages and specifies the sequence in which each stage of work is performed. Each stage of a pipeline contains one or more pipeline components (Microsoft .NET objects or COM objects) that can be configured to work with the specific requirements of the messaging solution or orchestrated business process.Processing StagesPipeline processing stages can include functions such as decoding or encoding, disassembling or assembling, and decrypting or encrypting. Processing stages are implemented in a prescribed order that cannot be modified.The processing stages for a pipeline depend upon its intended use. BizTalk Server provides two types of pipelines: receive and send. These two types of pipelines require separate categories of work, such as the encoding versus the decoding of a message. The pipeline also governs the process sequence by the use of policy files that specify the order in which each stage is to be executed. For instance, an incoming message must usually be decoded before it can be disassembled.
• #60: There are a number of reasons why you may need to implement pipelines in your BizTalk solution. By using pipelines, it is possible to modify the message in many different ways as it is being passed into and out of the MessageBox database.Receive PipelinesReceive pipelines can be used to process messages as they are received by BizTalk Server. For example, you can use receive pipelines to decode and/or decrypt messages (by using a private key) as well as verify the sender of messages as they are being received. This is important because messages exchanged over the Internet must frequently be encrypted, and it is necessary to confirm the identity of the sender of the messageSend PipelinesSend pipelines are used to process messages as they are being sent by BizTalk Server. For example, you can use send pipelines to encrypt messages (using a public key), or digitally sign outbound messages (using a private key) as proof of who the sender is. Before a message is sent, you can also use the validate component of a send pipeline to ensure that a message is valid against a known schema.
• #61: Receive pipelines are associated with receive ports. When a port receives a message via an adapter (or is called from within an orchestration), the message is passed to the pipeline for processing. The receive pipeline parses the initial message, with each component tentatively processing the message. The result of the pipeline process will be zero, one, or more messages that will make their way to the MessageBox and on to various subscribers.Each of the four stages in a receive pipeline performs a specific function and can contain only components specified for use in that stage. Each receive pipeline stage can contain up to 255 components, which will all be executed in order with the exception of the disassemble stage, in which only one component will execute. The four stages are as follows:Decode. This stage is used for components that decode or decrypt messages. For example, there is a built-in MIME/SMIME decoder pipeline component that can be used to decode MIME-encoded messages. Custom components for this stage could include a component to decode a compressed (zipped) file before further processing.Disassemble. Use this stage if you need to parse or disassemble the inbound message. The components within this stage probe the message to see if the message format is recognized, and then, if the message format is recognized, one of the components disassembles the message. Tasks performed in this stage include conversions of flat-file messages to XML format and splitting of messages. In order for property promotion to occur, an appropriate (flat-file or XML) disassembler must be specified in this stage.Validate. In this stage, messages are validated against a collection of schemas. Pipelines process only messages that conform to the schemas specified in this component, if present. If a message is received by the pipeline whose schema is not associated with any component in the pipeline, the message is not processed. Depending on the adapter, the message is either suspended or an error is issued to the sender. This stage runs once per message created by the Disassemble stage. The built-in validate component can be used in this stage as well as in other stages.Resolve Party. In this stage, the certificate associated with the sender’s security identifier (SID) is mapped to the corresponding configured BizTalk Server party. If the message was digitally signed, the component uses the signature to look up a Microsoft Windows® identity in the BizTalk Server 2010 Configuration database. If the message carries the authenticated SID of a Windows user, this identity is used. If neither mechanism succeeds, the sender is assigned a default anonymous identity. Party resolution is an important feature for managing trading partner relationships. Not all adapters support party resolution.
• #62: Send Pipeline StagesA send pipeline is responsible for processing documents before they are sent to their final destinations. The send pipeline accepts one message and produces one message for sendingBy default, the send pipeline consists of three empty stages:Pre-Assemble. This stage is a placeholder for custom components that should perform some action on the message before the message is serialized. This stage is run once per message and can contain between 0 and 255 components. All components in this stage are run.Assemble. In this stage, components are responsible for assembling or serializing the message and converting it to or from XML. This stage accepts either 0 or 1 component, which if present will be executed once for each message. Possible uses for this stage include converting to a flat-file formatted message and placing an envelope wrapper around a message.Encode. This stage is used for components that encrypt or encode the message, and it runs once per message. This stage can contain between 0 and 255 components, and all components in this stage are executed. If message signing is required, for example, place the MIME/SMIME Encoder component or a custom-encoding component in this stage. You may create a custom component to generate a message as a PDF file or to convert a message to compressed Zip format before sending it.
• #63: Default PipelinesWhen you create a new application, a reference to the Microsoft.BizTalk.DefaultPipelines assembly is automatically added to the project. This assembly contains the default pipelines provided with BizTalk Server. The default pipelines cannot be modified using the Pipeline Designer.XML Receive Pipeline The XML receive pipeline consists of all four stages; however, the decode and validate stages are empty. The disassemble stage contains the XML Disassembler component, and the ResolveParty stage runs the Party Resolution component, which resolves the certificated subject or the source security ID to the party ID.XML Send PipelinesThe XML send pipeline consists of all three stages, with the assemble stage having an XML assembler and the other two stages being empty. The assemble stage ensures that the outbound XML is well-formed.Pass-Through Receive PipelinesThe Pass-Through receive pipeline contains no components. It is used for simple pass-through scenarios in which no message processing is required. This pipeline is generally used when both the source and the destination of the file are known, and the message requires no validation, decoding, or disassembling. This pipeline is commonly used in conjunction with the Pass-Through send pipeline. Because this pipeline does not have a disassembler component, it cannot be used to route messages to orchestrations or to promote properties from within messages. Property promotion is discussed in detail in Module 5, “Routing BizTalk Messages.”Pass-Through pipelines are typically used to process non-message data, such as graphics files, Microsoft Word and PDF documents, or files that are sent as attachments. The Pass-Through pipelines treat the message as a blob (raw message data) and simply place the content directly in the MessageBox database.Pass-Through Send PipelinesThe Pass-Through Send pipeline contains no components. It is used for simple pass-through scenarios in which no message processing is necessary. This pipeline is the default pipeline that is used when you create a new send port. Because there are no components and no processing takes place, this pipeline is very efficient and should be used whenever practical. This pipeline is frequently used in conjunction with the Pass-Through receive pipeline when the message is not being processed by BizTalk but is simply being routed through BizTalk Server.Flat-File PipelinesThere are no default flat-file pipelines. Any time flat-file messages need to be processed, it will be necessary to create a custom pipeline as outlined in the following topics. When any flat-file message is to be processed through BizTalk Server, the pipeline will have at least one disassembler in which the document property will identify the flat-file message format that the disassembler can process. Each flat-file disassembler can specify only one document schema; therefore, if the pipeline can process multiple flat-file message formats, multiple disassemblers will be required.
• #64: The BizTalk Pipeline Designer is a feature in Microsoft Visual Studio® 2010. The Pipeline Designer provides a graphical representation of a pipeline and enables you to construct or edit send or receive pipelines for a BizTalk project
• #66: Automação de processos de negócios permite a coordenação de processos de negócios, como a aprovação de um pedido de compra, com as pessoas e aplicativos de negócios, tais como planeamento de recursos empresariais (ERP), gestão de relacionamento com clientes (CRM), ou linha de negócios (LOB). Estes processos frequentemente começam como tarefas manuais que exigem integração e de entrada com muitos sistemas diferentes e indivíduos. O processo pode exigir dias, semanas ou meses para ser concluídoBizTalk Server 2010 fornece as ferramentas e tecnologias para automatizar esses processos de negócios.BizTalk OrchestrationComo um programador, você pode implementar este tipo de integração de processos de negócios com uma aplicação customizada usando C #. No entanto, a criação, manutenção e gestão de processos de negócios complexos em linguagens de programação convencionais pode ser um desafio, caro e demorado. BizTalk Server 2010 permite que você crie esses processos de negócios de forma gráfica. Isso resulta em aplicações de automação de processos sendo desenvolvido mais rápido e de custo mais eficaz do que a construção do processo directamente em uma linguagem de programação. Ele também torna o processo mais fácil de entender, explicar e mudar.Business Rule EngineCom o tempo, as regras especificadas n uma orquestração pode mudar. As decisões incorporadas num processo de negócio do negócio em forma de regras são geralmente os mais voláteis. Por exemplo, um gerente de limite de gastos pode mudar, ou o limite de um cliente máximo de ordem pode mudar. BizTalk Server 2010 inclui o mecanismo de regras de negócio para que você possa directamente criar e modificar conjuntos de regras de negócio chamadas políticas. Essas políticas são criadas usando o Business Rule Composer e depois executado directamente pelo motor de regras de negócios
• #68: Orchestration DesignerBizTalk Orchestration Designer is a tool that is hosted within Microsoft Visual Studio®. The Orchestration Designer is used to create visual representations of your business processes. The actual underlying code that carries out the business process gets built into an executable module that runs on a BizTalk Server computer.The Orchestration Designer design environment provides a versatile drawing surface and a comprehensive set of implementation tools. These tools include shapes (such as Send, Receive, Transform, and Construct) that you can use to coordinate all of your business-to-business orchestrations on the screen using a graphical interface. The addition of each shape generates code that becomes part of the eventual business process.BizTalk OrchestrationBizTalk orchestrations provide the services that make it possible for you to design, execute, and manage business processes. An orchestration represents the underlying logic for processing messages similar to traditional procedural programming languages. An orchestration is a graphical rendering of the processing logic, providing many of the normal programming constructs as well as additional features needed to address requirements such as long-running transactions, parallel actions and decisions. An orchestration can be viewed as an event-driven, finite state machine in which the state-transition events are the arrivals of messages or ticks of the clock.Run-Time EngineThe BizTalk orchestration run-time engine executes the orchestration by creating individual instances of the business process. The run-time engine coordinates multiple instances of a business process, ensuring, for example, that a response message gets routed to the correct orchestration instance, which it does by using a specialized routing pattern called correlation. For example, you may create a process involved with hiring new employees. For each employee, there are a number of messages that need to be sent and tasks that need to be performed. BizTalk Server can manage several instances of the orchestration for each new employee and correlate each incoming message to the correct orchestration instance.
• #69: The BizTalk orchestration engine is a highly optimized service that monitors and executes orchestrations. The orchestration management tasks the orchestration engine is responsible for include:Creating instances of and executing orchestrations.Maintaining the state of a running orchestration instance so that it can be restored to memory when required.Performing optimizations of running orchestrations to maximize scalability, throughput, and efficient use of resources.Providing a reliable shutdown-and-recovery system.Dehydration and RehydrationWhen many business processes are running at the same time, memory and performance can be compromised. The orchestration engine solves these issues by performing the following actions on orchestration instances:
• #70: IntroductionBizTalk orchestration is a flexible and powerful capability that provides various services and tools to enable you to design, automate, and manage business processes. Similar to traditional procedural programming languages, an orchestration represents the underlying logic for processing messages.BizTalk orchestration provides a transactional programming model that includes support for exception handling and recovery from failed transactions. You can define two types of transactions when creating an orchestration:Atomic transaction. Enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete. Long running transaction. Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios.As a result, orchestrations provide you the flexibility to define the course of action in the event of a business process failure.
• #71: Scope ShapeA scope acts as a framework for organizing actions. You use it primarily for transactional execution and for exception handling. You also use a scope when you want to define variables, messages, and correlation sets that must remain local within the scope and when you need to use variables and classes that are non-serializable.A scope contains one or more blocks or other nested scopes. Group ShapeA Group shape is used to arrange actions in an intuitive and visually manageable way. You can use the Group shape as a placeholder for functionality yet to be added, or you can use it to make annotations about what actions take place within it. The name property on the Group shape can be up to 512 characters long. You can type annotations into the name property, and when the shape is collapsed, the entire name will be displayed.
• #74: Expression ShapeThe Expression shape allows you to enter complex expressions into your orchestration easily and quickly; however, you cannot use it to enter an arbitrary amount of code. For example, you can initialize and manipulate the values of your orchestration variables, assign values to dynamic ports, or make a .NET call to run an external program. You use the Expression Editor to define the expression.Throw Exception ShapeYou can explicitly throw exceptions in an orchestration by using the Throw Exception shape. When the throw is performed, the runtime engine will search for the nearest exception handler that can handle the type of exception being thrown. After a matching exception handler is found, control is transferred to the first statement of the exception handler. If the search for matching exception handlers fails, the orchestration halts. Transactions (which will be discussed in the next module) can help you minimize the impact of such an occurrence.
• #75: Call Orchestration ShapeThe Call Orchestration shape is used to invoke another nested orchestration synchronously, which means that the enclosing orchestration waits for the nested orchestration to finish before continuing.You can specify parameters that will be passed to the nested orchestration. Parameters can be messages, variables, port references, role links, or correlation sets. Parameters can be defined as one way (in or out), or they can also be passed by reference as with a .NET method parameter. Passed-in port references, role links, and correlation sets all perform in a way similar to that of self-addressed envelopes, which means that they supply the nested orchestration information that it can use to send information back to the enclosing orchestration.Start Orchestration ShapeSimilar to the Call Orchestration shape, the Start Orchestration shape can be used to nest other orchestrations; however, this nesting is asynchronous, which means that the flow of control in the invoking orchestration proceeds beyond the invocation without waiting for the invoked orchestration to finish its work.As with the Call Orchestration shape, you can specify parameters that will be passed to the called orchestration. The Start Orchestration shape can only take in parameters; it cannot take out or reference parameters.
• #85: Business RulesBusiness rules are statements that govern the conduct of business processes. A policy is a collection of related rules that are evaluated together, for example, a bank’s loan approval policy might be composed of several different rules that need to be evaluated. The policy is executed, and each rule is evaluated and possibly applied.Each rule consists of a condition (an if clause) and a resulting action (a then clause). The conditions and actions can be quite simple or very complex. The condition is evaluated, and if it evaluates to True, the specified actions are performed by the rule engine. Unlike in most programming models, there is no else action. For example, if you want to perform an action on all purchase orders, but the action varies based on the total order amount, you would need to create two rules, one for purchase orders with a total of less then $1,000 and one rule for purchase orders with totals greater than or equal to $1,000. These two rules would make up the discount policy.Within a policy, the various rules can have different priorities assigned. These priorities do not modify the order of evaluation but rather the order that the rules are fired in. That is, if multiple rules are to be fired (on the agenda), the priority will determine the order that the rules are applied. In this case, the rule that has the highest assigned priority will be fired.
• #86: RuleBusiness rules are statements that govern the conduct of business processes. Business rules consist of a condition and one or more consequent actions. Conditions are true/false, otherwise known as Boolean expressions, that consist of one or more predicates applied to facts. Multiple conditions can be combined to provide for complex computations. Complex conditions can be constructed by joining multiple simple conditions using AND, OR, and NOT modifiers. For example, when evaluating a customer order, you could have a rule such as: If customer exists AND total order amount > 1000 OR if customer exists AND customer rating = excellent THEN set discount amount = 10%.PolicyPolicies are logical rule sets. You compose a version of a policy, save it, test it by applying it to facts, and when you are satisfied with the results, publish it and deploy it to a production environment. Policies are versioned and deployed, so if a rule changes, you simply create a new version of the policy, test the policy, and then deploy it. You do not have to recompile or modify orchestrations or other business processes that are using a particular business policy.When called from an orchestration, the Business Rule Engine will always execute the latest version of a policy. Changes made to a business rule policy will be immediate. The next time the policy is called from an orchestration, the most recently deployed version will be used. After it is published, a business rule policy is immutable and can be changed only by creating a new version.VocabularyVocabularies are user-defined names for the facts used in rule conditions and actions. Vocabulary definitions render rules easier to read, understand, and share for the various workers within a particular business domain. For example, the source location for a particular fact might be a field in a particular record within a database, represented as an SQL query. Instead of employing the SQL query (an abstract procedural statement, difficult for most people to memorize or recognize) in the rule, a name meaningful to all the relevant parties in the development and deployment process can be associated with the query by creating a vocabulary definition. When you create a new vocabulary definition, you can choose from one of the following:A constant value, a range of values, or a set of valuesA .NET class or class memberAn XML document element or attributeA database table or columnCreating the necessary vocabulary for business rules makes reading, comprehending, and updating the business rules much easier than without using vocabularies. In addition to the vocabularies you can create, the Business Rule Composer uses predefined vocabularies for the predicates and functions used in the rule evaluations and actions.Rule StoreThe rule store is a repository for business policies and vocabularies. Policies and vocabularies are deployed to the rule store. The rule store is by default the Business Rule Database (BizTalkRuleEngineDb). This database is created when configuring business rules for the BizTalk group. Additionally, policies and vocabularies can be exported to an XML file to simplify modification and deployment between test and production environments.
• #87: Business RulesA business rule consists of a condition and one or more resulting actions. As mentioned before, business rules are If/Then conditions, and there is no Else clause. Each business rule either returns True or False.ConditionsA condition is a True/False (Boolean) expression that consists of one or more predicates applied to facts. Predicates can be combined with the logical connectives AND, OR, and NOT to form a logical expression that is potentially quite large but that will always evaluate to either True or False.ActionsAn action is the functional consequence of condition evaluation. If a rule condition is met, a corresponding action or actions are initiated. Actions are represented in the Business Rule Framework as Microsoft .NET–based objects or as set operations on XML documents or database tables. For example, if a business rule that checks whether or not a customer is preferred returns true, you could then call a method of a .NET class to execute code in the class. You could also update elements or attributes in an XML schema document, or you could update data in a Microsoft SQL Server™ database. You can execute more than one action within the THEN clause.FactsFacts are the data that rules use to make decisions. Facts can be derived from multiple data sources and must be fed into the rule engine through pre-defined vocabularies, XML schemas, .NET classes, or database row sets. Many facts are instance facts that will be different for each firing of the rules. For example, the customer name and account number fields in a PO message are instance facts. Other facts may be long term. For example, interest rates usually change infrequently and do not need to be looked up each time a rule is fired. Long-term facts are determined once and then held in the cache until refreshed, whereas instance facts are determined for each rule execution. A fact can be configured as a long-term fact by setting the Fact Retriever property for each version of the policy in the properties window for the version of the policy. A fact retriever object must be created to be able to fetch the facts from a persistent storage and present them to the policy object.
• #88: Common Orchestration ScenariosInstead of having to code and recode constantly changing business policies and logic within your complex business processes, you can incorporate a call to the Business Rule Engine and thus allow information workers to update the rules as needed.OverviewYou can integrate business rules into your orchestrations to support a variety of scenarios:You can use rules to determine whether another business process needs to be executed. For example, after successfully placing a customer order, you might want to call a second orchestration that handles the shipping of orders.You can use rules to evaluate business logic and to determine when a business process requires a variable delay. For example, you might set up a loop to check on the status of an item to see if the item is in stock. After initially checking the stock of an item that is not available, the rule delay would be one minute. The next time, the rule would wait five minutes before executing, the following time, the rule would wait 30 minutes before executing, and so on.You can use rules to determine the execution path for a business process, basing the determination on the results of the rule execution. For example, if the customer submitting the purchase order does not exist in the database, you could route the document to another business process to add the customer to the database before continuing to process the purchase order.
• #89: OverviewThe Business Rules Framework incorporates a graphical user interface—the Business Rule Composer—that developers, information workers, and administrators can all use in various ways to develop and apply both rules and policies.Developers can:Create the orchestrations from which the business rules will be called, and they define the action to be taken when a decision is returned to the orchestration. As long as the decision path within the orchestration does not change, the orchestration will not need to be redeployed.Create the initial business rule policies and create vocabularies to make it easier for information workers to edit and understand business rule policies.Information workers can:Design, test, and manage business policies. Changes made to a BRE policy will be executed from an orchestration without having to recompile and redeploy the BizTalk assembly. The BRE always calls the latest deployed version of the policy.Administrators can:Secure business rule policies. By default, when a new policy or vocabulary is created in the rule store, only the user who created it and the rule engine administrator have both read/execute and modify/delete access. The rule engine administrator can configure which users have the access level, or rights, to perform different operations (processes operate under user credentials).Deploy business rule policies from one physical environment to another. Deploying business rules to other physical environments is accomplished by using the Rules Engine Deployment Wizard and is covered later in this module. Rules can also be exported and imported using Microsoft Windows® Installer (MSI) packages.Monitor the results of executed business rules by using the BizTalk Administration Console. This tool allows auditing of the rules-based decision made within each orchestration instance.
• #90: Business Rule ComposerThe Business Rule Composer is a graphical user interface that allows you to create business rule policies, which contain one or more business rules. These rules can evaluate facts to determine if specific actions should be performed. To assist in humanizing these rules, vocabularies can be created that provide a user-friendly alias to the terms and conditions. Multiple versions of the policies and vocabularies can be created, tested, published, and deployed using the Business Rule Composer to make management of these artifacts easier.Create Business Rule PolicyA policy is a collection of rules. Each rule is a conditional comparison of facts, which if the comparison evaluates to True causes the actions defined in the rule to be executed. Rules are constructed in the Rule Composer pane by adding predicates and facts (which may be direct facts or may be based upon vocabularies) and defining actions. AND, OR, and NOT operators can be added to conditions to provide for complex comparisons.Facts and actions are added by dragging them onto the Rule Composer design surface.Testing, Publishing, and Deploying a PolicyWhen a version of a policy is defined to the satisfaction of the business analyst, the policy should be tested prior to publishing it. The act of publishing the policy to the Rule Store makes the policy available to the BRE. By default, the BRE uses a SQL Server database as the Rule Store. However, rules can be exported to an XML-based Rule Store as well. Once published, policy versions are immutable and cannot be changed without creating a new version. Remember that rules must also be deployed before they can be used by other applications.
• #92: OverviewBusiness Activity Monitoring (BAM) is a tool for monitoring and analyzing data from business process information sources. The data is presented in a real-time view of business state, trends, and critical conditions. BAM’s open application programming interface (API) can be used to gain visibility into data external to BizTalk processes, such as archival data or other non-BizTalk processes and systems. BAM gives business analysts the data they need when they need it, enabling them to make better business decisions based on more relevant data.BAM allows you to determine how your business is performing by answering questions such as:How long did it take for this process to be approved?How quickly was this order filled after it was received?How many process cycles occurred in the last month? In the last year?How many purchase orders were processed last week?How much is our total revenue this year so far?
• #93: OverviewBAM makes it possible for developers, business analysts, and end users, working individually or collaboratively, to extract the data they need from their business processes.
• #94: OverviewThe creation and implementation of BAM to monitor business processes usually involves several different roles with different skill sets and tools.Business Analyst RoleThe role of the business analyst is to create BAM activity definitions (activities) and to create the views that will be available to end users to view the business processes. Generally, Business Analysts do not know, and do not need to know, what the actual orchestration that defines the business process looks like. They know what information is important to track and the order in which the process occurs.Create ActivityAnalysts use Microsoft Excel 2010 to create activities that identify in list form the key performance indicators (KPIs) of the business processes, for example, receiving and processing a purchase order (PO). These activities will include milestones (a date/time measure for the receipt of a PO or the sending of an invoice) in addition to data points of interest, such as the order date, PO number, total, and discounted total amounts. These data points might be of interest for tracking and auditing purposes.
• #95: Tracking Profile Editor (TPE)The Tracking Profile Editor (TPE) is a graphical user interface used by developers to create and modify the tracking profiles that map a specific view of internal business processes and associated data to a business process that might be represented by one or more orchestrations.When you use the TPE to create a tracking profile, you create or load a profile that will define the relationship between:One or more BizTalk assemblies that have been deployed to the BizTalk Configuration database; each assembly may contain one or more orchestrations, pipelines, schemas, and property schemas.The activity, created by the business analyst, that has been deployed to the tracking database by the use of the BAM Management command-line tool.If you have multiple BAM activities deployed, you can use the TPE to create links of continuations between the activities. Linking BAM activities brings together the business analyst’s view of the process with the real-world implementation of that process as a group of orchestrations.
• #96: The BAM Portal is a tool in BizTalk Server 2010 that is used to view data collected in the BAM databases from a business process. When the model is deployed by using the BAM Manager, the views included in the data collection model are rendered as views for the BAM Portal. The BAM Portal is a Microsoft ASP.NET application (it does not rely on Windows SharePoint Foundation). For companies that already have SharePoint sites, Web parts are available to simplify integration of BAM data into those sites.The BAM Portal gives you the ability to:Access pre-created views of the business data created by the business analyst and work with PivotTables® in real time. In this way, users can customize the view to their own preferences.Perform activity searches against BAM data to find specific BAM activity. For example, the preceding slide shows sales manager data for the OrderMgmt application. Queries can be saved and reused. They can also be the basis for an alert, such as notification when a purchase order arrives from the specified customer.Drill down to see detailed information. This example shows the activity status for the city of Los Angeles. The Activity Status view shows the dates on which several business milestones were reached and tracking information (the Activity ID), in addition to the other data. With this functionality, it is easy to start with aggregated data (all orders processed) and see the details for orders that make up the totals.Configure and share alerts to notify specific users in the event that particular threshold conditions are met—for example, if the number of unprocessed purchase orders exceeds 100, send an e-mail message to the sales manager. Once created, alerts can be subscribed to by other users who are interested in the same information.Escalate issues to the systems administrator. A link is provided to send feedback to a preconfigured e-mail address notifying the recipient of problems that are identified by portal users.
• #103: Receive PortsBizTalk Server uses receive ports to receive messages from internal systems and trading partners. Receive ports can be configured to use one or more maps for incoming message transformation. If more than one map is specified, only the map that matches the inbound message will be applied. You can also configure the port to track message bodies or properties. Although message body tracking provides more information about each message, it can adversely affect the performance of BizTalk Server.Additionally, receive ports can function as either one-way ports or two-way ports. Receive LocationsA receive port can have multiple receive locations associated with it. This is useful when you have messages being received from multiple physical locations, such as from a file folder and an FTP site, but you want all the messages received through any of the locations to be processed in the same manner.Receive locations are configured with a URI, an address from which inbound messages arrive, a receive handler, and a receive pipeline. The URI is specific to the transport or adapter type (FILE, FTP, HTTP, Microsoft SharePoint® Services, and others). Receive locations can be in one of three possible states:Enabled. When enabled, receive locations process messages.Disabled. Disable a receive location if you want to prevent the receive location from receiving messages or if you want to delete the receive location.Suspended. If a service window has been configured for the receive location, the location will indicate that it is suspended while the service window is inactive.
• #104: Send ports are the locations to which BizTalk Server sends messages. A send port can function as either a one-way port or a two-way port. As specified earlier, one-way ports send messages, and two-way ports (also known as solicit-response ports) can both receive and send messages. However, not all adapters support two-way ports. The FILE, MSMQT, and SMTP adapters are supported only as one-way ports.There are three general types of send ports:Static send ports. These send ports contain a fixed destination address. When you create a static send port, as in the preceding illustration, you specify the adapter type, destination address (URI), and pipeline used for the static send port.Dynamic send ports. Dynamic send ports do not contain a fixed destination address. Instead, the destination address is set within the orchestration.Direct send ports. In the case of the static and dynamic send ports, the message is written to the MessageBox database before being processed into the send port. In some situations, it may be advantageous to have orchestrations communicate directly. In these cases, direct send ports can be used.Send ports can be created using either BizTalk Explorer or the BizTalk Administration Console. Some of the properties you can configure for a send port include:Send port name. Since you will likely have many send ports in your application, you should always assign a descriptive name to a send port to help identify which messages or processes are associated with a specific send port. For example, POAck_to_Vendor is a much better name then Port_1. Also, descriptive names can help when moving from one environment to another.Primary and secondary transport. Examples of transport types include FILE, FTP, SQL Server, and HTTP. Send ports contain both a primary and a secondary transport type so that if the primary transport is unavailable for some reason, messages can still be sent using the secondary transport type. For example, your primary transport type may be an FTP site. However, if the FTP site is unavailable, you can set the secondary transport to FILE and still successfully process messages through the send port. Later when the FTP site is back online, you can manually transfer received messages from the file location to the FTP site.Address (URI). The address or URI is the physical location where messages are sent when processed by a send port. The address is dependent upon the transport type.Retry count. The retry count is the number of times BizTalk will try to resend a message if the transmission fails. The default value is 3, which is satisfactory for many situations, but the allowed range is 0 through 1000, which allows flexibility in use. For example, you may not want retries to occur at all when communicating with a Web service, whereas you may want to try continuously until successful when sending to a SQL database.Service window enabled/disabled. You can enable the service window if you want to configure a port to send only at specified times of the day. By default, the service window is disabled, meaning that the send port will send messages at any time. If the service window is enabled, the Start Time and Stop Time properties must be specified. You can enable the service window, for example, if you want to send messages to a busy HTTP site only between midnight and 08:00 to prevent network delays during normal business hours. The messages will actually be delivered to the send port and be queued in the spool table in the MessageBox database until the appropriate time.
• #105: Filter ExpressionsFilter expressions are used to create subscriptions. Subscriptions determine which messages will be delivered to a specific port. You can use both the promoted properties from the inbound message schema and the BizTalk global properties to create the filter expressions on a send port. This is known as content-based routing because the actual contents of the message are used to determine how the message should be routed. For example, if you need to route all messages with an order amount over $500 to a specific folder for managerial approval, you can promote the amount node in the source schema and then create a filter expression for a send port to subscribe to messages only with an amount greater than or equal to $500.Subscribing to Failed MessagesBizTalk Server 2010 provides the ability to create a subscription for failed messages. When failed message routing is enabled on a receive port, a filter expression on a send port can be used to send the failed message to an orchestration or some other endpoint, such as a SharePoint site, to fix the error and resubmit the message. A sample of an error handling solution is provided in the BizTalk Server 2010 SDK (software development kit).
• #108: Information Workers/Business AnalystsThe role of a business analyst is to define the rules and actions that make up a business process and to define the key performance indicators used to monitor business activity. DevelopersDevelopers use the design provided by the business analyst to create an application that models the business process. IT Professionals/AdministratorsThe administrator plays an important role by establishing a secure BizTalk environment, setting up communications among the parts, deploying the application, and performing other administrative tasks to manage the BizTalk environment and applications in a production environment. The administrator role also includes the installation and configuration of a stable and high-performance SQL server environment.