Quite a few people have asked “What are sequental convoys?” and “When should I use them?”.  So here is the definition and a quick example on when and/or how I would use them. 

 “A sequential convoy enables multiple single messages to join together to achieve a required result. A sequential convoy is a set of related messages that have a predefined order. Although the messages do not have to be exactly the same, BizTalk Server must receive them in a sequential order.” * Microsoft definition

 Where this becomes handy in business is around batching of messages, an example of this would be when a business process requires batch processing that needs to retain the order in which the message was received.  The way this is accomplished is to put a Listen shape within a delay, which the delay the loop ends.  During this delay time any number of received messages can enter the same business process.  This approach can have a side effect of Zombie messages, but we will look at those in a future post.

In our book, we discuss a pharmaceutical ESB system and we have a process that batches order messages from vendors until 2pm, then sends order processing and shipping.  In this process we show the use of sequential convoys as well as look into the side effects of this process.

 

Printing in Silverlight has been made pretty simple, how it comes with some caveats because it opnly supports rasterized image printing.  Not 100% a problem but in LOB applications will run into issue with printing thinks like PDF, because all formatting is lost in reflect to the final printed document.

Here is a quick code method on printing in Silverlight 4:

PrintDocument documentToPrint= new PrintDocument();
documentToPrint.DocumentName = "Sample Document";
documentToPrint.StartPrint += new EventHandler(documentToPrint_StartPrint);
documentToPrint.PrintPage += new EventHandler(documentToPrint_PrintPage);
documentToPrint.Print();

 

The Life Cycle of a page when requested for the first time:

Initializing: During this phase, the server creates an instance of the server control

Loading: During this phase, the instance of the control is loaded onto the page object in which it is defined.

PreRendering: During this phase, the control is updated with the changes made to it. This prepares the control for rendering.

Saving: During this phase, the state information of the control is saved. For example, if a value is set for the control during the Load event, it is embedded in the HTML tag that will be returned to the browser.

Rendering: During this phase, the server creates the corresponding HTML tag for the control.

Disposing: During this phase, all cleanup tasks, such as closing files and database connections opened by the control are performed.

Unloading: During this phase, all cleanup tasks, such as destroying the instances of server control are performed. This is the final event in the life cycle of a server control

The processing sequence in which a page is processed during a postback event is:

Initializing: During this phase, the server creates an instance of the server control

Loading view state: During this phase, the view state of the control posted by the client is reloaded into the new instance of the control.

Loading: During this phase, the instance of the control is loaded onto the page object in which it is defined.

Loading the postback data: During this phase, the server searches any data corresponding to the control that is loaded in the data posted by the client.

PreRendering: During this phase, the control is updated with the changes made to it. This prepares the control for rendering.

Saving state: During this phase, the change in the state of control between the current request and the previous request of the page is saved. For each change, the corresponding event is raised. For example, if the text of a textbox is changed, the new text is saved and a text_change event is raised.

Rendering: During this phase, the server creates the corresponding HTML tag for the control.

Disposing: During this phase, all cleanup tasks, such as closing files and database connections opened by the control are performed.

Unloading: During this phase, all cleanup tasks, such as destroying the instances of server control are performed. This is the final event in the life cycle of a server control

The events associated with the relevant page cycle phases are:

  • Page Initialization: Page_Init
  • View State Loading:LoadViewState
  • Postback data processing: LoadPostData
  • Page Loading: Page_Load
  • PostBack Change Notification: RaisePostDataChangedEvent
  • PostBack Event Handling: RaisePostBackEvent
  • Page Pre Rendering Phase: Page_PreRender
  • View State Saving: SaveViewState
  • Page Rendering: Page_Render
  • Page Unloading: Page_UnLoad
 

Unfortunately you are not able to run both side by side; so I would suggest you run 2009 in a VM and test your 2010 project in that if you need downward compatibility.

Remember, BizTalk 2010 is the only version of BizTalk compatible with R2 version of the Microsoft Server 2008 and SQL 2008.  Setup is still roughly the same.

 

To add Assembly Viewer to the Windows registry

  1. From the Start menu, click Run.
  2. In the Run dialog box, type cmd.
  3. From the command line, navigate to <BizTalk Server Installation Folder>Developer Tools where BTSAsmExt.dll resides.
  4. At the command line, type:

    regsvr32 BTSAsmExt.dll

  5. To begin using Assembly View, log off and then log back onto the computer.

To remove Assembly Viewer from the Windows registry

  1. From the Start menu, click Run.
  2. In the Run dialog box, type cmd.
  3. From the command line, navigate to <BizTalk Server Installation Folder>Developer Tools where BTSAsmExt.dll resides.
  4. At the command line, type:

    regsvr32/u BTSAsmExt.dll

  5. To complete the removal, log off and then log back onto the computer.
 

I have not been able to find a post or get a true explanation on “reserved words” in BizTalk; however there are a few you should stay away from.  I have personally tested these.

You should refrain from using “BTS” or “EDI” anywhere in your namespace to avoid namespace property look-up issues.

I will be posting more about this as I work through the public version of BizTalk 2010 on Oct. 1, 2010.

 

Public production date announced was Oct. 1, 2010.

Free Developer Version Available

 

Southwest Florida .Net Code Camp is September 25, 2010 this year. Go here for more info.

I will be presenting Developing in MVC2 and Silverlight LOB.

So, if you are in the area or would like to joins us – please register.

 

BizTalk 2010 Public Beta is available at:

http://www.microsoft.com/downloads/details.aspx?FamilyID=0f852e77-f792-4784-b2d4-95113d40db64&displayLang=en

 

How does BizTalk Server work?

At its core it is an event-procesing engine that is based on pubsub converntional patterns.

Wikipedia define pubsub as:

“Publish/subscribe (or pub/sub) is a messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there may be. Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology.”

Common flow in BizTalk is once a meesage is recieved by an adapter, is is run through pre-processing in a pipeline, before being data transformed in maps, then being published to the messagebox.

 * IMPORTANT NOTE: Once a message has entered the messagebox it is immutable (which means CANNOT be changed).

Because of the the nature of pub/sub patterns a bit a latency is introduced, which BizTalk makes up for in the starabilities (durability, reliability, and scalability).

The most dynamic use for BizTalk is in SOA or Service bus architecture.  In this archtecture itinerary services was introduced, which basically applied a message with a purpose concept.

What is this message you talk about?

It is the data processed through the BizTalk messaging engine (IE. XML document, Word Document, Flat file, etc.).  The message basically contains 2 critical parts message type and context.  The message type defines it within the bus and is typically a XML namespace and root node.  The message context is a set of name/value pairs.

How does a message get to and from BizTalk?

BizTalk uses recieve locations which are defined as endpoints, which use a particular adapter which knowns how to receive that specific message.  These receive locations have a particular receive pipeline associated with them, which can be used to modify the message before it becomes immutable.  Now, a receive port is defined as containing more then one receive location, which apply XSLT maps to the message prior to being published to the messagebox.

BizTalk used send ports and orchestrations (2 real type of subscribers within BizTalk), send ports provide a means of transporting messages from the bus and an orchestration provides an executable business process, which uses the message to complete workflow operations.

© 2011 Greg Leonardo Suffusion theme by Sayontan Sinha
show
 
close