Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Gilt für:SQL Server
Azure 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)