Gemäß der GraphQL-Spezifikation ist es „eine Abfragesprache, die entwickelt wurde, um Client-Anwendungen durch Bereitstellung einer intuitiven und flexiblen Syntax und eines Systems zur Beschreibung ihrer Datenanforderungen und Interaktionen zu erstellen“.
Ab Version 25 ist die Verbindung von List & Label mit einer GraphQL-API als Datenquelle sehr einfach. Es muss lediglich ein neues List & Label GraphQLDataProvider-Objekt erstellt werden und die API-Adresse als URL-Konstruktorparameter übergeben werden:
GraphQLDataProvider prov = new GraphQLDataProvider("https://localhost:44375/api/graphql");
Zuerst versucht der Datenprovider, die im GraphQL-Server definierten Typen und Abfragen anhand des Schemas zu extrahieren und – darauf aufbauend – Tabellen, Zeilen, Spalten und Beziehungen zu erstellen.
Abfragen, die als Tabellen erstellt werden, haben ein Präfix ‚Q_‘ in ihrem Namen. Der Präfix kann geändert werden, indem dem optionalen Konstruktorparameter „queryPrefix“ der Klasse GraphQLDataProvider ein neuer Präfix zugewiesen wird. Diese Abfragen sind die einzigen Elemente, die auf der „Root“-Ebene zum Drucken und Gestalten verwendet werden können, da der Aufruf einer Abfrage die einzige Möglichkeit ist, Daten aus GraphQL zu erhalten. Die typbasierten Tabellen können nur als Untertabellen von Abfragen verwendet werden, wie unten gezeigt.
Sollte eine GraphQL-Abfrage Abfrageparameter enthalten, so werden diese automatisch als Berichtsparameter hinzugefügt. Hierbei gilt zu beachten, dass bei der Eingabe der Werte für den Berichtsparameter die GraphQL-Syntax vollständig beibehalten werden muss. Ein einfaches Beispiel zeigt, wie es mit dem Standardtypen String funktionieren würde:
{ Categories(CategoryName:"Beverages") { CategoryID, CategoryName, Description } }
Hier würde List & Label nun den Berichtsparameter „CategoryName“ anlegen und erwartet als Wert direkt den Kategorienamen (bspw. Beverages), nachdem gefiltert werden soll.
Doch wenn das GraphQL-Schema typisierte Abfrageparameter definiert hat ist es erforderlich, bei der Eingabe des Werts im Berichtsparameter das gesamte Schema anzugeben:
{ Categories(MyArgument:{CategoryName:{eq:“Beverages“}) { CategoryID, CategoryName, Description } }
Hier würde List & Label nun den Berichtsparameter mit dem Namen „MyArgument“ anlegen und erwartet bei der Eingabe als Wert nun die GraphQL-Syntax für die gesamte Abfrage, um den Filter aufbauen und ausführen zu können: {CategoryName:{eq:“Beverages“}}
Es gibt zwei weitere Eigenschaften in diesem Data Provider:
- QueriesRootName: Der GraphQL Server packt alle Abfragen als Felder eines einzigen Typs. Standardmäßig lautet der Name des Abfragetyps „Query“, aber wenn Ihre API das anders handhabt, müssen Sie List & Label über diese Tatsache informieren
- MutationsRootName: Eine Mutation ist ein Schreiben, gefolgt von einem Datenzugriff. Da das Schreiben der Datenbank weder benötigt noch von der Berichtsseite unterstützt wird, dürfen Mutationen nicht Teil der Struktur im Designer sein. GraphQL Server packt alle Mutationen als Felder eines einzigen Typs. Standardmäßig lautet der Name des Mutationstyps „Mutation“, aber wenn Ihre API das anders handhabt, müssen Sie List & Label darüber informieren, um die Mutationen aus der Datenstruktur auszuschließen.
Wenn Ihre GraphQL-Datenquelle Bilder unterstützen soll, können Sie diese mit GraphQL über die Base64-Stringcodierung serialisieren und übertragen. Um diese Felder für List & Label wieder in ein Bild zu dekodieren, können Sie das Ereignis ListLabel AutoDefineField verwenden. Der folgende Code zeigt, wie dies in einem Northwind-Sample aussehen könnte:
LL.AutoDefineField += new AutoDefineElementHandler(LL_AutoDefineField); void LL_AutoDefineField(object sender, AutoDefineElementEventArgs e) { string name = e.Name.ToString(); string value = e.Value.ToString(); if (name == "Q_categories.picture") { ListLabel ll = sender as ListLabel; e.Suppress = true; if (value.Length > 50 && value.Length %25 4 == 0) { ll.Fields.Add(e.Name, Convert.FromBase64String(value)); } else { ll.Fields.Add(e.Name, string.Empty, LlFieldType.Drawing_hBitmap); } } }
So sieht der Designer aus, wenn Sie ihn mit einem einfachen Northwind-Dienst verbinden. Beachten Sie, dass wir die Query Q_Categories als Root-Tabelle verwenden und nicht den Typ „Category“.
Natürlich können Sie auch eine GraphQL-Datenquelle zum Report Server hinzufügen. Es unterstützt auch die Übergabe von Authentifizierungsinformationen für den Zugriff auf Ihre API.