Was können Sie (noch) nicht mit dem AppDesigner erstellen

In der Rubrik AppDesigner im Detail wird beschrieben, welche Bereiche der Applikation mit welchen Metadatenobjekten erstellt und damit auch umgestellt werden kann. Hier wollen wir Ihnen einen schnellen Überblick geben, welche "größeren" Bereiche oder Anforderungen aktuell nicht auf Metadatenobjekte umgestellt werden können.

Die Sage 100 wird von Version zu Version weiter auf neue Technologie umgestellt. Dabei haben die komplexesten Geschäftsprozesse Vorrang, auch um zu verifizieren, dass eine komplette Umstellung auf Client-Server-Architektur via Metadaten, Makros und serverseitigen Geschäftsprozessen möglich ist. Dabei geht es zuerst um die grundlegenden Geschäftsabläufe, wie z.B. „schreibende“ Metadaten auch mit 1:N-Beziehung, komplette Bearbeitung eines Beleges oder einer Buchung.

Weniger Vorrang haben Dialoge, die noch ohne großen Aufwand via VBA in ihrer bisherigen Form (Accessformular) an die grundlegenden Geschäftsabläufe angebunden werden können.

Bei einer Umstellung muss man sich also die Frage stellen, welche Bereiche/ Funktionen/ Anforderungen können mit neuer Technologie umgesetzt werden. Was durch die neue Technologie abgedeckt ist, finden Sie in „Was können Sie mit dem AppDesigner erstellen“.

Im Folgenden wollen wir verdeutlichen, welche grundlegenden Bereiche/ Funktionen/ Anforderungen noch nicht mit neuer Technologie umgesetzt werden kann.

1:N:M-Beziehungen (ab Version 8.1 möglich)

Aufruf von Data-Edit-Elementen mit vorselektierten Datensatzbereich in der Navigationsleiste (ab Version 8.1.2 möglich)

Zusatzdialoge in Data-Edit-Elementen (bedingt durch Selektions-Elemente möglich)

Erfassungsdialoge in Kombination mit Auskünften

Auskunftsdialoge mit unterschiedlichen Elementen

Dateiauswahldialog (ab Version 8.1.1 möglich)

Überlegungen zur Umstellung

Prinzipiell kann man sagen: alles was Sage umgestellt hat, kann umgestellt werden. In Was können Sie mit dem AppDesigner erstellen und dem obigen Absatz „Was können Sie (noch) nicht mit dem AppDesigner erstellen“ wird aufgezeigt, welche Bereiche/ Funktionen/ Anforderungen auf Client-Server-Technologie umgestellt werden können. Andererseits kann man auch sagen, dass aktuell noch nichts umgestellt werden muss, da alles, was bisher via VBA/ Access funktionierte, weiterhin funktioniert. Nichts desto trotz muss irgendwann umgestellt werden, da Access als Host in Zukunft nicht mehr verwendet wird.

Neben der „nachziehenden“ Umstellung (wir schauen, was Sage umgestellt hat und stellen diese Bereiche auch um), könnte aber auch das Bestreben möglichst schnell die Pflege von AddIns abzustellen, ein Grund für eine Umstellung sein. Dann bliebe die Frage: wie implementiere ich clientseitige Interaktionen. Für Bereiche, die noch nicht per Metadatendefinition abgedeckt sind, wäre der Aufruf eines lokalen .NET-DLL-Applikations-Service (Sage.System.AppLibraryCall) möglich.

In Funktionsaufrufe wird darauf hingewiesen, dass diese Möglichkeit nicht zwingend dauerhaft zur Verfügung stehen wird. Zwar ist klar, dass z.B. externe Geräte, die an einen Client angeschlossen sind, in irgendeiner Form erreichbar (mit Datenaustausch) sein müssen, aber es ist noch nicht klar, ob es weiterhin mit Sage.System.AppLibraryCall möglich ist, geschweige denn, wie der Aufbau dieser Schnittstelle aussehen wird. Einfache Zusatzdialoge könnten auch heute schon mit dem Selektionselement abdeckt werden, aber auch hier wird voraussichtlich Nacharbeit nötig sein, denn ein Selektionselement ist für eine Selektion konzipiert (haben z.B. auch keine Berechtigungen).

Neben der Frage, ob verwendete Dialogtypen überhaupt schon durch Metadatenobjekte ersetzt werden können, bleibt vielleicht noch die Frage, was kostet mich die AddIn-Pflege und was kostet mich die Nacharbeit. Diese Frage können selbstverständlich nur Sie beantworten, nachfolgend aber einige Punkte, die aus unsere Sicht bei der Entscheidung berücksichtigt werden könnten.

Ein AddIn kann entfallen, aber in einem Stammdatendialog müssen Daten mit einem externen Gerät ausgetauscht werden.

Funktionalität durch Funktionsaufruf Sage.System.AppLibraryCall implementieren

Ein AddIn kann entfallen, aber in einem Stammdatendialog können Daten durch einen Dateiauswahldialog eingetragen werden.

Funktionalität durch Funktionsaufruf Sage.System.AppLibraryCall implementieren

Ein AddIn kann entfallen, aber es muss dafür ein UI-Dialog in .Net implementiert werden.

Abwägung: es gibt viel Code-behind (inklusive Geschäftsprozess)
- Geschäftsprozesslogik muss früher oder später nach .Net portiert werden. Hier könnte eine Implementierung via Sage.System.AppLibraryCall sinnvoll sein.

Ein AddIn ist nach wie vor nötig, aber es ergeben sich die oberen drei Fälle:

Für die ersten beiden Fälle könnte man den gleichen Ansatz verfolgen. Bei dem dritten Fall hat man eventuell zwei Bereiche mit gleichen Systemfunktionen. Eventuell kann es auch später durch die Komplettumstellung zu einem Redesign der .Net-Implementierung kommen.