Services & Integration Stuff

BizTalk - The way I see it! – Part 4: Developing Schemas

2008-05-02T08:04:00Z

Today, I’ll talk about how to develop Schemas using BizTalk, if you don’t know what a schema is, kindly use this link.

As a prerequisite, you must install the following software in order to develop BizTalk Applications:

· Microsoft Visual Studio (2003 or higher)

· Microsoft BizTalk Server 2006 (preferably R2), and its prerequisites

After you install BizTalk, Kindly walk with me thru the following steps:

1. Open Visual Studio

2. In the new Project window, you should see something similar to this

3. After selecting “Empty BizTalk Server Project” from templates pane, write a descriptive name of the new project, let’s say, “BizTalkTraining.OneBigApplication”

4. Next step is to create some folders inside the newly created project, as the following

This step is not mandatory; however, creating these folders will help you with the namespaces and target namespaces.

5. To create a new Schema, right-click the Schemas folder and say Add - new Item

6. In the Add New Item window, choose Schema, and type the name of the new Schema, let’s Say “Order”

7. Now, you should see the BizTalk Schema Editor,

Just a reminder: we’re in the process of creating a new schema that should describe -at the runtime- the shape of an XML document

8. Consider the following XML, we need to create our schema to match this XML

<Order>

<OrderID>123</OrderID>

<OrderAmount>10.1</OrderAmount>

<Products>

<Product ProductID=”456”>

<ProductName>Xyz</ProductName>

</Product>

</Products>

</Order>

By examining this XML, we should have the following elements to create the schema:

· One root element, named Order, under this root we’ll have:

o Element named OrderID

o Element named OrderAmount

o Record named Products, and under this,

§ Record named product, under this

· Attribute named ProductID,

· Element named ProductName

9. Going back to our XSD editor, we will do the following to form the new schema

a. Rename the Root element to be Order

b. Right-click Order node, and say Insert Schema Node – Child Field Element,

c. Rename the new field element to be OrderID

d. Repeat the same step for OrderAmount (Child Field Element), Products (Child Record),

e. Now, r-click the Products node, and add a new Child Record, rename it to Product

f. On Product, add a new Child Field Attribute named ProductID, and a new Child Field Element named ProductName

10. While clicking any of these nodes, like OrderAmount for example, notice the properties window in Visual Studio and how it changes from element to another.

11. Now you can generate an instance of this XSD

Check the VS output window to see the new instance.

As you can see in the context menu above, you can also validate the schema, or even validate the instance against this schema.

Quick Tip: if you have already an XML file that you want to create a schema for, you can “Add Generated Items” found under Add when right clicking the project (or any folder)

If you are new to BizTalk development, I urge you to exercise and discover more inside BizTalk schema editor. It has a lot of features that cannot be covered in a single blog post!

See you next time with “Developing Maps using BizTalk”

BizTalk - The way I see it! – Part 3: BizTalk artifacts

2008-04-30T23:24:00Z

In the previous posts, I talked about BizTalk Server Architecture after a brief introduction.

Today, I’ll talk about BizTalk artifacts covering the following points,

· Schemas

· Maps

· Orchestration

· Adapter

· Pipeline

Schemas (or XSD)

A schema is the standard way to describe XML document structure. BizTalk cannot deal with Xml documents (messages) without their XSD (unless you’re using these messages in a non-xml format)

To cut a long story short, XSD to xml is like a Class to its instance

Maps

Since BizTalk is used to integrate more than one system (definitelyJ), and given that different systems uses different schemas, so there gotta be something to “map” these different schemas to each other.

So, Maps are used to transform one schema to another. If you guys are familiar with XSLT, you should know exactly what I’m talking about.

Orchestration

Short definition: executable business process, you can consider it as a workflow (for now)

Longer definition: we need 2 posts (at least) to cover this; however this is already in my plan for the upcoming posts, God willing.

Adapter

When integrating with a system (say SQL Server), BizTalk should know how to send requests and receive responses to this system (such as select statements, executing stored procedures, etc...). That’s why we need adapters, to convert XML (BizTalk format) to some System format and the way back.

Pipeline

As we have seen in previous post, In case BizTalk receives a message, the message is processed by the adapter; it goes thru a pipeline which does the following:

1. Decode: Decrypts or decodes the message data

2. Disassemble: Disassembles an interchange into smaller messages and parses message contents

3. Validate: Validates the message data, generally against a schema

4. Resolve Party: Identifies the BizTalk Server party associated with some security token in the message or message context

However, all of these steps are not mandatory; some of them will function according to the configured pipeline.

For example, XML receive pipeline (BizTalk out of the box), only does the validation step (step 3).

See you next post with “Developing Schemas Using BizTalk”

BizTalk - The way I see it! – Part 2: Concepts - Cont

2008-04-11T11:01:00Z

In my previous post, we talked about some basic BizTalk concepts. In this post, we’ll talk about more of these concepts.

Before drilling into details about the BizTalk Server Architecture, let’s talk bit about a design pattern called Pub/Sub.

What is Pub/Sub??

Publish/Subscribe (aka Observer) is a design pattern that implies the following logic:

Consider a scenario where you tell your brother “bro, when my friend ABC calls me, please tell him I’m waiting for him at the XYZ place”

When you said such sentence, you just created a subscription!! COOL

Next day, your friend ABC calls at home, … By doing this, he just published a specific event.

If you previously worked with SQL Notification Services, you should be familiar with this concept. When a particular data is altered on the database, Notification Services sends a mail message for all subscribers.

BizTalk Server Architecture:

As shown above, BizTalk is composed from the following components:

· Cross-cutting component: like Process Management Administration, Deployment, BI, Reporting, Monitoring, etc …

· Orchestrations: are a BizTalk “workflow” that hosts some business process, we’ll take about it in more details on next posts

· Other Apps: It can be any application that consumes BizTalk artifacts, it can be even your .Net Console application that consumes a business process

· Pipeline: a pipeline is simple a pipeline that BizTalk messages should go through, it can be of different types, it will take a bit of our focus in next posts

· Adapters: or Transport Handlers, Converts message contents from one format to another, more to come on this

· MessageBox: this is the most interesting part in the architecture; it’s a SQL database that keeps our subscriptions configuration. Guided by a framework, it helps BizTalk determines how to process all messages. In our previous example of Pub/Sub, your brother brain acted as a MessageBox.

BizTalk Server Message:

· BizTalk Message is a typical XML Document. Important thing you should know about BizTalk Message, that is “BizTalk message is immutable”, i.e.: after the message is constructed, it can’t be changed.

· This message can contain some context properties that helps BizTalk routes this message to its correct destination.

· BizTalk also can route messages according to its contents; known as Content-Based Routing (CBR)

Example: you have a message that contains a customer order, you can configure BizTalk to route this kind of messages to two different destinations according to the order quantity.

· When can we consider the message constructed? When it’s placed in MessageBox.

Message Lifecycle inside BizTalk:

Ok, let’s take it step by step:

1. A message is received in BizTalk at something called Receive Port

A receive port contains one or more receive locations, Also Port can contain XSLT (Map) that transforms messages from one format to another.

A receive location contains a configuration of receive adapter and receive pipeline

A receive adapter: at this point, the configured adapter reads the Stream and constructs a message and places it on the pipeline

2. The constructed message is received on the pipeline, the receive pipeline contains 4 stages (we’ll take about it more on next posts)

3. The messaging engine takes the output of the pipeline and places it on MessageBox.

This engine will detect where to route this message according to subscriptions stored in MessageBox.

4. In this step, the messaging engine detected that a specific orchestration (Business Process) is waiting for this message type, so it simply activates an instance of this orchestration

5. After the message is processed by the orchestration, it’s placed again on MessageBox

Again, Messaging engine detects where to route this message according to the stored subscriptions

6. Messaging engine detected a Send Port waiting for this processed message,

A Send Port contains a configuration of send pipeline and send adapter

By sending the processed message to the send port, it’s grabbed by the Send Pipeline,

A Send Pipeline contains 3 stages (more on upcoming posts)

A Send Adapter reads the message and writes on a stream

See you next post, with “BizTalk artifacts”.

Mike

BizTalk - The way I see it! – Part 1

2008-04-09T17:21:00Z

Hello again,

It crossed my mind a couple of weeks ago to share some BizTalk knowledge with you guys, reason being it takes a lot of brains for any BizTalk developer to find information on the internet about how to develop BizTalk applications in one place.

You may wonder, why I shouldn’t surf MSDN instead of reading this tedious blog !!

The answer is simple, any developer working with any development environment; he/she “may” ( aka: must :) ) encounter issues finding a specific piece of info related to this development environment/product. This chain of posts is aimed to help BizTalk developers finding this particular piece of info easily by reading a training-like blog posts.

Points Covered:

Thru the upcoming posts, I’ll try to cover the following points:

Must-know BizTalk concepts
BizTalk artifacts

Schemas
Maps
Orchestration
Pipeline
Adapter

Developing Schemas Using BizTalk
Developing Maps using BizTalk
Developing Orchestration using BizTalk
Developing Pipelines using BizTalk
Deploying a BizTalk application

Note: I may add more points, or add details more than originally planned according to your comments, so sharing is most welcome as usual.

Who should read?

o BizTalk developers

o BizTalk developers wanna-be

o Integration geeks

Prerequisites:

o Microsoft Visual Studio 2005 (or 2008) and the development of .NET solutions

o Programming with the .NET Framework

o Extensible Markup Language (XML)

o Extensible Style sheet Language Transformations (XSLT)

o XML Schema Definition Language (XSD)

o Web Service use and development

So, What’s BizTalk? And what’s the need for it?

Firstly, it’s not fair to say “Microsoft BizTalk server”, but rather we should say “Microsoft BizTalk server & technology”.

Why? Because simple it’s not just another server that Microsoft released, it’s also a new technology, i.e.: new Integration framework

The need: basically because computer systems are not islands, they need to integrate. The need for an integration framework emerged since these systems are different in O/S platform, security mechanisms, and network architecture.

Microsoft BizTalk Framework: The Microsoft^®BizTalk ^TMFramework is a comprehensive XML-based implementation framework developers can use to design and implement solutions based on a Web Services Architecture. It helps establish a set of guidelines for the publishing of schemas in XML and the use of XML messages to easily integrate software programs to build rich, new Web-based solutions.

Microsoft BizTalk Server: BizTalk Server provides the tools and infrastructure companies require to exchange business documents among various platforms and operating systems, regardless of the application being used to process the documents. Using BizTalk Server, companies can easily exchange documents between applications within their own organization. BizTalk Server also provides a standard gateway for sending and receiving documents via the Internet. By taking advantage of BizTalk-compatible messages and compliant schemas, BizTalk Server enables organizations to conduct business online effectively and efficiently.

Source: http://www.microsoft.com/presspass/features/2000/01-03xmlglossary.mspx

More & more in the upcoming posts, cya then

Mike

Egoless Programming !!

2007-04-29T12:27:00Z

I was surfing the internet last week when I saw this interesting article, I couldn't help myself reading it altough I had a lotta work. I thought I can share it here with you guys.

I just copied its juice down here, if you're interested to know more, click the link below.

http://builder.com.com/5100-6404-1045782.html

Egoless Programming 10 Commandments
What we need is a set of rules or guidelines to help developers keep themselves (their egos, actually) separate from their code. Hence our Ten Commandments for Egoless Programming, which you can also download in handy "stone tablet" format:

Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
Critique code instead of people—be kind to the coder, not to the code.As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

I'm interested to know your comments/inputs to this and whether it's applicable or not in the "Egyptian" environment:)