In diesem abschließenden Teil zu virtuellen Entitäten in Dynamics 365 werden wir euch durch die restliche Konfiguration innerhalb der Plattform führen.
Registrierung des OData-Services als Datenquelle
Der erste Schritt besteht darin, unseren OData-Service als Datenquelle zu registrieren. Über die erweiterten Einstellungen – Verwaltung – virtuelle Datenquellen gelangt ihr zur Listenansicht der entsprechenden Entität. Hier kann eine neue Datenquelle mit dem mitgelieferten OData v4 Data Provider von Microsoft erstellt werden.
Im Formulareditor kann dann die Verknüpfung zum OData-Endpunkt hergestellt werden. Diesen haben wir im letzten Blog-Beitrag implementiert und als App Service in der Azure Cloud bereitgestellt. In der URL wird neben der reinen Adresse als relativer Pfad „odata“ spezifiziert – dort befindet sich der Einstiegspunkt der OData-Middleware.
Wichtig: Der darunterliegende Ticket-Endpunkt wird hier nicht angegeben, das kommt später.
Als Anforderungsparameter haben wir den ApiKey des Web Service für den zuvor beschriebenen Authentifizierungsmechanismus hinzugefügt. Dynamics365 liefert diesen Wert als Query-Parameter bei Anfragen gegen die Schnittstelle mit. Allerdings müssen die Metadaten-Endpunkte öffentlich erreichbar sein, denn beim Abrufen der Metadaten wird dieser Parameter leider nicht mitgeschickt.
Konfiguration der virtuellen Entität
Nach erfolgreicher Konfiguration der Datenquelle kann die virtuelle Entität erzeugt werden. Dies geschieht im klassischen Solution-Editor, da noch keine virtuellen Entitäten in der neuen PowerApps-Oberfläche angelegt werden können. Wurde die Entität über die entsprechende Checkbox als virtuell markiert, kann die zuvor erstellte Datenquelle ausgewählt werden. Anschließend werden die üblichen Eigenschaften konfiguriert.
Neben den bekannten Feldern aus normalen Entitäten besitzt eine virtuelle Entität noch zwei weitere wichtige Felder – der externe Name und der externe Sammlungsname. Die erstere der beiden Eigenschaften legt den Namen der Entität im OData-Endpunkt fest. Dieser entspricht in unserem Fall dem Klassennamen „Ticket“. Die zweite Eigenschaft gibt an, wie die Sammlung im OData-Endpunkt heißt und entspricht somit dem Pfad zum Tickets-Endpunkt. In unserem Beispiel ist dies der Pluralname der Entität.
Nun ist das Hauptfeld der Entität an der Reihe. Dieses wird hier auf die Ticketnummer festgelegt und ist vom Datentyp Einzelne Textzeile. Wie zuvor schon die Entität selbst verfügt auch das Hauptfeld über die Eigenschaft Externer Name. Dieser legt wieder das Mapping zur OData-Schnittstelle fest – die Namen der Felder müssen also auf beiden Seiten exakt übereinstimmen. Nachdem die Entität erstellt wurde, muss der externe Name des Primärschlüssels noch konfiguriert werden.
Nun ist es an der Zeit, dem Ticket weitere Attribute hinzuzufügen. Der Einzelpreis wäre üblicherweise vom Typ Money, da es sich um einen Geldbetrag handelt. Da dieser Datentyp für virtuelle Entitäten allerdings nicht unterstützt wird, muss auf den Datentyp Dezimalzahl ausgewichen werden. Wichtig an dieser Stelle ist das Attribut Feldanforderung. Dieses gibt an, ob der Einzelpreis optional oder die Eingabe verpflichtend ist. Sollte diese Einstellung nicht zu den Metadaten des Endpunktes passen, wird beim Laden der Entitätsdaten ein Fehler angezeigt.
Um unseren Use Case zu vervollständigen, folgt nun die Anlage einer Beziehung zwischen der virtuellen Entität Ticket und der konventionellen Entität Event. In diesem Fall ist die primäre Entität das Event. Auch hier muss wieder der externe Name des Attributes konfiguriert werden. Dieses muss in der OData-Schnittstelle vom Datentyp Guid sein und eine zu einem Event passende Id enthalten. In unserem Beispiel haben wir noch eine zweite Beziehung zum Kontakt nach demselben Schema erstellt.
Wurde alles korrekt konfiguriert, sollten die Tickets jetzt in der Listenansicht angezeigt werden.
Troubleshooting
Ist etwas schiefgelaufen, wird eine etwas wenig aussagekräftige Fehlermeldung anstelle der Listeninhalte angezeigt.
Die Fehlersuche gestaltet sich eher mühselig, jedoch eignet sich beispielsweise der Azure Dienst Application Insights dazu, Fehler im OData-Service bzw. in der Verknüpfung zu Dynamics zu finden. Ein guter Ansatzpunkt ist auch, die Attribute und Datentypen der virtuellen Entität genauestens zu überprüfen. Auch zusätzliche oder fehlende Felder können eine mögliche Ursache sein.
Fazit
Damit sind wir am Ende unserer dreiteiligen Blogserie zu virtuellen Entitäten angelangt. Es hat sich gezeigt, dass mit nur relativ wenig Glue-Code eine externe Datenquelle einfach in Dynamics365 integrieren werden kann. Dem Endanwender werden kaum Unterschiede zu normalen Entitäten auffallen, die virtuellen Entitäten sind großartig in das System integriert.
Wie man mit einem Custom Datenprovider virtuelle Entitäten auch schreibbar macht, das schauen wir uns in einem gesonderten Beitrag noch genauer an. Es bleibt also spannend!
