Mohammed Atef’s Technical blog

AS/400 BizTalk Adapters

Introduction
Microsoft® BizTalk® Server has providing a suite of new technology adapters. These include a new set of adapters for IBM Host Integration scenarios covering DB2, WebSphere MQ, Host Applications, and Host Files. In this post we shall look at WebSphere MQ and Host Files adapters in detail and explain their capabilities and use with AS/400.

WebSphere MQ Adapters
Now WebSphere MQ server on Windows is no longer required to connect to remote Queue Managers on non-Windows® systems. With the Server adapter a component is installed on the MQ computer that interacts with the MQ APIs.Let see MQ adapter architecture with BizTalk in the below image
clip_image002

The above image shows two environments are depicted, the BizTalk Server on Windows Server and an MQ Server which is running on AS/400. The MQSC adapter which enables sends and receives functionality using the chosen client. The MQ architecture for the Client works by receiving and sending messages to and from queues using a channel. A channel is a uni or bi-directional securable mechanism to perform reliable communication and is defined on a given Queue Manager on the server. Between the Client and the Queue Manager on both ends is the Message Channel Agent. It is the agent’s responsibility to control the send and receipt of messages.
Essentially there are three main components to using the Client adapter: MQ Client configuration, BizTalk Server port configuration, and the solution design itself. Let’s cover each of these in turn.

Client Configuration
MQ Client Configuration starts with a choice between the Base Client and Extended Client . The principle difference between the two is that the Extended Client is fully transactional while the Base Client is not. However, the BizTalk Server adapter is still able to guarantee at least once delivery with the Base Client due to the way it uses the client. Essentially, the adapter first retrieves a batch of messages non-destructively and only once they are safely in the MessageBox database are they removed from the queue. This is achieved using a cursor in MQ to enable locking and browsing of a queue without removing the messages. The same process occurs in reverse when sending messages, where the adapter checks the messages are safely on the queue before responding to the BizTalk Message Agent , which will then remove them from the MessageBox database. Because of this, it is possible in failure conditions to cause duplicate messages to be processed and your solution must take this into account if necessary. The Extended client ensures “once and once only” semantics.

BizTalk Server Configuration

There are a multitude of options here and we will consider the use of the most important ones here. The first thing to mention is that configuration is handled differently on Send and Receive. On the Receive side, the transport configuration is achieved through creating a Receive Location while on the Send side a Send Port is created and configured as shown below.
clip_image004

First, the connection between the BizTalk Server and the MQ Server must be defined. This is covered by four properties: channel name, connection name, queue and queue manager name.
The MQ adapter supports full ordered delivery on both the receive and send sides. When both are configured, First In, First Out (FIFO) processing all the way through BizTalk Server is possible .
Now let’s see how the orchestration is implemented as found in the below image
clip_image006

The above image shows an orchestration using the MQ client adapter and manual correlation to implement a solicit-response pattern. First, the orchestration must set the MQ header MQMD_CorrelID to a unique ID and a correlation set initialized containing this context property. Next, the message is sent to an MQ queue. After a period of time, a second message is received on a different queue. The adapter automatically copies this property and the receive port has a following correlation set – the same as that initialized in the send port. This ensures the second message is correlated to the first and the response message delivered to the correct orchestration. Using this approach, two different queues can be used to implement a more flexible approach to the solicit-response pattern.

for BizTalk Adapter for host files you can find this in this post

I hope this help.

Advertisements

June 24, 2009 - Posted by | Biztalk | , , ,

2 Comments »

  1. It’ s the first time I have heard that in Macedonia, obits are an unusual observe. You have wonderfully written the post. I have liked your way of writing this. Thanks for sharing this.

    Comment by copy a dvd | August 20, 2010 | Reply

  2. I do believe I will save this kind of thread

    Comment by UnsumbTus | January 19, 2012 | Reply


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: