Biztalk Business

Element or Attribute

artcorner — Mon, 23 Feb 2009 17:42:01 +0000

XML Attributes

XML attributes are normally used to describe XML elements, or to provide additional information about elements. From HTML you can remember this construct: . In this HTML example SRC is an attribute to the IMG element. The SRC attribute provides additional information about the element.

Attributes are always contained within the start tag of an element. Here are some examples:

HTML examples:



XML examples:

Usually, or most common, attributes are used to provide information that is not a part of the content of the XML document. Did you understand that? Here is another way to express that: Often attribute data is more important to the XML parser than to the reader. Did you understand it now? Anyway, in the example above, the person id is a counter value that is irrelevant to the reader, but important to software that wants to manipulate the person element.

Use of Elements vs. Attributes

Take a look at these examples:

Using an Attribute for sex:


  Anna
  Smith


Using an Element for sex:


  female
  Anna
  Smith

In the first example sex is an attribute. In the last example sex is an element. Both examples provides the same information to the reader.

There are no fixed rules about when to use attributes to describe data, and when to use elements. My experience is however; that attributes are handy in HTML, but in XML you should try to avoid them, as long as the same information can be expressed using elements.

Here is another example, demonstrating how elements can be used instead of attributes. The following three XML documents contain exactly the same information. A date attribute is used in the first, a date element is used in the second, and an expanded date element is used in the third:


Tove
Jani
Reminder
Don't forget me this weekend!
 


12/11/99
Tove
Jani
Reminder
Don't forget me this weekend!
 



  12
  11
  99

Tove
Jani
Reminder
Don't forget me this weekend!

Avoid using attributes? (I say yes!)

Why should you avoid using attributes? Should you just take my word for it? These are some of the problems using attributes:

attributes can not contain multiple values (elements can)
attributes are not expandable (for future changes)
attributes can not describe structures (like child elements can)
attributes are more difficult to manipulate by program code
attribute values are not easy to test against a DTD

If you start using attributes as containers for XML data, you might end up with documents that are both difficult to maintain and to manipulate. What I’m trying to say is that you should use elements to describe your data. Use attributes only to provide information that is not relevant to the reader. Please don’t end up like this:


 


This don't look much like XML. Got the point?

An Exception to my Attribute rule

Rules always have exceptions. My rule about not using attributes has one too:

Sometimes I assign ID references to elements in my XML documents. These ID references can be used to access XML element in much the same way as the NAME or ID attributes in HTML. This example demonstrates this:


  
    Tove
    Jani
    Reminder
    Don't forget me this weekend!
  

  
    Jani
    Tove
    Re: Reminder
    I will not!

The ID in these examples is just a counter, or a unique identifier, to identify the different notes in the XML file.

Biztalk Schemas

artcorner — Mon, 23 Feb 2009 17:20:51 +0000

There are basically four types of schemas available.

XML Schema

An XML schema defines the structure of a class of XML instance messages. Because this type of schema uses XML Schema definition (XSD) language to define the structure of an XML instance message, and this is the intended purpose of XSD, such schemas use XSD in a straightforward way.

Flat File Schema

A flat file schema defines the structure of a class of instance messages that use a flat file format, either delimited or positional or some combination thereof. Because the native semantic capabilities of XSD do not accommodate all of the requirements for defining the structure of flat file instance messages—such as the various types of delimiters that might be used for different records and fields within the flat file—BizTalk Server uses the annotation capabilities of XSD to store this extra information within an XSD schema. BizTalk Server defines a rich set of specific annotation tags that can be used to store all of the required additional information.

Envelope Schema

An envelope schema is a special type of XML schema. Envelope schemas are used to define the structure of XML envelopes, which are used to wrap one or more XML business documents into a single XML instance message. When you define an XML schema to be an envelope schema, a couple of additional property settings are required, depending on such factors as whether there are more than one root record defined in the envelope schema.

Property Schema

A property schema is used with one of the two mechanisms that exist within BizTalk Server for what is known as property promotion. Property promotion is the process of copying specific values from deep within an instance message to the message context. From the message context, these values are more easily accessed by various BizTalk Server components. These components use the values to perform actions such as message routing. Promoted property values can also be copied in the other direction, from the more easily accessible message context back into the depths of the instance message, just before the instance message is sent to its destination. A property schema is a simple version of a BizTalk schema that plays a role in the process of copying promoted properties back and forth between the instance message and the message context.

Various Biztalk Modules

artcorner — Mon, 23 Feb 2009 17:08:59 +0000

Below picture visualizes various modules in Biztalk Server

Biztalk Architecture

artcorner — Mon, 23 Feb 2009 17:01:29 +0000

The picture which helps me to understand the basics of Biztalk Architecture

Persistant Point

artcorner — Sun, 22 Feb 2009 15:02:05 +0000

After certain actions in a Biztalk orchestration the state of the entire orchestration – including full message data, variable values, etcetera – is serialized into xml and stored to the Biztalk database. This is persistence. It’s like a check point in a video game.

Often ignored, but a really important point when designing orchestrations is of course the persistence points. Understanding of the persistence points becomes really an important factor if you are dealing with orchestration performance. Lets take a glance at what they are and how we can take care of them.

The SQL Server does bulk of the job at the backend to keep the BizTalk server running. BizTalk has this inherent behavior of saving the orchestration state to the SQL Server so as to quickly and easily recover from any failures. Persistence points are those points in the orchestration that save the orchestration state to the database.

However, this behavior induces latency in the execution of the orchestration because of several database trips that are needed when executing the them. Although its quite difficult to avoid the persistence points when designing the orchestration, understanding them and using appropriate shapes and patterns can ensure that you keep them to minimum. For example, the orchestration persists its state after end of every transaction, at the end of orchestration, after every send shape etc. However, if the Send shapes are enclosed within atomic transactions, they do not persist the state. Instead, the state is then persisted at the end of the atomic transaction.

In a usual scenario, the persistence in the orchestrations occur at the following points -

End of a transactional scope (atomic or long running)
At the execution of other orchestrations through the Start Orchestration shape
At the Send shape (except in an atomic transaction)
At the end of the orchestration

Apart from that, the engine might decide to persist the orchestration in the following cases -

When an Orchestration Instance is suspended
When the system shutdowns in a controlled manner
When the engine determines it wants to dehydrate
When an orchestration instance is finished

Persistence can also occur at debugging breakpoints when the orchestration debugger is being run.

Lets just illustrate with a simple example how persistence points can increase the latency during the execution of the orchestration.

Consider orchestration scenario that has 2 send shapes sending messages to two different systems.

This can be implemented in the following ways -

A. A parallel branch that has two Send shapes.

B. Two send shapes being executed sequentially in the orchestration.

C. Two send shapes being executed sequentially in the atomic shape.

Question: Now which of these do you think would work the fastest?
Of course the (B) scenario is out of question. The two Send shapes will have their persistence points. If the Send shape is the last shape in the orchestration, then the persistence point of the Send shape and the end of the orchestration will be batched together to result in a single persistence point instead of two.

With scenario (A) even we have the parallel branches in place, Biztalk by nature executes them in a sequential manner. Parallel branches do not necessarily mean they are executed on separate threads. Hence, even in this case, it results in sequential execution with two persistence points. Infact, in this case, the persistence point will not be batched with end of the orchestration and hence it results in the slowest of the three.

The scenario (C) takes the fastest position of the three. The send shapes are enclosed in the atomic shape and hence the state is persisted only at the end of the atomic shape. Again, if it is at the end of the orchestration, the persistence point will be batched with the persistence point at the end of the orchestration. Hence resulting in a single persistence point.

Hence, when designing the orchestration from the performance perspective, it is imperative to take a look at what points the orchestration will be persisting the data. Reducing the database trips helps increase the performance of the orchestration.

104 Differences between Biztalk 2004 and Biztalk 2006

artcorner — Sun, 22 Feb 2009 10:00:42 +0000

Setup

Dramatically simplified one-computer installation experience
Component updater technology that checks for missing prerequisite components and installs them automatically from the Web or from a pre-downloaded CAB file
More flexibility for multi computer installations
Seamless upgrade from BizTalk Server 2004
Automatic installation of 64-bit software on 64-bit operating systems
Ability to install 32 and 64-bit engine components side-by-side on 64-bit computers

Configuration

Default configuration that is targeted for new developers
New feature-based user interface (UI) that presents a consolidated view of each feature
Ability to selectively configure or unconfigure each feature
Consolidated views for databases and service accounts
Reentrant design allows you to go back to change settings or edit configuration options after the initial configuration is complete

Microsoft Management Console (MMC) administration

A single management tool for configuring, deploying, managing, and monitoring your BizTalk Server applications
Task-based design provides easy access to your most common tasks
Integrated hub page or dashboard that summarizes system health
Powerful querying capabilities for performing root-cause analysis
Updated management pack for use with Microsoft Operations Manager (MOM) 2005
Support for bulk operations greatly speeds up remediation of errors
Support for clustering BizTalk Hosts that provide 99.99 percent availability
Ability to view message properties, body, and parts in the message viewer. Enhanced error and event reporting with the exception message box capabilities built in
BizTalk messaging services can be clustered to better support high availability
Addition of a limited-privilege BizTalk Operator role for administration
Tracking and reporting APIs
Visual Studio is no longer required or recommended in the production environment

Application concept

Introduction of the BizTalk application, which is a collection of BizTalk Server artifacts for simplified deployment, management, and troubleshooting
Ability to quickly import and export a BizTalk application
Application-based views of errors in message processing

Application deployment

One-click start and stop operations for deploying and undeploying BizTalk applications
Built-in support for deploying all BizTalk Server artifacts, including COM components, ad-hoc scripts, and generic files
Ability to package and deploy applications across servers that use Windows Installer technology
New deployment command line tool

Business Activity Monitoring (BAM)

Proactive business alerts and notifications support
New customizable BAM portal built on ASP.NET 2.0 technology
Operations integration enables escalation from BAM operator to IT administrator
New BAM addin for Excel
Enhancements to the BAM Manager
Support for messaging and message tracking

Tracking Profile Editor (TPE)

Ability to retrieve activities from the BAM database
Activity-centric design
Support for messaging

Business Activity Services (BAS)

Enhancements to the BAS Web site that provide tighter integration with the new Windows SharePoint Services adapter
Support for preconfigured send ports, called mapped ports
Improvements in the parameter service that provide support for structured, typed parameters
Inclusion of a Message Repair sample from SWIFT
Improvements in the Microsoft Office InfoPath UI
Integration with new BizTalk Server setup & deployment tools for a single, BizTalk Server wide deployment solution

Orchestration Designer for Business Analysts (ODBA)

Ability to model high-level business process workflows:
Create business process workflows using ODBA
Export ODBA workflows to BizTalk Orchestration Designer (OD)
Import existing orchestrations from OD to ODBA for documentation purposes
Improved layout provides an enhanced first-time design experience together with the capability to read imported orchestrations
Support for BAM Activity Definition XML
Ability to define global “data of interest” list
Import XML into Excel at design time to avoid duplication of data entry in Excel
Invoke BAM Web pages directly from ODBA

Orchestration Designer improvements

Zoom support
Ability to preserve collapsed and expanded shapes across save operations
Ability to call pipelines from an orchestration for outbound batching support

New adapters

POP3 receive adapter. For more information about the POP3 Adapter
Windows SharePoint Services adapter

Enhancements in existing adapters

Message Queuing adapter and IBM MQSeries adapter now ship in the box
More granularity in the performance counters for all adapters
SMTP adapter enhancement
Enhanced e-mail composing
File adapter enhancements
Ability to connect to UNC shares using alternative credentials
Migration of several registry keys to property pages that can be modified in the UI
Directory browse button
HTTP adapter enhancements
Ability to optionally suspend failing requests
Migration of BatchSize registry key to the UI
SOAP adapter enhancements
Ability to call Web services without orchestrations (messaging-only scenarios) by using content-based routing (CBR) send ports
Ability to call Web services that have array-type parameters
IBM MQSeries adapter enhancements
Uses “dynamic send” capability to dynamically receive messages from a queue
Ability to receive messages based on Match options
Ability to create queues in Windows MQSeries Queue Manager from within orchestrations or pipeline components
MSMQT adapter enhancement
Ability to easily remove the MSMQT adapter

Developer enhancements

Flat-File Schema Creation Wizard
Visual Studio 2005 support only; runtime built on .NET Framework 2.0
Automated solution level redeploy

Messaging Engine and core enhancements

Ability to resume more types of failed and suspended messages
Ability to route failed messages together with detailed error information for automated error handling
Support for routing messages with errors to business owners for correction, instead of suspending them
In-order delivery for all transport types that preserves the message order from the publisher to the subscriber
Large message transformation
Engine throttling
Execution of pipelines from within orchestrations
New and more detailed performance counters
Enhanced error-handling functionality
Fewer tools and manual tasks
Resubmit capability
Improved run-time scalability when tracking is enabled
Orchestration engine can add message parts dynamically

Enterprise Single Sign-On (SSO)

Password synchronization capability
Non-Windows, or host-initiated SSO
MMC snap-in for management – based on MMC 3.0
Client UI for end users
Ability to specify multiple accounts for access accounts
Extension in group type affiliate application to specify multiple mappings
Remote IssueTicket capability
Ability to specify ticket time-out at the affiliate application level
Back-up secret capability in configuration UI

Biztalk 2006 Advanced Features

artcorner — Sun, 22 Feb 2009 09:37:30 +0000

#	Features	Area
1	*Host Throttling* More sophisticated engine throttling in BizTalk Server 2006 prevents unrecoverable situations from occurring by closely monitoring many facets of the BizTalk runtime and adjusting processing accordingly. Plus, easily configurable throttling parameters exist on the host level allowing for tuning at the appropriate level of granularity.	Core Engine
2	*Admin MMC Console* Our MMC console is now a one-stop-shop for all things “administration”. Hub pages provide high level dashboard summaries of the health of your group but also allow for more detailed drilldowns and diagnosis. The console has advanced querying capabilities, bulk terminates and resubmissions, and easy message viewing, for starters.	Administration
3	*Application concept* Introducing the strict notion of an application container allows for a much more intuitive experience with the BizTalk product and one that is consistent across developer and IT Pro roles. When you package all the necessary artifacts into an application container, you can then manage that application selectively. Now administrators can deploy, start, stop, manage, and troubleshoot at the application level with just a few mouse clicks.	Deployment
4	*New platform support* BizTalk Server 2006 has support for Virtual Server 2005, the x64 platform, SQL Server 2000 and SQL Server 2005, as well as Visual Studio .NET 2005 and the .NET Framework 2.0, allowing you to leverage all of the latest Microsoft technologies.	Platform
5	*Improved Setup and Configuration* Performing a single box buildout or a complicated multi-machine topology has never been easier with the streamlined setup and configuration processes in BizTalk Server 2006. A pre-requisite checker, a seamless upgrade path from BTS 2004 to BTS 2006, and prescriptive multi-box buildout and upgrade guides are just some of the additions contributing to this area of the product.	Setup
6	*New Adapters* We now include many more adapters in the box at no extra cost including SAP, MSMQ, MQSeries, POP3, WSS, and many more as part of our Enterprise Application Adapters suite.	Adapters
7	*Operator Role* This new role allows users to administer their BizTalk group without being able to view potentially sensitive message content or promoted properties – a regulatory requirement for some lucky companies.	Administration
8	*Routing of failed messages* This feature allows you to optionally subscribe to suspension events that occur in the message engine and handle them. Logging of malformed partner documents or creating email alerts for failures are just a few creative possibilities.	Core Engine
9	*Flat file schema generation wizard* Developing flat file schemas to process documents from legacy systems used to come with headaches, but this process has been significantly improved by the introduction of a FF Schema Wizard in BTS 2006.	Development
10	*In-order delivery on send ports* This adapter-agnostic feature allows any send port to process outbound documents serially. Failure options also exist to allow even very strict FIFO solutions to be easily realized.	Core Engine
11	*Streamlined Developer Redeployment* Preserving users’ bindings between assembly redeployment from Visual Studio increases the productivity of developers and greatly decreases time to solution.	Development
12	*Enhanced e-mail composing* The SMTP adapter has been completely overhauled to make it trivial to compose e-mail messages and hence easily involve users in your business processes.	Adapters
13	*Best Practice Analyzer* This utility will allow users to check their environment for utilization of best practices prior to going live in production. BPA web updates will ensure all of the latest knowledge is quickly and easily disseminated to users. On the road to bulletproof deployment.	Administration
14	*BAM Enhancements* Alerting and notification make involving business users in your business processes an asynchronous, event-driven model. Plus, out of box BAM portals and web parts make it easier to display relevant and customized content to data consumers. Allowing BAM in messaging-only solutions and continuation from non-BTS applications also opens up new doors in terms of visibility into your extended business processes.	Business Activity Monitoring
15	*Improved large message transformation* Messages over a configurable size threshold can now be mapped in a streaming fashion, utilizing minimal system resources and ensuring platform stability.	Core Engine
16	*E2E Scenarios* New to our documentation and SDK are the End to End Scenarios which describe and illustrate proven practices for developing SOA, B2B, and BPM scenarios with BizTalk Server via production-ready solution samples.	Documentation
17	*More resumable suspension scenarios* More cases resulting in resumable suspensions allow for easier manageability and decrease total cost of ownership for IT professionals.	Core Engine
18	*Updated MOM Pack* An updated MOM Pack supporting Microsoft Operations Manager 2005 will be available and customized to the BizTalk Server 2006 product.	Administration
19	*Non-atomic interchange processing* Interchanges are batches of sub-documents that arrive as one message. Previously, if 1 of 100 sub-documents were to fail processing, the other 99 documents would be automatically suspended as well. This option allows for sub-documents to be processed more independently.	Core Engine
20	*Remote administration capabilities* Admin-only installs allow remote users to administer multiple environments from a single MMC console. This eliminates VS as a requirement for overseeing and managing your production environments.