Dynamics CRM 2011 mise à Jour en bloc
Running Dynamics CRM 2011 de déploiement 3. Besoin de mettre à jour des millions de clients enregistre régulièrement (delta mises à jour). En utilisant le standard de mise à jour (un par un) prend quelques semaines. Aussi nous ne voulons pas toucher à la DB directement, comme elle peut casser des trucs dans le futur.
Est-il une mise à jour en bloc à la méthode d'Dynamics CRM 2011 webservice/API REST, nous pouvons utiliser? (WhatWhereHow)
exemple clair en Vrac créer ou mettre à jour sur MS CRM donné en lien ci-dessous mscrmtutorials.blogspot.dans/2014/07/...
qu'avez-vous de faire? nous utilisons kingswaysoft
qu'avez-vous de faire? nous utilisons kingswaysoft
OriginalL'auteur Tedd Hansen | 2011-12-16
Vous devez vous connecter pour publier un commentaire.
Je me rends compte de ce post est de plus de 2 ans, mais je peux ajouter, en cas de quelqu'un d'autre le lit, et a un besoin similaire.
Peter Majeed la réponse est sur la cible en ce que les processus CRM les demandes d'un enregistrement à la fois. Il n'y a pas de modification en bloc qui fonctionne de la façon dont vous êtes à la recherche pour. Je vous encourage à ne pas toucher la DB directement si vous avez besoin de support technique Microsoft.
Si vous êtes à la recherche à des mises à jour périodiques de millions d'enregistrements, vous avez quelques options. Envisager l'utilisation de Scribe ou de développer votre propre utilitaire d'importation ou d'un script à l'aide de la CRM SDK.
Scribe est probablement va être votre meilleure option, car elle est rentable pour l'importation des données, et de vous permettre de mettre à jour facilement et insérer à partir du même fichier.
Si vous écrivez votre propre .Net/SDK utilitaire, je suggère de faire il multithread et par programme briser votre fichier d'entrée dans la mémoire ou sur le disque et chaque thread de travail avec son propre sous-ensemble de données qui est, bien sûr, si l'ordre d'exécution n'a pas à être chronologique en fonction du contenu du fichier d'entrée. Si vous pouvez diviser et conquérir le fichier d'entrée sur plusieurs threads, vous pouvez réduire le temps d'exécution global considérablement.
Aussi, si votre politique d'entreprise vous permet d'avoir accès à l'un des Serveurs CRM et vous pouvez passer votre code directement sur le serveur et de l'exécuter à partir de là, vous pouvez éliminer la latence du réseau entre un poste de travail exécutant le code et le CRM web services.
Dernière mais pas moins, si ce gros volume d'importation de données provenant d'un autre système, vous pouvez écrire un CRM plug-in pour s'exécuter sur les Récupérer et RetrieveMultiple messages (événements) dans CRM pour votre entité spécifique, par programmation de récupérer les données souhaitées à partir de l'autre système (et si l'autre système est indisponible - il suffit d'utiliser la copie mise en cache dans le CRM), et de garder CRM à jour en temps réel ou sur "last-mis en cache sur' la base. Ce n'est certainement plus l'effort de codage, mais potentiellement élimine le besoin d'un grand travail de synchronisation à exécuter toutes les quelques semaines.
OriginalL'auteur iFirefly
Oui et non, surtout pas. Quelqu'un peut me corriger si je me trompe, auquel cas je serai heureux d'éditer/supprimer ma réponse, mais tout ce qui est fait dans Dynamics CRM est fait que d'un seul à la fois. Il n'a même pas essayer de traiter basés sur les insertions, mises à jour et des suppressions. Donc, sauf si vous allez tout droit direct DB opérations, il vous faudra des semaines.
La webservice est laisser "en vrac" et les insertions/suppressions/mises à jour, mais j'ai mis "en vrac" entre guillemets car il n'est de définir un processus asynchrone où il n'toutes les données pertinentes des opérations - yep - un à la fois. Il y a une section du SDK qui traite de ce type de gestion des données (linked). Et pour mettre à jour les enregistrements de cette façon, vous devez d'abord souffrir de la surcharge de sélectionner toutes les données que vous souhaitez mettre à jour, puis de créer un fichier xml qui contient les données, et enfin la mise à jour de données (rappelez-vous: une ligne à la fois). Donc, il serait plus efficace de simplement parcourir vos données et émettre un
Update
demande pour chacun de vous.(Je note que notre organisation n'a pas expérimenté toute mémorable questions concernant directement DB access pour gérer ce que le SDK n'est pas le cas, je n'ai rien vu dans mon internet personnel de lectures qui suggèrent d'autres ont.)
Edit:
Voir iFirefly de réponse ci-dessous pour une autre excellente manière de résoudre ce problème.
OriginalL'auteur Peter Majeed
Je réalise que c'est une vieille question, mais elle vient en haut sur "CRM mise à Jour en bloc" de sorte que le Mise à jour de correctif Cumulatif 12 fonction ExecuteMultiple doit être mentionné ici, sa ne va pas travailler autour de votre problème (volume important) parce que iFirefly et Peter souligner CRM fait tout un à la fois. C'est empaqueter toutes vos demandes dans une seule enveloppe laisser CRM gérer l'exécution de chaque mise à jour et réduire le nombre d'allers-retours entre votre application et le serveur si vous finissez par l'émission d'un
Update
demande pour chaque enregistrement.OriginalL'auteur BenPatterson1
C'est tout à fait une vieille question, mais personne n'a mentionné le jeun façon (mais aussi la plus difficile) de mise à jour/création d'énormes quantités de documents dans CRM 201X - en utilisant la fonction d'importation, ce qui est totalement faisable à l'aide de CRM SDK. Il est un parfait MSDN article à ce sujet:
https://msdn.microsoft.com/en-us/library/gg328321(v=crm.5).aspx. En bref, vous devez:
1) Créer un fichier Excel contenant les données que vous souhaitez importer (il suffit d'exporter les données de CRM 201X et de vérifier comment la structure ressemble, n'oubliez pas que les 3 premières colonnes sont masquées)
2) créer une Carte d'Importation entité (spécifier le fichier que vous avez créé)
3) Créer des mappages de colonnes si nécessaire
4) Créer à l'Importation et ImportFile entité, fournir la bonne mappages
5) Analyser des données à l'aide de ParseImportRequest
6) Transformer les données en utilisant TransformImportRequest
7) Importer des données à l'aide de ImportRecordsImportRequest
Ce ont été les étapes pour CRM 2011, maintenant, en 2017, nous avons plus de versions disponibles et il y a de légères différences entre eux. Vérifiez l'échantillon qui est disponible sur MSDN et dans le SDK:
https://msdn.microsoft.com/en-us/library/hh547396(v=crm.5).aspx
Bien sûr, point 1, sera la partie la plus difficile, parce que vous avez à construire XML ou un fichier docx parfaitement correspondant à ce que le CRM s'attend, mais je suis en supposant que vous le faites à partir de app externe, de sorte que vous pouvez utiliser quelques grands .NET bibliothèques qui rendra les choses beaucoup plus simple.
Je n'ai jamais rien vu de plus rapide que la norme de CRM à l'importation quand il s'agit de la mise à jour/création d'enregistrements, même si vous allez pour le parallélisme et des Lots de demandes de mise à Jour.
Si quelque chose va mal avec le MSDN sites, je poste ici un exemple à partir du lien ci-dessus qui montre comment importer des données de CRM par programmation:
OriginalL'auteur Pawel Gradecki
Pas sûr de savoir comment ce serait aller avec des millions de documents, mais vous pouvez sélectionner vos dossiers, puis cliquez sur le bouton Modifier dans le ruban. Cela fera apparaître le "Modifier Plusieurs Enregistrements" boîte de dialogue. Toute modification sera appliquée à tous vos dossiers.
OriginalL'auteur Glen Richards
La BulkUpdate API fonctionne bien pour moi, c'est 10 fois plus rapide que la mise à jour des enregistrements un à un. Voici un extrait de code qui effectue la mise à jour globale:
OriginalL'auteur Danny Tsai
J'ai travaillé sur un très gros projet de migration de données pour Dynamics CRM 2011. Nous avons besoin de charger environ 3 millions d'enregistrements sur un week-end. J'ai fini la construction d'une application console (un seul thread) et a couru plusieurs instances sur plusieurs machines. Chaque application console avait un id (1, 2, etc.) et a été responsable du chargement des segments de la base de données sur un unique clause SQL where qui correspondent à la demande de l'id.
Vous pourriez faire la même chose avec les mises à jour. Chaque instance peut interroger un sous-ensemble d'enregistrements à mettre à jour et peuvent effectuer les mises à jour via le SDK. Depuis que nous avons chargé des millions d'enregistrements sur un week-end, je pense que vous avez pu effectuer millions de mises à jour (si relativement petites) en seulement quelques heures.
OriginalL'auteur Tim Dutcher
Microsoft PFE équipe pour dynamics CRM a écrit
nouveau Autre CRM SDK library qui font usage de la parallélisation
pour en vrac exécuter les demandes d'assurer la sécurité des threads.
Vous pouvez essayer : Parallèle Exécuter les Demandes de
Je serais intéressé de savoir si il fonctionne et évolue en fonction de plusieurs millions d'enregistrements.
OriginalL'auteur hdoghmen
CRM ne pas mettre en place un moyen de mettre à jour des données en vrac; il y a 3 façons d'améliorer la majeure partie opération de mise à jour de la performance, mais en interne, ils ne peuvent pas changer le fait que le CRM mises à jour de l'enregistrement d'un par un.
Fondamentalement, les idées sont:
3 façons d'améliorer en vrac performances de fonctionnement:
OriginalL'auteur C Y
Un de mes clients a eu exactement le même problème. Il a résolu par la création d'une coutume ETL et de faire le parallélisme attaquant à deux front-end. Le tout a été fait en C#. Aujourd'hui, il pourrait être possible avec KingswaySoft ou Scribe.
OriginalL'auteur Nick