Aufrufen von SSIS mit SSISDB-Implementierung vom SQL Server-Service-Broker

Question

Aufrufen von SSIS mit SSISDB-Implementierung vom SQL Server-Service-Broker

9

Die Anforderung besteht darin, einen Webdienst über SSIS aufzurufen und das SSIS von einer SQL Server Service Broker-gespeicherten Prozedur aufzurufen.

Hier ist, was ich gerade mache:

Warteschlange

%Vor%

Meine gespeicherte Prozedur:

%Vor%

Nun sieht die gespeicherte RunSSIS-Prozedur wie folgt aus:

%Vor%

Jetzt wird die folgende Ausnahme in der Ereignisanzeige ausgelöst, da der Sicherheitskontext für die Sql-Service-Broker-Aktivierung in der SSISDB-Umgebung nicht erkannt wird.

Der aktivierte Proc '[schema]. [usp_ProccessingQueueActivation]' läuft weiter Warteschlange '' Ausgabe der folgend: 'Der aktuelle Sicherheitskontext kann nicht zurückgesetzt werden. Bitte Wechseln Sie zur ursprünglichen Datenbank, in der "Execute As" aufgerufen wurde, und versuchen Sie es es wieder. "

Um das Problem zu lösen, habe ich die folgenden Ansätze ausprobiert

Also folge ich diesem Link Ссылка und einen Benutzer mit einem selbstsignierten Zertifikat erstellt (denke, dass es ist ein Benutzer, der keine Berechtigung hat). Aber es gibt denselben Fehler zurück, tiefer graben fand ich das [intern]. [prepare_execution] in SSISDB hat die Anweisung "REVERT" in Zeile 36, die den Fehler als verursacht es mag keine Impersonation überhaupt.
- Ich habe versucht, die gespeicherte RunSSIS-Prozedur in SSISDB zu verschieben und zu versuchen, sie von der gespeicherten Aktivierungsprozedur aufzurufen, sie wurde abgeschossen, da SSISDB keinen Benutzer mit SQL Server-Authentifizierung erlaubt. Sie muss über eine Windows-Authentifizierung und Benutzer verfügen Erstellt von Zertifikat hat offensichtlich keine Windows-Anmeldeinformationen.

Meine Frage ist

Bin ich auf dem richtigen Weg? Ich erwarte sicherlich nicht 2 Komponenten von SQL-Server zusammen zu verwenden wäre so schwierig.
Wenn nicht in korrekter Vorgehensweise, was wäre der beste Ansatz, um einen Service von Service Broker aufzurufen? Ich habe "External Activation" für SQL Server Service Broker gesehen, aber noch nicht untersucht. Aber ich würde versuchen, bei etwas zu bleiben, das innerhalb der Serverumgebung lebt und skalierbar ist, und nicht die Idee mag, verschiedene Komponenten in der Produktumgebung zu installieren (es ist immer ein Overhead für den Support persönlich, da es noch einen Punkt gibt, der es kann) scheitern)

Ich verwende Windows-Authentifizierung und meine Berechtigung hat sys_Admin Zugriff.

sql-server ssis service-broker

Sukanta 21.03.2016, 22:06

quelle

2 Antworten

Tags und Links sql-server ssis service-broker

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Android Datenbindung mit Menüs

score 0 · Answer 1

Ich denke, Sie können den "WITH EXECUTE AS CALLER" herausnehmen und alles (das proc und dann das Paket, das letztendlich aufgerufen wird) wird unter dem Sicherheitskontext des Service Brokers ausgeführt. Solange dieser Kontext die Berechtigung hat, das zu tun, was Sie tun möchten, sollten Sie in Ordnung sein.

Ich habe keinen Service Broker auf diese Weise verwendet, aber ich mache dasselbe mit Jobs, die vom SQL Agent abgefeuert werden. Solange der Sicherheitskontext des Agenten die Berechtigungen hat, die in den Procs / Paketen benötigt werden, läuft alles gut. Wir verwenden Netzwerkkonten für unsere Dienste, so dass alles zwischen den Servern funktioniert.

score 0 · Answer 2

Dies hat einen Code-Geruch nach enger Kopplung und mein erster Instinkt besteht darin, die Warteschlange, die DB, in der sich der Proc befindet, und die SSIS-Ausführung in ein PowerShell-Skript zu entkoppeln. Lassen Sie das Skript die Nachrichten vom Service Broker abrufen und rufen Sie dann SSISDB auf einer anderen Verbindung auf, ohne [catalog].[create_execution] und [catalog].[set_execution_parameter_value] in einem gespeicherten Prozess zu verpacken. Sie können dieses Skript weiterhin direkt vom Agenten ausführen.

Dieser Ansatz bietet Ihnen die größte Flexibilität in Bezug auf Sicherheitskontexte, wenn eine der Komponenten auf einen anderen Server wechselt, wenn etwas in dev / QA anders benannt wird oder sich Technologien ändern (Azure ServiceBus anstelle von Broker für Beispiel). Sie können auch mit der Protokollierung / Überwachung kreativ werden.