Über mehrere Konversationen und/oder Warteschlangen

Question

Ich wundere mich über die genaue Definition einer Konversation und MS-Dokumente und Tutorials sind nicht ganz auf dem Punkt damit.

Zuerst ... gibt es einen Unterschied zwischen einem Dialog und einer Konversation?

eine Warteschlange Unter der Annahme, nur identische Nachrichten oder gleichwertige Nachrichten enthalten sollte

• jedes Gespräch rund um ein dreht sich (IE Nachrichtentypen durch eine aktivierte Verfahren in einer Weise ähnlich zu einem Fall, wenn/SWITCH-Szenario abgewickelt wird) eindeutige Warteschlange?

• Wenn eine Prozedur A eine Nachricht an eine Warteschlange sendet, die eine Prozedur B aktiviert, die die Nachricht behandelt, dann eine Antwort ausgibt, kann Prozedur A auf die Antwort warten, oder sollte ich eine Prozedur C verwenden? Darf ich annehmen, dass ich zwei Warteschlangen erstellen muss, die auf demselben Vertrag basieren? Aber wie viele Dienste? Wie und wo würde ich in diesem Szenario END CONVERSATION verwenden?

• Wenn eine Prozedur A eine Nachricht an eine Warteschlange sendet, die eine Prozedur B aktiviert, die die Nachricht behandelt und dann eine oder mehrere Nachrichten für eine andere/andere Prozedur C ausgibt, sind all diese Warteschlangen/Dienste/usw. in der gleichen Konversation? Die gleiche Konversationsgruppe? (Was ich nach der GET CONVERSATION GROUP tun meine Gespräche, um sicherzustellen, sind in der gleichen Gruppe?) Hat das vorbei bedeuten das gleiche Gespräch Griff, wenn BEGIN TRANSACTION Ausgabe/BEGIN DIALOG oder mit

  [MIT
  [{RELATED_CONVERSATION = related_conversation_handle
  | RELATED_CONVERSATION_GROUP = related_conversation_group_id}]

? Und ... last but not least, wenn ich mehrere Nachrichten benutze, um Anrufe mit verschiedenen Parametern an C weiterzuleiten/zu verzweigen, in welchem ​​Fall würde ich ganz andere Konversationen/Konversationsgruppen starten wollen, die dasselbe tun oder ist es immer besser eine einzigartige „Erzählung“

• Oh ... ein andere Sache zu haben ... ist es eine bewährte Methode, mehrere Nachrichten zu verwenden, um sich jeder von warten einige Behandlungen dann anrufen, bevor ein anderes zu beenden? Gibt es eine Möglichkeit, in der jede Prozedur eine Nachricht erhält, eine Antwort sendet und dann die von den Antworten aktivierte Prozedur die vorherigen Nachrichten in ihrer Warteschlange überprüfen/zählen und nur weiterlaufen kann, wenn sie alle da sind? Müsste das die Konversations-ID (oder Konversationsgruppen-ID) überprüfen, um sicherzugehen, dass diese Nachrichten alle von derselben Gruppe von Antworten ausgegeben werden?

  Ich hoffe, das ist nicht zu viel verwirrend, aber MS-Tutorials sind ... naja ... ein bisschen zu einfach.

Answer 1

Zunächst ist ein Dialog das gleiche wie eine Konversation, soweit ich das beurteilen kann. Zwei Namen für die gleiche Sache.

Warteschlangen können viele verschiedene Nachrichtentypen enthalten. Es liegt an der Sache, die Nachrichten zu verarbeiten (ob das eine intern aktivierte gespeicherte Prozedur oder eine externe Anwendung ist), um den Typ zu unterscheiden und das "Richtige" damit zu tun. Ein Dienst kann nur eine Warteschlange haben, aber eine Warteschlange kann viele Dienste haben (obwohl ich das in der Praxis nicht gesehen habe). Ein Dienst definiert, welche Nachrichtentypen durch den Dienstvertrag akzeptiert und produziert werden können.

In Bezug auf Ihre Frage, ob Sie möchten, dass ein Warteschlangenprozessor auf die gleiche Konversation reagiert oder eine neue startet, liegt ganz bei Ihnen. Mein Vorschlag wäre, auf dieselbe Unterhaltung zu antworten, wenn Sie nicht wissen, dass Sie einen guten Grund haben, dies nicht zu tun. Zur Verwendung der gleichen Konversation können Sie das Konversationshandle abrufen, wenn Sie die receive-Anweisung ausgeben. Verwenden Sie diese als Konversation, wenn Sie die nachfolgende send mit Ihrer Antwort ausgeben.

Die Art, wie ich über Konversationsgruppen denke, ist, dass Sie möglicherweise mit verschiedenen Diensten in Bezug auf die gleiche Sache sprechen müssen. Hier ist ein künstliches Beispiel:

Lassen Sie uns sagen, dass ich einen neuen Einstellungsvorgang habe. Es hat die folgenden Schritte:

• erstellen Login
• einen Eintrag im Abrechnungssystem erstellen
• sie mit Ihrem Versicherer obwohl

Sie sind alle logisch für das gleiche Ereignis registrieren (zB "Ich habe einen neuen Mitarbeiter eingestellt"). Sie können also alle Konversationen in einer Konversationsgruppe bündeln und die einzelnen Konversationen einzeln verfolgen. Etwas wie folgt aus:

declare @handle uniqueidentifier, @group uniqueidentifier = NEWID(), 
@message XML = '<employee name="Ben Thul" />'; 

BEGIN TRAN 
    begin dialog @handle 
     from service [EmployeeService] 
     to service 'LoginService' 
     on contract [LoginContract] 
     with related_conversation_group = @group; 

    SEND ON CONVERSATION (@handle) 
     MESSAGE TYPE [NewLoginRequest] 
     (@message); 

    INSERT INTO [dbo].[OpenRequests] 
    (
     [GroupIdentifier], 
     [ConversationIdentifier], 
     [ServiceName], 
     [Status], 
     [date_modified] 
    ) 
    VALUES 
     (@group, @handle, 'LoginService', 'RequestSent', GETUTCDATE()); 

    BEGIN DIALOG @handle 
     FROM SERVICE [EmployeeService] 
     TO SERVICE 'PayrollService' 
     ON CONTRACT [PayrollContract] 
     WITH RELATED_CONVERSATION_GROUP = @group; 

    SEND ON CONVERSATION (@handle) 
     MESSAGE TYPE [NewPayrollRequest] 
     (@message); 

    INSERT INTO [dbo].[OpenRequests] 
    (
     [GroupIdentifier], 
     [ConversationIdentifier], 
     [ServiceName], 
     [Status], 
     [date_modified] 
    ) 
    VALUES 
     (@group, @handle, 'PayrollService', 'RequestSent', GETUTCDATE()); 

    BEGIN DIALOG @handle 
     FROM SERVICE [EmployeeService] 
     TO SERVICE 'InsuranceService' 
     ON CONTRACT [InsuranceContract] 
     WITH RELATED_CONVERSATION_GROUP = @group; 

    SEND ON CONVERSATION (@handle) 
     MESSAGE TYPE [NewInsuranceRequest] 
     (@message); 

    INSERT INTO [dbo].[OpenRequests] 
    (
     [GroupIdentifier], 
     [ConversationIdentifier], 
     [ServiceName], 
     [Status], 
     [date_modified] 
    ) 
    VALUES 
     (@group, @handle, 'InsuranceService', 'RequestSent', GETUTCDATE()); 
COMMIT 

Nun haben Sie eine Möglichkeit, jede dieser Anfragen separat und eine Art und Weise zu verfolgen, um sie alle zu demselben logischen Operation zu binden. Wenn jeder Dienst die Nachricht verarbeitet, antwortet er entweder mit einem Erfolg, einem Fehler oder einer Nachricht "Ich brauche etwas anderes". An diesem Punkt können Sie die Tabelle OpenRequests mit dem aktuellen Status aktualisieren.

Service Broker kann überwältigend sein. Mein Rat für Sie ist, darüber nachzudenken, welche Nachrichten von wo zu wo und mit dem Entwerfen von Diensten, Nachrichtentypen, Verträgen usw. um das zu übergeben sind. Es ist unwahrscheinlich, dass Sie alle Funktionen von SB nutzen werden.