Azure Data Factory (ADF)

SQL Satury – Transitioning From SSIS to Azure Data Factory:
https://www.sqlsaturday.com/SessionDownload.aspx?suid=17898

Azure Data Factory Dokumentation:
https://docs.microsoft.com/de-de/azure/data-factory/

On-Premise / Hybrid (Azure – SSIS) / Azure:
https://docs.microsoft.com/de-de/azure/data-factory/concepts-integration-runtime

Zugriff auf On-Premise SQL Server:
https://docs.microsoft.com/de-de/azure/data-factory/create-self-hosted-integration-runtime

Bereitstellen der Azure-SSIS Integration Runtime in Azure Data Factory:
https://docs.microsoft.com/de-de/azure/data-factory/tutorial-deploy-ssis-packages-azure

 

 

 

Nur Fehlernummern (Error Code) in SSIS-Jobs

Leider werden in SSIS-Jobs nur unverständliche Fehlernummern hinterlegt. Manche Nummern sind auch im Internet nicht sofort zu finden.
Eine Lösung, wäre suchen nach der Fehlernummer in d. u. g. Seite:
https://docs.microsoft.com/en-us/sql/integration-services/integration-services-error-and-message-reference?view=sql-server-2017
Oder diese Liste einmal in eine eigene Datenbank hinterlegen und dann können diese Fehlermeldung in Jobs erweitert werden…

SQL: Deploy SSIS-Solution

Es gibt prinzipiell verschiedene Stellen, wohin man den Code ablegen kann, damit der SQL Server diesen aufruft.

  • Filesystem
  • SQL Server
  • SSIS Package Store
  • SSIS Catalog

Wobei ich derzeit diese letzte Variante „SSIS Catalog“ in aktuellen Datenbanken. Es wird in der Datenbank automatisch eine Datenbank „SSISDB“ und soweit die Service Integration auch installiert ist, gibt es auch einen „Integration Services Catalog“. Beim Erstem Aufruf muss ein Passwort hinterlegt werden (IMHO unveränderbar). Es wird dann der erste Ebene „SSISDB“ angelegt und darunter können/müssen für jede SSIS-Solution, die man hier ablegt gleich einen neuen Ordner anlegen. Daher bitte die Ordner die Ordnernamen sprechend festlegen (wieder IMHO kaum unveränderbar).

Hier meine Schritte:

SQL: Agent Job anlegen

Das Anlegen von Agent Jobs sind eigentlich recht einfach. Aber gilt nicht für den allerersten Job;-). Aber es sind mehrere Schritte:

  1. Meist erst das Bereitstellen einer SSIS-Solutions. Dazu mehr unter „SQL: Deploy SSIS-Solution“
  2. Einmalig meist das Anlegen eines Credentials und eines Proxy. Dazu mehr unter „SQL: Credentials und Proxy“
  3. Dann das eigentliche Anlegen des Agent Jobs (hier unten im Text)
  4. Und das Testen…Und wo man die Ursachen von Fehlern findet (hier ganz unten im Text)

Möglicherweise fehlen noch Rechte:

Lösung: Rolle ssis_admin in SSISDB und Rolle db_ssisoperator in msdb hinzufügen. Falls dann sind aber diese „User“ zwar in den beiden Datenbank (jeweils unter: Security / Users) sichtbar, aber so mit einem „X“ oder „irgendwie deaktiviert“… Dann müssen diese User auch in der Datenbank hinzugefügt werden – wie im T-SQL Code:
(Bitte die meinuser und meinlogin anpassen – und häufig sind beide gleichen Buchstabenfolge. Speziell bei AD-Usern und AB-Gruppen.)

USE [SSISDB]
GO
CREATE USER [ meinuser ] FOR LOGIN [ meinlogin ] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember @rolename = 'ssis_admin', @membername = 'meinuser';
GO

USE [msdb]
GO
CREATE USER [ meinuser ] FOR LOGIN [ meinlogin ] WITH DEFAULT_SCHEMA=[dbo]
GO
EXEC sp_addrolemember @rolename = 'db_ssisoperator', @membername = 'meinuser';
GO

SSIS Job: OLEDB oder ADO.NET?

Was ist besser OLEDB oder ADO.NET?

Diese Frage kann ich nicht beantworten, aber in einem DataFlow kann zwar beides benutzt werden, aber wenn ADO.NET als Quelle benutzt wird, werden auch „char(…)“ immer weitergeleitet als „nchar(…)“ – Und wenn auch das Ziel unbedingt char(…) sein, müsste man das wieder zurückwandeln
Das Bedeutet für mich: Im Zweifel OLEDB…

4. Jun. 2019 Zusatz: 
Als Ziel wurde ein ADO.NET benutzt und mehrere hundert Sätze wurden ohne entsprechende Fehlermeldung nicht importiert. Genauer, wir hatten 1-4 Fehlermeldungen und viele fehlenden Sätzen – aber nicht „Bulk“! Wir hatten „Bulk“ nicht angehakt. 

 

„Full cache“ oder „Partial cache“ in dem „Lookup“ Control?

Was ist der Unterschied?

Der „Full cache“ wird (vermutlich) nur einmal geladen und während des Imports nicht mehr aktualisiert.
Dieser Cache wird komplett im Arbeitsspeicher abgelegt und nicht ausgelagert – kann also bei riesigen durchsuchten Tabellen zum „out of memory“ führen.
Und genauso wichtig: der Full Cache wird immer „Case sensitive“ genutzt – ein MSCRM dagegen meist „Case Insensitive“!

Der „Partial cache“ wird aktualisiert, wenn im erstem Moment im Cache kein Treffer ist, wird erst versucht ob das Satz schon in der DB ist und wenn das so ist, wird dieser Treffer im Cache eingetragen.

Das bedeutet für die normale Integration soll/muss meist „Partial cache“ genutzt werden, wenn Tabellen durchsucht werden, die möglicherweise neue bzw. andere Sätze enthalten!

 

Link/s:

https://blog.sqlauthority.com/2014/05/15/sql-server-ssis-look-up-component-cache-mode-notes-from-the-field-028/

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/0e9a7e11-7baa-4147-ab02-02f43bbe0a87/what-is-difference-between-full-cache-and-partial-cache-in-lookup-transformation-in-ssis?forum=sqlintegrationservices

https://blogs.msdn.microsoft.com/mattm/2008/11/23/lookup-pattern-incremental-persistent-cache-updates/

 

VisualStudio 2017: Text in Annotation ist unsichtbar?

Wieso ist der Text unsichtbar ist? Ursache weiterhin unbekannt, aber die Lösung: Die Annotation anklicken – solange man weiß wo die sein sollte;-(

Dann ist der Rahmen sichtbar und „rechter Mausklick“ im Annotation  den Dialog „Set Text Annotation Font…“ öffnen und nur mit „OK“ bestätigen…

Problem ist natürlich für einen Dritten, der keine Idee haben kann wo ein Text versteckt sein könnte…. 

Bisher ist mir keine sonstige Lösung bekannt.

Voraussetzung für das Anlegen von SSIS – SQL Agent Jobs

Vorab:
Um einen normalen SSIS-Job (*.dts oder *.ispac) als SQL Server Agent Job laufen zu lassen, muss ein Proxy festgelegt sein – und beim Anlegen eines Proxy werden die hinterlegten Credentials verlangt.
Also muss zuerst ein Credentials hinterlegt werden.

SQL Server Aufruf: „Security / Credentials“
Credentials name: SendDataMigrationStatusCred
Identity: „Domain User“ (e.g. Admin, SSISAdmin… ask the Support)

SQL Server Aufruf: „SQL Server Agent / Proxies“:
Proxy name: SendDataMigrationStatusProxy
Credentials name: SendDataMigrationStatusCred
Active to he following subsystems: SQL Server Integration Services Packages
(Wir wollen üblicherweise diesem Proxy nur das Erlauben, was unbedingt nötig ist – also nur ein einziges Häkchen)

SQL Server Aufruf: „SQL Server Agent / Jobs“
Anlage eines neues Agent Jobs:  DeltaImport
Der Job hat nur einen einzigen Step (in diesem Beispiel):
Hinweis: Dieses Beispiel nutzt einen *.ispac Job, der im SSIS-Catalog hinterlegt ist.

„Schedules“ oder andere Einstellungen können an dieser Stelle festgelegt werden.

Oder es werden die Schedules nicht hier definiert, sondern als „Maintenance Plans“. Das erlaubt mehr Möglichkeiten wie ein „Controlling“. Damit können bei Abbruch eines Agent Jobs andere Agent Jobs aufgerufen werden oder bestimmte Einstellungen zurückgesetzt werden bevor der geplante Agent Job gestartet wird.

 

 

Management / Maintenance Plans
Check DeltaImport“

DataTools sind plötzlich verloren – was kann los sein?

Das Problem erwischt uns bei uns seit kurzer Zeit ganz kalt:
Von heute auf morgen kann man nicht mehr Integration Service Projekte aufrufen.

Vorab: Die Ursache ist schlicht und einfach war das „Disable the extension“ anzuklicken – Bitte: Maximal darf „Never Show this message again“ angeklickt werden, oder ganz rechts das „X“.

Was war passiert?

Als das Visual Studio gerade einmal neu gestartet wurde… und nichts geht mehr!


Auch ein „vollständiges VisualStudio“ und „DataTools“ oder nur die „DataTools“ Update, Repair, Neuinstallation… hat bisher gar nichts gebracht– höchstens Zeit, Nerven oder ein noch kaputteres System!

Lösung im Visual Studio: Einfach dieses „Microsoft Integration Service Projekts“ wieder „enablen“:
(Aufruf über Menü im VS: Tools / Extensions an Updates / „Microsoft Integration Service Projekts“)

Dann muss man (derzeit) das Visual Studio leider noch einmal starten und weil die Anzeige scheinbar weiterhin so kaputt ist, muss man jetzt die Projekt einfach „reloaden“:

Wie wurde das überhaupt disabled? Ja, die Ursache ist der Empfehlung  von Microsoft zu folgen und einfach die „Extension“ zu disablen (siehe ganz oben den gelben Balken;-).

Diese Quelle hilft (aber zeigte nicht die Ursache):
https://stackoverflow.com/questions/49310399/microsoft-datatransformationservices-wizards-error-in-vs-2017

SQL Server und VisualStudio: 32 oder 64 bit? Welches Target ist möglich?

Wenn man einen einzigen SQL Server frisch installiert hat, dann scheint es einfach sein. Aber falls man auf eine unbekanntes System kommt, muss man selber schauen:

--SQL Serverversion:
Select @@version

Aber wenn man dann per VisualStudio und/oder den Data Tools Jobs anlegt, dann muss meist das „Target“ korrekt angepasst werden und muss mehr hinterfragen:

<nnn> Version 32/64bit
140 SQL Server 2017
130 SQL Server 2016
120 SQL Server 2014
110 SQL Server 2012

Um 32 bit oder 64 bit zu entscheiden, muss im Filesystem nachgeschaut werden und kontrolliert werden, ob eine DtsDebugHost.exe vorhanden ist:

C:\Program Files (x86)\Microsoft SQL Server\<nnn>\DTS\Binn\

oder

C:\Program Files\Microsoft SQL Server\<nnn>\DTS\Binn\

SSIS/Kingsway MSCRM-Lookup per ScriptComponent

 

Verweise:

//KingswaySoft.DynamicsCrmServices   
//Pfad: C:\WINDOWS\assembly\GAC_MSIL\KingswaySoft.DynamicsCrmServices\1.0.0.0__705df8e0751bcea7\KingswaySoft.DynamicsCrmServices.dll
//KingswaySoft.IntegrationToolkit.DynamicsCrm   
//Pfad: C:\Program Files (x86)\Microsoft SQL Server\120\DTS\PipelineComponents\KingswaySoft.IntegrationToolkit.DynamicsCrm.dll

Namespaces im Code:

using KingswaySoft.DynamicsCrmServices.Soap2011.OrganizationService;
using KingswaySoft.DynamicsCrmServices.Soap2011.OrganizationService.Messages;
using KingswaySoft.DynamicsCrmServices.Soap2011.OrganizationService.Metadata;
using KingswaySoft.DynamicsCrmServices.Soap2011.OrganizationService.Query;
using KingswaySoft.IntegrationToolkit.DynamicsCrm;

Code:

    public override void Input0_ProcessInputRow(Input0Buffer Row)
    {
        /*
         * Add your code here
         * 
         * http://www.kingswaysoft.com/blog/2013/06/24/Writing-Script-Component-or-Script-Task-using-CRM-Connection-Manager
         */

        //var connMgr = this.Connections.Dynamics365;
        //var conn = (CrmConnection)connMgr.AcquireConnection(null);

        var connMgr = this.Connections.Dynamics365;
        var connectionString = (string)connMgr.AcquireConnection(null);
        var conn = new CrmConnection(connectionString);

        var orgService = (IOrganizationService)conn.GetCrmService();

        //Select parentcustomerid from contact where contact = '00000-0000000000-00000-00000-0000'
        var inputValue = Row.contactid;  // input0: Field "contactid"
        var retrievedEntity = orgService.Retrieve("account", parmInputvalue, new ColumnSet("parentcustomerid"));
        var outputValue = retrievedEntity.GetAttributeValue("parentcustomerid");
        Row.parentcustomerid = outputValue;  // output0: new Field "parentcustomerid"
    }
</pre

 

Läuft gerade ein SSIS Job?

Das kann per SQL festgestellt werden:

/*per SQL die "laufende SSIS package executions" 
bestimmen:*/
/*Select status, start_time as start_time2, 
         folder_name, project_name ,* 
  from SSISDB.catalog.executions 
  where end_time is null 
  order by start_time desc
*/
Select top 5 status, start_time as start_time2, 
   folder_name, project_name ,* 
from SSISDB.catalog.executions 
order by start_time desc
/*
Die richtige execution_id auswählen und als 
@operation_id eintragen 
(typisch MS - muss ja auch keiner Logik folgen):
Exec catalog.stop_operation  @operation_id =  12210
Exec catalog.stop_operation  @operation_id =  12211
*/


…oder im SSMS (Management Studio) herausfinden:

per SSMS-Dialog:
Rechte Maus auf „Integration Services Catalogs \ SSISDB“ und „Active Operations“ auswählen…Dort die gewünschte Package auswählen und auf „STOP“ klicken.

Links:
https://sabigdata.wordpress.com/2015/02/12/stop-ssis-package-execution-in-ssis-catalog/

Voraussetzungen für Importe per SSIS

Voraussetzungen für Importe per SSIS: 1) DataTools installieren oder VisualStudio + DataTools for VS 2) Kingswaysoft installieren: „SSIS Integration Toolkit for Microsoft Dynamics 365“ Automatisierung: Nur wenn Lizenz installiert ist 3) Zugriff auf den „Quell-SQL Server“ und/oder Sonstige Quellen 4) Zugriff auf das Ziel „MS Dynamics 365“ bzw. MSCRM 5) Zugriff auf einen „Import-SQL Server“ Versionen? Express: Automatisierung als BATCH Sonst (Standard, Enterprise, ..): Automatisierung per Agent Jobs und/oder SSIS Integration Service und/oder BATCH 6) Datenbank „FOD_StagingDB“ (Angelegt von Importen für Logging, Crossreference, Errorhandling, …) (Benutzt bei Importen per SSIS/Kingswaysoft) Hinweise: • Abhängigkeiten bei Zugriffen von „SELECT – Zugriffe mit Daten mit zwei oder mehreren unterschiedlichen Server kann bestehen z.B. Unterschiede von Daten vom Quell- und Ziel-Server zu bestimmen… • Wie sollen bei Fehlern reagiert werden? Gar kein Errorhandling oder sollen alle Error „wieder vorgelegt werden“ bis Fehler gelöst ist? • Migration oder Integration? ODFR hat bisher keine Migration erlebt! • Unterschied zwischen Full-Import und Delta-Import? Delta-Importe können so geschrieben werden, dass z.B. am jedem 1. Samstag auch Full-Importe erlauben! • Können wir E-Mails an Kd. und uns senden bezüglich bestimmter Fehler/Abbrüche? ODFR empfiehlt dies einzurichten

SSIS package executions in „SSISDB“ (Integration Service Catalogs)

Di laufende SSIS package executions in dem Integration Server Catalog finden und ggf. beenden.

Quelle: https://sabigdata.wordpress.com/2015/02/12/stop-ssis-package-execution-in-ssis-catalog/

/*
Stop SSIS package executions in "SSISDB" (Integration Service Catalogs)

Links:
Stop SSIS Package execution in SSIS.Catalog
*/

--per SSMS-Dialog:
--Rechte Maus auf "SSISDB" und "Active Operations" auswählen...Dort den gewünschten Paackage auswählen und auf "STOP" klicken.

--per SQL die "laufende SSIS package executions" bestimmen:
Select status, start_time as start_time2, folder_name, project_name ,* from SSISDB.catalog.executions where end_time is null order by start_time desc
/*
--Die richtige execution_id auswählen und als @operation_id eintragen (typisch MS - muss ja auch keiner Logik folgen):
Exec catalog.stop_operation  @operation_id =  ...
*/