Der OpenEdge Data Provider für List & Label 24 steht ab sofort als Download zur Verfügung.

Den OpenEdge Sourcecode und die DLL finden Sie wie üblich auch in Ihrer List & Label Installation unter C:\Program Files (x86)\combit\LL24\Beispiele\Progress\OpenEdge. Den C# Sourcecode finden Sie nur hier im Download Bereich.

Entwickelt wurde diese Version unter OpenEdge 11.7 64bit und mit der Visual Studio 2017 Community Edition. Der Data Provider ist mit dem .Net Framework 4.0 compiliert, die OpenEdgeDemo mit .Net Framework 4.6, da die integrierten Progress.Messages.dll und Progress.o4glrt.dll für OpenEdge 11.7 .Net Framework 4.6 voraussetzen.

Falls Sie eine andere OpenEdge Version verwenden und auch über einen .Net Client (wie z.B. dem combit Report Server) auf den OpenEdge Appserver zugreifen möchten, ist es ggf. erforderlich den OpenEdgeProxy mit anderen Einstellungen neu zu generieren.

Der Dataprovider ist in den combit Report Server fest integriert über den Source Code. Ein Wechsel zu einer anderen Version des Data Providers ist hier nur über combit möglich. Der Proxy, d.h. die Schnittstelle zum OpenEdge Appserver kann aber über die Registry konfiguriert werden und somit auf ihre OpenEdge Version angepasst werden.

Für List & Label 24 wurde der Data Provider erweitert um zusätzliche Möglichkeiten, die erforderlich sind, wenn der Data Provider über den OpenEdge Appserver auf Services zugreift (wie der Report Server). Bei einem Database Service, der Zugriff auf eine OpenEdge Datenbank gibt, ist das keine Problem. Anders sieht es allerdings aus, wenn ein Auswertung zum Beispiel Daten in ein ProDataset schreibt und dieses dann in List & Label verarbeitet werden soll. Da List & Label tabellenweise Daten anfordert, muss man das ProDataset zwischen einzelnen Appserver Aufrufen zwischenspeichern (Cache) und auch für unterschiedliche Appserver Agents verfügbar machen.

Um das zu ermöglichen, schickt der Data Provider bei jedem Request eine ClientId (= Instance Guid) mit. Zusätzlich sendet der Data Provider einen neuen „ClientEvent“, wenn bestimmte Dinge passieren. Um einen Cache zu implementieren, macht man etwa folgendes:

• Client Event „ReportParametersCollected“: Report Parameter auswerten, Daten erstellen und in einen Cache schreiben. Hierzu schreibt man z.B. das Dataset als Json auf die Platte in eine Datei deren Name aus Service Name und ClientId gebildet wird.
• Beim Zugriff auf Daten lädt man den Cache zurück in das Dataset.
• Beim einem Dispose() des DataProviders schickt dieser einen letzen Event „ClientDisposed“. Das ist dann der Zeitpunkt einen Cache zu löschen.

Im aktuellen Download ist ein Beispiel für einen Datei Cache. Die Datei enthält JSON des Dataset. Der Name der Datei ergibt sich aus ClientId und Service Name.

Im Verzeichnis ‚ListLabelSamples‘ sind auch noch weitere Beispiele wie Rechnungsdruck, PDF Export auf dem Client oder dem Appserver, Beispiele mit Client Datasets usw.

Ein Database Service, der Zugriff auf eine komplette Datenbank gibt, hat einen gewissen Charme, war aber bisher nur begrenzt nützlich, da das Feature von „Calculated Tables“ fehlte. Das sind im Prinzip Temp-Tables, die in einen Database Service integriert werden können. Die Daten in diesen Temp-Tables werden erzeugt, wenn die Tabellen angefordert werden. Parameter sind hier z.B. die aktuelle Parent Relation und ggf. auch Report Parameter – beides schickt der Data Provider mit.  Zusätzlich zu „Calculated Tables“ gibt  es auch seit längerem „Calculated Fields“. Ein Beispiel für beides finden Sie im Sports2000Service der Demo.