Frage

Ich plane, einen POC für die Integration von MS CRM und BizTalk 2010 zu beginnen.

Vorher wollte ich wissen, dass ein Körper BizTalk 2010 zur Integration mit MS CRM verwendet wird?

War es hilfreich?

Lösung

Wir verwenden BizTalk 2010, um in den Organisationsdienst von Microsoft Dynamics CRM 2011 zu rufen.

Es gibt im Grunde zwei Möglichkeiten, dies zu tun, aber ich bin verpflichtet, andere zu finden.

Der erste Weg besteht darin, die BizTalk -Schemata zu verwenden, die mit dem SDK zusammen mit einem externen C# -Sbasierten -Bibliothekshelfer versehen. Dieses Szenario ist im Internet ziemlich erzählt. Beachten Sie, dass in diesem Szenario BizTalk nicht in die CRM-Frühgeborenenklassen (Konto usw.) aufgerufen werden kann. Es ermöglicht nur die Verwendung des generischen Crentity-Objekts, das den Umgang mit der Zuordnung zu einer schmerzhaften Erfahrung macht.

Der externe Helfer ist notwendig, um sich mit den Eigenheiten der Live -Oeid -Föderation zu befassen.

Diese erste Methode hat den Vorteil, einfach zu sein. Sie können jedoch keine nativen CRM -Typen von BizTalk verwenden.

Der zweite Weg besteht darin, zumindest teilweise die oben genannten Probleme zu lösen. Zunächst beinhaltet es den Bau einer WCF-Fassade, die einheimische CRM-Objekte (z. B. Konto usw.) enthüllt und die sich mit LiveID-Föderation befasst.

Wie erzeugt, sind die frühen Klassen nicht serialisierbar, sodass sie nicht Teil einer WCF-Schnittstelle (und eines Dienstes) sein können. Dies kann gelöst werden, indem alle Eigenschaften mit einem dekoriert werden DatacontractAttribute. Außerdem müssen nur schreibgeschützte Eigenschaften ein zusätzliches leeres Set {} hinzugefügt werden. Bitte beachten Sie, dass es eine große Anzahl solcher (einfacher) Änderungen in den generierten Klassen gibt. Glücklicherweise ist die Syntax als generierte Datei konsistent und ein paar einfache Regex von.

Auf der BizTalk -Seite konsumieren Sie die WCF -Fassadenmetadaten, um BizTalk -Schemas zu erzeugen. Leider erhalten Sie riesige Multi-Megabyte-Dateien und Cross-Abhängigen-Schemata.

Zuerst müssen Sie die kreisförmigen Abhängigkeiten brechen. In meinem Fall musste ich ein zusätzliches Schema hinzufügen, um gemeinsame komplexe Typen zu halten, die sowohl vom "Vertrag" als auch von der "Metadaten" Schémas verwendet wurden.

Als nächstes können Sie die riesigen erzeugten Schemas in Ihren Karten nicht leicht verwenden. Das Öffnen der Karte (oder das Schema allein) dauert das Alter. Zweitens wird der Compiler ersticken und Visual Studio wird abstürzen.

Um dies zu lösen, müssen Sie das manuell ändern GeneratedefaultFixedNodes Attribut in der .BTM XML -Datei Ihrer Karte.

Ich empfehle jedoch, eine vereinfachte Version der generierten Schemas zu verwenden, in der Sie nur Knoten und Strukturen enthalten, die Teil der Zuordnung sind. Da die meisten Knoten optional sind, wird die resultierende XML -Anforderung an die WCF -Fassade gleich sein.

Der Vorteil dieser zweiten Methode besteht darin, mit nativen CRM -Typen aus BizTalk umzugehen. Aber die Implementierung mag zunächst kompliziert klingen. In der richtigen Automatisierung funktioniert es in der Praxis ziemlich gut, selbst angesichts der Veränderungen auf der CRM -Seite.

Keine der Methoden fühlt sich jedoch als "native" BizTalk -Integration an. Deshalb arbeite ich daran, einen alternativen Weg zu finden, vielleicht indem ich eine dedizierte kundenspezifische Bindung aufbaue, aber bisher ohne Erfolg.

Sehen Meine Frage hier.

Hoffe das hilft.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top