Vor einigen Wochen habe ich einen Crashkurs innerhalb weniger Stunden in Sachen MSMQ durchlaufen müssen, an dessen Ende eine Biztalk Lösung stand. Da ich auf einige Hindernisse gestoßen war, fasse ich mal meine Erfahrungen zusammen.
Kurz gesagt, MQ dient der asynchronen Kommunikation zweier Applikationen. Und das auch über Rechnergrenzen, oder gar Domänengrenzen hinweg. Dazu legt nach dem FIFO Prinzip eine Anwendung auf ihrem System Nachrichten ab, und eine andere lauscht auf die Adresse und greift die Nachricht ab. MSMQ kann sich dabei verschiedener Kommunikations Protokolle bedienen. (engl. Einführung in MSMQ)
MSMQ unterstützt gegenwärtig drei Queue Typen:
- Public Queues (benötigt Active Directory, Adressen werden dort direkt veröffentlich und sind von allen in der selben AD erreichbar, bzw. über Domängrenzen über Replikation)
- Private Queues (benötigt kein AD, die Adresse muss der empfangenden Anwendung daher aber auch bekannt sein, selbst mit AD!)
- Transaktions Queues (Sicherheit verbunden mit hohen Overhead Kosten)
Zum Entwickeln empfehlen sich Hilfstools, denn das größte Problem meines Erachtens (eigentlich das Einzige das ich hatte) ist die Kommunikationsinfrastruktur zu konfigurieren, solange man nicht eine sehr simple Netzwerkstrutur vor sich hat.
Zu einem gibt es dafür von MS das MQBench Paket und dann noch von Cogin ein freies MSMQ First Aid Kit.
Im bin Verzeichnis von MQBench gibt es 2 Tools: MSMQRecv bzw. MSMQSend, mit denen man über die Kommandozeile das Empfangen und Senden testen kann. Zum Vorgehen empfiehlt es sich zuerst einmal lokal zu testen, ob die MQ korrekt eingerichtet wurde. Funktioniert das, kann man zum eigentlichen Empfangsrechner über gehen der die Messages später abgreifen soll. Diese Tools haben aber einen Nachteil, sie unterstützen nur den Typ Public Queue, da sie nur das Pathnamen Format beherrschen. Aber der Pathname MUSS im AD nachgeschlagen werden, sobald es über Rechnergrenzen hinweg geht, d.h. Lokal funktionieren Pathnamen auch wunderbar mit Privat Queues!
Beispiel lokaler(!) Zugriff auf private MQ:
msmqrecv .\private$\MeineTestNachrichten
Remote Zugriff:
msmqrecv <rechnername>\private$\MeineTestNachrichten
-> Error: 0xc00e0003 (= Queue Not Found)
(geht nicht, Path wurde nicht in AD publiziert, da privat!)
Anmerkung: ein Versuch das ganze mit einem Formatname anstatt Pathname aufzurufen führt zu einem 0xc00e0014 (= Illegal Queue Pathname), die Tools können nur Pathname!
Das selbe gilt leider auch für das FirstAidKit!
Wie aber Eingangs erwähnt, unterstützt MSMQ unterschiedliche Kommunikationprotokolle, wie z.B. TCP. Dadurch hat man also die Möglichkeit ohne AD Lookup direkt auf die MQ eines anderen Rechners zuzugreifen. Um aber den Protokoll Zugriff beschreiben zu können, benötigt man das Direct Format Name Format. Da ich kein freies Tool kenne das einem das abnimmt, hab ich mir kurzerhand was in .NET zusammengecoded.
(Eine Anmerkung zum MSMQ Biztalk Adapter, dieser unterstützt das "Direct Format Name" Format ebenfalls von Haus aus.)
Unter System.Messaging gibt es im .NET Framework das richtige Werkzeug dazu:
...
MessageQueue mq = null;
bool cr = false;
string strFormatnameaddress = @"FormatName:DIRECT=TCP:192.168.1.114\test";
try
{
msg.Priority = MessagePriority.Normal;
mq = new MessageQueue(strFormatnameaddress);
cr = mq.CanRead;
}
catch (System.Messaging.MessageQueueException ex)
{
Console.WriteLine("MSMQ Error: " + ex.ToString());
}
catch (Exception ex)
{
Console.WriteLine("Error: " + ex.ToString());
}
finally
{
mq.Close();
}
return cr;
...
Das CanRead Flag gibt uns auf jeden Fall Informationen dazu, ob wir nun überhaupt auf die MQ zugreifen können, oder nicht. Jedenfalls ist die Programmierung sehr simpel, das gilt auch für das empfangen, bzw. senden von Messages:
...
// empfang aller Messages in der MQ
Message[] msgs = mq.GetAllMessages();
...
// senden einer Message in die MQ
Message msg = new Message();
msg.Label = "Test Message";
msg.Body = "Das ist nur ein Test";
mq.Send(msg);
...
Das eigentliche Problem fängt nun da an, wenn man keinen Zugriff auf die Message Queue bekommt. Das läßt sich in der Regel auf Security Einstellungen zurückführen.
Was kein großes Problem ist, solange man sich am gleichen AD befindet und man über den Pathnamen zugreifen will (Es reicht in der Regel dem User des lesenden Rechners einfach die Zugriffsrechte auf die MQ zu gewähren, notfalls den Anonymus Access erlauben). Befindet man sich in unterschiedlichen AD (aber noch unter dem gleichen Forrest) benötigt man eigentlich nur noch zusätzlich eine funktionierende AD Replikation für den Pathnamen Zugriff. Ansonsten sollte in der Regel der Direct Format Name Zugriff funktionieren.
Was aber wenn sich die Rechner in unterschiedlichen Forrests befinden? Die unterschiedlichen Forrests müßen sich diese Vertrauen, und das bedeutet entweder Zertifikate, oder die "Umsonst"-Variante: ein Loch in die "Mauer schlagen". Dazu benötigt es nicht viel mehr als eines zusätzlichen Eintrages in die Registry des MQ Servers:
http://msdn.microsoft.com/en-us/library/cc236138(PROT.10).aspx
1.) HKLM\Software\Microsoft\MSMQ\Parameters\security\NewRemoteReadServerAllowNoneSecurityClient dword = 1
2.) Zugriffsrechte für Anonymus
Das gibt dem Admin sicherlich richtige Magenschmerzen ;)
Dazu hat John Breakwell von Microsoft, der einem auch bei einem Microsoft Call Support leistet, ein ausführliches Blog verfasst. Folgende Einträge beschäftigen sich mit MSMQ und Rechnern in unterschiedlichen Forrests:
http://blogs.msdn.com/johnbreakwell/archive/2008/02/14/how-do-i-send-msmq-messages-between-domains.aspx
http://blogs.msdn.com/johnbreakwell/archive/2008/06/27/cross-forest-msmq-you-need-to-be-trusting.aspx
http://blogs.msdn.com/johnbreakwell/archive/2008/10/13/authenticating-msmq-messages-between-forests.aspx
