2016-03-21 15 views
9

L'esigenza è di chiamare un servizio Web tramite SSIS e chiamare SSIS da una stored procedure attivata di SQL Server Service Broker.Chiamata SSIS con implementazione SSISDB da SQL Server Service broker

Ecco quello che ho facendo attualmente:

coda

CREATE QUEUE [schema].[ProccessingQueue] WITH STATUS = ON , RETENTION = OFF , ACTIVATION ( STATUS = ON , PROCEDURE_NAME = [schema].[usp_ProccessingQueueActivation] , MAX_QUEUE_READERS = 10 , EXECUTE AS N'dbo' ), POISON_MESSAGE_HANDLING (STATUS = ON) 

mia stored procedure:

ALTER PROCEDURE [schema].[usp_ProccessingQueueActivation] 
WITH EXECUTE AS CALLER 
AS 

BEGIN 
    SET NOCOUNT ON; 

    <snip declaration> 
    BEGIN 
     BEGIN TRANSACTION; 

      WAITFOR 
      (
       RECEIVE TOP (1) 
        @ConversationHandle = conversation_handle, 
        @MessageBody = CAST(message_body AS XML), 
        @MessageTypeName = message_type_name 
       FROM [schema].[ProccessingQueue] 
      ), TIMEOUT 5000; 

      <snip awasome stuff> 
       EXEC dbo.RunSSIS <param> 

       DECLARE @ReplyMessageBody XML = @MessageBody; 
       SEND ON CONVERSATION @ConversationHandle MESSAGE TYPE [type] (@ReplyMessageBody); 
      END 

      <handle error> 

     COMMIT TRANSACTION; 
    END 
END 

Ora qui è quello che RunSSIS stored procedure assomiglia

ALTER PROCEDURE [dbo].[RunSSIS] 
     <params> 
AS 
BEGIN 
     DECLARE @exec_id BIGINT 

     EXEC [SSISDB].[catalog].[create_execution] 
    @package_name=N'<SSIS_package>', 
    @folder_name=N'<folder>', 
    @project_name=N'<projectName>', 
    @use32bitruntime=FALSE, 
    @reference_id=NULL,    
    @[email protected]_id OUTPUT 

     EXEC [SSISDB].[catalog].[set_execution_parameter_value] 
     @exec_id, 
     @object_type=30, 
     @parameter_name=N'<param_Name>', 
     @parameter_value=<param> 

     SELECT @exec_id 

     EXEC [SSISDB].[catalog].[start_execution] @exec_id 
END 

Ora ciò genera l'eccezione seguente in event-viewer poiché il contesto di sicurezza dell'attivazione del broker di servizio Sql non è riconosciuto nell'ambiente SSISDB.

La attivato proc '[schema] [usp_ProccessingQueueActivation].' Esecuzione su coda '' in uscita il seguente: 'Il contesto di protezione corrente non può essere ripristinato. Si prega di passare al database originale dove è stato chiamato 'Execute As' e provare di nuovo . '

Per risolvere il problema ho cercato quelle seguente approccio

  • Così mi segui questo link http://www.databasejournal.com/features/mssql/article.php/3800181/Security-Context-of-Service-Broker-Internal-Activation.htm e creato un utente con un certificato auto firmato (pensando che è utente che doesn' t ha il permesso). Ma restituisce lo stesso errore, scavando più a fondo ho trovato che [interno]. [Prepare_execution] in SSISDB ha l'istruzione "REVERT" nella riga n. 36 che genera l'errore come a cui non piace affatto Impersonazione.

    • ho cercato di spostare il RunSSIS stored procedure per SSISDB e provare a chiamare da stored procedure di attivazione, era abbattere come SSISDB non consente a qualsiasi utente con autenticazione di SQL Server, ha bisogno di avere un Windows auth e User created by Certificate ovviamente non ha credenziali Windows.

La mia domanda è

  • Sono sulla strada giusta? Certamente non prevedo che usare 2 componenti del server SQL insieme sarebbe così difficile.
  • Se non nell'approccio corretto quale sarebbe l'approccio migliore per chiamare un servizio da un intermediario di servizi? Ho visto "Attivazione esterna" per il broker del servizio SQL Server ma non ho ancora esplorato. Ma cercherò di attenermi a qualcosa che vive all'interno di un ambiente server e scalabile, e non mi piace l'idea di installare componenti diversi nell'ambiente di produzione (è sempre un overhead per il supporto personale, poiché c'è un punto in più che può fail)

Sto utilizzando l'autenticazione di Windows e la mia credenziale ha accesso sys_Admin.

+0

Questo sembra un adattamento migliore per http://dba.stackexchange.com – stuartd

+0

Vedere [Attivatore esterno di Service Broker] (https://blogs.msdn.microsoft.com/sql_service_broker/2009/05/18/get- started-with-using-external-activator /) –

+0

La firma del codice funziona? https://msdn.microsoft.com/en-us/library/bb283630.aspx –

risposta

0

Penso che si possa prendere "WITH EXECUTE AS CALLER" e tutto (il proc e quindi il pacchetto che finisce per essere chiamato) verrà eseguito nel contesto di sicurezza di Service Broker. Finché quel contesto ha le autorizzazioni per fare ciò che vuoi fare, dovresti stare bene.

Non ho usato un Service Broker in questo modo, ma faccio la stessa cosa con i job sparati da SQL Agent. Finché il contesto di sicurezza dell'agente ha le autorizzazioni necessarie nei proc/pacchetti, tutto funziona correttamente. Usiamo account di rete per i nostri servizi in modo che tutto funzioni anche tra i server.

+0

È un po 'tardi per rispondere, Abbiamo effettivamente abbandonato l'intero SSIS chiamante -> webservice dal broker di servizi Sql e viene utilizzato con SQL CLR route . Per proteggere la chiamata, disabilitiamo la chiamata anonima e forziamo l'accesso a Windows, Dato che si tratta di un sito intranet, e inoltre ci aspettiamo che tutti coloro che chiamano il sito web debbano effettuare l'accesso, Questo funziona. Ma continuo a riempire questa è un'opportunità mancata da Microsoft per creare un vero sistema basato su eventi push dal Database – Sukanta

0

Questo ha un odore di codice di accoppiamento stretto e il mio primo istinto è quello di disaccoppiare la coda, il DB che ospita il proc e l'esecuzione di SSIS in uno script PowerShell. Chiedi allo script di ricevere i messaggi dal broker di servizi, quindi chiama SSISDB su una connessione diversa senza disporre di [catalog].[create_execution] e [catalog].[set_execution_parameter_value] in un processo memorizzato. È ancora possibile eseguire questo script direttamente da Agent.

Questo approccio offre la massima flessibilità per quanto riguarda i contesti di sicurezza, se uno dei componenti si sposta su un server diverso, se qualcosa è denominato diversamente in dev/QA o le tecnologie cambiano (ServiceBus di Azure invece di Broker per esempio) . Puoi anche essere creativo con la registrazione/monitoraggio.

Problemi correlati