SEND (Transact-SQL)

Gilt für:SQL ServerAzure SQL Managed Instance

Sendet eine Nachricht mit einer oder mehreren vorhandenen Konversation.

Transact-SQL-Syntaxkonventionen

Syntax

  
SEND  
   ON CONVERSATION [(]conversation_handle [,.. @conversation_handle_n][)]  
   [ MESSAGE TYPE message_type_name ]  
   [ ( message_body_expression ) ]  
[ ; ]  

Argumente

IM GESPRÄCH conversation_handle [.. @conversation_handle_n]
Gibt die Konversationen an, zu der die Nachricht gehört. conversation_handle muss eine gültige Konversations-ID enthalten. Das gleiche Konversationshandle kann jeweils nur einmal verwendet werden.

MESSAGE TYPE message_type_name
Gibt den Nachrichtentyp der gesendeten Nachricht an. Der Nachrichtentyp muss in den von den Konversationen verwendeten Dienstverträgen enthalten sein. Diese Verträge müssen das Senden des Nachrichtentyps von dieser Seite der Konversation zulassen. Die Zieldienste der Konversationen können beispielsweise nur Nachrichten senden, die im Vertrag als SENT BY TARGET oder SENT BY ANY angegeben sind. Wenn diese Klausel weggelassen wird, ist die Nachricht vom Nachrichtentyp DEFAULT.

message_body_expression
Stellt einen Ausdruck bereit, der den Nachrichtentext darstellt. message_body_expression ist optional. Wenn message_body_expression jedoch angegeben wird, muss der Ausdruck von einem Typ sein, der in varbinary(max) konvertiert werden kann. Der Ausdruck darf nicht NULL sein. Wird diese Klausel ausgelassen, ist der Nachrichtentext leer.

Bemerkungen

Wichtig

Wenn die SEND Anweisung nicht die erste Anweisung in einem Batch oder gespeicherten Verfahren ist, muss die vorherige Anweisung mit einem Semikolon (;)) beendet werden.

Die Erklärung SEND übermittelt eine Nachricht von den Diensten an einem Ende eines oder mehrerer Service Broker-Konversationen an die Dienste am anderen Ende. Die Anweisung RECEIVE wird dann verwendet, um die gesendete Nachricht aus den mit den Zieldiensten verbundenen Warteschlangen abzurufen.

Die in der ON CONVERSATION-Klausel angegebenen Konversationshandles stammt aus einer der folgenden Quellen:

  • Wenn eine gesendete Nachricht keine Antwort auf eine von einem anderen Dienst empfangene Nachricht darstellt, verwenden Sie das Konversationshandle, das von der BEGIN DIALOG-Anweisung zurückgegeben wird, mit der die Konversation erstellt wurde.

  • Wenn eine gesendete Nachricht eine Antwort auf eine zuvor von einem anderen Dienst empfangene Nachricht ist, verwenden Sie das Konversationskonto, das von der RECEIVE Anweisung zurückgegeben wird, die die ursprüngliche Nachricht zurückgegeben hat.

  • Der Code, der die SEND Anweisung enthält, ist manchmal getrennt vom Code, der entweder den BEGIN-DIALOG oder RECEIVE Anweisungen mit Konversationshandhabung enthält. In diesen Fällen muss der Konversationshandle eines der Datenelemente in den Zustandsinformationen sein, die an den Code mit der Anweisung SEND übermittelt werden.

Nachrichten, die an Dienste in anderen Instanzen von SQL Server-Datenbank-Engine gesendet werden, werden in einer Übertragungswarteschlange in der aktuellen Datenbank gespeichert, bis sie an die Dienstwarteschlangen in den Remoteinstanzen übertragen werden können. Nachrichten, die an Dienste in derselben Instanz von Datenbank-Engine gesendet werden, werden direkt in den Warteschlangen abgelegt, die den betreffenden Diensten zugeordnet sind. Wenn eine Bedingung verhindert, dass eine lokale Nachricht direkt in die Warteschlange des Zieldiensts eingeht, kann sie solange in der Übertragungswarteschlange gespeichert werden, bis die Bedingung beseitigt ist. Dies kann beispielsweise auftreten, wenn bestimmte Typen von Fehlern vorliegen oder wenn die Zieldienstwarteschlange inaktiv ist. Sie können in der sys.transmission_queue-Systemsicht die in der Übertragungswarteschlange vorhandenen Nachrichten anzeigen.

SEND ist eine atomare Aussage. Wenn eine SEND Anweisung bei mehreren Konversationen eine Nachricht sendet und fehlschlägt, zum Beispiel wenn sich eine Konstruktion in einem fehlerhaften Zustand befindet, werden keine Nachrichten in der Übertragungswarteschlange gespeichert oder in eine Ziel-Service-Warteschlange gelegt.

Service Broker optimiert die Speicherung und Übertragung von Nachrichten, die in mehreren Konversationen in derselben SEND Anweisung gesendet werden.

Nachrichten in den Übertragungswarteschlangen für eine Instanz werden anhand folgender Kriterien der Reihe nach übertragen:

  • Prioritätsstufe ihres zugeordneten Konversationsendpunkts

  • Innerhalb der Prioritätsstufe die Sendereihenfolge in der Konversation

Prioritätsstufen, die in Konversationsprioritäten angegeben werden, werden nur für Nachrichten in der Übertragungswarteschlange angewendet, wenn die HONOR_BROKER_PRIORITY-Datenbankoption auf ON festgelegt wird. Wenn HONOR_BROKER_PRIORITY auf OFF festgelegt wird, wird allen Nachrichten in der Übertragungswarteschlange für diese Datenbank die Standardprioritätsstufe 5 zugewiesen. Prioritätsstufen werden nicht auf eine SEND Instanz angewendet, bei der die Nachrichten direkt in eine Service-Warteschlange in derselben Instanz der Datenbank-Engine gelegt werden.

Die Aussage SEND sperrt jede Unterhaltung, auf die eine Nachricht gesendet wird, separat, um eine pro Gespräch geordnete Zustellung zu gewährleisten.

SEND ist in einer benutzerdefinierten Funktion nicht gültig.

Berechtigungen

Um eine Nachricht zu senden, muss der aktuelle Benutzer eine Berechtigung für die Warteschlange jedes Dienstes haben RECEIVE , der die Nachricht sendet.

Beispiele

Im folgenden Beispiel wird ein Dialog gestartet und eine XML-Nachricht im Dialog gesendet. Zum Senden der Nachricht wird das XML-Objekt in varbinary(max) konvertiert.

DECLARE @dialog_handle UNIQUEIDENTIFIER,
    @ExpenseReport XML;

SET @ExpenseReport = <construct message as appropriate for the application>;

BEGIN DIALOG @dialog_handle
    FROM SERVICE [//Adventure-Works.com/Expenses/ExpenseClient]
    TO SERVICE '//Adventure-Works.com/Expenses'
    ON CONTRACT [//Adventure-Works.com/Expenses/ExpenseProcessing];

SEND ON CONVERSATION @dialog_handle
    MESSAGE TYPE [//Adventure-Works.com/Expenses/SubmitExpense](@ExpenseReport);

Im folgenden Beispiel werden drei Dialoge gestartet, und es wird jeweils eine XML-Nachricht gesendet.

DECLARE
    @dialog_handle1 UNIQUEIDENTIFIER,
    @dialog_handle2 UNIQUEIDENTIFIER,
    @dialog_handle3 UNIQUEIDENTIFIER,
    @OrderMsg XML;

SET @OrderMsg = '<construct message as appropriate for the application>';

BEGIN DIALOG @dialog_handle1
    FROM SERVICE [//InitiatorDB/InitiatorService]
    TO SERVICE '//TargetDB1/TargetService'
    ON CONTRACT [//AllDBs/OrderProcessing];

BEGIN DIALOG @dialog_handle2
    FROM SERVICE [//InitiatorDB/InitiatorService]
    TO SERVICE '//TargetDB2/TargetService'
    ON CONTRACT [//AllDBs/OrderProcessing];

BEGIN DIALOG @dialog_handle3
    FROM SERVICE [//InitiatorDB/InitiatorService]
    TO SERVICE '//TargetDB3/TargetService'
    ON CONTRACT [//AllDBs/OrderProcessing];

SEND ON CONVERSATION (
    @dialog_handle1,
    @dialog_handle2,
    @dialog_handle3
)
    MESSAGE TYPE [//AllDBs/OrderMsg](@OrderMsg); 

Weitere Informationen

BEGIN DIALOG CONVERSATION (Transact-SQL)
END CONVERSATION (Transact-SQL)
RECEIVE (Transact-SQL)
sys.transmission_queue (Transact-SQL)