BizTalk Server Adapter for Printing

table of contents

 

Introduction. 3

Context. 3

Adapter Communication Patterns. 3

Implementation. 4

Design Time. 4

Runtime. 8

Registration. 9

Case study. 10

Conclusions. 10

 

Introduction

So when actually you will think of writing a custom adapter?

There are various BizTalk adapters developed by third parties that could be leveraged in your integration project. But what happens if the adapters available do not support the functionality that your solution requires? What if you have your own custom server application that you want to integrate with BizTalk? At this point, you may want to consider building a custom BizTalk adapter using the Microsoft BizTalk Server 2004 Adapter framework.

One of our client’s requirements was, to dynamically send messages to printer based on content; this promoted me to write a custom print adapter for BizTalk Server.

This print adapter is quite similar to SMTP Adapter wherein you can send messages to but does not pull any messages for BizTalk processing.

 

Context

Adapters play a fundamental role in connecting BizTalk Server 2004 with target applications or technologies. There are three categories of adapters:

·         Application adapters like SAP, JDE, PeopleSoft, and Siebel.

·         Technology adapters like File, FTP, HTTP, MSMQ, SMTP, and Web services.

·         Data Adapters like SQL Server, Oracle, or DB2.

Adapters can also be classified into following category

·         In-process adapters, such as the File adapter, execute in the BizTalk Server 2004 process space, called a host instance, which manifests itself as the Windows NT service BTSNTSVC.exe

·         Isolated adapters execute in their own process space. You may choose to create Isolated adapters for security reasons or for design reasons. For example, the BizTalk Server 2004 SOAP adapter is implemented as an IIS extension and runs inside the ASP.NET process space rather than the BizTalk Server process space.

 

Adapter Communication Patterns

Before we delve too far into the details of configuring adapters, it is important for you to understand the way in which an adapter can communicate with BizTalk and other external applications. This will make some of the configuration choices more meaningful when it comes to configuring receive and send ports in the next section.

The BizTalk adapter framework provides a number of communication patterns that can be supported by an adapter, as follows:

·         One Way Receive BizTalk receives a message from a wire protocol (File, HTTP, and so on) and passes it off to a receive pipeline, which then persists it to the MessageBox database.

·         One Way Send BizTalk picks up a message from the MessageBox database and passes it through a send pipeline, which then sends it out to the appropriate endpoint.

·         Request Response BizTalk receives a message in the same way as a One Way Receive, but then the requesting application waits for a response from BizTalk. An example of this type of interaction is exposing an orchestration as a Web service via the SOAP adapter. In this case, a client application sends a request into the SOAP adapter, bound to the orchestration, and then waits for a response.

·         Solicit Response BizTalk sends a message to an application in the same way as a One Way Send, but then it waits for a response from the external application. An example of this type of interaction is consuming a Web service within an orchestration via the SOAP adapter. In this case, the orchestration makes a request out to the Web service and then waits for a response.

 

Implementation 

The BizTalk Server 2004 Adapter framework is an extensible API that sits on top of the underlying BizTalk messaging engine. It provides design-time and runtime interfaces that allow the developer to build a BizTalk adapter. The framework is a COM API that is accessible to managed code via a .NET Primary Interop assembly. The recommended approach for adapter development is to use managed code; therefore, all code samples in this section will be in C#.

I have used Custom Adapter wizard from GotDotNet, now available in BizTalk 2006.

Generally, approach to develop a custom adapter falls broadly into three categories

·         Design time

·         Runtime

·         Registration

 

Design Time

This version of Print adapter takes Printer name, font face, font size and document name (appear in printer queue). This can be extended if required.

Following class diagrams are generated using one of VS.NET 2005 new feature.  

Print Transmit Adapter class diagram

One should implement UpdateUriForDynamicSend menthod to make adapter dynamic.

Base adapter class diagram

 

Adapter Management class diagram

Runtime

Print adapter is One-Way Send just like SMTP adapter

The messaging engine will deliver messages to the send adapter either in IBTTransmitter.TransmitMessage() or IBTTransmitterBatch.TransmitMessage(), depending on whether the adapter is batch aware. Both methods have a Boolean return value that indicates whether the adapter sent the message.

If the adapter returns true, the engine will delete the message from the application queue on behalf of the adapter. If, however, the adapter returns false, the adapter is responsible not only for deleting the message from the application queue, but also for handling any send failures that, for example, require the message to be retried for transmission, suspended, and so on.

For adapters returning false, the TRansmitMessage() implementation should be a nonblocking call and should therefore add the message to a logical queue of messages ready to be sent. The adapter should have its own thread pool, which will service the queue, send the messages, and then notify the engine of the outcome of the transmission.

The message engine threads are typically more CPU bound than the threads used to send data over the wire. Mixing these two types of threads has a negative impact on performance. Nonblocking send adapters enable the decoupling of these two types of thread usage and yield a significant performance improvement

One-way send sequence diagram

For the best performance, send adapters should be nonblocking and batch aware. When the BizTalk FILE adapter was changed from blocking and nonbatch aware to nonblocking and batch aware, a threefold performance gain was realized.

Blocking transmits can cause a performance degradation of an entire host instance because if the send adapter does excessive blocking in transmitMessage(), it will be preventing engine threads from delivering messages to other adapters.

 

Registration

Adapter registration can be done using Adapter Registration Wizard available at SDK or can be done by updating the registry with the appropriate adapter settings via a registry file

Finally you need to add adapter to BizTalk using BizTalk MMC.

 

Case study

This adapter was written of a global investment bank for there message broker application and is successfully deployed with zero defects.

 

Conclusions

There are many applications and data adapters for BizTalk are available but in live scenarios one can come across to implement a custom functionality which is very specific to business. Thankfully this is yet very generic feature which might required for any business.

 

I am thankful to John Callaway (the instructor, of BizTalk Deep Dive training courses in the UK) for encouraging me to write a custom adapter for printing.

 

posted @ Friday, May 05, 2006 4:23 AM | Feedback (3)

BizTalk Server Performance Tuning

BizTalk Server Performance Tuning...

 

Well…with every project whether it is a windows application, a web application or any integration project; performance tuning is the most sizzling area of debate.

 

Following are the findings from the performance carried out on heavily loaded message broker architect on Biztalk server 2004. I will not be going to talk about the hardware used or message volume (consider it as best and high respectively.)  You can also consider these points as Do and Don’t for any Biztalk solution.

 

• Avoid extensive use of atomic scope

There are various scenarios where developer uses atomic scope unintentionally without knowing the impact.

 

A typical example is when you have to marked Orchestrations as long running because whenever there is invocation of the rules engine via the Orchestration ‘rules’ shape needs to be performed within an atomic scope, but an atomic scope may only be present in an orchestration that is marked as long running.

 

The best approach is to call the rules engine via custom code in an ‘expression’ shape, this would enable the removable of the atomic scope and also the orchestration could then be marked as transaction type = none. This gave a performance improvement in the order of 15%

 

• Effect of Tracking via BAM

BAM is used across the business process to monitor business activities, as an general approach a user can track or raise BAM events at any point in orchestration but this will be a major performance issue.

 

The reason for this is due to the fact that the buffered event stream is called in a manner that forces it to be flushed to the data base on every BAM API call, a more performant approach would be to only flush the BAM stream at persistence points which would result in fewer database writes. However, in order to do this the BAM buffered event stream would need to be state in the Orchestration, to do this correctly would require it to be marked as seralizable, currently it is not. Alternatively the Tracking Profile Editor could be used to achieve this.

 

 

• Delivery Notifications

The performance cost of using ‘delivery notifications’ in the Orchestration is the most remarkable discovery. Delivery notifications are Biztalk system level messages that are sent internally to the Biztalk engine; they enable an Orchestration to block on a send operation until the message has been successfully transmitted by the send adapter. This is important due to the nature of the scalable architecture of Biztalk, where, a send from Orchestration is always via persistence to the Message Box, which enables any send host to actually send the message. The down side of this approach is that a successful send from an Orchestration simply means the message was successfully persisted to the message box and does not necessarily mean the message was actually transmitted. For this reason the solution marks send ports in Orchestration as delivery notification required.

 

Delivery notifications effect performance in two ways, firstly the publication and routing of these internal messages adds additional load to the Message Box and the engine. Secondly, there is reduced concurrency of these Orchestrations which may lead to performance degradation.

 

Not using delivery notifications for this scenario gave a performance gain in the order of a 48% performance.

 

 

• Inline Send to a physical Location (BizTalk 2006 goodies)   

On analysis of the performance data, particularly around the performance cost of the delivery notifications, it was determined that significant gains could be realised by executing the send pipeline within Orchestration and sending the message from the Orchestration, i.e. an inline-send from Orchestration. The benefit of doing this would be to eliminate two Message Box publications and routings for each send to an MQ queue, the performance gains alone for not using delivery notifications were in the order of 45%, it was felt that the removal of a further message box publication and routing would yield an additional performance gain that would be significant.

 

For this to be possible a mechanism to execute the send side pipeline from within the Orchestration would be required, in addition, code would need to be written to transactional write a message to the MQ queue, which would have the same effect as using delivery notifications. One problem here is that there is no way out of the box to execute a pipeline from within an Orchestration in Biztalk Server 2004.  

 

Also to be noted is that the next version of Biztalk is currently planned to natively support execution of pipelines from within an Orchestration, thus meaning only a custom component to send the message to an MQ queue would need to be developed.

 

posted @ Wednesday, March 29, 2006 3:30 AM | Feedback (1)

BizTalk Server 2004 Adapter for Printing 2.0 (supports dynamic send port printing)

This release of Printing Adapter comes with following enhancements

1. Adapter to support dynamic send port printing
2. Adapter to support for dynamically modifying the Document Name that is shown in the print spool.

 

Actually after first release, I didn’t have an opportunity to test and enhance these missing features. This is actually implement by my role model Sir Kevin Smith

 

The updated code is available here….

 

 

posted @ Thursday, March 23, 2006 6:39 AM | Feedback (1)

Tip to improve developement with Biztalk Rule Engine

For those guys who are working extensively on MS rule engine and have faced trouble while

a)     Adding rule to already deployed policy

b)     Resetting arguments of rule

 

Trivial approach is either to remove policy and re-import it or make a copy of existing policies (1.0,1.1,1.2) but when u actually import the combination of tested policy and vocabulary, it say missing vocabulary or dependency could not be find.

 

TIP:

You can set nStatus to 0, this will give you flexibility to meet above two points without re-importing and creating versions of policies.

 

Use BiztalkRuleEngineDb

Update re_ruleset

set nStatus = 0

Where strName = 'MT340_Validation_Policy'

 

 

This holds good for vocabularies also.

 

*courtesy: Neha, my collugue

posted @ Monday, December 12, 2005 3:19 AM | Feedback (1)