Ici, se trouve la conception et l'implantation d'une architecture impliquant Dynamics 365 / Dynatrace / StresStimulus. L'objectif est de démonter comment nous pourrions mesurer les enjeux de performance des servers CRM à l'aide de Dynatrace and StresStimulus.
Voici mes choses à faire en détail comme guide de migration ! Le livre blanc donne un aperçu de la manière d'orchestrer les données. J'essaye de répondre à la question suivante : "Comment orchestrer le modèle de données lié à Dynamics 365 ?".
Le processus d'orchestration est composé de plusieurs vagues ou plusieurs étapes : https://www.dataobjectexception.com/post/my-how-to-guide-to-successful-data-migration-dynamics365 .
Une migration de données se concentre sur le mouvement des données entre la source (système de données hérité et entreprise) et la destination (système cible). Ainsi, dans notre livre blanc, une migration de données se concentrera sur le mouvement des données entre Dynamics CRM/365 sur site (source) et Dynamics CRM/365 sur site ou en ligne (destination).
Cependant, les pièges sont réels et peuvent retarder la migration des données. Même avec les outils et les procédures les mieux testés, nous devons identifier ces pièges et trouver un moyen de les surmonter.
De quels pièges parle-t-on ? Le Livre Blanc décrit les écueils potentiels concernant les points suivants : contexte de données, contexte de plateforme, contexte fonctionnel, contexte de code et enfin, contexte d'architecture .
La migration des données de Dynamics CRM 2011 (sur site) vers Dynamics 365 (sur site, version 8.2) signifie migrer les données commerciales, les données système et les métadonnées CRM 2011 vers D365. Cela dit, ce processus nécessite une méthodologie adaptée à la plateforme D365 car il s'exécute dans une approche "big bang" en tenant compte du contexte technologique et des contraintes techniques qui mettent continuellement la pression sur le processus de transfert des données et des données. Métadonnées CRM.
La méthodologie se caractérise par un processus en termes de stratégie et de dynamique (étapes), ce processus étant soutenu par l'utilisation d'outils spécifiques aux technologies .NET, Dynamics 365 et MS SQL Server . Concrètement, ces outils nous ont aidés à mettre en place nos stratégies, c'est-à-dire organiser notre modèle de données, regrouper et ordonner nos entités, exclure nos entités du processus et ajuster notre code de migration.
Ce livre blanc décrit comment la migration des données de CRM 2011 vers D365 (on-premise) a été organisée, structurée et orchestrée .
Le processus de migration des données nécessite une approche méthodologique pour traiter les éventuelles erreurs générées par nos tests de validation une fois les données transférées. En effet, le processus de migration des données doit s'accompagner d'un processus de « Dépannage ». Ce dernier doit apporter la solution adéquate, précise et pertinente pour permettre au processus migratoire de se concrétiser.
Deux types d'erreurs sont possibles : une erreur de type générique et une erreur de type spécifique. De par le contenu des erreurs générées par la plateforme CRM, il est naturel de les catégoriser selon ses deux types.
Afin de mieux appréhender le contenu de ces erreurs (génériques et spécifiques), des moyens en termes d'outils sont mis à disposition ( journal de la plateforme, journal de la trace CRM, journal du serveur, suivi des requêtes SQL, décompilation du CRM services du .NET Framework ). En conséquence, l'utilisation de ces outils peut générer un processus (contenant des étapes inclusives), créant des niveaux inclusifs de "Dépannage". Une fois les erreurs saisies de manière transparente, des solutions peuvent être appliquées et ainsi mettre fin à l'erreur générée par la plateforme.
Le livre blanc décrit comment nous dépannons et résolvons les erreurs post-migration des données .
La migration des données Dynamics CRM (sur site) a échoué suite à une mise à jour vers Windows Server 2003 (correctifs de sécurité). Précisément, le processus d'actualisation des jetons de sécurité du service Google (éditeurs DFP) a échoué.
Processus de validation préliminaire : journaux du service Windows (écouteur) et des serveurs de migration de données (observateur d'événements).
Processus d'isolation des problèmes : application du service Windows en tant qu'exécutable, débogage de la bibliothèque .Net de l'API Google, environnement physique du service Windows et enfin, les utilisateurs et le contrôleur de domaine.
Processus de résolution lié à l'environnement physique du service Windows. Il a fallu développer un nouveau service (en tant qu'écouteur) afin de transférer les données Dynamics CRM vers le nouvel environnement physique (Windnows Server 2008/2012) et dans une nouvelle file d'attente. Une fois les données transférées, le service (listener) déployé dans le nouveau serveur physique pourra récupérer les données de la file d'attente et pourra migrer les données vers le Google Cloud.
Le livre blanc décrit comment nous pourrions résoudre un problème d'authentification dans un contexte de contraintes de temps .