Charles Young

  Home  |   Contact  |   Syndication    |   Login
  196 Posts | 64 Stories | 510 Comments | 373 Trackbacks

News

Twitter












Article Categories

Archives

Post Categories

Image Galleries

Alternative Feeds

BizTalk Bloggers

BizTalk Sites

CEP Bloggers

CMS Bloggers

Fun

Other Bloggers

Rules Bloggers

SharePoint Bloggers

Utilities

WF Bloggers

Introduction

 

Perhaps the greatest architectural change between BizTalk Server 2004 and earlier versions is the introduction of the MessageBox and the subscription mechanism that delivers messages to instances of BizTalk services.   Subscription is central to understanding BizTalk Server 2004, and is the subject of this article.   In many ways, it is a fairly straightforward and simple mechanism, but there are subtleties.  This article explains the fundamental features of subscription, and explores its implementation within the BizTalk engine.   In a future article, I will cover additional features of the subscription mechanism such as ordered delivery, convoying, message predicates etc.

 

The essential idea of subscription is very simple.   Messages are received (via receive handlers or from orchestration Send ports) and handed to the BizTalk engine.  The engine determines and stores a set of contextual property values for the message, and then interrogates a rule store to determine a set of matching subscriptions.   Each subscription comprises a set of rules which match messages in terms of property values.   For each matched subscription, a record is entered into an application-specific queue, and is associated with a specific instance of a service.   Queued messages are then de-queued using a number of separate worker threads, and routed to the designated instances of services.  In essence, the subscription mechanism acts as a rules engine that infers, from a set of predicate-based rules, which messages should be handed to which service instances.

 

 

 

 

 Fig. 1:  BizTalk Server 2004 Subscription

 


Before we go further, I should mention that BizTalk Server 2004 ships with a rules engine codenamed 'Dragonfly'.   When I began to look at the mechanisms involved in subscription, I discovered that the Subscription Viewer (a tool in the SDK) uses a specialised class (SubscriptionRuleStore) provided by this rules engine to represent subscription rule-sets programmatically.  I got quite excited about this discovery, assuming that BizTalk subscription is implemented using the Dragonfly rules engine.   However, after further research, I can find no evidence that this is the case.  The subscription mechanism is largely implemented using a number of SQL Server stored procedures to match subscriptions to messages and to queue these messages.  The subscriptions, themselves, have a number of BizTalk-specific features, and the SubscriptionRuleStore class does not fully represent these features.  Hence the Subscription Viewer does not provide a comprehensive insight into subscriptions, although the main features are covered.

 

Message Properties

 

The subscription mechanism primarily matches subscriptions to messages in terms of contextual message properties.  Each time a message is received by BizTalk, its properties are determined, and are recorded in the MessageProps table.  As we will see the second article, not all message properties are promoted into the MessageProps table in this way.   For those that are, some of these property values are provided automatically by BizTalk and others are derived from fields within the message itself. 

 

The MessageProps table serves something of a double purpose.  As well as holding the promoted contextual properties of each message, it is also used to record the batch of messages each individual message belongs to, and the order in which the message was received within the batch.   In BizTalk Server 2004, all received messages belong to a batch.  However, some adapters only support batches containing exactly one message.  

 

Subscription Matching

 

Once BizTalk has recorded the properties of an inbound message, it next finds all subscriptions which match the incoming message using the bts_FindSubscriptions stored procedure.  Each subscription is defined within the Subscription table as a separate record with a subscription ID (a Guid) and a creation time.  Subscriptions may be grouped together using a Group ID, and each subscription group has a priority number (see the section on priority below).

 

Predicates

 

Subscriptions are defined primarily in terms of message property predicates.  Each predicate describes an expression used in subscription matching.  For example, a predicate might define an expression that tests for messages with an orderQty property value that is greater than 5000.  BizTalk supports the following predicate types:


 

  • Bitwise AND
  • Equals
  • Exists
  • GreaterThanOrEquals
  • GreaterThan
  • LessThanOrEquals
  • LessThan
  • NotEquals

 

The Subscription Viewer utility does not represent Bitwise AND or Exists predicates directly.  Instead, these are represented as Equals predicates.   In the case of Exists predicates, the Subscription Viewer represents these as ' = EXISTS'.   'Exists' predicates test for the existence of a message property rather than its value.   A good example of the use of 'Exists' predicates is on subscriptions created by dynamic send ports.  When a dynamic send port is enlisted, it creates separate subscriptions for each of the adapters registered with the system.  Each subscription includes an 'Exists' predicate to check for the existence of an 'OutboundTransportLocation' message property.

 

Predicates are collected into ‘And’ and ‘Or’ groups.  BizTalk does not allow these groups to be nested, and therefore is somewhat constrained in terms of the subscription rules which potentially could be created.

 

Services, Service Instances and Ports

 

Subscriptions are created by services, and results in messages being routed to service instances.  It is important to explain carefully the concept of services in BizTalk.  As we will see, this is not quite as straightforward as you might expect.   The term 'service' has more than one meaning.

 

BizTalk runs as a Windows service (BTSNTSvc.exe).  A Windows service is, of course, a software program that runs in its own process outside of the current logged-on user's security context.  One of the tasks of this service is to manage BizTalk hosting.   A BizTalk host is a configurable and administrable logical unit within BizTalk that, at runtime, maps to one or more 'host instances'.  A host instance manages loaded BizTalk components such as adapters.   A BizTalk host virtualises host instances, allowing single point administration of a scalable group of host instances running on a cluster (group) of BizTalk machines.   BizTalk defines two types of host.  ‘In-process’ hosts are used to create host instances that run within a BTSNTSvc.exe process.  ‘Isolated’ hosts define host instances that run within other processes, such as IIS-defined processes.

 

Host instances are used to host various types of BizTalk component including 'Host Instance Sub-services'.  These sub-services are COM components that implement the undocumented IBTSService interface through which sub-service instances can be started and stopped.   There are five BizTalk sub-services defined as follows:


 

  • Caching Service
  • End Point Manager
  • MSMQT
  • Tracking
  • XLANG/s

 

The caching and tracking sub-services are treated as internal to BizTalk, whereas other sub-services provide the messaging and orchestration facilities directly available to BizTalk developers and administrators.   The End Point Manager (EPM) sub-service supports general messaging between external endpoints.  The MSMQT sub-service supports the use of the message queuing adapter to provide an MSMQ native interface integrated directly with the BizTalk MessageBox.   Both EPM and MSMQT allow adapters and pipelines to be configured and enlisted via the notion of Receive Ports/Receive Locations and Send Ports.   The XLANG/s sub-service manages business process execution using orchestrations.

 

 

 

 

Fig. 2:  BizTalk Server 2004 Hosts and Sub-Services

 

For the purposes of subscription, tracking and activity monitoring, BizTalk provides a further definition of the term 'service'.  For the sake of clarity, I will call these 'subscriber services' in order to distinguish them from Windows services or host instance sub-services.   However, they are simply called 'services' within the BizTalk documentation.   Subscriber services are closely related to host instance sub-services.  Host instance sub-services provide the functionality that defines subscriber services and which create and manage instances of those subscriber services at runtime.  

 

A subscriber service is modelled along the same general lines as a service described by WSDL (Web Service Description Language).   It acts as a collection of one or more ports.  Each port is an endpoint to which messages are routed or from which messages are returned to the MessageBox.  BizTalk categorises subscriber services in terms of 'service classes'.   There are four service classes defined as follows in the adm_ServiceClass table in the administration database:

 

  • Messaging InProcess
  • Messaging Isolated
  • MSMQT
  • XLANG/s

 

Note that the two Messaging service classes are supported by the EPM host instance sub-service.   HAT provides a slightly different view of services classes, and recognises some additional 'internal' classes.  These include the 'Tracking' service class, and a catch-all 'Other' class.  HAT also recognises a 'Routing Failure Report' service class.   When the subscription mechanism cannot successfully route a message to a port on an instance of a subscriber service, BizTalk generates a routing failure report message which is posted to the MessageBox.   This message is not subscribed to by any actual service.   The 'Operations/Messages' menu in HAT can be used view messages currently in the MessageBox.   This view displays all messages and their service classes, including the Routing Failure Report messages.

 

At run time, the host instance sub-services create and manage instances of the subscriber service classes.  These 'service instances' then receive messages from the MessageBox via the subscription mechanism (and de-queuing), and may return messages to the MessageBox.   The notion of service classes and instances is somewhat abstract, but relates directly to runtime service classes and instances.  This can most clearly be seen in terms of XLANG/s orchestrations.   Orchestrations are defined in a BizTalk Visual Studio project, and are compiled into .NET classes that implement the BTXService interface (this is not related to the IBTSService interface mentioned above).   At run time, the XLANG/s sub-service creates instances of these classes.  Each instance is an in-memory state machine that receives, processes and returns messages to and from the MessageBox.  Messages are delivered by the subscription mechanism directly to these service instances.   In a similar fashion, each time a Send port is created through the BizTalk Explorer, a new EPM service is defined.  Run-time instances will then be created to handle messages routed to the Send port.

 

At run time, any single service class may have several instances.  Each instance is recorded, for the duration of its lifetime, within the Instances table.  In the case of Orchestrations, of course, this lifetime may be extended by dehydrating the instance.   Each instance can be in one of several states as follows:

 

  • Ready to Run
  • Active
  • Dehydrated
  • Suspended (Not Resumable)
  • In Breakpoint
  • Zombie.

 

Service instances and ports are the key to understanding subscriptions.  The BizTalk engine uses each subscription to route messages to ports on specific service instances.   Subscriptions may, or may not, contain an Instance ID.   Subscriptions with an Instance ID are related directly to a live or dehydrated service instance.  Orchestration service instances create these instance-specific subscriptions dynamically.  Each time process flow reaches a Receive shape in an orchestration, subscriptions are dynamically created for the orchestration ports connected to that shape.   The subscription is removed when a message has been received on the port.  Subscriptions without an Instance ID result in the creation of a new service instance each time they match an incoming message, and are termed 'Activate' subscriptions.

 

Each subscription may also be associated with a port.  Ports are defined at the service level.  In the case of EMP 'Messaging' services, there is one port per service.   In the case of Orchestration services, each orchestration can define multiple ports.  Orchestrations allow one port to be marked as the 'Activate' port'  This results in the publishing of a single 'Activate' subscription which will result in new orchestration instances being created each time the subscription matches an inbound message.   Note that subscriptions are created for EPM 'Send' ports and orchestration 'Receive' ports.   These are treated in the same way by the subscription mechanism.   In earlier versions of BizTalk, we got used to thinking of messaging ports and orchestration ports as very different things, but in BizTalk Server 2004, although they are implemented by different code, they are unified in terms of subscription.

 

As well as services of the four service types described at the beginning of this section, BizTalk creates subscriptions for the additional 'internal' services.  For example, the Cache Manager creates a single subscription that selects messages with a 'BizTalkControl' property with a value of 'CacheRefresh'.   BizTalk uses the MessageBox to route internal control messages.

 

Subscription Evaluation and Message En-queuing

 

Each time a matching subscription is found for an inbound message, the BizTalk engine evaluates that subscription.  Evaluation is a simple process that, after some checks, inserts the message into an application-specific queue.  In the second article, we will explore the way in which the evaluation stage checks for the existence of message predicates. 

 

In BizTalk, each application is defined by a separate 'Host', and by set of queue tables within the MessageBox.   As well as the main queue table, these include the 'suspended' and 'scheduled' queues.   As we have seen, a 'host' is a virtual container that maps to one or more 'host instances' at runtime.   Only the Enterprise version of BizTalk supports multiple host instances for any one host, and each host instance runs on a separate server within a BizTalk group.  For the purposes of our discussion, we are chiefly interested in the fact that messages are placed on the main queue in a specific order reflecting the order in which messages were received, and that each subscription defines a priority level which is used to set the priority of the message within the queue.

 

Note that the queue contains only various identifiers for the message and the service instance.   Additional data, including the message context, is spooled into a separate table (Spool) with individual message parts stored in the MessageParts table.

 

Message De-queuing

 

BizTalk reads messages off the queue using one or more 'de-queuing' worker threads.   One of these threads is designated as the ‘primary’ thread.   The de-queuing threads deliver (route) each message to the designated service instance.   As you can imagine, there is quite a lot of fine detail involved in this process.   BizTalk uses locks to ensure that there is no contention between the threads, and that deadlocks cannot occur.   De-queuing is completely de-coupled from message delivery.   The BizTalk engine constantly inspects queues to discover and process any new messages.   Each time BizTalk invokes a de-queuing stored procedure, it inspects the queue for messages that belong to a particular service class, and which are destined for a specific host instance (for subscriptions which are instance-specific), and reads off a batch of messages.  The maximum size of a batch is 20 records.  

 

Priority

 

Message batches are de-queued in priority order.   Priority is defined at the subscription level, and ranges from 1 to 10.   1 represents the highest priority and 10 represents the lowest.   The default priority level is 5.  BizTalk allows you to set the priority level when configuring EPM messaging Send ports, but not when configuring Orchestration ports.   Orchestration ports generate subscriptions with a priority of 7.   Because messages are de-queued in service class-specific batches, priority levels do not operate across different service types.  It is not relevant, for example, if an Orchestration port has a lower priority that an EPM Messaging port.   However, if one EPM Messaging port has a higher priority than another, this is highly relevant.   Messages will be delivered to service instances in priority order.

 

Unfortunately, the SDK subscription viewer does not display the priority data for subscriptions, even though it has this information available to it through the SubscriptionRuleStore class.

 

Since we are discussing priority, it is worth mentioning another aspect which currently I do not fully understand.   Towards the beginning of this article I mentioned briefly that subscriptions are grouped, and that each subscription group has a group priority.   When BizTalk matches subscriptions to messages using the bts_FindSubscriptions stored procedure, it primarily orders the subscriptions by the order in which the matching messages are received in the message batch, and then secondarily by the subscription group ID (a Guid).  The records are then further ordered by subscription group priority.   If we assume that subscriptions are then evaluated in this sort order, this will affect the order in which messages are placed on the queue.   However, it is difficult to see what ordering by group priority achieves.   Unfortunately I have yet to see a case where there are multiple subscriptions in a single subscription group, so I cannot tell for certain how this feature is used.

 

Conclusions

This article has discussed the basic mechanism of subscription.   There are a number of additional features which will be the subject of an additional article.   These include ordered delivery, convoying, filtering, message predicates and time windows.

posted on Wednesday, June 23, 2004 12:03 PM

Feedback

# Subscriptions in BizTalk2004 - The Essential Ins and Outs 6/24/2004 12:22 PM Ugh!!'s Greymatter Honeypot
Excellent article ! Looking foward to Part 2

# re: How subscription works - Part1 9/7/2004 2:34 PM l
stop copying from lee g's blog, you cheat

# re: How subscription works - Part1 9/8/2004 7:18 AM Lee
Okay, I don't know who complained about you copying from me, but I have to say that I am pretty impressed at your level of understanding (and I wrote everything you described above for subscriptions). (you also posted this before my posts) Wow. I will have to add a link to you in my blog cause this is impressive. Thanks for writing it. So as a bonus, here is what a subscription group is for. Well first, how it is used. Consider an orchestration with a listen activate receive with two receives. What would happen if one message were to fill both subscriptions???? We don't actually want to activate two instances and we don't actually want to send the message to the same sched twice. So what happens is that when a message routes to multiple subscriptons in the same group, it is only sent to the subscription with the highest group priority (this is different from the normal priority setting and you can't configure this). Why did I actually design this feature??? It was meant as a catch-all. Think about an orchestration designed to handle all POs. But then maybe you want a completely different orchestration to handle POs over $5000. Maybe you want another one to handle all POs over $20000. Instead of constantly editting all of their activation subscriptions and constantly redeploying them, you could group them together and have one basically override the other. Therefore you have one catchall and then others which handle the specifics, but the logic of what is a special, specific message does not need to be built into the catchall. Unfortunately this did not make it into the list of features to expose. Maybe one day. Like I said, great write up. :)

# re: How subscription works - Part1 9/8/2004 7:24 AM Lee
Hey ... get off my case about the Subscription Viewer. :) Do I seem like a UI designer to you. Subscriptions were going to be oompletely hidden originally and then I built this to keep people out of the tables. Sorry I didn't get everything exposed. You seem to be working around it. :) There were a number of reasons why we tried to unify the object model for rules and subscriptions, but it didn't quite work so you got left with my SubscriptionRuleStore which you have dug up. Next version more information should be available in non-SDK features. That is not a promise, but a hope.

# re: How subscription works - Part1 9/8/2004 7:46 AM lee
Okay, one more comment and then I am done. :) You say: "
Predicates are collected into ‘And’ and ‘Or’ groups. BizTalk does not allow these groups to be nested, and therefore is somewhat constrained in terms of the subscription rules which potentially could be created."

This is not an accurate statement since any boolean expression can be normalized / flattened into this format, so we have not constrained any functionality. It is true that for deeply nested expressions, expanding them could be tedious, this is an implementation decision based upon optimizing for the majority of our cases. Thanks. :)

# re: How subscription works - Part1 9/13/2004 12:40 PM Charles
Fantastic Lee. Straight from the horse's mouth. I'm especially grateful for the correction re. And/Or groups. I shall edit the original article to reflect your comments. Sorry if I seemed a bit rude about the subscription viewer...but then again, perhaps I'm not that sorry :-)

I promised a part 2 ages ago, and have actually written most of this, and a part 3 as well. I shall use your comments as a spur to get this completed. I wonder if I could pass this material to you at some point for a quick review before publishing. If you would be willing, drop me a line at charlesy@solidsoft.com.

# re: How subscription works - Part1 9/16/2004 3:36 PM harish
I think your figure 2 is incorrect, when you create a new host it looks like a new BTSNTSvc.exe process is created which what I think you would expect the HOST block to be at the same level as the BTSNTSvc.exe block? just some feedback for the diagram.

Also related question. In a multi server development environment thats are in the same BizTalk group how do I make sure each developers unit test gets performed on thier own machine? I know you can specify a unique host instance on each developers machine..but the I issue I see is you cant specify a host for the send ports as the host in a send side is on the handler - is it possible to have multiple file handlers(say) on hosted on each developers machine?

# re: How subscription works - Part1 10/1/2004 12:54 PM Sovon Nath
This post is really impressive. Currently, I am stuck with a situation where I have two MSMQT. Here one of these queues should have a higher priority than the other. Which means that if there are messages in the higher priority queue then the orchestration should process only from that and keep on ignoring the lower priority queue. This will continue until there are no more messages in the higher priority queue. At this point the orchestration will process messages from the lower priority queue.

Please give me an idea as to how to achieve this.

# re: How subscription works - Part1 11/1/2004 12:54 PM Carlo Poli
Brilliant article.

I have found the hard way that your statement about not all properties being stored in MessageProps table is true. I've created my own context property and try to use that for routing, which I just can't get to work, when setting the property in an orchestration.

I am wondering what's the logic that decides whether a property will be stored or not. It would be great if you get around to posting your findings on that. I guess I'll have to use a data property for routing for now.

# re: How subscription works - Part1 2/7/2005 10:43 PM Adrian Griffith
I'd sure like to know how an orchestration creates a subscription. I work with BTAHL7. My receive port accepts a multi-part message (HL7) and outputs the XML.

I began this orchestration just working with an Appointment Cancellation (HL7 SIU/S15). I have a mapper artifact that transformed to a little Appt schema. It worked.

I have attempted to make this same orchestration work with a New Appointment (HL7 SIU/S12). I included the additional schema, rebuilt, and redeployed. But all I get is no subscription found.

Through HAT I can see that the message flow appears proper. The inbound message instance is parsed by the correct schema.

S15 processing still works.

I removed the transformation of the S15 thinking that may update the Orchestration subscription.

I created a mapper artifact to transform the S12 to my Appt schema hoping that would update the orchestration subscription.

You can not promote an element in HL7 schemas.

What do I do?

# re: How subscription works - Part1 3/23/2005 3:37 AM Theresa casteel
I want to cancel all Norton works off of my computer now.

# re: How subscription works - Part1 4/6/2005 11:48 AM Abhijeet Raje
Charles,
Where can i fine Part 2 and Part 3?

Also, can you provide some in-depth article on how correlation works.
I know how it works very well; i want to know how Biztalk makes it work, like in above article (http://geekswithblogs.net/cyoung/articles/7007.aspx ) you have explained.

Coming straight to my concern.
Example
I send a message out of orchestration and will wait for some response file.

If response file is "Y" then I will terminate main orchestration
Else response file is "N" then will wait for the parent message with some correction in content.

Question:
Should I initialise the correlation set for receiving second file only if I receive response file with "N" or I can initialise correlation straight way without considering response.

I want to know what will be the performance issues in second approach where I am initialling correlation for those messages also for which I may receive “Y” (more in number 95%).

Regards,
Abhijeet

# re: How subscription works - Part1 4/19/2005 6:55 PM Baron
Hello,

I have a publish/subscribe scenario and it works great but...
It seems to pick up the same message and kick off the same orchestration more than once. Now I do update the message so that a promoted property is updated to prevent an infinite loop but it seems to kick off another instance of my orchestration before I can complete the first instance of my orchestration. I only want the orchestration to run once. It does some database information handling and it is happening twice....

Any ideas ?


Baron

# re: How subscription works - Part1 4/29/2005 8:59 PM Abhilash M S
An excellent article . Looking forwar to future posts. I assumed wrongly that all properties were being stored in MessageProps table

# BTS 2002 vs BTS 2004 8/19/2005 1:42 PM Abhilash M S
I  have often been asked What is the big difference between Biztalk 2002 and 2004 , There are a...

# BTS 2002 vs BTS 2004 8/19/2005 1:52 PM Abhilash M S
I  have often been asked What is the big difference between Biztalk 2002 and 2004 , There are a...

# re: How subscription works - Part1 9/14/2005 9:07 AM speco
hey guys try to break some of the stuff down. There are newbies around.

# re: How subscription works - Part1 4/14/2008 2:04 PM kishore
Hi, I work with HL7 protocol using BT2006/R2. I'm unable to receive any HL7 messages fired on to the port which is being listened by BTHL7 application. I can see the messages comming through the port with MS network monitor and BTAHL7 receive tool supplied by BT.
Can anybody give any suggestions why there are no messages getting into BT application listening on MLLP port please?
Thanks you,
Kishore

# re: How subscription works - Part1 10/19/2008 2:06 PM Islam Fayez
Hi,

I think that we can use the subscriptions with filters on send ports to implement Dynamic SQL Send Ports am I right?

# SQL dynamic ports 10/19/2008 10:33 PM Charles Young
Not sure what you mean here. A dynamic port is one where the adapter is selected dynamically according to the value of the OutboundTransportLocation property which must be promoted on each message you want to send via the port. The value must be a URL, and the ‘scheme’ within the URL is typically used to select the appropriate adapter. The rest of the URL is used to connect to the desired external location.


In BizTalk 2004, the SQL adapter did not support dynamic ports. Microsoft no longer documents this restriction for BizTalk 2006, but also gives no clue about how you might configure messages for dynamic ports using the SQL Server adapter. I did a little digging, and I believe this is the answer...


• Set and promote the OutboundTransportLocation message property to ‘SQL://<datasource>/<initial catalog>’. Remember that, if you are doing this in an orchestration, you set the Microsoft.XLANGs.BaseTypes.Address property on your dynamic orchestration port in order to achieve this.


• Set and promote the OutboundTransportType message property to ‘SQL’. You can set the Microsoft.XLANGs.BaseTypes.TransportType on an orchestration dynamic port to do this. This may not be required.


• Set the SQL.ConnectionString property on your message. I doubt this needs to be promoted.


Please note, I have not tried this out. I will be interested if you can get it to work.

# re: How subscription works - Part1 10/20/2008 8:35 AM Islam Fayez
OK here is what i did to implement a workaround SQL Dynamic Send Ports; i did a Direct port configuration in my orchestration and a filter expression on a physical port with the message type i'm sending. I went with this technique because i can't set the SQL.ConnectionString property on the port in my orchestration; all it gives me is the Microsoft.XLANGs.BaseTypes.Address.

http://msdn.microsoft.com/en-us/library/ms915985.aspx says that there are SQL Dynamic Send Ports; but when you configure a dynamic port you can't see the connection string property nor the namespace nor the document root element; when you go in design and set the URI its not enough cuz the SQL adapter is not configured with connection string (you must set it on the global SQL adapter; and then it will be global on the server; a solution is to implement custom SQL adapter just to put the values for the three properties which is a headache).

I found that Direct port configuration where you can route the message based on a filter expression (pub/sub techniques) was the best for my situation.

Enlight me if wrong and also if know how to set SQL.ConnectionString value plz tell cuz i cant find it on the properties of the message. Thanks



# re: How subscription works - Part1 10/20/2008 8:42 AM Charles Young
The SQL.Connection string property would be set on your message, rather than the dynamic port in the orchestration. Dynamic ports only support Address and TransportType properties. There are additional SQL properties you can set for namespace and root.

Like I say, I haven't actually tried this out myself, so can't guarantee that the adapter supports everything correctly. Let me know how it goes.

# re: How subscription works - Part1 10/20/2008 9:15 AM Islam Fayez
Hi again,
I can't find a property on my message (in expression shape) with SQL.ConnectionString, can you give me some steps and details on how to set this property?

Thanks

# re: How subscription works - Part1 11/12/2008 8:42 AM Jim McLay
Hi,

Has anyone found SQL.ConnectionString property, it is not on the message, I have tried referencing some of the BizTalk SQL dll's in the same way as with MSMQ (..MsmqAdapterProperties.dll) to no avail. The client site I am working at has a need to alter the connection string dynamically to update several different databases, suggested using code but they are firm believer of the SQL Adapter.

# re: How subscription works - Part1 5/20/2009 11:17 AM Walid F
Very good article, does it apply biztalk 2006?

btw, where is part 2

Thanks

# re: How subscription works - Part1 5/21/2009 10:55 AM Charles Young
The model hasn't changed sunstantially in more recent versions of BizTalk.

This was the article where I learned never, never to promise a 'part II'. Maybe one day...

# re: How subscription works - Part1 6/4/2010 1:21 AM Vivek
Excellent article. this article gave me in site of subscription mechanism, which msdn couldn't do. Thanks a lot for information. Please Give us more on BTS 2009.

Post A Comment
Title:
Name:
Email:
Comment:
Verification: