Slide 1
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 2
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 3
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 4
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 5
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 6
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 7
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 8
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 9
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 10
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 11
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 12
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 13
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 14
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 15
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 16
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 17
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 18
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19
Slide 19
Entwicklung xdPPS
Holger Looks
cimdata software AG
Gründung: 1983 in Mittelfranken
Standort: Gunzenhausen (50 km südlich von Nürnberg)
24 Mitarbeiter, davon 10 Vollzeit OpenRoad Programmierer
Produkt xdPPS – ERP System für die mittelständische Fertigungsindustrie
xdPPS ist komplett mit OpenRoad programmiert
Fertigungsformeln OR Scripte
Seite 2
Historie xdPPS
/36
1983
AS/400
1989
RPG
Unix - AIX
1993
Ingres ABF
Windows I
1995
OpenRoad 3.0
Windows II
1999
OpenRoad 3.5/4.0/4.1
Windows III
2010
OpenRoad 5
Seite 3
Architektur (funktional) xdPPS
Reporting
Oberfläche
Workflow
Import
Export
Erweiterung Verteilung
CRM/Vertrieb
Fertigung
Beschaffung
Qualität
...
Modularität
Flexibilität
Seite 4
Architektur (technisch) xdPPS
Clients
HTML
Browser
Java
Applet
Desktop
Wireless
JavaScript
VBScript
mClient
Mobile
Phone
Client
Java
Client
C++ / C#
Client
VB / VBA
Client
xdPPS
Application Services
Tomcat
4GL
JSP
xdPPS
Business Object Services
IIS
4GL
xdPPS
Data Access Services
C#
ASP
ASP.Ne
t
.Net Framework
J2EE Framework
Server
4GL
Ingres/Net
Ingres
Database
Enterprise Access
Oracle
SQL
Server
Seite 5
Entwicklung xdPPS V3
Beginn der Entwicklung in 2008
2010 erste Ablösungen der Vorgängerversion
Ziele der Neuentwicklung
Neues Design der Oberfläche
Neue Funktionalitäten um die Flexibilität der Anwendung zu erweitern
Beibehaltung Datenbankdesign (geringe Migrationskosten)
Umfang
ca. 6.300 Masken
ca. 2.800 Prozeduren
ca. 4.500 Userclasses
Seite 6
Neues Design der Oberfläche
Definition von Frame Templates
Definition von Field Templates
Definition von Grundoperationen
(Speichern/Neuanlage/Änderung/Aktualisieren/Export/Druck/…)
Seite 7
Frame Templates
Definition von Frame Templates
Jeder Maskengrundtyp hat ein eigenes OpenRoad Frame Template
(Verwaltungsmaske/Übersichtsmaske mit Tabelle/Druckprogramm/…
Jedes Template definiert die Oberflächenelemente und das Sourcecode Gerüst
(Userclasses, Events, Functions)
Alle Grundoperationen sind als Funktionspointer angelegt und werden (wenn
notwendig) lokal überschrieben
Seite 8
Field Templates
Definition von Field Templates
Nutzung für Standardfelder (z.B. Matchcodefelder, Feldstrukturen)
Seite 9
Definition von Grundoperationen
// Zentrale Definition
und Menüpunkteissind
zentral
ifButtons
CurObject.phCloseFrame
not null
then jeweils mit einem Funktionspointer versehen
Der Funktionspointer
kann dann lokal überschrieben werden.
CurObject.phCloseFrame.Call();
endif;
// Lokale Überschreibung
procedure InitFrame(
)=
declare
iMode = integer not null with default,
enddeclare
begin
FramePilot.phSaveFrameAndGo = CurFrame.Scope.GetProcHandle('saveFrameAndGo');
FramePilot.phCloseFrame
= CurFrame.Scope.GetProcHandle('closeFrame');
end
Seite 10
Neue Funktionen
Ziel der neuen Funktionen:
Endanwender soll xdPPS an kundenspezifische Anforderungen anpassen können
Maskengestaltung (Feldpositionen/Farben/Pflichtfelder)
Dynamische Erweiterung Datenmodell
Scripting
Workflow
Realisierung durch dynamische OpenRoad Scripte
Seite 11
Feldpositionen
Feldpositionen – Nutzung User3Bias (generell auf FB_MOVEABLE)
mit einer Aktion wird das Frame in den User3Bias geschaltet
Anwender kann Felder neu positionieren und die Positionen abspeichern
Vereinfachung von Masken
Seite 12
Feldfarben
Feldattribute (BgColor/FgColor) können benutzerspezifisch geändert und
gespeichert werden
Seite 13
Dynamische Erweiterung Datenmodell
Der Endanwender kann in xdPPS in der Anwendung das Datenmodell erweitern.
Die Änderung ist releasesicher.
Seite 14
Scripting
Der Endanwender kann in xdPPS mit Hilfe von Scripten das Verhalten von
Anwendungen ändern.
Scripte können auf Masken- bzw. Feldebene definiert werden.
xdPPS nutzt hier dynamische OpenRoad Prozeduren.
Seite 15
Workflow
xdPPS besitzt hunderte von Ereignissen (z.B. Kunde wird angelegt)
Jedes Ereignis kann jetzt einen Workflow starten, der verschiedene Aktionen
durchführen kann.
Mögliche Aktionen:
Benachrichtigungen
Start von Programmen/Auswertungen
Ausführung von xdPPS Aktionen
Seite 16
Vorteile OpenRoad
direkte Unterstützung von SQL im Sourcecode
schnelle und konsistente Anwendungsentwicklung durch Templates
eine Vielzahl von OpenRoad Systemklassen stehen für die Programmierung zur
Verfügung
dynamische Programmierung (Makros für Endanwender/dynamische Masken) ist
möglich
große Softwareentwicklungen sind möglich
Seite 17
Wünsche an OpenRoad
Unterstützung Bigint für Maskenfelder
In OpenRoad 6 als Variable bereits definierbar; aber Maskenfelder sind nicht
als Bigint definierbar
Pixelgenaues Resize für Tabellen
Derzeit nur ein eingeschränktes Resizing möglich (Anzahl Spalten und in einer
Spalte Anzahl Zeichen)
Bessere Unterstützung ActiveX Controls
Derzeit muss sehr oft ein Wrapper um das Control gebaut werden, da
OpenRoad nicht alle Attribute/Methoden nutzen kann.
Seite 18
Kontakt
cimdata software AG
Industriestr. 25
91710 Gunzenhausen
www.cimdata-sw.de
Seite 19