MD Consulting wird oft in der Rolle als Gupta-Partner zu unterschiedlichsten Themen um Unterstützung gebeten. Hiermit möchten wir Ihnen von einem erfolgreich abgeschlossenen Projektcoaching in Bereich Gupta und SAP berichten.

Bei einem führenden deutschen Triebwerkhersteller kommen unternehmensweit Geschäftsanwendungen unterschiedlichster Art zum Einsatz. Ebenfalls unterschiedlich ist die technische Grundlage selbiger Applikationen: von Gupta über Visual Basic bis SAP. Dieses Unternehmen kam auf MD Consulting zu und erklärte folgende Problemstellung.
Es ergab sich die Notwendigkeit des Datenaustauschs zwischen dem SAP-System und einer Gupta-Anwendung. Da die Gupta-Anwendung nicht direkt mit dem SAP-System kommunizieren soll, sondern über eine Zwischenschicht, möchte der Kunde dies in Form einer DLL lösen. Die Erfahrung in der Entwicklung einer solchen Schnittstelle ist beim Auftraggeber bereits vorhanden. Es wurde bereits vor einiger Zeit für eine Visual Basic Applikation der Datenaustausch mit dem SAP-System erfolgreich realisiert. Nur wie genau funktioniert das unter Gupta? Aus diesem Grund wurde MD Consulting als Gupta-Spezialist beauftragt, dem Entwicklerteam dieses Unternehmens durch einen Vor-Ort-Workshop die Grundlagen der Entwicklung einer solchen Schnittstelle zu vermitteln – das Ganze natürlich unter Gupta.

Die endgültige Entwicklung selbst möchte der Auftraggeber selbst in die Hand nehmen. Um diesen Workshop nun möglichst effizient durchführen und alle für das Entwickler-Team relevanten Informationen weitergeben zu können, war seitens MD Consulting eine umfassende Vorbereitung notwendig. Dies wurde durch zur Verfügung gestellten Unterlagen über die Gupta-Anwendung und das eingesetzte SAP-System gewährleistet. Um jetzt einen möglichst großen Nutzen aus diesem Workshop zu ziehen, erarbeitete der Gupta-Spezialist von MD Consulting zusammen mit den Teilnehmern Codefragmente, die bei der vollständigen Umsetzung durch den Auftraggeber selbst weiter verwendet werden konnten.
Nach einem Tag intensiver Zusammenarbeit, konnte der Auftrag erfolgreich abgeschlossen werden. Dem Team des Auftraggebers war es nun ein Leichtes mit Hilfe des im Workshop erlangten Wissens die gewünscht Schnittstelle zu entwickeln. Weitere Zusammenarbeit ist in Planung.

Client-/Server-Projekt

Softwareentwicklung
1 Manntag

Technologie:
GUPTA Team Developer
Visual Basic
SAP

18. Januar 2017

Unser Kunde entwickelt Bibliothekssoftware, welche aus verschiedenen Programmen und Schnittstellen besteht. Darunter befinden sich einige Anwendungen, erstellt Mitte der 90er Jahre, die bis heute ihre Daseinsberechtigung hielten und mittlerweile mit dem Team Developer 4.2 weiter entwickelt – durch häufigen Wechsel der Programmierer eher angestückelt als gepflegt – werden.

Der Source und die Anwendung sollen weiterhin auf der Win32-Basis belassen werden, da der Einsatz von ActiveX und einigen externen Schnittstellen via DLL-Einbindung zu viel Aufwand bei der Umstellung nach .NET bedeuten würde. Da es neben der Team Developer-Abteilung auch eine .NET-Abteilung gibt, wollte man durch den Einsatz des Team Developer 6.x erreichen, Schnittstellen und eine entsprechende Codebasis gemeinsam nutzen zu können. Daher das Vorhaben, die bestehenden Team Developer-Anwendungen auf die Team Developer Version 6.x zu migrieren, um den gestiegenen Anforderungen gerecht zu werden.
Migrationsverlauf:

• Erläuterung und Abstimmung der Migrationsschritte.
• Migration der Hauptanwendung von der Team Developer Version 4.2 nach Team Developer 6.0 Service Pack 5.

Die relativ rasche Umstellung der ActiveX-Komponenten und der Unicode-Anpassungen brachte einen schnellen Erfolg der Migration. Die teilweise durchgeführten Tests zeigten keine schwerwiegenden Probleme auf. Ein ausführlicher Test ist allerdings notwendig und geplant, da auch einige Schnittstellen zu externen Systemen geändert wurden.

Nun erfolgte die Vorstellung der neuen Features des Team Developer 6.x., sowie die Einweisung der Kundenmitarbeiter in die Konsumierung von .NET-Funktionalität.
Bei der Demonstration war ein sehr positives Feedback zu erkennen, da dies doch recht einfach zu handhaben ist. Zusammen mit der .NET-Abteilung wurden diverse Tests erstellt, um aufzuzeigen wie die Funktionalitäten eines intern erstellten Assemblys mit dem Team Developer verwendet werden könnte.

Als weitere gemeinsam verwendbare Schnittstelle wurde die Bereitstellung von Webservices erläutert. Demonstriert wurde dies anhand eines klassischen Webservices (ASMX – Webservice)  und der Konsumierung mit dem Team Developer 6.0 und dem Team Developer 6.1.

Da die intern erstellten Webdienste allerdings mittels WCF (Windows Communication Foundation) und dem Framework 4.0 erstellt wurden und werden, bestand die Anforderung, ebenfalls diese konsumieren zu können. Da hier Restriktionen Seitens des Team Developer bestehen und beachtet werden wollen, konnten wir durch unsere Erfahrungen dem Kunden viel Forschungsarbeit ersparen.

Fazit:

• Umstellung der Anwendung vom Team Developer 4.2 auf den Team Developer 6.0 verlief schnell und problemlos
• Anforderung der Konsumierung von .NET-Funktionalität mit dem Team Developer unter Beachtung vorhandener Einschränkungen umsetzbar
• Einsatz von klassischen Webservices möglich
• Erste Schritte der Konsumierung von WCF-Webdiensten sind gemacht, weitere Details sind zu untersuchen

Client-/Server-Projekt

Consulting
2 Manntage

Softwareentwicklung

Technologie:
GUPTA Team Developer .NET
WCF
Framework 4.0

18. Januar 2017

Ein Schwein ist krank oder ein Kalb will nicht selbstständig auf die Welt kommen. Probleme, die schnellst möglichst vor Ort gelöst werden müssen. Tierärzte im Einsatz: Kaum ein Einsatz abgeschlossen ruft schon wieder der Nächste. Alle Daten müssen vor Ort auf der Weide oder im Stall abrufbar sein und natürlich müssen alle Einsätze abgerechnet werden. Damit nichts vergessen wird, am besten sofort.

Das Abrechnungsprogramm, eine Gupta Team Developer Lösung, sollte nun auf die neuen SEPA-Lastschriften umgestellt werden.
Im ersten Teil des Coachings vermittelte der Kunde die Funktionsweise der XMLLIB.APL.
Dann erstellten wir nach Vorlage der Sparkasse die nötigen Bausteine zur Erstellung der SEPA-XML-Datei.
Zum Abschluss wurde die Datei durch das Prüfprogramm der Sparkasse verifiziert und für gut befunden.
Der Kunde war mit dem Ergebnis des Coachings sehr zufrieden.

Client-/Server-Projekt

Softwareentwicklung
1 Manntag

Technologie:
GUPTA Team Developer

18. Januar 2017

Eine bestehende Anwendung für das Tracking von Strafmandaten und eine entsprechende Kassensoftware, erstellt mit dem TD 3.1, soll lt. Kundenanforderung ins Web umgestellt werden. Hierbei sollten verschiedene Wege vorgestellt und betrachtet werden.
Die Anwendung enthält zahlreiche DLL-Aufrufe und ActiveX-Komponenten. Die Umstellung nach TD 5.2 wurde durch den Kunden bereits realisiert.

Inhalt des Workshops:

• Grundlagen zur Migration nach TD 6.x Win32
• Grundlagen zur Migration nach TD 6.x .NET
• Grundlagen XAML – Verwendung von WPF-Controls
• Konsumieren von .NET-Assemblies
• Gegenüberstellung einer Web-Anwendung und einer browserbasierten Anwendung
• Aufgrund der bestehenden Programmstruktur wäre die Umstellung auf eine Web-Anwendung zu aufwändig
• Erstellen und Einrichten einer XBAP-Anwendung
• Erstellen einer Liste von erforderlichen Eckdaten zur Klärung mit dem Endkunden

Folgende Probleme sind bei der Migration aufgetreten:

• Datenbankzugriff auf SQL Server über ODBC
• DB-Connect unter .NET funktionierte nicht, unter Win32 war es ok;
  OLEDB funktionierte, konnte aber nicht mit Subselects umgehen
• Umstellung auf TD 6.1 .NET durchgeführt – DB Connect erfolgreich
• Durch die Projektstruktur der umzustellenden Software war eine Migration direkt nach TD 6.1 Win32 nicht möglich, da der Compiler nicht alle enthaltenen DLL-Aufrufe umsetzen konnte. Deshalb erfolgte die Migration nach TD 6.0 Win32 und die Anwendung wurde soweit abgespeckt, dass nur die notwendigen Module enthalten waren. Test unter TD 6.0 Win32 erfolgreich
• Die DLL-Aufrufe wurden in ein .NET-Assembly gepackt, welches eingebunden wurde
• Probleme traten auf, wenn Member-Variablen einer Klasse als Bindvariablen verwendet wurden. Das Select-Statement wurde hier nicht korrekt ausgeführt.

Lösung brachte hier die Umstellung der Statements ohne Bindvariablen. Im TreeView-Control wird bei Verwendung der Funktion SalTreeSetSelectedItem zwar das Item selektiert, aber nicht in den sichtbaren Bereich bescrollt. Dies ist allerdings nur bei der Eigenschaft ShowRoot = NO falsch. Ist diese Eigenschaft auf Yes gesetzt, ist das Scroll-Verhalten richtig

Eine Liste von notwendigen Voraussetzungen konnte erstellt werden. Der Kunde kennt nun die Schritte zur Umstellung seiner Anwendung als XBAP-Anwendung. Bei Umstellung der Anwendung ist weitere Unterstützung vorgesehen.

Client-/Server-Projekt

Softwareentwicklung
2 Manntage

Technologie:
GUPTA Team Developer

18. Januar 2017

Bisher wurden verschiedene Anwendungen über Citrix den Anwendern in verschiedenen Kantonen zur Verfügung gestellt. Da dies mit erheblichen Aufwand und auch Kosten bei der Bereitstellung des Citrix-Clients verbunden ist, möchte man dies durch Bereitstellung einer Browseranwendung einsparen.

Migrationsverlauf:

• Vermittelt wurden Grundkenntnisse für die Verwendung von WPF-Controls. In einem bestehenden Projekt wurde dies bereits anhand der ProgressBar praktiziert. XAML wurde hier aufgrund der Gesamtzeit des Workshops vernachlässigt.
• Vermittelt wurde die Vorgehensweise beim Ersetzen von WinAPI-Funktionen durch äquivalente .NET-Funktionalität. Dabei wurden Grundkenntnisse beim Konsumieren von .NET Assemblies vermittelt und anhand der WinAPI-Funktion ShelExecute praktisch umgesetzt.
• Vermittelt wurde die Erstellung von WPF-Browser-Anwendungen. Hierbei wurde speziell auf das Veröffentlichen dieser eingegangen. Speziell auf die Erstellung eigener Zertifikate und Anpassung der index.htm zur Bereitstellung einer individuellen Installationsanleitung.
• Diskussion zur Verwendung von Web Services sowie Demonstration zum Erstellen und Konsumieren von Web Services.
• Verwendung der MS Office Interop

Folgende Probleme sind bei der Umstellung nach .NET aufgetreten:

• Menü wird nicht korrekt übersetzt – Funktion VisMenuGetText funktioniert unter .NET anders als unter Win32, dieser Bug wurde an GUPTA gemeldet.
• Im Menü sind unter .NET keine Mnemonics sichtbar.
• Der Background verschiedener Controls ist nicht transparent, daher unschöne Anzeige der GUI.
• VisTblSetCellColor wird unter .NET nicht unterstützt – gibt es ein Äquivalent?
• SalGetFileStr liefert unter .NET nicht nur die erste Zeile wie unter Win32, sondern die ganze Daten zurück.
• Variablenreferenzierung bringt Fehler (ist allerdings zum Teil bedingt durch den Aufbau der Programmstruktur) Workaround oder Beseitigung der Fehlermeldung wurde erarbeitet.
• Keine HTML-Hilfe unter .NET.
• Remote Publishen einer WPF-Browser Anwendung funktionierte nicht – Alternative über locales Publishen und Kopieren auf dem Remote-Rechner.

Hierzu werden teils Testfälle durch den Kunden erstellt, damit die Fehler im Rahmen des Migrationstages an Gupta gemeldet werden können. MD Consulting konnte 2 EMPs für den Kunden bewirken.
Für nicht mehr unterstützte Funktionalitäten wird nach äquivalenten Möglichkeiten gesucht und der Kunde darüber informiert.
Für einen Tag sehr viel geschafft!

Client-/Server-Projekt

Softwareentwicklung
1 Manntag

Technologie:
GUPTA Team Developer .NET

18. Januar 2017