Entwicklung der ERP-Software xdPPS mit OpenROAD

Werbung
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


Herunterladen