Gedanken zu SQL, Reports, ETL und CRM
Egal bei Benutzung im Architekt oder über dem Administrator Tool, bei beiden erfolgen Fehlermeldungen:
Auch Neustart bringt nichts.
SLX 7.5.3 Datenbank eingehängt in eine installierte SLX 7.5.4 Umgebung. Ist das die Ursache?
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
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
Sobald ein Report neu angelegt wird. können auch viele Parameter automatisch angeboten werden. Diese Parameter sind „hidden“ und haben lediglich einen statischen „Default“ Value.
Lediglich haben einige Parameter eine besondere Bedeutung. Speziell „CRM_Url“: DIeser (leere!) Parameter wird benötigt um von einem Report wieder in das CRM zu springen.
Es können bei on-Premise MSCRM prinzipell mit SQL als auch XML-Fetch die Daten im Report bneutzt werden. Aber das MSCRM kann ohne die Daten im Code direkt zu beschränken bzw. diese zu filtern: Durch Pre-Filterung!
Ein Dataset muss dabei nur
* bei Datasets mit SQL-Query: muss das ALIAS der Tabelle mit „CRMAF_“ angefangen
* bei XML Fetch: muss z.B. in der <entity name=“account“ enableprefiltering=“1“> eingetragen werden.
Links:
https://nishantrana.me/2014/07/06/using-pre-filtering-in-fetch-xml-based-report-in-crm-2013-online/
Set col = datagrid.Columns.Add(8) ' "8" indicates a Combo column
With col
.Caption = "Some Field"
.FieldName = "SOMEFIELD"
.Visible = true
.Width = 50
.ReadOnly = false
.DisableEditor = false
With .Items
.Add("Value 1")
.Add("Value 2")
.Add("Value 3")
End With
End With
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
GILT NIE ALS AUGETESTET!!!!
Eine SalesLogix Tabelle umbennen openCRMS schrieb am 4. Oktober 2009 15:45 Es passiert jedem Entwickler einmal, dass er einen Tipp- oder Schreibfehler beim Erstellen einer SalesLogix-Tabelle im Architect macht. Da der Architect jedoch leider keine Option bietet eine Tabelle umzubenennen, muss man den Umweg über SQL gehen. Dies wiederum führt dazu, dass eine auf SQL Basis umbenannten Tabelle in SalesLogix nicht mehr korrekt nutzbar ist. Der Grund hierfür ist die Tatsache, dass beim Anlegen einer SalesLogix Tabelle im Databasemanager des Architects, der Tabellenname zugleich in mehreren Tabellen als Systeminformation gespeichert wird: in der Tabelle SECTABLEDEFS, RESYNCTABLEDEFS und JOINDATA.
Um diese Probleme zu umschiffen, habe ich den folgenden SQL-Script geschrieben, dass es mir erlaubt, eine SalesLogix-Tabelle, die ich im SQL Server Management Studio umbenannt habe, in SalesLogix wieder benutzen kann.
ACHTUNG: Machen Sie das nicht so einfach, falls auch Remote-Clients in dem System vorkommen könnten!
/*
GILT NIE ALS AUGETESTET!!!!
Eine SalesLogix Tabelle umbennen
openCRMS schrieb am 4. Oktober 2009 15:45
Es passiert jedem Entwickler einmal, dass er einen Tipp- oder Schreibfehler
beim Erstellen einer SalesLogix-Tabelle im Architect macht. Da der Architect
jedoch leider keine Option bietet eine Tabelle umzubenennen, muss man hierfÜr
den Umweg über SQL gehen. Dies wiederum fÜhrt dazu, dass eine auf SQL Basis
umbenannten Tabelle in SalesLogix nicht mehr korrekt nutzbar ist. Der Grund
hierf¸r ist die Tatsache, dass beim Anlegen einer SalesLogix Tabelle im
Databasemanager des Architects, der Tabellenname zugleich in mehreren Tabellen
als Systeminformation gespeichert wird:
in der Tabelle SECTABLEDEFS, RESYNCTABLEDEFS und JOINDATA.
Um diese Probleme zu umschiffen, habe ich den folgenden SQL-Script geschrieben, dass es mir erlaubt, eine SalesLogix-Tabelle, die ich im SQL Server Management Studio umbenannt habe, in SalesLogix wieder benutzen kann:
*/
Declare @myTable varchar(128)
Declare @newTableName varchar(128)
set @myTable = 'ALTER_NAME'
set @newTableName = 'NEUER_NAME'
select * from sysdba.SECTABLEDEFS where TABLENAME = @myTable
update sysdba.SECTABLEDEFS
set TABLENAME = @newTableName
where TABLENAME = @myTable
update sysdba.RESYNCTABLEDEFS
set TABLENAME = @newTableName
where TABLENAME = @myTable
update sysdba.JOINDATA
set FROMTABLE = @newTableName
where FROMTABLE = @myTable
update sysdba.JOINDATA
set TOTABLE = @newTableName
where TOTABLE = @myTable
Gelegentlich kommt es vor, dass das MSCRM hängt und die Anwender auch nicht benutzten können und asynchrone Jobs sich selber sperren.
Es hilft meist, den „Async Job“ einfach Neustarten…
/*Anzahl der Sätze Total*/
Select Count(1) from [dbo].[AsyncOperationBase] with (nolock)
/*Benutzung*/
Select Sum(Coalesce(Len([Data]),0)) as [Data]
,Sum(Coalesce(Len([WorkflowState]),0)) as [WorkflowState]
,Sum(Coalesce(Len([Message]),0)) as [Message]
,Sum(Coalesce(Len([RegardingObjectIdName]),0)) as [RegardingObjectIdName]
,Sum(Coalesce(Len([RegardingObjectIdYomiName]),0)) as [RegardingObjectIdName]
,Sum(Coalesce(Len([FriendlyMessage]),0)) as [FriendlyMessage]
,Sum(Coalesce(Len([OwningExtensionIdName]),0)) as [OwningExtensionIdName]
from [dbo].[AsyncOperationBase] with (nolock)
/*Interner Zustand der Tabelle... z.B. falls diese riesig ist*/
SELECT 'AsyncOperationBase' Tablename, type_desc, total_pages * 8 as total_pages_in_KB, used_pages * 8 as used_pages_in_KB, total_pages, used_pages, data_pages,container_id, allocation_unit_id
FROM sys.allocation_units
WHERE container_id in (SELECT partition_id FROM sys.partitions WHERE OBJECT_ID = OBJECT_ID('AsyncOperationBase') )
/*Verteilung bezüglich des StatusCode*/
Select StatusCode, COUNT(1) Anzahl, Case when StatusCode=0 Then 'Ready/WaitingForResources'
when StatusCode=10 Then 'Suspended/Waiting'
when StatusCode=20 Then 'Locked/InProgress'
when StatusCode=21 Then 'Locked/Pausing'
when StatusCode=22 Then 'Locked/Canceling'
when StatusCode=30 Then 'Completed/Succeeded'
when StatusCode=31 Then 'Completed/Failed'
when StatusCode=32 Then 'Completed/Canceled'
Else 'unbekannter Status'
END StatusCode_Readable
FROM dbo.[AsyncOperationBase] with (nolock)
Group by StatusCode
Wenn es mehrere Millionen Sätze gibt, dann lohnt sich die Missing Indizees einmal anzuschauen…
Es gibt normalerweise eine regelmäßigen Bereinigungs-Job, der alte Sätze löscht.
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
Bei „Product“, „Quote“ und „Opportunity“ (und weiteren Entitäten) kommen Pflicht-Felder vor. Z.B. sind „Einheiten“ verlangt. Bei einem Import stößt man auf dieses ER-Model:
Beispiel: UOMGroup: „Weight“
UOM: „Gramm“, „Kilogramm“, „Tonne“
Prinzipiell werden die Daten im MSCRM in den folgenden Tabellen
Es gibt neben der Grafik weitere Activities, die das MSCRM unterstützt.
/*
NOCH *NICHT* AUGETESTET!!!!
Eine SalesLogix Tabelle umbennen
openCRMS schrieb am 4. Oktober 2009 15:45
Es passiert jedem Entwickler einmal, dass er einen Tipp- oder Schreibfehler
beim Erstellen einer SalesLogix-Tabelle im Architect macht. Da der Architect
jedoch leider keine Option bietet eine Tabelle umzubenennen, muss man hierfür
den Umweg über SQL gehen. Dies wiederum führt dazu, dass eine auf SQL Basis
umbenannten Tabelle in SalesLogix nicht mehr korrekt nutzbar ist. Der Grund
hierfür ist die Tatsache, dass beim Anlegen einer SalesLogix Tabelle im
Databasemanager des Architects, der Tabellenname zugleich in mehreren Tabellen
als Systeminformation gespeichert wird:
in der Tabelle SECTABLEDEFS, RESYNCTABLEDEFS und JOINDATA.
Um diese Probleme zu umschiffen, habe ich das folgenden SQL-Script geschrieben, dass es mir erlaubt, eine SalesLogix-Tabelle, die ich im SQL Server Management Studio umbenannt habe, in SalesLogix wieder benutzen kann:
*/
Declare @myTable varchar(128)
Declare @newTableName varchar(128)
set @myTable = 'ALTER_NAME'
set @newTableName = 'NEUER_NAME'
select * from sysdba.SECTABLEDEFS where TABLENAME = @myTable
update sysdba.SECTABLEDEFS
set TABLENAME = @newTableName
where TABLENAME = @myTable
update sysdba.RESYNCTABLEDEFS
set TABLENAME = @newTableName
where TABLENAME = @myTable
update sysdba.JOINDATA
set FROMTABLE = @newTableName
where FROMTABLE = @myTable
update sysdba.JOINDATA
set TOTABLE = @newTableName
where TOTABLE = @myTable
Das Kingswaysoft verlangt eine bestimmte Datenstruktur um diese in MS Dynamics 365 zu bringen. Gleiches gilt für…