Archiv für Juli 2013

Wie zeige ich Managed Properties in der Dokumenten-vorschau von SharePoint 2013 an?

Donnerstag, 25. Juli 2013

blog_Managed_Properties_SharePointSeit dem Erscheinen von SharePoint 2013 ist die Anpassung der Nutzeroberfläche via Code-Anpassung deutlich einfacher geworden. Dies hat damit zu tun, dass man im aktuellen Produkt schon mit Grundwissen in HTML eine ganze Menge anstellen kann und dazugehörige JavaScripts oft automatisch generiert werden. Heute zeige ich Ihnen wie Sie die Dokumentenvorschau in SharePoint 2013 / Office 365 mit ein bisschen HTML Know-How mit Metadaten von Dokumenten anreichern können.

Zunächst eine Vorschau auf das Endergebnis: damit keine Missverständnisse entstehen: alles, was Sie nun sehen und lesen ist auch in Office 365 (SharePoint Online) durchführbar und hat tatsächlich auch in Office 365 (Plan E3) so stattgefunden.

Was wir sehen, ist die Anzeige eines Suchergebnis Webpart, der eine Sicht auf bereits in der Suchdatenbank erfasste Daten in Form eines Bilderkatalogs aus einer definierten Ergebnisquelle anbietet. Die Metadaten der Bilder werden in einer separaten App (Benutzerdefinierte Liste) gehalten und wurden zuvor aus einer NAV-Datenbank importiert. Neue Daten werden 1x täglich per Auto-Job via SIMEGO Data Synchronization Studio importiert.

So kann der Nutzer bequem per Drag&Drop ein Dokument hochladen, bevor SharePoint sich über einen automatischen Designer-Workflow den passenden Datensatz auswählt und die Metadaten über ein Nachschlagefeld in die Bildbibliothek überträgt. Nachdem dies passiert ist und die Nachschlagespalten der Bildbibliothek mit Daten befüllt wurden, erstellt SharePoint nach ein paar Minuten automatisch für jede Spalte eine “crawled property” (durchforstete Eigenschaft). Zu finden im Suchschema der Websiteeinstellungen. Diese wiederum können wir mit einer bereits vorhandenen Managed Property (RefinableString01, etc.) verknüpfen, da diese passend zum Anwendungsfall abgefragt, abgerufen, eingeschränkt und sortiert werden können. Beim Erstellen einer solchen Infrastruktur empfiehlt es sich, involvierte Listen und Bibliotheken abschließend neu zu indizieren (Listen/Bibliothekseinstellungen). Da wir anders als beim SharePoint Server leider keinen Crawl manuell auslösen können, muss man teilweise etwas Geduld (teilweise mehrere Stunden) mitbringen. Einmal im Index erfasst, werden Daten jedoch korrekt übergeben.

Über den Einsatz des Refinement Panel Webparts (Einschränkungen) kann das Suchergebnis des Bilderkatalogs nun anhand ausgewählter Kriterien gefiltert werden. Dort können die nun verknüpften Managed Properties in den Webparteigenschaften einfach als Einschränkungskriterium hinzugefügt werden.

Nun aber gehen wir über zum eigentlichen Thema: dem Anbinden der besagten Properties an die Elementanzeigevorlage und anschließend an die Dokumentenvorschau. Dieser Zwischenschritt ist erforderlich, da die Dokumentenvorschau die Managed Properties als Parameter von der Elementanzeigevorlage übergeben bekommt. Zwar müssen diese in der Elementanzeigevorlage deswegen nicht zwangsläufig angezeigt werden, jedoch muss der Parameter zur Übergabe im Code enthalten sein. Zunächst benötigen wir zur Umsetzung den SharePoint Designer (2013) und ein wenig HTML Know-How.

Wir navigieren mit dem Designer in das Verzeichnis “_catalogs/masterpage/Display Templates/Search”. Hier finden wir nun die vorgefertigten Display Templates in Form von html-files und js-files vor. Sollten die html-files nicht sichtbar sein, aktivieren Sie auf der Sitecollection-Ebene das Feature “Veröffentlichungsinfrastruktur”. Nach ca. 3 Minuten wurden alle html-files generiert. Diese Display Templates bestehen aus zwei Komponenten (html und js). Dabei wird das js automatisch generiert und braucht daher nicht angepasst zu werden. Zunächst exportieren wir eine Kopie des html-file der gewünschten Vorlage und passen diese folgendermaßen an, bevor der Upload in SharePoint auf demselben Weg erfolgt. Gleiches gilt für die Anpassung der zugehörigen HoverPanel.html (Beide Codes sind im Screenshot geöffnet).

Als erstes tragen wir in beiden(!!) html-Codes die Managed Properties mit Ihrem initialen Namen ein und beachten dabei die hier vorgegebene Syntax. Wie das vorangestellte Tag <mso:ManagedPropertyMapping> verrät, geht es hier nicht um das Anzeigen von Daten, sondern lediglich um deren Übergabe.

Zu der Anzeige der Daten kommen wir jetzt. Für eine saubere Darstellung empfiehlt sich der Einsatz einer Tabelle, die wir im Body der HoverPanel.html erstellen und innerhalb der Zellen wiederum die Property anzeigen.

Wichtig: damit die Daten korrekt übergeben werden, müssen wir einmal auf den Link des HoverPanel.js verweisen!

Anschließend können wir alle Codes einchecken (sofern noch nicht geschehen) und nun die Früchte ernten. Wählen Sie in der Webpartkonfiguration des Suchergebniswebparts die soeben erstellte und angepasste Anzeigevorlage aus und wir sind fertig! Das Beste ist, dass wir diese Anzeigevorlage in einem ggf. später erstellten Suchcenter erneut zuweisen und verwenden können. :)

Als Fazit lohnt es sich wirklich zu feiern, wie viel leichter es im Vergleich zu SharePoint 2007 oder SharePoint 2010 geworden ist, an Daten aus dem Backend heranzukommen, diese im Frontend anzuzeigen oder sogar zum Filtern zu verwenden. Das Erstellen einer komplexen Webanwendung mit SharePoint 2013 macht wirklich großen Spaß!

Autor: Karsten Ulferts

Die schwarze Magie mit XML Mapping in Word 2013 als BusinessObject-Export

Donnerstag, 25. Juli 2013

bildteaser_blog_072013Kennen Sie das Problem bei allen üblichen Reporting Suites, dass exportierte Word-Dokumente schlecht bis garnicht bearbeitbar sind? Der Aufbau des Dokumentenlayouts wird mit Tabellen oder gar Frames zusammengehalten und der Benutzer hat seine Mühe, mal eben ein paar Zeilen einzufügen. Doch was ist, wenn der Kunde einen vollständigen Export benötigt, dessen Resultat (also das Word-Dokument) auch gut, wenn nicht sogar sehr gut, bearbeitbar ist? Was ist, wenn die Vorlage dafür auch noch vom Kunden änderbar sein soll? “Back to the roots” ist die Lösung, denn Microsoft bietet hierfür eine einfache, mächtige und kaum bekannte Möglichkeit: XML Mapping

Was ist XML Mapping?

Schwarze Magie! Doch schweifen wir für einen Moment ab. Der Weg zu diesem Lösungsansatz führte über den Gedanken der Word-Vorlagen und Serienbriefe. Es musste doch irgendwie möglich sein, einem Word-Dokument beizubringen, dass es Felder automatisch ausfüllt und die dafür nötigen Daten aus irgendeiner Datenquelle zieht. Grundsätzlich ist dies auch völlig problemlos möglich, wenn man ein paar einfache Daten anbinden will.

Doch in der Realität braucht man eben immer etwas mehr, als das schöne bunte Beispielprojekt einem zeigt. So auch hier, denn es musste auch möglich sein, anhand der Daten einzelne Tabellen oder Tabellenzeilen zu wiederholen. Der Ansatz des Serienbriefs zerschellte also in tausende kleine Teile. Auch die Word-Vorlagen führten nicht zum Ziel. Irgendwie muss das doch aber funktionieren? Vielleicht fügt man dem Dokument einfach ein wenig VBA hinzu? Klar, das würde auch funktionieren, aber wer möchte schon freiwillig die Ausführung von VBA in einem Word-Dokument aktivieren, welches man von einem Internetportal heruntergeladen hat? Und selbst wenn, will man sowas denn veröffentlichen? Eher nicht.

Fast schon aufgegeben, fand sich dann jedoch ein Menüpunkt “XML-Zuordnungsbereich” im Entwicklertools-Menü, welcher vielversprechend klingt und förmlich darauf wartete, dass man ihn klickt.

XML-Zuordnungsbereich

Wie genau funktioniert XML Mapping nun?

XML-Zuordnung
Mit einem Klick auf den genannten Knopf öffnet sich ein Menü “XML-Zuordnung” am rechten Bildschirmrand. In diesem sieht man eine Dropdown-Liste mit allen verfügbaren XMLs, welche im Dokument eingebettet sind, und deren inhaltliche Struktur. Standardmäßig sieht man daher erst einmal die üblichen Dokumenteigenschaften mit den Daten für Autor, Titel, Beschreibung, usw.

Es scheint also, als könne man eine XML-Struktur inkl. Daten in ein Word-Dokument einbetten. Da man .docx-Dateien problemlos mit dem OpenXML SDK bearbeiten kann, war dies also schonmal der erste Lichtblick. Sollte es tatsächlich möglich sein, dass man mit nur wenigen Zeilen C# ein ganzes serialisiertes BusinessObject in Word einbetten kann, welches wiederum im Word-Dokument vorgefertigte Felder ausfüllt? Ja, genau das sollte es.

Doch erst einmal müssen wir eine Vorlage erstellen. Dazu legen wir uns eine XML-Datei mit der gleichen Struktur wie unser zukünftiges serialisiertes BusinessObject an, jedoch erst einmal ohne Daten. Warum? Nun, es ist eben eine Vorlage. Das vorbereitete XML soll ja ersetzt werden. Ein Klick in die Dropdown-Liste zeigt uns einen Menüpunkt, mit welchem wir unsere XML-Struktur dem Word-Dokument bekannt machen können.

XML-Zuordnung - Neue Komponente
In meinem Beispiel verwende ich dazu dieses XML als Vorlage.

Ist das erledigt, haben wir unsere XML-Struktur zur Verfügung und können unsere Felder hinzufügen. Dabei kann man sogar zwischen unterschiedlichen Typen wählen und somit sogar eine Datumsauswahl direkt im Word-Dokument anbinden, was die Bearbeitbarkeit deutlich erhöht. Dazu Klicken wir einfach mit der rechten Maustaste auf das gewünschte XML-Element und es öffnet sich folgendes Menü.
Kleiner Tipp: Bei leeren XML-Feldern wird einem automatisch der Standardtext angezeigt. Diesen kann man ändern, wodurch auch bei leeren Feldern ein beliebiger Text als Fallback stehen kann.

XML-Zuordnung - Steuerelement

Und was ist mit Wiederholungen?

Da sind wir auch schon beim Kern. Bis hier hin ist ja alles schön und gut, wäre aber auch mit einer einfachen Serienbrief-Datenbindung möglich gewesen. Doch wir wollen ja Wiederholungen in Wiederholungen in Wiederholungen in […]. Dazu klickt man einfach mit der rechten Maustaste auf das XML-Element, welches sich wiederholt, und verwendet den erscheinenden Menüpunkt. Der Einfachheit halber kann man sich auch eine paar Absätze, Tabellen und Texte vorbereiten, markieren und mit diesem Menüpunkt eine Wiederholung daraus erzeugen. Diese Wiederholungen lassen sich sogar noch sinnvoll benennen, wodurch der Nutzer nützliche Menüpunkt erhält.

XML-Zuordnung - Wiederholung

Verarbeitung und Beispiel

Nun muss das Dokument nur noch nach den eigenen Vorstellungen gefüllt werden. Das war’s dann auch schon.
Die damit erstellte Vorlage, welche lediglich ein simples Word-Dokument (docx) mit einer vorbereiteten und eingebetteten XML-Struktur ist, muss nun nur noch mit dem OpenXML SDK bearbeitet werden. Es muss also das Dummy-XML, welches wir im obigen Schritt hinzugefügt haben, ersetzt werden. Entgegen der unten verlinkten Quelle, muss diese Ersetzung natürlich nicht mit VBA-Code innerhalb des Dokuments geschehen. In meinem gleich folgenden Beispiel habe ich dafür dieses XML mit Daten verwendet.

Den Rest erledigt Word beim Öffnen des Dokuments von selbst. Es füllt die Felder und erzeugt die einzelnen ausgefüllten Wiederholungen, wie man im Beispiel-Dokument wunderbar sehen kann. Hierfür habe ich natürlich wieder ein Beispiel vorbereitet, welches nur einen Klick entfernt ist.
Kleiner Tipp: Im Bearbeitungsmodus erkennt man die Magie des Ganzen erst richtig.

Fazit

Es ist also sehr einfach möglich, dem guten Microsoft Word beizubringen, wie es ein Dokument mit Daten zu füllen hat. Das enthaltene XML (bzw. das serialisierte BusinessObject) ist natürlich schnell und einfach mit C# und dem OpenXML SDK in das Dokument eingefügt. Ein komplettes Aufbauen des Dokuments mit dem OpenXML SDK oder aufwändigem Code bleibt einem erspart. Dadurch, dass das Dokument in Word selbst erstellt wird, ist es am Ende für den Nutzer genauso einfach zu bearbeiten, wie die Vorlage selbst. Aufgrund der Nützlichkeit der Wiederholungen ist es zudem noch einfacher für den Benutzer.
Und das Beste an dieser Methode ist, dass die geänderten Daten (inkl. der Wiederholungen) in die XML-Struktur zurück geschrieben werden, wenn der Nutzer auch die entsprechenden Felder verwendet. Dadurch wäre sogar ein Re-Import der Daten denkbar. Wenn das mal nicht nach schwarzer Magie klingt!

Quellen/Links: OpenXML SDK, XML Mapping, CustomXML mit dem OpenXML SDK
Autor: Dirk Sarodnick
Google+

ProTechnology Webseite nun auf ASP.Net. Von Redirect, Routing-Regeln und Sonderzeichen …

Donnerstag, 18. Juli 2013

bildteaser_blog_072013Im Juli war es soweit: Unsere neue Webseite ist online gegangen. Ein Besuch lohnt sich, denn der neue dynamische Webseitenaufbau sowie der hinzugekommene News-Bereich verraten stets Aktuelles zu Ihren Wunschthemen. Doch nun zum heutigen Beitrag aus der Kategorie „Der Verzweiflung nahe“ oder „wenn Routing-Regeln trotz offensichtlicher Korrektheit willkürlich nicht funktionieren“. So geschehen im Zusammenhang mit der Einrichtung unserer neuen Unternehmenswebsite. Aber, wie so häufig, lag der Fehler auch hier im Detail …

Anders als unser vorhergehender Internetauftritt basiert unsere neue Seite nun – wie es sich für ein Microsoft-Systemhaus gehört – auch auf Microsoft-Technologien. So setzen wir nicht mehr PHP sondern ASP.Net unter Verwendung von DotNetNuke als Content Management System ein.

 

routing-website_alt_neu

Aus Alt mach Neu

Da sich natürlich strukturell einiges getan hat sind die neuen Inhalte nun auch über neue URLs zu erreichen. Für Benutzer, die uns über die Startseite besuchen, ist das kein Problem. Allerdings sollten auch diejenigen, die sich zum Beispiel Lesezeichen gesetzt haben, nicht auf einer unschönen 404-Fehlerseite landen – und gleiches gilt freilich auch für Suchmaschinentreffer.

 

routing-bing_urls

Von Bing indexierte Seiten

Deswegen holt man sich in so einem Fall zum Beispiel über die „Webmaster Tools“ der namhaften Suchanbieter eine Liste aller indexierten Seiten ab und stellt über entsprechende Weiterleitungsregeln sicher, dass Aufrufe der alten URLs an einer sinnvollen neuen Stelle herauskommen. Diese Weiterleitungen versieht man mit dem HTTP-Code 301, der angibt, dass es sich um eine dauerhafte und nicht nur temporäre Situation handelt. Soweit also zur Theorie, im Regelfall ist das auch tatsächlich kein kompliziertes Vorhaben.routing-excel

Links die alte, rechts die inhaltlich am besten passende neue URL

In einer ASP.Net Anwendung gibt es nun verschiedene Möglichkeiten, das zu bewerkstelligen. Wir haben uns dafür entschieden, die Regeln über die „web.config“-Datei zu verwalten. Praktisch sieht das also folgendermaßen aus:

routing-web_config

Weiterleitungsregeln in der web.config

Eingestellt sind Weiterleitungen, die alle Aufrufe von ehemaligen Dateien zum Download abfangen und in unseren neuen Downloadbereich umleiten sowie separate Weiterleitungen für Aufrufe von konkreten alten Seiten. Soweit so gut, flugs die Konfigurationsdatei aktualisiert und getestet. Klappt, alles prima. Noch eine Stichprobe, auch alles gut. Aller guten Dinge sind drei, also noch ein letzter Versuch und … 404, Seite nicht gefunden. Zunächst mal kratzen wir uns also am Kopf und schauen nochmal in die Datei hinein. Stimmt die URL? Irgendwo ein Tippfehler? Kann eigentlich nicht sein, war ja alles Copy & Paste. Augenscheinlich ist also alles gut, dennoch funktionieren aber einige Regeln, scheinbar willkürlich, einfach nicht.

Einige Versuche mit geleerten Caches, anderem Browser und ausgewerteten IIS Logs später ist die Situation noch immer ungeklärt. So etwas Seltsames kommt einem selten unter und langsam gehen dann auch die Ideen aus …

Kurz davor stehend, kurzerhand eine andere technische Variante der Weiterleitung zu verwenden, gab es aber dann doch noch ein winziges Detail, welches zufällig ins Auge fiel. Bei Aufruf einer der funktionierenden Weiterleitungen war kurz nach Absenden der Anfrage für den Bruchteil einer Sekunde eine an die URL angehangene Zeichenfolge zu sehen, welche da eigentlich nicht hingehört. Den Moment abgepasst und per Screenshot festgehalten sah besagte URL folgendermaßen aus:

routing-url

URL mit codierten Sonderzeichen

Also die codierten Zeichen schnell in einer ASCII-Tabelle nachgeschlagen und siehe da – offenbar werden drei Sonderzeichen an die URL angehängt. Die Frage ist nur, wo kommen die her? Und genau an dieser Stelle kam der rettende Geistesblitz …

routing-notepad1

routing-notepad2

Anzeige von unsichtbaren Zeichen und geändertes Encoding

Schauen wir uns die besagte „web.config“ in einem passenden Editor wie Notepad++ noch einmal genauer an, kann man über verschiedene Optionen sowohl unsichtbare Zeichen sichtbar machen, als auch die Kodierung der Datei ändern. Ursprünglich auf UTF-8 eingestellt, waren die drei Zeichen also in der Weiterleitungsregel zwar vorhanden, wurden aber nicht angezeigt. Damit wird diese natürlich auch nicht verarbeitet, solange die Sonderzeichen am Ende nicht mit in die URL eingegeben werden. Da die URL aber in diesem Fall durch Copy & Paste aus der Konfigurationsdatei in den Browser eingefügt wurde, waren auch die Zeichen mitgekommen.

Nach Überprüfung aller Regeln und entsprechenden Korrekturen funktionierte dann alles tadellos und wie erwartet. Prima! Bleibt jetzt nur noch die Frage, wie sie da hineingeraten sind. Doch auch dies ließ sich schnell klären: die einzelnen URLs wurden nämlich aus dem oben abgebildeten Excel-Dokument ebenfalls per Copy & Paste übernommen – samt unsichtbarer Sonderzeichen, die je nachdem ob von vorn oder hinten mit dem Markieren begonnen wurde entweder dabei waren oder nicht.

Autor: Tom Halank

Dynamics CRM-Daten in der Cloud – kein Wagnis, sondern Mehrwert. Wir migrieren.

Donnerstag, 11. Juli 2013

blog_kundendaten_crmMit den Kundendaten in die Cloud ist für viele ein Graus. Besonders im Bereich der Kundenmanagement-Lösungen ist der Schutz von Daten ein sensibles Thema. Das Unternehmen muss dafür sorgen, dass die Kunden sich auf einen sicheren Umgang mit ihren Daten verlassen können, um ihr Vertrauen nicht zu verlieren. Oft kommt man da um eine getrennte Datenhaltung nicht herum.

Gerade in Deutschland müssen oft sehr strenge Datenschutzrichtlinien eingehalten werden, wenn es um Kundendaten geht. Microsoft hat hier vorgesorgt und mehrere Zertifizierungen für Dynamics CRM Online erzielt. Doch welche sind das?

Im Microsoft-Jargon heißt das übersetzt: Microsoft Dynamics CRM Online-Vertrauensprinzipien. Hier eine kurze Zusammenfassung mit verlinkten weiterführenden Informationen.

1. Der Schutz Ihrer Daten
Bei Microsoft Dynamics CRM Online können Sie Ihre Kundendaten immer strikt von den Daten anderer Kunden getrennt aufbewahren. Sie erhalten eine eigene Datenbank, damit ein Höchstmaß an Sicherheit und Integrität Ihrer Daten gewährleistet ist. Mehr dazu hier.

2. Transparenz
Microsoft bietet klare Informationen darüber, wer auf Ihre Microsoft Dynamics CRM Online-Kundendaten zugreifen kann. Sie arbeiten hier mit Sicherheitsrollen und wenn gewünscht kann auch Ihr Active Directory an das System angebunden werden.

3. ISO zertifiziert
Microsoft Dynamics CRM Online ist ISO-zertifiziert nach 27001. Diese Zertifizierung auf der Basis von IT-Grundschutz gehört zu den besten Sicherheitsstandards weltweit. Mehr dazu hier. Zudem erfüllt Dynamics CRM Online die EU-Standardvertragsklauseln, HIPAA-Business Associate Agreement, Vereinbarung zur Auftragsdatenverarbeitung. Mehr erfahren Sie hier.

4. Sicherheit ohne Kompromisse
Microsoft sorgt dafür, dass Sicherheit und Datenschutz sowohl in der Softwareentwicklung als auch beim Life-Betrieb von Anfang an berücksichtigt werden. Die Kundendaten sind auf fünf verschiedenen Levels geschützt: auf Daten-, Anwendungs-, Host-, Netzwerk- und physischer Ebene. Mehr dazu in folgendem Dokument. Hinzu kommt, dass Microsoft regelmäßig Backups durchführt. In Fällen eines kritischen Benutzerfehlers können Sie außerdem auf Anfrage über Nacht ein Backup einspielen lassen.

Alles ist vertraglich geregelt und vor allem Microsoft garantiert Ihnen mit der Cloud mehr Sicherheit und Verfügbarkeit, als es manch anderer Hoster liefern kann, nämlich 99,9 %. Und ein wesentlicher Vorteil der Mietlösung ist, dass deutlich Stom-, Installations- und Wartungskosten gespart werden können.

ProTechnology erkannte den Mehrwert und geht mit seinen Kundendaten in die Wolke.

Nachdem es ProTechnology’s Bestreben ist mit den meisten Systemen in die Microsoft-Cloud zugehen war nach Lync, TFS und SCCM unser CRM-System der nächste Kandidat. Wir mussten hier von OnPremise Dynamics CRM 2011 auf Dynamics CRM Online migrieren. Welche Schritte galt es hier zu überwinden? Ein Whitepaper seitens Microsoft gibt es dazu leider nicht. Somit mussten wir uns selbst eine Strategie überlegen.

Migration Step 1: Zunächst wollten wir die Oberfläche, Anpassungen und Eigenentwicklungen, wie Plugins, aus der Servervariante in die Online-Version übernehmen.

Für diesen Schritt steht uns Standardfunktionalität zur Verfügung. Alle meine Anpassungen sind in einer Lösung vorhanden. Nun muss ich diese nur exportieren und im neuen System importieren. Im Anschluss habe ich Formularänderungen, Namensanpassungen, Workflows und Dialoge im CRM-System enthalten. Es empfiehlt sich jedoch die Workflows nochmal zu testen. Wir hatten das Problem, dass keiner der Workflows/Dialoge funktionierte. Doch in diesem Fall galt die Devise “Reboot tut gut”. Einmal deaktivieren und wieder aktivieren und schon waren automatische und bedarfsgesteuerte Workflows funktionstüchtig.

Letztlich hatten wir noch zwei Plugins im Einsatz, die für die Online-Version registriert werden mussten. Unser SharePoint-Dynamics CRM-Plugin, welches u.a. automatisch eine SharePoint-Kundenbibliothek anlegt und im CRM die Sicht auf die entsprechende SharePoint-Seite gewährt, musste noch ein wenig angepasst werden, da es nun mit der CRM Online-Version kommunizieren soll. Gesagt, getan und schon lief auch diese Verbindung wieder reibungslos.

Dynamics CRM - Lösung exportieren_importieren

1. Lösungen in Dynamics CRM exportieren und wieder importieren

Migration Step 2: Nun ist die Oberfläche und die Funktionalität dieselbe wie zuvor. Doch die Daten fehlen noch.

Der standardmäßig vorhandene Importwizard eignet sich eher weniger für den gesamten Datenimport, weil man nur geringfügig einen entitätsübergreifenden Massenimport starten kann. Denn als Admin kann  man zwar verschiedene Importdateien in eine .zip packen und importieren. Jedoch darf eine Importdatei höchstens 8MB groß sein und die .zip-Datei darf 32MB nicht überschreiten. Legt man jedoch seine Email-Kommunikation im CRM per Outlook-Integration ab, so spricht man hier von viel größeren Datenmengen. Somit müsste diese .XML gesplittet werden, damit sie dem Maximalvolumen entsprechen. In Summe gibt es im Dynamics CRM 95 Entitäten. Muss man diese alle einzeln bearbeiten, splitten und in .zips verpacken, ist der Aufwand für den Import immens.

In einem anderen Blog-Beitrag haben wir schon mal über die Importfunktionalität gerade bei Emails berichtet: “Mit ein wenig Code und unter Verwendung der EWS Managed API können die E-Mails an das CRM-System übermittelt werden. Ein entsprechendes Codebeispiel in C# kann hier heruntergeladen werden.” Dieser Auszug verdeutlicht, dass mit Programmierkenntnissen Daten importiert werden können.

Doch zurück zu unserem Fall: Wir haben unsere Daten mit einem Drittanbietertool namens SIMEGO schnell migriert. Dieses Data Sychronization Studio ist eine vielfältig einsetzbare Lösung. Mit ihr können nicht nur SQL-Datenbanken miteinander verknüpft werden, sondern es unterstützt auch viele andere Datenbanken/-Formate. Für den Import brauchten wir nicht mal Programmierkenntnisse, sondern lediglich eine Lizenz von SIMEGO. Mehr zur Funktionalität von SIMEGO in diesem Blog-Beitrag. Hier finden Sie auch ein Video, wo Sie das Tool live im Einsatz sehen.

SIMEGO

2. SIMEGO als Import-Assistent.

Autor: Melanie Wolf