Daniel Esser

Microsoft Dynamics CRM Online ist ein weitere Produkt aus dem Hause Microsoft welches als Software-as-a-Service in der Cloud angeboten wird. Dies bietet viele Vorteile für Unternehmen; zum einen wird die Anwendung von Microsoft betreut und gewartet, es gibt verlässliche Service Level Agreements, es muss kein On-Premise Server betrieben und gewartet werden, die Notwendigkeit für einen IT-Support wird auf das Minimum reduziert.

Auf der anderen Seite stellt die Cloud auch neue Herausforderungen an die Interoperabilität mit bestehenden Anwendungen die ggf. bereits in der Azure Cloud einer anderen Cloud (z.B. Amazon) oder auch On-Premise laufen. Kernfrage in diesem Zusammenhang ist wie kann sichergestellt werden, dass die Zugriff auf die CRM-Daten aus allen Anwendungen heraus sichergestellt werden kann. Folgende Szenarien beschäftigen unsere Kunden aktuell:

  • Zugriff auf die CRM-Daten in der Cloud aus Office 365 heraus; spezielle aus Excel und Outlook
  • Automatisierter Zugriff auf die CRM-Daten z.B. über ein ETL-Werkzeug (im speziellen SSIS im Microsoft SQL Sever Umfeld)

Nun wäre die erste nahelegende Idee sicherlich; Windows Authentifizierung und fertig. So einfach ist es aber nicht, allerdings aus guten Gründen. Microsoft hat die Azure Cloud absichtlich nicht auf proprietäre Standards fußen lassen, da dies dem Prinzip der Elastizität und Interoperabilität widersprechen würde.  Die Azure Cloud ist offen für alle Software-Produkte; dies schließt Linux und Unix Betriebssysteme ein. Auch ein SAP-System oder ein Apache Hadoop Cluster kann in Azure gehostet werden.

Mircosoft setzt in Sachen Authenzifizierung auf das OAuth 2.0 Protokoll als offenen Standard. Dies bringt natürlich die eine oder andere Herausforderung beim Aufbau hybrider Lösungen mit sich.

SSIS in Azure als Applikation registrieren

Bevor mit einer Applikation oder einem Web Service auf das CRM zugegriffen werden kann muss im Azure Active Directory eine „Application“ registriert werden und dieser „Applikation“ die benötigten Berechtigungen zugewiesen werden.

01

Wechsel auf den Reiter „Application“

 

03

„Add“ um eine Applikation hinzuzufügen.

 

05

Eigene Applikation registrieren.

06

Da wir keine Web Application einrichten möchten wählen wir Native Application aus.

07

Die Redirect URI ist nicht sehr relevant bei der Registrierung einer Native Application. Für die Authentifizierung ist die URI allerdings relevant.

08

Auf der Übersichtsseite ist die Client-Id der Applikation ersichtlich. Diese wird später für die Authentifizierung benötigt.

03

Mit „View Endpoints“ können die Endpoints für die OAuth Authentifizierung eingesehen werden.

04

Alle Endpoints für die OAuth 2.0 Authentifizierung.

  • OAuth 2.0 Authorization Endpoint: https://login.microsoftonline.com/cc5d3ad0-1cc1-4e3c-b909-aff8eb96fb69/oauth2/authorize?api-version=1.0
  • Client Id der Application: c5f5bfc0-5eb2-4e27-b428-ac190808f799
  • Redirect URI: https://www.myredirecturi.com

Beispiel Code um sich gegenüber CRM Dynamics zu Autorisieren

  • UserCredential – Die Benutzerdaten eines im Azure AD hinterlegtem Benutzers der Zugriff auf auf das CRM hat.
  • Authority – OAuth Endpoint + Tenant ID (ID des Azure ADs)
  • Client ID – die ID mit der sich die Applikation registriert

Das Ergebnis in der Datei ist der OData Feed und die Übersicht der zur Verfügung stehenden Datentöpfe:

Code

Next Steps…

Im nächsten Blog-Beitrag werde ich darauf eingehen wie der Code z.B. in einem SSIS Script Task eingearbeitet werden kann und der OData-Feed verarbeitet wird.