Es ist zu kompliziert um es umzusetzen:
Gutes Beispiel, bei dem es eigentlich funktionieren sollte – aber MS typisch – nicht läuft:
Gedanken zu SQL, Reports, ETL und CRM
Es ist zu kompliziert um es umzusetzen:
Gutes Beispiel, bei dem es eigentlich funktionieren sollte – aber MS typisch – nicht läuft:
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…
Das Anlegen von Agent Jobs sind eigentlich recht einfach. Aber gilt nicht für den allerersten Job;-). Aber es sind mehrere Schritte:
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
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.
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:
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.
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“
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
Wozu Integrationuser, Scribeuser oder SSISUser? Und wenn das etwas bringt was kostet das und wie kann das erreichen?
Wozu? Bei Integration von zwei Systemen müssen alle Änderungen jeweils des Anderen bringen. Und solche Änderungen können die Änderungen dieses speziellen „Integrationuser“ herausgefiltert werden.
Was kostet das? Im MSCRM kann das ein kostenfreier User sein – solange dieser „Non-Interactive“ ist. Gilt für on-premise und Online.
Wie kann man erreichen? Diesen User Neuanlegen und dabei so einstellen:
Dabei kann es sein, bei einem MS Dynamic 365 einen zeitliche Aspekt zu beachten. Hier fand ich einen gute Beschreibung:
https://community.dynamics.com/crm/b/innovatingoncrm/archive/2014/09/25/crm-online-non-interactive-user
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\
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
Das Kingsway „SSIS Integrations Toolkit for Dynamics 365“ kann seit den neuen Versionen die Parallelität ein- bzw. ausschalten:
In selbst umgesetzten Importe wurde die Parallelität jedoch komplett anderes umgesetzt.
Einer der wichtigsten Punkte war wie Klarheit, welche Sätze Importiert wurde und welche nicht. Es wurden die Sätze z. B. nach dem Erstem Buchstaben des Namens in eigene Jobs verteilt und damit 26 oder 27 Jobs (A-Z und andere Zeichen) gleichzeitig erlaubt. Technisch sind diese vielen Jobs alle nur ein Einziger, jedoch Aufgerufen mit Parametern. Der klare Vorteil, wenn bestimmte Buchstaben vollständig durchlief, mussten nicht alle neu importiert, sondern fehlerfreie Buchstaben konnten deaktiviert werden und mussten damit nicht erneut importiert. Immer wenn einmal die Menge groß wird und damit mehrere Millionen Sätze importiert werden müssen, kommt der Faktor „Laufzeit“ ins Spiel und dann können Importe auch überraschend abgebrochen aus anderen Gründen des Imports-Job selber. Und die leichte Übersicht spart viel Analyse und dann können die fehlende Jobs viel schneller wieder gestartet werden.
In der Realität müssen die Anzahl der parallele Jobs passen zu den Kapazitäten vom Import-Server, Frontserver und dem SQL Server. Wenn Virtuelle Server benutzt werden, können speziell diese zu den Initial Importen kurzfristig anders konfigurieren als in der Produktivzeit.
Merge per Kingswaysoft Nötig ist dazu das normale „SSIS Integration Toolkit for Microsoft Dynamics 365“ und nicht das „SSIS Productivity Pack“. Link: https://www.kingswaysoft.com/products/ssis-integration-toolkit-for-microsoft-dynamics-365/help-manual/crm/destination
CRM Destination Component Editor – Action (Nur möglich bei account / contact / lead / incident):
Merge action is only possible with the following CRM entities:
When Merge action is chosen, you will be working with the following 4 columns with the first two columns being required in order to merge a pair of CRM records:
Doublettenerkennung Test: Kingswaysoft „Duplicate Detector“
Beispiel: http://www.tpein.dk/?p=242
Eine Quelle und sucht innerhalb dieser Quelle nach Doubletten:
Es können mehrere Rechte im MSCRM für eine Person bzw. Team und jede Entität und und und …
Die Rechte sollten klar festzustellen, aber gelegentlich gibt es Ausnahmen. Siehe unten!
Beispiel ein Import meldet die Fehlermeldung mit der Nummer 262153.
Ein Binäre Darstellung gibt:
0100 0000 0000 0000 1001
…(siehe Link)…
But wait, There is no Access Right with a binary value of 1000. Since I’ve been unable to find any other documentation, my guess is that something on our installation (that was an upgrade from a CRM 4.0 server) still has a reference to the CRM 4.0 enum values in which AppendToAccess is actually 8 (1000) rather than 16 (0001 0000).
Using that assumption and the table above, 262153 is made up of ShareAccess, AppendToAccess, and ReadAccess. This means the user has to have sufficient Access Levels for Share, Append, and Read privileges of the entity, in order to successfully perform the requested operation.
Quelle:
http://dotnetdust.blogspot.com/2014/03/how-to-interpret-accessrights-numbers.html
Sehr gute Zusammenfassung unter:
Installation guide to Kingswaysoft:
http://www.tpein.dk/?page_id=262
Software download list:
http://www.tpein.dk/?page_id=274
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/
Wenn erst später ein neuer SQL Server installiert wird, und dann z.B. als Ziel des Visual Studio Projektes jetzt auf „SQL Server 2016“ wechselt wird, dann sind die Kingswaysoft Controls nicht mehr vorhanden!
Versuche:
Repair oder Change des „SSIS Integration Toolkit for Microsoft Dynamics 365“ scheidet wenn das Toolkit weiterhin im Visual Studio sichtbar ist.
Lösung:
Deinstallieren des „SSIS Integration Toolkit for Microsoft Dynamics 365“ und einfach dann wieder installieren. Eine ggf. installierte Lizenz ist dann weiterhin gültig (soweit diese vorher auch gültig war;-)
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