Entwicklung der ERP-Software xdPPS mit OpenROAD

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