Modernisierung mit OpenEdge ein Erfahrungsbericht - Mike Liewehr, AKIOMA Mike Fechner, Consultingwerk - Progress Software
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Modernisierung mit OpenEdge ein Erfahrungsbericht Mike Liewehr, AKIOMA Mike Fechner, Consultingwerk
Agenda Vorstellung Mike Liewehr / AKIOMA Vorstellung Mike Fechner / Consultingwerk AKIOMA SWAT und Consultingwerk SmartComponent Library Auszug aktueller Modernisierungsprojekte Exemplarische Herausforderungen und Lösungen
AKIOMA
Long-term Progress Partner
Products:
o AKIOMA SWAT
Develop Enterprise Business web-applications with an OpenEdge Backend
o AKIOMA Connect
Integrate your Application/Services in Realtime with connectors for ERP, CRM, DMS, MS-
Exchange, Office 365, MS-Sharepoint and many more
o Development Tools
Visual Designer, Cloud-Deployment, SCM integration
o Services + Consulting
State-of-the-art Software development processes + Architecture
Mike Liewehr
AKIOMA SWAT Foundation for the AKIOMA Applications Also available as a separate Product Deeply integrated with SmartComponentLibrary Unique approach to the UX Suitable for complex Applications Idea: Rollbase / force.com, but more flexible
Agenda Vorstellung Mike Liewehr / AKIOMA Vorstellung Mike Fechner / Consultingwerk AKIOMA SWAT und Consultingwerk SmartComponent Library Auszug aktueller Modernisierungsprojekte Exemplarische Herausforderungen und Lösungen
Consultingwerk Independent IT consulting organization Focusing on OpenEdge and related technology Located in Cologne, Germany, subsidiaries in UK and Romania Customers in Europe, North America, Australia and South Africa Vendor of developer tools and consulting services Specialized in GUI for .NET, Angular, OO, Software Architecture, Application Integration Experts in OpenEdge Application Modernization
Agenda Vorstellung Mike Liewehr / AKIOMA Vorstellung Mike Fechner / Consultingwerk AKIOMA SWAT und Consultingwerk SmartComponent Library Auszug aktueller Modernisierungsprojekte Exemplarische Herausforderungen und Lösungen
SmartComponent Library Developer Framework aimed to increase Developer productivity and flexibility Reduce or avoid repeating tasks Tools (code generation and round-trip dev.) Integration with various Progress tools (OpenEdge, Telerik, KUIB, BPM, Corticon, DataDirect …) Architecture Framework and Application Framework Allow integration with existing Applications and Frameworks Allow usage of individual framework components as needed
Framework Backend Architecture OpenEdge Reference Architecture compliant Complies with the Common Component Specification (CCS) Business Entities, Data Access Objects are a key components Business Tasks, including support for scheduled and asynchronous processing Common Infrastructure Components, Services
User-Interface Flexibility OpenEdge GUI for .NET Angular Web Applications NativeScript Offene Standardschnittstellen (z.B. RESTful, .NET, Java) Partner frontends, wie z.B. AKIOMA SWAT Support für statische User Interfaces und UI Repository
Modernisierungsoptionen Vielzahl an unterstützten UI‘s ermöglicht flexible Modernisierungsvorhaben Direkte Umsetzung des „finalen“ UI‘s Zuerst Integration modernes GUI for .NET in klassisches ABL GUI Dabei Modernisierung der Backend Architektur Und dann Migration auf das Ziel-UI oder mehrere UI‘s
AKIOMA SWAT Architektur
Principles of SWAT-Framework
o Cover Backend + Frontend
UI Components have matching Backend services
o Not forcing a given Application Layout
o Allow (Backend-) Developers to implement the whole stack
o Progress Best practises
JSDO / CCS / OERA
o OpenEdge on the Backend, enhanced by state-of-the art
technology (node.js…)
o Provide low-code, quick approaches, but also allow more
control and working on lower levels
16Highlights
o Multi-Windowing Web-UI, welches ein natives Windows-GUI
ersetzen kann
o Rich-Text-Editor
o Drag&Drop, Treegrid, Scheduler…
o Erzeugen von Dokumenten (z.B. Word, Excel…) aus dem
Backend
o Integration-Services (Exchange, Salesforce, ERP…)
o Real-Time-Messaging
o Node.js-Integration
o Support für Client-Logic
17AKIOMA UX Architecture
Deployment Repository
Designtime
API - Object-Types-Hierarchy
CI, Staging, SCM
- Attributes
- Objects, Object-Instances
- Links
UI-Builder A
UI-Builder B
Runtime
Tools… API
Service-Interface
Transfer Repo into JSON
UI-Builder Browser running AKIOMA Rendering-Engine
Transform JSON into screensAgenda Vorstellung Mike Liewehr / AKIOMA Vorstellung Mike Fechner / Consultingwerk AKIOMA SWAT und Consultingwerk SmartComponent Library Auszug aktueller Modernisierungsprojekte Exemplarische Herausforderungen und Lösungen
Auszug aktueller Modernisierungsprojekte OSC / OSIV am-Computersysteme Großer schwäbischer KFZ-Zulieferer
OSC / OSIV Open System IV (Invalidenversicherung) Gründung 1996 als Behördenpool 7 IV-Stellen von 7 deutschsprachigen Kantonen der Schweiz 4 regionale Untersuchungszentren in Verbindung mit den Sozialversicherungsstellen OSC als Kompetenzzentrum für Anwendungs- entwicklung
OSC / OSIV 20 Mitarbeiter, 3 Freelancer, externe Supporter Kernaufgaben Anwendungsentwicklung Anforderungsanalyse, Business Analyse Technischer Support
Aktuelle OSIV Software Workflowgestütztes Fall-Management, vollständig papierlos mit Einbindung eines DMS Extrem Integrierter Monolith, sämtliche Bereiche der Invalidenversicherung sind abgebildet Zahllose Funktionen in der Software, Validierungen, Anwendungsmasken Durchdachtes Konzept, stabil, performant Hohe Akzeptanz bei den Anwendern 20 Jahre Entwicklungsdauer, ca. 120 Entwicklerjahre
Gründe für ein Refactoring Unabhängige Analyse der Anwendung Wartungsaufwand der Anwendung hoch Trainingsaufwand neuer Anwender hoch Veraltete Technologiebasis, kaum noch Erweiterungsmöglichkeiten User Interface und UX Veraltet Neue Anforderungen: Mobile, eGovernment, Home- Office
Ziele des Refactorings Sicherstellung des zukünftigen Betriebs der Anwendung Zukunftssicherheit und Investitionsschutz Erhalt des guten Images vom OSIV
Grundlagen des Refactorings Wiederverwendung von Teilen des aktuellen Quellcodes Einsatz des aktuellsten Technologie-Stacks von Progress Software Browserbasierte Lösung, Cloud-enabled, N-Tier Beibehalten der aktuellen Datenbankstruktur Einsatz moderner Anwendungsframeworks State-of-the-art user-centric UI/UX
Aktuelles UI OSIV 5.x
Web-Anwendung, OSIV3G
UI / UX Projekt hoher Focus auf UI und UX Einbindung von UI / UX Beratern User-Centric Design Incl. Eye-Tracking Permanenter Prozess, laufend involviert in die Aufgabenspezifikation
Herausforderungen Komplexität der Fachlogik, hohe Redundanz in der Implementierung Kaum Trennung von UI und Business-Logik Bestehender Anwendungscode wesentliche Beschreibung der aktuellen Funktionalität Code-Analyse komplex
Herausforderungen Extrem gute Performance der bestehenden Anwendung Hohe Optimierung von Queries Dokumentenanzeige extrem schnell (Blättern durch Dokumentenstapel) Folge war Skepsis, in wie weit eine akzeptable Performance durch die Web-Anwendung erreicht werden kann
Eng verzahnte Schnittstellen Einbindung DMS als Basis für Workflow, Möglichkeit Dokumente mit Anmerkungen zu versehen Emailschnittstelle (in und out) zur Kommunikation mit Versicherten, Gutachtern, Versorgenden, … SEDEX (Secure Data Exchange der Schweizer Behörden) ISDS (Informationssicherheit und Datenschutzkonzept)
Projektanforderungen Neues UI / UX Konzept erlaubt keine Überführung des Masken-Layouts Datenbankstruktur darf nur (leicht) erweitert werden, Parallelbetrieb von OSIV 5.x und 3G Wechsel von pessimistischem Record Locking zu optimistischem Keine Änderungen am Quellcode von OSIV 5.x möglich Steigerung der Wartbarkeit
OSIV3G: Soft Migration
Current OSIV 5.x Migrierte Module
Harvesting von
bestehendem Code
+ additional Fields
and Tables,
z.B. SelfHdl Framework
OSIV-DB DB‘sProjektplanung Entwicklung und Deployment in 4 Ralisierungseinheiten Zuschnitt der RE‘s nach MVP für verschiedene Anwenderkreise Sperren der jeweiligen Funktionalität im Legacy-System kurz nach der Einführung
(Teil-)Automatische Code-Migration
Überlegungen zu (teil-)automatisierter Code-Migration
wurden verworfen
Hohe Redundanz der Business-Logik
Abweichender Strukturierung/Paketierung der neuen
Anwendung gewünscht
bestehende Business-Logik Maskenorientiert organisiert
neue Business-Logik nach SOA, OO und DDD Methoden
organisiert
Bestehende Libraries (Module) insb. in Anfangsphase
des Projektes mit OO-Wrapper genutztTeam Bestehendes Entwicklerteam verfügt über hohes Know- How der Fachlogik, aber kaum Know-How über moderne Software-Architekturen, Objektorientierung und Web-Technologien Externe Entwickler kennen die komplexe Fachlogik nicht
am-Computersysteme
Aktuelle Software ERP-System mit ca. 150 Installationen Entwickelt mit Sybase + Delphi Client-Server mit komplexem, state-of-the-art Windows GUI (Treeview, Multi-Window...) Sehr komplexe Geschäftslogik mit viel Branchen- Knowhow
Gründe für Modernisierung Web-Fähigkeit Cloud-Fähigkeit Optimierungen Entwicklungs-Prozess Zentrale Code-base Support für Customizing
am-computersysteme Herausforderungen Wenig Zeit, da viel Kundenindividuelle Entwicklung in der alten Applikation Kein Web-Knowhow Sehr komplexe Geschäftslogik
150 angepasste Installationen Standarisierte Kernlösung wird in der Regel bei den Kunden stark angepasst Anpassungen am Datenbank-Schema Anpassungen im Quellcode Feature-Switches, IF-THEN-ELSE Neue globale Anforderungen müssen zum Teil per Copy und Paste verteilt werden
Deutscher KFZ-Zulieferer > 2 Mrd. Umsatz > 5000 Mitarbeiter 14 Werke weltweit Eigenentwickeltes ERP auf Basis von OpenEdge
Modernisierungsvorhaben 1. Fertigungsleitstand zur Anzeige von Produktionsauftragsdetails in der Fertigungsstraße 2. Modernisierung des eigenen ERP‘s um den hohen Ansprüchen des Unternehmens gerecht zu werden
Systemumgebung
14 Werke weltweit
Kaum Nutzen von Standardwerkzeugen für
Entwicklungsworkflow
Eigenes Ticket-Management System
Grundlage für Entwicklung und Deployment
Keine Integration in moderne Build und Development
Tools
Prinzipiell bereit zu Wechsel, aber jeweils Skepsis
gegenüber dem Nutzen oder VorteilContinous Deployment Mehrfach tägliche Updates in Produktion Große Updates (Schemaänderungen), nur zu eher seltenen Wartungsfenstern möglich, 14 Standorte nicht zu synchronisieren, Abstimmung mit dem Werk erforderlich Änderungen welche hierdurch geblockt werden, werden erst später deployed – komplexe Analyse der Abhängigkeiten, Featureswitches
Agenda Vorstellung Mike Liewehr / AKIOMA Vorstellung Mike Fechner / Consultingwerk AKIOMA SWAT und Consultingwerk SmartComponent Library Auszug aktueller Modernisierungsprojekte Exemplarische Herausforderungen und Lösungen
Erfolgsfaktor Entwickler
Bestehende Entwickler im Team Neue / Externe Entwickler im Team
Jahrzehntelange Erfahrung mit dem Keine Kenntnis des „Business“
„Business“ und bestehender
Geschäftslogik Idealerweise bereits Erfahrung mit
Vielzahl der geforderten neuen
Keine oder kaum Erfahrung mit neuen Technologien
Technologien
Mehrschicht-Architektur
Objektorientierung
Web Technologien
Neue Entwicklungstools und –
verfahren
Eingebunden in das TagesgeschäftAnforderungen an bestehende Entwickler Progress OpenEdge 11 OOABL, ProDatasets PASOE N-Tier, Backend only (in den Projekten mit Web-UI) OO-Entwicklung Web-Entwicklung JavaScript / TypeScript CSS
Anforderungen an bestehende Entwickler Neue Tools PDSOE SCM Tools der Frameworks Build / Test / Deployment Neue Entwicklungsverfahren Agile, SCRUM TDD
Akquise zusätzlicher Entwickler Neueinstellungen Mitarbeiter der Framework-Anbieter, bzw. Partner Mitarbeiter weiterer Progress-Partner Wayfare flusso … Partner/Dienstleister des Kunden …
Einarbeitung bestehender Entwickler
Schulungen als Grundlage
Kombination mit Entwicklern mit mehr Erfahrung im
Umgang mit den neuen Technologien
In einem Entwicklerteam
Gemeinsames Backlog, gemeinsames Entwickeln einer
Lösung, bis hin zu pair-programming
Weitestgehende Befreiung vom TagesgeschäftEinarbeitung bestehender Entwickler
Permanentes Coaching und Mentoring
Code-Review
Agiler Ansatz führt zur Lösung von weiteren
Herausforderungen während des Projektes, z.B. durch
Erweiterung von Framework-Funktionalität (im Projekt,
extern)
Erfordert regelmäßige weitere Ausbildung der
Entwickler in geeigneter DosisUI / UX Graphische Entwicklungs-Tools Kein HTML-Knowhow nötig
UI / UX Support für Client-Logic Client-Logic-API Progress-Spezifische Erweiterungen Entry,Lookup,can-do... Kein bzw. nur sehr rudimentäres Javascript/Web- Knowhow nötig Optimale Integration mit Backend + OpenEdge
Software-Entwickler Frameworks Exemplarische Lösung von Architekturanforderungen Templates, Basisklasse, API‘s, SDK‘s, hand-in-hand greifende Komponenten Referenzimplementierung / best-practices Entwicklungsprozesse
Entwicklungs-Prozess Entwicklungs-Workflow Ready-to-use SCM, Versionierung Staging Ticket-Management Deployment... Kein Muss, aber erleichtert den Start
Interaktion zwischen Back- und Frontend OSIV Anwender stößt bei Validierung oft auf Fragen oder Warnungen: „XYZ ist eingetroffen … wie soll verfahren werden?“ Fragen/Warnungen abhängig von komplexer Logik Wiederkehrendes Pattern in der OSIV Anwendung Legacy Code: MESSAGE … UPDATE Statements Validierung kann ebenfalls Felder sperren oder einfärben
Beispiel Ja/Nein Prompt (Legacy)
Interaktion zwischen Front- und Backend Modale Prompts in Web-Anwendungen problematisch Progress AppServer kann keine Frage ans Frontend schicken und auf die Antwort warten, kein INPUT- Blocking PASOE beantwortet lediglich Requests vom Browser Einsatz von Messaging unerwünscht aufgrund von Skalierbarkeit
Interaktion zwischen Front- und Backend Lösung: Einsatz Questions-API des SmartComponent Library mit SWAT Erweiterungen Wenn Validierungslogik auf Frage stößt, wird die Validierung abgebrochen und die Frage als JSON Objekt an das Frontend geschickt Frontend sperrt die Maske bis der Anwender die Frage beantwortet hat und wiederholt die Anfrage (Speichern) Einsatz der Framework-API‘s gekapselt hinter Facade analog zum Legacy-Code
Beispiel Ja/NeinPrompt (Neu)
Frage als JSON Objekt
am-Computersysteme - Customizing Einführung neuer Lösungen für Customizing Grundlage: Definition der Kernfunktionalität Ziel: Entwicklung eines Standards mit Anpassungsmöglichkeiten jenseits von Quellcode Veränderung Konfiguration der Code-Basis Architektur: OERA / CSS / OO Patterns und Principles Teilweise Einsatz von Corticon
am-Computersysteme - Customizing Dependency Injection, Konfigurierbarkeit von Abhängigkeiten CCS Service Manager zur Abstraktion des Zugriffs auf Services Business Services mit Fachlogik Framework-Komponenten (Projekt oder fremd) Programmierung erfolgt weitestgehend gegen Interfaces
Implementierung des Customizings Implementierung alternativer Komponenten Ableitungen (Implementierungsdetail Alternativer Komponenten) Adapter-Pattern Decorator-Pattern Factory-Pattern … Feature-Switches (wenn Wartbarkeit nicht gefährdet)
Decorator Pattern
Consumer (z.B. Referenziert / nutzt
Business Entity) IPreisfindung
über factory
Referenziert / nutzt
CustomPreisfindung BasisPreisfindungDecorator Pattern
Consumer (z.B. Referenziert / nutzt
Business Entity) IPreisfindung
über factory
Referenz. /
nutzt Referenziert / nutzt
CustomBPreisfindung CustomAPreisfindung BasisPreisfindung
- Lose Koppelung der Implementierungsvarianten
- Keine Ableitung, da Ableitung fix ist und nur eine Basisklasse möglich istDecorator Pattern
Consumer (z.B. Referenziert / nutzt
Business Entity) IPreisfindung
über factory
Referenziert / nutzt
CustomAPreisfindung BasisPreisfindung
CustomBPreisfindungDomain Driven Design Einsatz von Komponenten von Domain Driven Design Definition von Modulen und den Schnittstellen (Interfaces) zwischen diesen Innerhalb eines Modules können Objekte und Services relativ direkt miteinander interagieren Über Module hinweg erfolgt Kommunikation mit der Facade des Modules Erlaubt Austausch kompletter Module
Domain Driven Design
CRM-Module Order Processing-Module Factory/Warehouse-Module HR-Module
Module-Facade Module-Facade Module-Facade Module-Facade
Order / Order
Item Employee
Line
Customer
Invoice Inventory Sales RepDomain Driven Design Austauschbarkeit ganzer Module – auch durch Adapter hin zu Fremdsystemem Reduzierung fachlicher Komplexität - nicht jeder Entwickler muss gesamten Code verstehen, sondern nur die Facaden kennen Unit Test einfacher, Mocken kompletter Module Phasenweise Migration: Facaden können zuerst Legacy Code verstecken oder „quick and dirty“ Code maskieren
Continous Deployment mit Docker Anforderung bei dem KFZ-Zulieferer mit den 14 Standorten, bis zu mehrmals täglich Deployment neuer Anwendungsstände Aktuell: Kopieren (manuell) ausgewählter R-Codes in Deployment Umgebung
Continous Deployment mit Docker Neue Architektur hat hier komplexere Anforderungen Erweiterte Abhängigkeiten im Code der OOABL Anwendung Service-Komponenten typischer Weise auf dem AppServer gecacht (Neustart einzelner Anwendungsmasken „auf Zuruf“ keine Option Abhängigkeiten von Framework-Metadaten (z.B. Maskenlayout) in Framework DB
Continous Deployment mit Docker Ziel: „on the fly“ Austausch des kompletten Applicationsbackend in Form eines Docker- Containers Einsatz von Docker-Tools zur Orchestrierung Docker-Container enthält PASOE (Supported seit OpenEdge 11.7.4) Applikation Framework Konfigurations- und Metadaten
Live-Demo UX Multi-Windowing Treeview / Drag&Drop Texteditor Dokumenten-Generierung Dokumenten-Bearbeitung Integration (Aufruf Maske von extern)
Live-Demo Technik Masken-Erstellung UI-Strukturierung Client-Logic-API Integration Backend
Fragen / Diskussion
Kontakt
AKIOMA Consultingwerk
www.akioma.com www.consultingwerk.com
YouTube:
https://www.youtube.co
m/channel/UCD01t63ih5z
xyn2jjkh0-6gSie können auch lesen
