by community-syndication | Oct 9, 2009 | BizTalk Community Blogs via Syndication
Several customers and MS engineers reported me recently some very long collect statements scenarios using version 10.15 and sometimes infinite ones.
1) Some bugs were indeed identified in some VBS queries which might create looping scenarios in some VBS query execution .
These bugs were so fixed.
2) A long collect statement can occur also when .VBS queries (belonging mainly to the “Server Info” query category) are running too long time.
MBV 10.15 enumerates indeed in some .VBS queries some registry keys or registry values, and when targeting several remote servers of the BizTalk group it can be sometimes long.
I decided so to implement a timeout mecanism to stop a VBS, .BAT, or .CMD query after 30 secs by default.
This timeout value can be changed of course in the MBV UI via the “VBS/BAT/CMD Query Timeout” Global Option.
3) When you have a long query situation or infinite one, please do the following :
– Note in the status bar of MBV UI the pending query (it will be also logged in the Status log file)
– Kill MBV (as stopping via the UI the collect statement during a query execution will NOT work, I don’t want to kill my query execution thread)
– Keep the generated status log file and send it to me later (it is precious for me to know what happened before MBV was killed)
– Restart MBV and then uncheck the queries which seem to run too long or infinite and then start a new collect statement (usually these queries should belong to the “Server Info” category) to exclude them from the collect statement
Current build 10.15.7777 available on this blog contain both the VBS queries fix and the VBS Query Timeout implementation.
Sorry for these introduced regressions and continue to send me your feedbacks or possible bugs found
JP.

by community-syndication | Oct 7, 2009 | BizTalk Community Blogs via Syndication
I’ve largely finished my presentation for the October Rules Fest 2009 conference in Dallas at the end of the month. I’m speaking on complex event processing (CEP). My plan is to provide a broad survey of CEP technologies, chiefly concentrating on the similarities and differences between event stream and rules processing. There has been a lot of interest and activity around event processing in the rules community in recent years, and not a little controversy about the best approaches and, indeed, the role, if any, of Rete rules engines in detection of complex events. Constructing the presentation has been something of a journey for me, and hopefully it will prove of interest to those attending the conference.
This is rather last-minute plug for ORF 2009. It is the second year of this ‘alternative’ rules conference which is differentiated by a clear and unashamed focus on technology (there are other well-established rules conferences which focus on application at the business level), and by a wide-ranging interest in several related areas of science and research. For me, some of last year’s highlights included hearing Gary Riley explain how he managed to squeeze so much performance out of the CLIPS engine and listening to Dan Levine’s talk on rule-based mechanisms in the human brain. It’s that kind of event.
The major rule-processing vendors (ILog (now IBM), FICO, Tibco, etc.,) are well represented at the event together with the JBoss team. Charles Forgy, who came up with the Rete algorithm three decades ago, is a star speaker (a fascinating talk is promised on how to maximise the benefits of parallelisation in rules engines). I’m particularly looking forward to hearing Andrew Waterman’s talk on the use of rules processing in game-playing software used to promote sustainability and development of natural resources in Mexico. I’ve been aware of this project for some time. Greg Barton will be reporting on his experiences at Southwest Airlines. There are interesting sessions on rule modelling and aspects of rule languages and DSLs, plenty on CEP, and various talks on constraint programming, rule verification and other topics. And, to remind us all that technology, for technology’s sake, is never a good idea, John Zackman will be there to talk about the role of rules in Enterprise Architecture.
ORF 2009, only in its second year, offers an incredibly varied diet for the rule technologist. Together with the boot camps and introductory sessions at the beginning of the programme, it offers practical hands-on experience, a chance to learn about rules processing in depth, a showcase for the wide-ranging application of rules in many different areas of IT and an insight into many areas of research.
Places are still available, I understand. The cost is kept as low as possible by the conference organisers, so visit http://www.octoberrulesfest.org for more information and book in while you can.
by community-syndication | Oct 6, 2009 | BizTalk Community Blogs via Syndication
This post is a follow-up to http://blogs.msdn.com/adapters/archive/2008/06/30/using-the-wcf-sql-adapter-to-read-messages-from-ssb-queues-and-submit-them-to-biztalk.aspx and explains how to push a message using the WCF SQL Adapter from BizTalk to a SQL Service Broker (SSB) queue.
Scenario
1. An XML message is dropped to a file share
2. This XML message is made available to the WCF SQL Adapter by using the File Adapter
3. The WCF SQL Adapter then pushes this XML message to a preconfigured SSB queue by invoking a Stored Procedure
Create the database artifacts required for the SSB conversation
1. A message type, which denotes the format of the message in the queue
2. A contract, which denotes the conversation between a sender and a receiver and also includes the type of message flowing between them
3. The Initiator & Target queues, where messages are stored
4. The Initiator & Target services, which utilize the above queues
USE master;
GO
ALTER DATABASE <your db name here>
SET ENABLE_BROKER;
GO
USE <your db name here>;
GO
CREATE MESSAGE TYPE
[//SqlAdapterSSBSample/RequestMessage]
VALIDATION = WELL_FORMED_XML;
CREATE CONTRACT [//SqlAdapterSSBSample/SampleContract]
([//SqlAdapterSSBSample/RequestMessage]
SENT BY INITIATOR
);
CREATE QUEUE InitiatorQueue1DB;
CREATE SERVICE
[//SqlAdapterSSBSample/InitiatorService]
ON QUEUE InitiatorQueue1DB;
CREATE QUEUE TargetQueue1DB;
CREATE SERVICE
[//SqlAdapterSSBSample/TargetService]
ON QUEUE TargetQueue1DB
([//SqlAdapterSSBSample/SampleContract]);
5. A stored procedure, say InitiatorSP, that will take the message as an argument and push it to the SSB queue. Let’s use the name RequestMsg for the argument.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[InitiatorSP]
@RequestMsg xml
AS
BEGIN
DECLARE @DlgHandle UNIQUEIDENTIFIER;
BEGIN DIALOG @DlgHandle
FROM SERVICE
[//SqlAdapterSSBSample/InitiatorService]
TO SERVICE
N’//SqlAdapterSSBSample/TargetService’
ON CONTRACT
[//SqlAdapterSSBSample/SampleContract]
WITH ENCRYPTION = OFF;
SEND ON CONVERSATION @DlgHandle
MESSAGE TYPE
[//SqlAdapterSSBSample/RequestMessage]
(@RequestMsg);
END
GO
Create the BizTalk artifacts
1. Start the BizTalk Server 2009 Administration Console
2. Create a new BizTalk application, say SSBSendApplication
3. Create a new Receive Port, say FileReceivePort and add a new Receive Location, say FileReceive
a. Set the Type to File and configure the Receive Folder to point to a local share, say c:\in
4. Create a new Static One-way Send Port, say SqlSendPort
a. In the General tab,
i. Set the Type to WCF-SQL
ii. Click Configure and set the properties as follows
1. In the General tab, set
a. Address – the format is “mssql://<servername>/<instancename>/<databasename>”. For example, on my machine (using the default instance of SQL server), mssql://localhost//SSBTestDb (where SSBTestDb is the name of my database)
b. Action – the format is “TypedProcedure/<schemaname>/<storedprocedurename>”. For example, in my case, it is TypedProcedure/dbo/InitiatorSP
2. In the Messages tab, select Template and fill in the XML box with the following
<InitiatorSP xmlns=”http://schemas.microsoft.com/Sql/2008/05/TypedProcedures/dbo”>
<RequestMsg>
<bts-msg-body xmlns=”http://www.microsoft.com/schemas/bts2007″ encoding=”string”/>
</RequestMsg>
</InitiatorSP>
*Note that this approach requires that the xml encoding is string.
iii. Leave the other properties as is
b. In the Filters tab, add a filter BTS.ReceivePortName == FileReceivePort
5. Create a new Static One-way Send Port, say FileSendPort
a. In the General tab, set the Type to File and configure the Receive Folder to point to a local share, say c:\out
b. In the Filters tab, add a filter BTS.SPName == SqlSendPort
6. At this point the configuration of BizTalk application is completed, so start the application.
Send the message to SSB queue
1. Drop a request file to the c:\in share (one that file receive port is using). Note that this exact message will show up in the SSB queue. Here’s a sample message
<RequestMessage>Hello World</RequestMessage>
Consume the message from SSB queue
1. You can now consume the message from the SSB queue. On running the below query, you will see the above message.
DECLARE @DlgHandle UNIQUEIDENTIFIER;
DECLARE @RecvMsg XML;
RECEIVE TOP (1)
@DlgHandle=conversation_handle,
@RecvMsg = CAST(message_body as XML)
FROM TargetQueue1DB;
IF NOT (@DlgHandle IS NULL)
BEGIN
END CONVERSATION @DlgHandle;
SELECT @RecvMsg AS ReceivedMessage;
END