This document discusses BizTalk Server artifacts like schemas, maps, and orchestrations. It provides an overview of how schemas define message structure, how maps transform data between schemas, and how orchestrations implement business processes programmatically. Key topics covered include using the BizTalk editor to create schemas for XML, flat files, and property fields; mapping data between schemas using functoids; and designing orchestrations visually in the Orchestration Designer.

1. BizTalk Server 2006 Artefactos – Formação Sandro Pereira DevScope

2. Agenda BizTalk Server Services and Tools BizTalk Schemas BizTalk Maps BizTalk Orchestration BizTalk Adapters Tools for Developers Developers Tools

3. BizTalk Schemas

4. BizTalk Schema Each unique document type requires a separate schema that defines the records and fields contained in that document. The XML schema defines: The elements, attributes, and data types that appear in a document. The ordering of tags in the document. Fields that are mandatory or that might occur multiple times in a single document. BizTalk Server 2006 uses the XML Schema definition language (XSD) to define the structure of all messages that it processes, and refers to the definitions of message structure as schemas.

5. BizTalk Schema Types XML Schema An XML schema defines the structure of XML messages. This type of schema uses XML Schema definition language (XSD) to define the structure of an XML message. Flat File Schema A flat file schema defines the structure of messages that use a flat file format. Flat files can be either delimited or positional. Property Schema A property schema is a special type of schema that defines specific field elements that you want to promote as a property field.

6. Using Multiple Schemas To use a type defined in one schema (Schema1) within another schema (Schema2): 1. Provide a reference to Schema1 within Schema2 by using the Importsproperty of the Schema node in Schema2. 2. Click the ellipsis button (...) in the Imports property field to open the Imports dialog box. 3. In the Import New Schema as drop-down list, choose XSD Import, XSD Include, or XSD Redefine. 4. Click Add to open the BizTalk Type Picker dialog box, and then browse within your BizTalk project to select Schema1.

7. Reusing and Redefining Schemas

8. Creating a Schema Using BizTalk Editor Child Record. Represents a collection of information. A record node can include simple types of information, such as strings and numbers, represented as child field nodes. A record node can also include complex types of information represented as a child record node or as a group node (sequence group node or choice group node). Field Attribute. Represents items of information that are simple in nature, such as strings and numbers. Field Element. Represents items of information that are simple in nature, such as strings and numbers. Must use a field element if the field has children or is repeated. The following menu choices are available when inserting nodes into a schema tree: Sequence Group. Contains other nodes that must appear in an instance message in the same order in which they appear within the Sequence Group node.

9. Promoting a Schema Property Promotion is a mechanism that you must use when you want to reference a specific value within a message instance and make it available to various BizTalk Server components (such as orchestration) or for content-based routing purposes. The promoted property will also be visible to IntelliSense® in the Expression Editorwhen code is required.

10. Promoting a Schema Property Property fields are used in filter expressions and employ property schemas to specify the fields that are to be promoted. You can use the Quick Promotion feature to streamline the process of promoting a property field and to automatically create a property schema. Message properties are referred to by the name of the message, followed by the namespace (the schema) and property name in parentheses: MyMessage(InvoicePropertySchema.InvoiceID) Distinguished fields are used in a message when you need to make decisions or to manipulate data within your orchestration. You can designate a field as a distinguished field by decorating it with the Distinguished Field attribute. Distinguished fields are referred to by the path to the field in the message, using dots to separate the message name, the names of any records that enclose the field, and the name of the field itself: MyMessage.MyRecord.MySubrecord.MyDistinguishedField

11. Creating a Flat File Schema BizTalk Editor is designed to make it easy to create schemas for positional flat files, delimited flat files, and combined positional and delimited flat files. Positional Flat Files. A positional flat file is made up of fields that are of the same fixed length and records that have a common end-of-record terminator. The structure of an incoming file must be represented in the records and fields of the schema so that the positional nature of the incoming file is preserved. Therefore, before defining the message structure of a schema, obtain a layout of the necessary records and fields. Delimited Files. A delimited flat file contains one or more records separated by a specified delimiter. BizTalk Editor does not read delimiters as part of the data. However, if the delimiter character does appear as data, the data can be formatted (placed within quotation marks, for example) so that the data and the delimiter are distinguishable.

12. Testing a Schema Validating the schema. After you have finished creating a schema, or at various times during its creation, you can validate it to find out whether it contains any internal inconsistencies or other issues that might prevent it from being used effectively for processing instance messages. Generating a sample instance. After you have validated a schema, you can use it to generate a sample instance message. The sample instance message that is generated contains the element and attribute structure specified by the schema and generates fake data where required. Validating an instance message. You can use BizTalk Editor to find out whether any instance message conforms to that schema.

13. Best Practices

14. BizTalk Schemas

15. BizTalk Maps

16. What Is a BizTalk Map? A map is the XML file that defines the correspondence between the records and fields in one schema and the records and fields in another schema. You create a map when you want to transform or translate data that you receive or send from one schema to another.

17. BizTalk Map Process Data transformation is the process of creating a correspondence between the records and fields in a source schema and the often different records and fields in a destination schema. Data transformation can also be used to perform operations such as: Averaging data from a looping record and sending the output to a single field in the destination schema. Converting character data to its ASCII format. Adding data to or subtracting data from one or more records and sending the result to a single field in the destination schema. Data translation is the process of changing the format of an instance message. If your internal processes utilize only XML data, but your trading partner needs to receive instance messages in a flat file format, you can perform the necessary translation before you send such messages to your 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.

18. Types of BizTalk Maps Basic Mapping This type of mapping 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 message. Complex Mapping Complex mapping involves records or fields that can occur multiple times for a single instance of the Record node or Field Element node in the schema tree. This type of variable count mapping is called looping.

19. Creating a Map Using BizTalk Mapper BizTalk Mapper consists of the following views within the Visual Studio .NET shell: Destination schema tree view. This view displays the schema that describes the transformed instance message to be processed by BizTalk Server. Source schema tree view. This view displays the schema that describes the incoming instance message. The links that define the mapping originate from the source schema tree view, passing through the map zone view and ultimately to the destination schema tree view. Map grid view. This view is located between the source and destination schemas, and contains 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.

20. Working with Functoids Functoids perform calculations by using predefined formulas to process specific field values. These calculations are executed based on the designated order of the records and fields. By linking a functoid to nodes in both the source schema and the destination schema, data can be concatenated; values added together, date and time information can be modified, and so forth. If you want to implement functionality that is not available in the functoids that are included with BizTalk Mapper, you can create custom functionality by using the Scripting functoid, which allows you to access custom script or code during run time to perform functions not otherwise available. For example, you can call a COM object or Microsoft .NET object at run time by using the Scripting functoid and writing your own custom script. BizTalk Server 2004 supports the following languages for the Scripting functoid: C, Jscript, Microsoft Visual Basic® .NET, Extensible Stylesheet Transformation (XSLT), XSLT Call Templates

21. Using Basic Functoids

22. Using Advanced Functoids

23. Adding Functoids to a Map

24. Managing Map Zone Layers

25. Best Practices

26. BizTalk Maps

27. BizTalk Orchestrations

28. What Is BizTalk Orchestration? Orchestration Designer You can use BizTalk orchestration to create detailed representations of business processes that can be implemented programmatically within an integrated design environment called Orchestration Designer. This design environment provides a versatile drawing surface and a comprehensive set of implementation tools..

29. Working in BizTalk Orchestration Designer

30. Physical Ports vs. Logical Ports Physical ports are used to receive and send messages between BizTalk Server and the outside world. Physical ports are configured and managed by using BizTalk Explorer. Logical ports are used within BizTalk Server to pass messages to and from a BizTalk orchestration. Logical ports are configured by using Orchestration Designer and appear on the Port Surface areas.

31. Using Message and Data-Handling Shapes

32. Using Port and Role Link Shapes

33. Using Orchestration Flow Shapes

34. Using Orchestration Flow Shapes

35. Using Orchestration Nesting Shapes

36. Using Transaction and Exception Handling Shapes

37. Creating Orchestration Variables and Types

38. Creating Expressions

39. Correlating Messages with Orchestration Instances

40. BizTalk Messaging

41. How BizTalk Messaging Works The BizTalk Messaging service performs the following tasks: Receives inbound documents Parses inbound documents to determine their specific format Extracts key identifiers and identifies applicable routing rules Delivers documents to their respective destinations Tracks documents

42. What Is the Publish and Subscribe Messaging Model? BizTalk Server uses a publish and subscribe (or pub/sub) messaging infrastructure that is highly scalable at both database and processing levels. This publish and subscribe routing mechanism can manage large volumes of messages (including large messages) and interact with a wide variety of backend systems. Subscriptions are criteria that describe which message types each business process will receive. Business processes hold subscriptions to specified types of messages; each subscription allows the business process holding it to initiate or continue the processing of one type of message.

43. What Is a Port? Ports specify how your orchestration will send messages to and receive messages from other business processes. Each port has a type, a direction, and a binding, which together determine the direction of communication, the pattern of communication, the location the message is sent to or received from, and how the communication takes place. Depending on these factors, a port may be associated with: A URI (a physical location). A transport (either file, HTTP, or BizTalk Message Queuing). A send pipeline, to prepare a message for sending (for example, by assembling, encrypting, compressing, or performing A receive pipeline, to prepare a received message for processing (for example, by disassembling, decrypting, or decompressing it).

44. What Is a Web Port? Web ports are specially configured ports that are used to access Web services. A Web port can contain multiple Web operations that represent a mix of oneway (request-only) and two-way (request-response) Web methods. Each Web operation in a Web port represents one method of a Web service.

45. What Is a Send Port Group? A send port group is a named collection of send ports that you can use to send the same message to multiple destinations in a single configuration. This is useful when you want to send a message to multiple destinations.

46. What Is Message Routing? A typical BizTalk Server business process involves receiving, processing, and sending messages. At times, you may receive types of messages (such as partner-to-partner correspondence) that do not require intensive processing in an orchestration, and could therefore benefit from a simpler solution. Content-based routing eliminates the need for message subscriptions for messages that are deterministically bound to specific ports, and provides additional flexibility for users who want to route messages based on context properties (or simply based on receive port configuration properties). To enable content-based routing, you must perform the following steps: 1. From the source schema for the incoming message, promote the field nodes that will contain the filters. 2. Create and configure both a receive port and a receive location for incoming messages. 3. Create a send port, and configure a filter on the send port to create a subscription for messages that meet the conditions of the filter expression. 4. Enlist and start the send port.

47. Creating a Receive Location A receive location is the combination of a specific address at which inbound messages arrive and a specific address of the messaging pipeline that processes the messages received at the first specific address. Receive locations are created in BizTalk Explorer as part of the process of creating a receive port. Receive locations have both adapter-specific properties and common properties. Only the common properties can be accessed by an administrator using the BizTalk Server Administration console.

48. Deploying and Testing a BizTalk Solution

49. Assembly Deployment Steps

50. Binding the Physical Ports Specify Later You can bind your port either to a receive location or to a send port. If you do not have all of the information you need to specify a physical location, you can choose the Specify Later port binding option in Orchestration Designer, and then you need only to specify the port type that describes the port. The information about the actual location will be specified separately, after the application has been deployed, either by an administrator working in BizTalk Explorer or programmatically, perhaps by using a script. Dynamic Binding If you will not know the location of a communication until run time, you can use dynamic binding. For example, you might specify the location based on a property of an incoming message. A port binding specifies the entry points into the BizTalk-based application, and is used to associate the application with physical ports. The port binding contains configuration information that specifies where and how a message is to be sent or received. Web Service References If your project contains a reference to a Web service, Orchestration Designer will detect the reference and make available a corresponding Web port type. You simply add a port to your orchestration and assign it an existing Web port type, and BizTalk Server will provide a complete Web port.

51. Completing Post-Deployment Tasks

52. Completing Post-Deployment Tasks Create a Receive Location A receive location is the combination of a specific address at which inbound messages arrive and the messaging pipeline that processes the message received at that specific address. Receive locations have both adapter-specific properties and common properties. Only the common properties (enable, receive handler, and processing schedules) can be accessed by using BizTalk Server Administration. Create Physical Send Port Similar to a receive location, a send port is a grouping of endpoints that are used for transmitting messages. A send port consists of a primary URL and a backup URL, and optionally refers to one send pipeline and an encryption certificate. Bind the Ports You can use BizTalk Explorer to bind an orchestration to a BizTalk Server port,such as a receive port or send location, on a per-message per-port level. For example, a one-way inbound port matches a one-way receive port; a requestresponse inbound port matches a request-response receive port. An orchestration is fully bound only when all of its ports are bound. Optionally, you can specify a map to be used for mapping the message types on each port. Enlist the Orchestration After orchestrations are bound in BizTalk Explorer, you must use BizTalk Server Administration to enlist the orchestrations into a host.

53. Deploying Assemblies: Best Practices

54. Tools for Developers Orchestration Designer simplifies the process of creating orchestrations models of business processes that are compiled into executable code. BizTalk Editor helps you define schemas, which are used to describe the format of data that is processed within organizations and between trading partners. BizTalk Mapper presents source schemas and destination schemas side by side, making it possible to define transformations between data fields in messages. Pipeline Designer prepares incoming and outgoing messages for further processing by implementing such operations as encryption and decryption,compression, reformatting, and validation. The BizTalk project system is shipped with a Visual Studio template called the BizTalk Server Project template. When you use the template, the following BizTalk tools become available to you in Visual Studio:

55. Consuming and Publishing Web Services

56. BizTalk Web Integration Scenarios

57. Consuming a Web Service from an Orchestration

58. Creating a Web Port

59. Publishing an Orchestration as a Web Service

60. Publishing a Schema as a Web Service

61. Business Rules

62. What Are Business Rules?

63. Business Rules Terminology

64. Business Rules Example

65. Integrating Business Rules into an Orchestration

66. Business Rules

67. Tracking BizTalk Message Activity

68. What Is Health and Activity Tracking? To help you monitor, track, and debug your business processes, Health and Activity Tracking (HAT) offers the following capabilities: Displays the processing steps taken by messages Can retrieve messages either by data or by system information Allows real-time monitoring and tracking Can display both archived and real-time data Limits data access to only those people with appropriate permissions Allows you to modify which data is tracked without affecting the rest of the BizTalk Server environment - no redeployment is necessary Allows you to do real-time debugging of your orchestrations Event Tracking HAT tracks data based on events—when a service begins or ends, for example, or when a message is sent or received. Data Tracking You can track both the contents of a message and the promoted properties of a message. These actions are called, respectively, message body tracking and message property tracking.

69. Unlock your business potencial