Execution Server Benutzerhandbuch

Execution Server Benutzerhandbuch

Visual Rules Suite - Execution Platform

Execution Server Benutzerhandbuch

Version 6.1.2

Bosch Software Innovations

Americas:

Bosch Software Innovations Corp.

161 N. Clark Street

Suite 3500

Chicago, Illinois 60601/USA

Tel. +1 312 368-2500 [email protected]

www.bosch-si.com

Asia:

Bosch Software Innovations c/o Robert Bosch (SEA) Pte Ltd

11 Bishan Street 21

Singapore 573943

Tel. +65 6571 2220 [email protected]

www.bosch-si.com

Europe:

Bosch Software Innovations GmbH

Schöneberger Ufer 89-91

10785 Berlin / GERMANY

Tel. +49 30 726112-0

Fax +49 30 726112-100 [email protected]

www.bosch-si.de

Execution Server Benutzerhandbuch: Version 6.1.2

Visual Rules Execution Server 6.1.2

Copyright © 2013 Bosch Software Innovations GmbH

© Bosch Software Innovations GmbH, 2013. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch die Bosch Software Innovations GmbH nicht gestattet. MLDS, Visual Rules und Work Frame Relations sind eingetragene

Marken der Bosch Software Innovations GmbH. BOSCH und die Bildmarke sind registrierte Marken der Robert Bosch

GmbH, Deutschland. Verwendete Produkt- und Firmenbezeichnungen sind eingetragene Marken und - unabhängig von ihrer

Kennzeichnung - Eigentum ihrer jeweiligen Inhaber.

Execution Server Benutzerhandbuch

Inhaltsverzeichnis

1. Einleitung ................................................................................................................................... 1

1.1. Anwendungsbereich .................................................................................................................. 1

1.2. Identity Management ................................................................................................................. 1

1.3. Berechtigungs-Konzept .............................................................................................................. 2

1.3.1. Execution-Server-Berechtigungen .............................................................................................. 2

1.3.1.1. Standard-Berechtigungspaket ................................................................................................. 3

1.3.2. Execution-Server-Benutzerrollen ................................................................................................ 3

1.3.2.1. Administrator ....................................................................................................................... 3

1.3.2.2. Deployer ............................................................................................................................ 3

1.3.2.3. ACL Manager ...................................................................................................................... 4

1.3.2.4. Benutzer ............................................................................................................................ 4

1.3.3. Execution-Server-Zugriffsrechte ................................................................................................. 4

1.4. Mandantenfähigkeit und Konzept der Datentrennung ....................................................................... 5

1.4.1. Mandantenfähigkeit ................................................................................................................. 5

1.4.2. Konzept der Datentrennung ...................................................................................................... 5

1.4.2.1. Trennung der Mandantendaten ............................................................................................... 5

1.4.2.2. Trennung der Anwendungsdaten ............................................................................................. 6

1.4.2.3. Notwendigkeit und Vorteile der Datentrennung ........................................................................... 6

1.4.3. Mandantenbeziehungen und Angebote ....................................................................................... 7

1.4.3.1. Mandantenbeziehung ............................................................................................................ 7

1.4.3.2. Angebot ............................................................................................................................. 7

1.5. Audit-Protokoll .......................................................................................................................... 9

1.6. Distribution .............................................................................................................................. 9

1.6.1. Maintenance Tool ................................................................................................................. 10

2. Aufsetzen des Execution Servers .................................................................................................. 11

2.1. Vorbereiten der Datenbankumgebung ......................................................................................... 11

2.1.1. Automatischer Modus ............................................................................................................ 11

2.1.1.1. Beispiel: Oracle Datenbank .................................................................................................. 11

2.1.2. Manueller Modus .................................................................................................................. 12

2.1.2.1. Beispiel: Oracle Datenbank .................................................................................................. 13

2.2. Vorbereiten des Web Servers .................................................................................................... 13

2.2.1. Vorbereiten eines Tomcat Application Servers ............................................................................ 13

2.2.2. Vorbereiten eines WebSphere Application Servers ...................................................................... 13

2.2.3. Vorbereiten eines JBoss Application Servers .............................................................................. 13

2.3. Deployment des Execution Servers ............................................................................................ 14

2.3.1. Spezifische Prozedur für Deployment auf WebSphere .................................................................. 14

2.3.2. Spezifische Prozedur für Deployment auf JBoss ......................................................................... 14

2.4. Installation des Execution Servers .............................................................................................. 15

2.4.1. Installieren des Execution Server mit dem Installationsassistenten .................................................. 15

© Bosch Software Innovations iii/71

Execution Server Benutzerhandbuch

2.4.2. Installieren des Execution Servers mit dem Maintenance Tool ....................................................... 17

2.4.2.1. Schritte zum Anlegen der Datenbanktabellen und Schemas mit dem Maintenance Tool .................... 17

2.4.2.2. Ausgeben von SQL Befehlen ................................................................................................ 19

2.4.2.3. Ausführung von SQL Befehlen .............................................................................................. 19

2.4.2.4. Verwendung von Properties anstatt von Kommandozeilenargumenten .......................................... 19

2.4.2.5. Berechtigung auf Datenbankschemas vergeben ....................................................................... 20

2.4.2.6. Registrierung der Applikation in Identity Management ................................................................ 20

2.5. Installation der Lizenz .............................................................................................................. 21

2.6. Konfiguration des Execution Servers ........................................................................................... 22

2.6.1. Execution Server Home ......................................................................................................... 22

2.6.2. Execution Server Konfiguration ................................................................................................ 22

2.6.3. Laufzeitprotokollierung ........................................................................................................... 23

3. Aktualisierung einer bestehenden Version ...................................................................................... 25

3.1. Migrieren von der Version 6.0 .................................................................................................... 25

3.2. Migrieren von Databank Schemas und Daten ............................................................................... 26

3.3. Aktualisieren von Berechtigungen, Rollen und Angeboten in Identity Management ................................ 26

4. Erstellung und Bereitstellung von Rule Services .............................................................................. 28

4.1. Konzepte ............................................................................................................................... 28

4.1.1. Rule Service ........................................................................................................................ 28

4.1.2. Regelbibliothek ..................................................................................................................... 28

4.1.3. Versionen von Regelbibliothek und Rule Service ......................................................................... 29

4.1.4. Visual Rules Archiv ............................................................................................................... 30

4.1.5. Rule Service Einstellungen ..................................................................................................... 30

4.1.5.1. Aktiv ................................................................................................................................ 30

4.1.5.2. Gültig von und Gültig bis ..................................................................................................... 30

4.1.5.3. Name der aktiven Konfiguration (Active Configuration Name) ...................................................... 30

4.1.5.4. Statistiklevel ...................................................................................................................... 31

4.2. Arbeitsschritte ......................................................................................................................... 31

4.2.1. Regeln festlegen, die als Rule Service exportiert werden sollen ..................................................... 31

4.2.2. XML Namespace für Rule Services definieren ............................................................................ 32

4.2.3. Einstellen von Aktionen als Rückgabewert ................................................................................. 32

4.2.4. Bereitstellen von Regelprojekten vom Visual Rules Modeler .......................................................... 33

5. Arbeiten mit der Webkonsole ....................................................................................................... 35

5.1. Aufruf der Webkonsole ............................................................................................................. 35

5.1.1. Einstellung einer bestimmten Sprache ...................................................................................... 35

5.2. Verwaltung bereitgestellter Rule Services ..................................................................................... 35

5.2.1. Anzeige bereitgestellter Rule Services ...................................................................................... 36

5.2.2. Filterung angezeigter Rule Services ......................................................................................... 37

5.2.3. Hinzufügen eines Rule Service mittels Visual Rules Archiv ............................................................ 37

5.2.4. Löschen eines bereitgestellten Rule Service .............................................................................. 38

5.2.5. Anzeige der WSDL-Datei eines Rule Service ............................................................................. 39

© Bosch Software Innovations iv/71

Execution Server Benutzerhandbuch

5.2.6. Herunterladen eines Rule Service ............................................................................................ 39

5.2.7. Anzeige der Eigenschaften und Änderung der Einstellungen eines Rule Service ................................ 39

5.2.8. Verwaltung der Metadaten eines Rule Service ............................................................................ 41

5.2.8.1. Hinzufügen von Metadaten ................................................................................................... 41

5.2.8.2. Löschen von Metadaten ...................................................................................................... 41

5.2.8.3. Editieren von Metadatennamen und –werten ........................................................................... 42

5.2.9. Anzeige der Ausführungen eines Rule Service ........................................................................... 42

5.2.10. Anzeige der erforderlichen Bibliotheken eines Rule Service ......................................................... 42

5.2.11. Verwalten von Zugriffsrechten für einen Rule Service ................................................................. 42

5.3. Verwaltung der Ausführungen von Rule Services ........................................................................... 43

5.3.1. Anzeige der Ausführungen von Rule Services ............................................................................ 43

5.3.2. Filterung angezeigter Ausführungen ......................................................................................... 44

5.3.3. Löschen von Ausführungen von Rule Services ........................................................................... 45

5.3.4. Herunterladen einer Statistik zur Ausführung eines Rule Service .................................................... 45

5.4. Verwaltung bereitgestellter Bibliotheken ....................................................................................... 45

5.4.1. Anzeige bereitgestellter Bibliotheken ......................................................................................... 46

5.4.2. Filterung angezeigter Bibliotheken ............................................................................................ 46

5.4.3. Anzeige von Eigenschaften und Verwendung einer Bibliothek ........................................................ 47

5.4.4. Löschen einer bereitgestellten Bibliothek ................................................................................... 48

5.5. Wartung des Execution Servers ................................................................................................. 48

5.5.1. Lizenzen verwalten ............................................................................................................... 48

5.5.1.1. Lizenz hinzufügen .............................................................................................................. 48

5.5.1.2. Lizenz löschen ................................................................................................................... 49

5.5.2. Konfiguration und Anzeige von Nachrichten der Laufzeitprotokollierung ........................................... 49

5.6. Konfiguration der Anzeige von Tabelleninhalten ............................................................................ 49

5.6.1. Ein- und Ausblenden von Spalten ............................................................................................ 50

5.6.2. Verschieben einer Spalte ....................................................................................................... 50

5.6.3. Verändern des Sortierkriteriums und der Sortierreihenfolge ........................................................... 50

5.7. Filterung angezeigter Objekte .................................................................................................... 50

5.7.1. Eingabe von Filterkriterien ...................................................................................................... 50

5.7.1.1. Eingabe von Datum und Uhrzeit ............................................................................................ 51

5.7.2. Anwenden eines Filters .......................................................................................................... 51

6. Aufrufen von Regeln im Execution Server ...................................................................................... 52

6.1. Konzepte ............................................................................................................................... 52

6.1.1. Authentifizierung für eine Rule Service Anfrage .......................................................................... 52

6.1.2. Format der Rule Service Anfrage ............................................................................................. 52

6.1.3. Format der Rule Service Antwort ............................................................................................. 54

6.1.4. Generische Rule Service Anfragen ........................................................................................... 54

6.1.4.1. Generisches VRRequest Format ........................................................................................... 54

6.1.5. XML Repräsentation von Datentypen ........................................................................................ 55

6.1.5.1. Einfache Typen .................................................................................................................. 55

© Bosch Software Innovations v/71

Execution Server Benutzerhandbuch

6.1.5.2. Strukturen ......................................................................................................................... 57

6.1.5.3. Listen und Mengen ............................................................................................................. 57

6.1.5.4. Maps ............................................................................................................................... 57

6.1.5.5. Aufzählungen ..................................................................................................................... 58

6.1.6. Abbildung des Regelmodells auf WSDL .................................................................................... 58

6.2. Arbeitsschritte ......................................................................................................................... 59

6.2.1. Aufrufen eines Rule Service .................................................................................................... 59

7. Verwendung der RESTful Web Services ........................................................................................ 61

7.1. Über REST ............................................................................................................................ 61

7.2. Authentifizierung ...................................................................................................................... 61

7.3. Format der Rückgabe .............................................................................................................. 61

7.3.1. Atom Syndication Format ....................................................................................................... 61

7.3.1.1. Atom Feed Document ......................................................................................................... 62

7.3.1.2. Atom Entry Document ......................................................................................................... 62

8. Arbeiten mit Metadaten ............................................................................................................... 64

8.1. Konzept Metadaten .................................................................................................................. 64

8.2. Metadaten definieren ............................................................................................................... 64

8.2.1. Zuordnung von Metadaten zu Rule Services .............................................................................. 65

8.2.1.1. Standard-Metadata Mapper .................................................................................................. 65

8.2.1.2. Eine WSDL durch Angabe von Metadata abholen ..................................................................... 66

8.2.1.3. Benutzerdefinierter Metadata Mapper ..................................................................................... 66

A. Rule Service Klassenlader and -Hierarchie ..................................................................................... 70

A.1. Rule Service Klassenlader ........................................................................................................ 70

A.2. Klassenlader Hierarchie ........................................................................................................... 70

© Bosch Software Innovations vi/71

Kapitel 1. Einleitung

Kapitel 1. Einleitung

1.1. Anwendungsbereich

Der Visual Rules Execution Server ist eine Web-Anwendung, die es ermöglicht, mehrere Versionen von Regeln zu verwalten und diese als Web-Services auszuführen. Darüberhinaus erlaubt er das Austauschen und Deployen von

Regeln zur Laufzeit und sammelt Statistiken zu den ausgeführten Regeln.

Abbildung 1.1. Überblick Execution Server 6

Der erste Schritt um Regeln als Web-Service auszuführen ist, diese zu bauen und als Regelbibliothek

zu paketieren. Danach können diese Bibliotheken auf dem Visual Rules Execution Server bereitgestellt werden. Dies kann entweder mit dem

Visual Rules Modeler

, der Team Platform oder dem Builder erreicht werden, die alle eine entsprechende Integration bereitstellen.

Regelbibliotheken werden mit der

Webkonsole verwaltet. Diese ist eine Web-Oberfläche, auf die Benutzer mit

Standard-Webbrowsern zugreifen können. Wurde eine Regelbibliothek und ihre Abhängigkeiten bereitgestellt, so wird daraus ein sogenannter Rule Service erzeugt, welcher als

Web-Service mittels Standard Web Service Clients

aufgerufen werden kann. Jede Ausführung eines Rule Service kann eine Statistik erzeugen, welche im Visual

Rules Modeler angezeigt werden kann. Zur Persistierung von Statistiken und Bibliotheken wird ein relationales

Datenbankverwaltungssystem (RDBMS) verwendet.

Während all dieser Schritte ist eine Authentifizierung notwendig und Zugriffe sind durch

Berechtigungen

eingeschränkt, welche vom Identity Management

verwaltet werden.

Bei alledem unterstützt der Execution Server Mandantenfähigkeit .

1.2. Identity Management

Das Identity Management (IM) ist eine Benutzerverwaltungskomponente. Ihre Bedienoberflächen können von anderen Systemen verwendet werden, um ihre Benutzer zu identifizieren und zu authorisieren. Der wesentliche

Anwendungsbereich des IM in einer Kundenanwendung besteht in der Verwaltung von Berechtigungen.

© Bosch Software Innovations 1/71

Kapitel 1. Einleitung

Sie können das Identity Management in der Webkonsole über den Tab Benutzerverwaltung erreichen, wenn nötig. Weitere Informationen zum Identity Management finden Sie in der zugehörigen Dokumentation.

1.3. Berechtigungs-Konzept

Das Berechtigungs-Konzept des Visual Rules Execution Server basiert auf den folgenden Konzepten:

Abschnitt 1.3.1, „Execution-Server-Berechtigungen“

Abschnitt 1.3.2, „Execution-Server-Benutzerrollen“

Abschnitt 1.3.3, „Execution-Server-Zugriffsrechte“

Die tatsächlichen Rechte eines Benutzers/Teams ergeben sich aus deren Kombination.

Ein Team kann weitere Teams enthalten. Generell sind alle Berechtigungen, die einem Team zugewiesen sind, automatisch auch jedem Benutzer/Team innerhalb des Teams zugewiesen.

1.3.1. Execution-Server-Berechtigungen

Execution-Server-Berechtigungen sind Berechtigungen, die im Identity Management mit Bezug auf den Visual

Rules Execution Server definiert sind. Dabei repräsentiert jede Berechtigung bestimmte Arten von Aktionen.

Die folgenden Execution-Server-Berechtigungen werden unterschieden:

Tabelle 1.1. Übersicht der Execution-Server-Berechtigungen

Berechtigung

Zugriff auf die Applikationsinstanz

Visual Rules Archiv bereitstellen

(Regel-)Bibliothek bereitstellen

(Regel-)Bibliothek löschen

Log-Informationen anzeigen/herunterladen

Logging konfigurieren

Lizenzen hinzufügen/löschen

Applikationskonfiguration anzeigen

Beschreibung

Berechtigung zum Zugriff auf die Applikationsinstanz

Berechtigung zum Bereitstellen eines Rule Service und aller erforderlichen Bibliotheken mittels Visual Rules

Archiv

Berechtigung zum Bereitstellen eines Rule Service mittels Regelbibliothek oder einer Bibliothek

Berechtigung zum Löschen eines bereitgestellten Rule

Service oder einer Bibliothek

Berechtigung zum Anzeigen/Herunterladen von Log-

Informationen

Berechtigung zum Ändern des Detaillierungsgrads des

Logging

Berechtigung zum Hinzufügen/Löschen von Lizenzen

Berechtigung zum Anzeigen der

Applikationskonfiguration

Berechtigung zum Verwalten von Zugriffsrechten Zugriffsrechte verwalten

Benutzer brauchen zumindest die Zugriff auf die Applikationsinstanz Berechtigung um mit dem Execution Server arbeiten zu können. Zusätzlich sollten Benutzer die Berechtigungen

Benutzer abfragen

und Gruppen abfragen vom Identity Management haben.

© Bosch Software Innovations 2/71

Kapitel 1. Einleitung

1.3.1.1. Standard-Berechtigungspaket

Das Standard-Berechtigungspaket ist eine sinnvolle Gruppierung von Berechtigungen und Benutzerrollen für ein

Angebot im Anwendungsbereich des Empfängers im Identity Management. Es enthält die folgenden Execution

Server-Berechtigungen:

• Visual Rules Archiv bereitstellen

• (Regel-)Bibliothek bereitstellen

• (Regel-)Bibliothek löschen

• Zugriffsrechte verwalten

• Zugriff auf die Applikationsinstanz

Die folgenden Execution-Server-Benutzerrollen sind enthalten:

Abschnitt 1.3.2.2, „Deployer“

Abschnitt 1.3.2.3, „ACL Manager“

Abschnitt 1.3.2.4, „Benutzer“

1.3.2. Execution-Server-Benutzerrollen

Execution-Server-Benutzerrollen sind Benutzerrollen, die im Identity Management mit Bezug auf den Visual

Rules Execution Server definiert sind. Dabei repräsentiert jede Benutzerrolle einen virtuellen Benutzer, der befugt ist, bestimmte Aufgaben auszuführen (d.h. dem die entsprechenden Execution-Server-Berechtigungen standardmäßig per Definition zugewiesen sind).

Standardmäßig werden die folgenden Execution-Server-Benutzerrollen bereitgestellt:

Abschnitt 1.3.2.1, „Administrator“

Abschnitt 1.3.2.2, „Deployer“

Abschnitt 1.3.2.3, „ACL Manager“

Abschnitt 1.3.2.4, „Benutzer“

Weitere Execution-Server-Benutzerrollen können im Identity Management definiert werden.

Standardmäßig beinhaltet jede Execution-Server-Benutzerrolle die Berechtigungen Benutzer

abfragen und Gruppen abfragen, die im Identity Management allgemein definiert sind. Diese

Berechtigungen sind die Mindestvoraussetzung, um mit dem Execution Server zu arbeiten.

1.3.2.1. Administrator

Die Benutzerrolle Administrator repräsentiert einen Administrator. Ihm sind standardmäßig alle Execution-Server-

Berechtigungen zugewiesen.

1.3.2.2. Deployer

Die Benutzerrolle Deployer repräsentiert einen Benutzer mit allen relevanten Execution-Server-Berechtigungen zum Bereitstellen von Rule Services und Bibliotheken. Dies sind die Folgenden:

• Visual Rules Archiv bereitstellen

• (Regel-)Bibliothek bereitstellen

• (Regel-)Bibliothek löschen

© Bosch Software Innovations 3/71

Kapitel 1. Einleitung

1.3.2.3. ACL Manager

Die Benutzerrolle ACL Manager repräsentiert einen Benutzer mit allen relevanten Berechtigungen zum Verwalten

von Execution-Server-Zugriffsrechten

. Die Rolle besteht aus folgenden Berechtigungen:

• Zugriffsrechte verwalten

1.3.2.4. Benutzer

Die Benutzerrolle Benutzer repräsentiert einen Benutzer mit allen relevanten Berechtigungen zum Ausführen von freigegebenen Services. Die Rolle besteht aus folgenden Berechtigungen:

• Zugriff auf die Applikationsinstanz

1.3.3. Execution-Server-Zugriffsrechte

Während Berechtigungen und

Rollen bestimmte Arten von Aktionen auf dem Execution Server erlauben, sind

Zugriffsrechte kontextsensitiv in Bezug auf

Rule Services . D.h. sie beschränken den Zugriff auf einen bestimmten

Rule Service für einen Benutzer, ein Team oder einen Mandanten. Im Gegensatz zu

Berechtigungen

und Rollen

werden Zugriffsrechte nicht über das Identity Management

verwaltet, da dieses keine Rule Services kennt.

Zugriffsrechte werden daher direkt in der Webkonsole des Execution Servers verwaltet.

Die folgenden Zugriffsrechte existieren:

Tabelle 1.2. Übersicht der Execution-Server-Zugriffsrechte

ANZEIGEN

AKTUALISIEREN

AUSFÜHREN

HERUNTERLADEN

Zugriffsrecht Beschreibung

Erlaubt es, einen Rule Service inklusive Metadaten und Ausführungen zu sehen. Alle folgenden Rechte enthalten dieses Recht implizit.

Erlaubt es, Metadaten für einen Rule Service zu editieren oder Ausführungen zu löschen.

Erlaubt es, einen Rule Service auszuführen.

Erlaubt das Herunterladen einer Visual Rules Archiv

Datei, welche die

Regelbibliothek des Rule Service

und alle abhängigen Bibliotheken enthält. Ebenso wird

das Herunterladen von Statistiken hiermit erlaubt.

Um Zugriffsrechte verwalten zu können, erhalten ACL Manager das ANZEIGEN-Recht für alle Rule

Services.

Wie bereits erwähnt, können Zugriffsrechte für Benutzer, Teams und Mandanten vergeben werden. Die

tatsächlichen Zugriffsrechte eines Benutzers ergeben sich daher aus einer Kombination dieser Rechte. Hierfür relevant sind nur die Rechte des Benutzers, die Rechte aller Teams, zu welchen der Benutzer gehört, und die

Rechte des Mandanten des Benutzers.

Die Berechnung der tatsächlichen Zugriffsrechte erfolgt in zwei Schritten. Zuerst werden die Rechte des

Benutzers und die der Teams vereint. Das erhaltene Resultat wird anschließend mit den Rechten des Mandanten abgeglichen. D.h. die Zugriffsrechte für den Mandanten können die tatsächlichen Zugriffsrechte einschränken.

Als Beispiel seien die folgenden Entitäten mit ihren Zugriffsrechten auf einen bestimmten Rule Service gegeben:

• Benutzer [ANZEIGEN, AKTUALISIEREN]

• Team [ANZEIGEN, AUSFÜHREN]

• Mandant [ANZEIGEN, HERUNTERLADEN]

© Bosch Software Innovations 4/71

Kapitel 1. Einleitung

Die Kombination aus den Zugriffsrechten für Benutzer und Team ergeben [ANZEIGEN, AKTUALISIEREN,

AUSFÜHREN]. Dennoch wird das tatsächliche Zugriffsrecht für den Benutzer auf [ANZEIGEN] reduziert. Dies geschieht wegen den einschränkenden Zugriffsrechten des Mandanten, welche weder AKTUALISIEREN noch

AUSFÜHREN enthalten.

Bitte beachten Sie, dass Zugriffsrechte für Mandanten nur im Fall von

Mandantenbeziehungen

berücksichtigt werden. D.h. wenn ein empfangender Mandant auf die Daten eines anbietenden

Mandanten zugreifen will, muss der anbietende Mandant erst die entsprechenden Zugriffsrechte für den empfangenden Mandanten setzen. Während der empfangende Mandant nun die Zugriffsrechte für seine Benutzer und Teams verwalten kann, kann der anbietende Mandant immer noch die

tatsächlichen Zugriffsrechte einschränken.

1.4. Mandantenfähigkeit und Konzept der Datentrennung

1.4.1. Mandantenfähigkeit

Die Mandantenfähigkeit erlaubt die Nutzung einer einzelnen Execution Server Instanz und zugehöriger Datenbank durch mehrere Mandanten. Der Execution Server stellt sicher, dass die Daten eines jeden Mandanten nur durch die Benutzer des besitzenden Mandanten zugreifbar sind. Im Gegensatz zu dem Ansatz, jedem Mandanten eine eigene Instanz zur Verfügung zu stellen, ermöglicht Mandantenfähigkeit einen effizienteren Umgang mit

Ressourcen wie z.B. Hardware- oder Virtualisierungsinfrastrukturen und Lizenzen.

1.4.2. Konzept der Datentrennung

Das Konzept der Datentrennung des Visual Rules Execution Server beinhaltet folgende Aspekte:

Abschnitt 1.4.2.1, „Trennung der Mandantendaten“

Abschnitt 1.4.2.2, „Trennung der Anwendungsdaten“

Zu den Gründen für die Datentrennung siehe

Abschnitt 1.4.2.3, „Notwendigkeit und Vorteile der

Datentrennung“

.

1.4.2.1. Trennung der Mandantendaten

Da der Execution Server Mandantenfähigkeit unterstützt, muss sichergestellt sein, dass die Daten der Mandanten

(z.B. Bibliotheken, Ausführungen, usw.) getrennt abgelegt werden. Dazu braucht jeder Mandant einen eigenen

"privaten" Bereich für seine Daten. Dies wird erreicht, indem für jeden Mandanten ein eigenes Datenbankschema verwendet wird. Darüberhinaus wird ein zusätzliches Datenbankschema benötigt, um globale (d.h. nicht mandantenspezifische) Information zu speichern, so wie das Mapping zwischen den Mandanten und den ihnen zugewiesenen Datenbankschemata.

© Bosch Software Innovations 5/71

Kapitel 1. Einleitung

1.4.2.2. Trennung der Anwendungsdaten

Im Gegensatz zum herkömmlichen Ansatz, für jede Anwendung ein eigenes Datenbankschema zu verwenden, verwendet der Visual Rules Execution Server für jeden Mandanten ein eigenes Datenbankschema. Der Grund hierfür liegt in der Tatsache, dass die Trennung der Mandantendaten erste Priorität hat. Anwendungen trennen ihre Daten durch die Verwendung einer Art von Namensraum. Ein eigener Namensraum für jede Anwendung ermöglicht die gemeinsame Verwendung eines Mandantenschemas durch verschiedene Anwendungen. So wird sichergestellt, dass eine Anwendung nicht die Daten anderer Anwendungen beeinflußt (nicht einmal, wenn diese vom gleichen Typ sind, wie z.B. zwei verschiedene Instanzen des Execution Servers). Die sogenannten

Namensräume sind lediglich Präfixe, welche den Namen der Datenbankobjekte einer Anwendung vorangestellt sind. Das folgende Beispiel zeigt dies für die Verwendung der Tabelle EP_VERSION.

Tabelle 1.3. Trennung der Anwendungsdaten

Applikationsname

Execution Server 1

Execution Server 2

Namensraum (Präfix)

ES1

ES2

DB-Objektname

EP_VERSION

EP_VERSION

Präfix+'_'+DB-

Objektname

ES1_EP_VERSION

ES2_EP_VERSION

Dieses Muster wird über alle betroffenen Schemata (globale Verwaltungsschemata und Mandantenschemata) hinweg auf alle Datenbankobjekte angewandt, die spezifisch sind für eine Anwendungsinstanz. Die folgende

Abbildung zeigt, wie die Namensräume eine Art virtueller anwendungsspezifischer Schemata über mehrere tatsächliche Datenbankschemata aufspannen:

1.4.2.3. Notwendigkeit und Vorteile der Datentrennung

Herkömmliche Mandantenfähigkeit setzt voraus, dass die Anwendung die Daten der Mandanten trennt und sicherstellt, dass kein Mandant auf die Daten anderer Mandanten zugreifen kann. Dies kann auf verschiedene

Arten geschehen, z.B. durch eine zusätzliche Spalte in jeder Tabelle, welche die ID des Mandanten enthält. Der

Ansatz der Trennung durch Schemata im Visual Rules Execution Server hat folgende Vorteile:

• Mandantendaten können physikalisch getrennt gespeichert werden, indem verschiedene Tablespaces verwendet werden.

• Ressourcen können effizient genutzt werden, da mehrere Anwendungen der gleichen Art in einem einzelnen

Mandantenschema installiert sein können.

• Eine Schema-Migration ist für eine bestimmte Anwendung eines bestimmten Mandanten möglich (z.B. während einer Aktualisierung der Anwendung).

• Die Datenzusammensetzung eines einzelnen Mandanten betrifft nicht notwendigerweise andere Mandanten.

© Bosch Software Innovations 6/71

Kapitel 1. Einleitung

1.4.3. Mandantenbeziehungen und Angebote

Das Konzept der

Datentrennung

stellt sicher, dass die Daten von Mandaten strikt getrennt sind. Im Identity

Management trifft dies ebenso auf die Applikation zu. Damit andere Mandanten die Applikation nutzen können, ist eine Art der Zusammenarbeit nötig. In manchen Fällen ist es sogar wünschenswert, auf den gleichen

Daten arbeiten zu können. Um diese Zusammenarbeit zu ermöglichen, wird das grundlegende Konzept um

Mandantenbeziehungen

und

Angebote

erweitert.

Die Konzepte Mandantenbeziehung und Angebot entstammen dem Identity Management. Weitere Informationen hierzu finden Sie im Handbuch des Identity Management.

Die Applikation ist verfügbar für Benutzer des Mandaten, der bei der Installation angegeben wurde. Um sie Benutzern von anderen Mandanten verfügbar zu machen, ist es notwendig, eine

Mandantenbeziehung und ein Angebot

zu erstellen. Geschieht dies im

Anwendungsbereich des

Empfängers

für die Applikation, so eignet sich das Standard-Berechtigungspaket

dafür.

1.4.3.1. Mandantenbeziehung

Mandantenbeziehungen werden zum Ausdrücken und Kontrollieren der Zusammenarbeit zwischen Mandanten im Identity Management verwendet. Der Mandant, der die Beziehung anlegt, wird "Anbieter" oder "anbietender

Mandant" genannt. Der Partner der Beziehung wird dagegen als "Empfänger" oder "empfangender Mandant" bezeichnet. Eine Mandantenbeziehung teilt nicht automatisch eine Applikation, Berechtigungen, Rollen oder

Daten. Dies geschieht erst, wenn der Mandantenbeziehung ein

Angebot

hinzugefügt wird.

1.4.3.2. Angebot

Ein Angebot wird verwendet, um eine oder mehrere Applikationen mit einem empfangenden Mandanten in einer

Mandantenbeziehung zu teilen. Dies wird durch das Hinzufügen von Berechtigungen oder Rollen zu dem Angebot erreicht.

Ein Angebot definiert, auf wessen Daten die Berechtigungen angewendet werden können. Dieser sogenannte

Anwendungsbereich kann entweder der des empfangenden oder anbietenden Mandanten sein. Dies wird durch die Einstellung "Daten des empfangenden Mandanten" beziehungsweise "Daten des anbietenden Mandanten" bestimmt.

Anwendungsbereich des Empfängers.

Der Anwendungsbereich des Empfängers wird verwendet, wenn der Anbieter nur die Applikation mit dem empfangenden Mandanten teilen will. Dies wird für mandantenfähige

Szenarien verwendet, bei denen die strike

Datentrennung beibehalten werden soll.

© Bosch Software Innovations 7/71

Kapitel 1. Einleitung

Abbildung 1.2. Anwendungsbereich des Empfängers

Anwendungsbereich des Anbieters.

Der Anwendungsbereich des Anbieters wird verwendet, wenn der

Anbieter die Applikation und seine Daten mit dem empfangenden Mandanten teilen will. Das ist dafür gedacht, dass es eine enge Beziehung zwischen beiden Mandanten gibt und beide gemeinsam auf den gleichen Daten arbeiten oder der empfangende Mandant die Daten des anbietenden Mandanten verwenden darf. Zu beachten ist in diesem Fall, dass der Anbieter

Zugriffsrechte

für den empfangenden Mandanten vergeben muss.

Abbildung 1.3. Anwendungsbereich des Anbieters

© Bosch Software Innovations 8/71

Kapitel 1. Einleitung

Rollen können Berechtigungen von verschiedenen Applikationen enthalten. Sobald eine Rolle im Anwendungsbereich des Anbieters angeboten wird, werden alle Berechtigungen in diesem

Anwendungsbereich angeboten. Dies kann zu unerwünschten Effekten führen. Zum Beispiel

enthalten die Rollen des Standard-Berechtigungspakets

die Berechtigung "Benutzer abfragen" des

Identity Management, welche es dann dem empfangenden Mandanten erlauben würde, Benutzer des anbietenden Mandanten zu sehen.

1.5. Audit-Protokoll

Der Execution Server schreibt bestimmte Aktionen von Benutzern in ein Audit-Protokoll. Dies ermöglicht es nachzuvollziehen, welche Benutzeraktionen in der Vergangenheit den Zustand der Applikation verändert haben.

Das Audit-Protokoll ist standardmäßig aktiviert. Per Konfiguration des Execution Servers kann dies deaktiviert

werden. Informationen über die aktuelle Konfiguration der Audit-Protokollierung werden beim Start in das

Laufzeitprotokoll des Execution Servers geschrieben.

Die folgenden Aktionen werden protokolliert:

• Bereitstellen von (Regel-) Bibliotheken. Dies trifft auch für das Hochladen von Visual Rules Archiv Dateien zu

• Überschreiben von (Regel-) Bibliotheken

• Bereitgestellte (Regel-) Bibliotheken löschen

• Ändern von Rule Service Einstellungen

• Hinzufügen, Entfernen oder Ändern von Metadaten von Rule Services

• Hinzufügen, Entfernen oder Ändern von Zugriffsrechten

für Benutzer, Teams und Mandanten

• Hochladen einer Lizenzdatei

• Löschen einer Lizenz

• Ändern des Detaillierungsgrades der Laufzeitprotokollierung

• Löschen von Ausführungen

Sofern das Schreiben von Einträgen in das Audit-Protokoll durch Ausnahmen verhindert wird,

werden diese in das Laufzeitprotokoll des Execution Servers geschrieben. Dies dient dazu, die

Informationen zu erhalten. Da die Datei des Laufzeitprotokolls in ihrer Größe beschränkt ist, wird dringend empfohlen, im Fehlerfall schnell zu reagieren, da ansonsten der Verlust dieser

Informationen droht.

1.6. Distribution

Der Visual Rules Execution Server ist als Web Archive (WAR) gepackt und wird als Bestandteil einer Distribution ausgeliefert. Die Distribution ist ein Zip Archiv und enthält folgendes:

Tabelle 1.4. Distributions Inhalt

Ordner

api-source legalnotice maintenance doc

Inhalt

Quellcode des Application Programming Interface

(API). Hilfreich sofern ein

benutzerdefinierter

Metadaten Mapper

für den Execution Server entwickelt wird.

Rechtliche Informationen zu Lizenzen und

Verwendung von Bibliotheken von Drittanbietern

Maintenance Tool

Handbücher

© Bosch Software Innovations 9/71

Kapitel 1. Einleitung

1.6.1. Maintenance Tool

Das Maintenance Tool ist ein Kommandozeilenprogramm für den Visual Rules Execution Server um

Wartungsaufgaben auszuführen. Es kann verwendet werden, um Tabellen in einem leeren Datenbank Schema anzulegen. Es ist Bestandteil der Execution Server Distribution und da es als Zip Archiv paketiert ist, muss es als erstes entpackt werden, damit es verwendet werden kann. Zum Aufruf des Programms dient entweder ein *.cmd

(für Microsoft Windows Betriebssysteme) oder ein *.sh (für *nix Betriebssystem) Skript. Die Verbindung zur

Datenbank verwendet JDBC und benötigt aus diesem Grund den JDBC-Treiber für die Datenbank. Die jar-Datei des Treibers muss dazu nur in das driver Verzeichnis kopiert werden, dass sich im Verzeichnis des entpackten

Archivs befindet.

Das Maintenance Tool wird über die Kommandozeile gestartet und benötigt eine Java Runtime

Environment (JRE) um ausgeführt zu werden. Ein Weg dies zu erreichen ist durch Setzen der

Umgebungsvariable JAVA_HOME und Hinzufügung dieser auf den Pfad des Betriebssystems. Dies ist in der Java Dokumentation beschrieben.

Nach dem Entpacken kann das Programm auf der Kommandozeile ausgeführt werden. Dazu öffnen Sie eine

Kommandozeile und navigieren zu dem Verzeichnis, in dem das Zip Archiv entpackt wurde. Im folgenden Beispiel wird angenommen, dass es sich um das Verzeichnis maintenance in tmp auf einem Microsoft Windows

Betriebssystem handelt:

C:\tmp\maintenance>

Das Verzeichnis ist richtig, wenn sich das Kommandozeilenprogramm ausführen lässt, beispielsweise durch

Eingabe von:

MaintenanceTool

Dieser Aufruf wird alle verfügbaren Kommandozeilen-Optionen mit ihrer Beschreibung und Alternativen ausgeben.

© Bosch Software Innovations 10/71

Kapitel 2. Aufsetzen des Execution Servers

Kapitel 2. Aufsetzen des Execution Servers

Voraussetzungen: Die erforderliche Datenbank sowie das Identity Management sind gestartet.

Das Aufsetzen des Execution Servers umfasst folgende Tätigkeiten:

Abschnitt 2.1, „Vorbereiten der Datenbankumgebung“

Abschnitt 2.2, „Vorbereiten des Web Servers“

Abschnitt 2.3, „Deployment des Execution Servers“

Abschnitt 2.4, „Installation des Execution Servers“

Abschnitt 2.5, „Installation der Lizenz“

Abschnitt 2.6, „Konfiguration des Execution Servers“

2.1. Vorbereiten der Datenbankumgebung

Der Visual Rules Execution Server unterstützt bezüglich der Datenbank im Wesentlichen zwei Betriebsmodi, nämlich einen

automatischen Modus und einen

manuellen Modus . Welcher Betriebsmodus passend ist, hängt

hauptsächlich von Ihren Sicherheitsanforderungen ab.

Im automatischen Modus benötigt der Datenbankbenutzer Berechtigungen, um die Struktur der

Datenbank zu ändern. Der automatische Modus ist nicht für produktive Umgebungen geeignet, ist aber dennoch wertvoll für Evaluationszwecke, da er den Systembetrieb stark vereinfacht. Bei

Verwendung des automatischen Modus wird empfohlen, für die Installation des Execution Server eine separate Datenbankinstanz bereit zu stellen. Bei Verwendung des manuellen Modus müssen die Datenbankschemata für Mandanten manuell aufgesetzt werden. Für Beispiele sehen Sie

Abschnitt 2.1.1.1, „Beispiel: Oracle Datenbank“ und

Abschnitt 2.1.2.1, „Beispiel: Oracle Datenbank“

.

2.1.1. Automatischer Modus

Bei Verwendung des automatischen Modus wird empfohlen, für die Installation des Execution Server eine separate Datenbankinstanz bereit zu stellen.

Im automatischen Modus wird ein Großteil der administrativen Aufgaben vom Execution Server durchgeführt (z.B.

das Erzeugen der Mandantenschemata und Ihre Initialisierung mit Datenbankobjekten wie Tabellen). Um dies tun zu können, muss der Datenbankbenutzer, der vom Execution Server für die Datenbankverbindung verwendet wird, zu folgenden Aktionen berechtigt sein:

• Erzeugen neuer Schemata in der Datenbank

• Initialisieren dieser Schemata mit Tabellen und anderen Datenbankobjekten

• Ausführen regulärer Datenbankoperationen auf diesen Objekten

2.1.1.1. Beispiel: Oracle Datenbank

Wenn der Execution Server im automatischen Modus betrieben werden soll, muss ein Datenbankadministrator die folgenden Statements ausführen, um die Datenbank für die Installation des Execution Server vorzubereiten:

© Bosch Software Innovations 11/71

Kapitel 2. Aufsetzen des Execution Servers

-- Create a database user which the Execution Server uses to connect to the

-- database. This user must have sufficient privileges for regular

-- operation of the Execution Server and additionally to create database schemata

-- for new tenants automatically (the specification of the tablespaces

-- in the example is optional).

create user <username> identified by <password> default tablespace <tablespaceName> temporary tablespace TEMP;

-- grant login privilege so the Execution Server is able to connect to the

-- database grant create session to <username>;

-- grant create user privilege so that the Execution Server is capable to create

-- a database schema for the tenant (the schema is created when a user logs

-- into the Execution Server for a tenant for the first time if no schema

-- exists for the tenant, i.e. a schema named according to the tenants

-- technical name prefixed with 'VRS_') grant create user to <username>;

-- grant create database object privileges in all schemata in the database

-- so that the Execution Server is able to automatically create its database

-- objects in the tenant schemata grant create any table to <username>; grant create any view to <username>; grant create any index to <username>; grant create any sequence to <username>; grant create any trigger to <username>; grant alter any table to <username>; grant alter any index to <username>; grant alter any sequence to <username>; grant alter any trigger to <username>;

-- grant CRUD privileges in all schemata so that the Execution Server is able to

-- perform regular database operations across all tenant schemata grant select any table to <username>; grant insert any table to <username>; grant update any table to <username>; grant delete any table to <username>;

Beispiel 2.1. Automatischer Modus in Oracle Datenbank

2.1.2. Manueller Modus

Bei Verwendung des manuellen Modus müssen die Datenbankschemata für Mandanten manuell aufgesetzt werden. Siehe

Abschnitt 2.4.2.1, „Schritte zum Anlegen der Datenbanktabellen und

Schemas mit dem Maintenance Tool“

.

Der manuelle Betriebsmodus setzt voraus, dass ein Datenbankadministrator den Benutzer, der vom Execution

Server für die Datenbankverbindung verwendet wird, anlegt und konfiguriert.

© Bosch Software Innovations 12/71

Kapitel 2. Aufsetzen des Execution Servers

2.1.2.1. Beispiel: Oracle Datenbank

-- Create a database user which the Execution Server uses to connect to the

-- database. This user only must have sufficient privileges for regular

-- operation of the Execution Server. In this operational mode the database

-- administrator is responsible for the creation of database schemata

-- and their initialization with the Execution Server database tables using

-- a command line based maintenance tool which is provided as part of

-- the Execution Server distribution.

create user <username> identified by <password> default tablespace <tableSpaceName> temporary tablespace <tempTableSpaceName> quota unlimited on <tableSpaceName>;

-- grant login privilege so the Execution Server is able to connect to the

-- database grant create session to <username>;

Beispiel 2.2. Beispiel Oracle Datenbank: Anlegen und Konfigurieren eines Datenbankbenutzers für den manuellen

Modus

2.2. Vorbereiten des Web Servers

Um den Web Server vorzubereiten, fügen Sie die Datenbank als Daten Resource hinzu, die über einen JNDI

Namen erreichbar ist. Der JNDI Name ist abhängig vom Application Server Hersteller, wie im Folgenden beschrieben.

2.2.1. Vorbereiten eines Tomcat Application Servers

Um einen Tomcat Application Server vorzubereiten, konfigurieren Sie die Datenbank als eine JDBC Daten

Resource mit dem JNDI Namen jdbc/executionserverDS.

2.2.2. Vorbereiten eines WebSphere Application Servers

Um einen WebSphere Application Server vorzubereiten, führen Sie folgende Schritte durch:

1.

Konfigurieren Sie die Anmeldedaten für die Datenbank als JAAS J2C Authentication Data Alias.

2.

Konfigurieren sie den für die Datenbank notwendigen herstellerspezifischen JDBC Provider.

3.

Konfigurieren Sie die Datenbank als JDBC Datenquelle. Benutzen Sie hierbei die folgenden Werte:

• Der JNDI Name ist jdbc/executionserverDS.

• In den Sicherheitseinstellungen, spezifizieren Sie den Authentication Alias für container-managed- sowie und component-managed Authentication Alias.

• In den Sicherheitseinstellungen, setzen Sie die Mapping-Konfiguration für den Alias auf

DefaultPrincipalMapping

.

4.

Speichern Sie die Konfigurationsänderungen und starten Sie den WebSphere Server neu um den

Authentication Alias effektiv werden zu lassen.

2.2.3. Vorbereiten eines JBoss Application Servers

Um einen JBoss Application Server vorzubereiten, konfigurieren Sie die Datenbank als eine JDBC Daten

Resource mit dem JNDI Namen java:jboss/jdbc/executionserverDS.

© Bosch Software Innovations 13/71

Kapitel 2. Aufsetzen des Execution Servers

2.3. Deployment des Execution Servers

Der Execution Server wird als gepacktes Web Archiv (WAR) ausgeliefert und kann installiert werden, indem er auf einem Application Server bereitgestellt wird. Die grundsätzliche Vorgehensweise um den Execution Server zu

Deployen ist wie folgt:

1.

Deployen Sie die executionserver.war

2.

Starten Sie den Execution Server.

Nach der Bereitstellung auf dem Application Server sollte probehalber die Webkonsole aufgerufen werden. Dies ist in

Abschnitt 5.1, „Aufruf der Webkonsole“

beschrieben.

Der Deploymentprozess ist abhängig vom Application Server Hersteller. Wenn Sie einen Tomcat Application

Server einsetzen sind ist keine besondere Prozedur notwendig. Die Prozedur für einen WebSphere Application

Server finden Sie unter Abschnitt 2.3.1, „Spezifische Prozedur für Deployment auf WebSphere“

. Wenn Sie einen

JBoss Application Server einsetzen, lesen Sie

Abschnitt 2.3.2, „Spezifische Prozedur für Deployment auf JBoss“

.

2.3.1. Spezifische Prozedur für Deployment auf WebSphere

Wenn Sie einen WebSphere Anwendungsserver benutzen, ist die Prozedur den Execution Server zu Deployen wie folgt:

Der Standard Klassenlader von WebSphere ist nicht geeignet für den Execution Server.

WebSphere kann den vorkonfigurierten JNDI Namen für die Datenbank des Execution Servers nicht auflösen.

1.

Fügen Sie die executionserver.war WAR Datei als neue Enterprise Application hinzu. Mappen Sie den

Context-Root, z.B. auf /executionserver.

2.

Passen sie den Modul Klassenlader des Execution Server wie folgt an:

• Gehen Sie zu Anwendungen > Anwendungstypen > WebSphere-Unternehmensanwendungen und klicken

Sie auf die executionserver_war.

• In der SektionModule, klicken Sie auf Module Verwalten.

• Klicken Sie auf das Modul Visual Rules Execution Server SOA.

• Im Drop-down Menü Reihenfolge der Klassenlader, wählen Sie Mit dem lokalen Klassenlader geladene Klassen zuerst (übergeordneter zuletzt)

.

• Speichern Sie die Konfigurationsänderung.

3.

Um den JNDI Namen für den Execution Server in der Execution Server Propertiesdatei anzupassen, gehen

Sie wie folgt vor:

• Starten Sie die Execution Server Anwendung. Die Execution Server Konfigurationsdatei wird mit initialen

Werten angelegt.

• Stoppen sie die Execution Server Anwendung.

• Die Execution Server Konfigurationsdatei befindet sich im Execution Server Home Verzeichnis (siehe

Abschnitt 2.6.1, „Execution Server Home“ ) unter config/executionserver.properties. Passen Sie

in dieser Datei folgendes Property an: executionserver.jndi.name=jdbc/executionserverDS

4.

Starten Sie den Execution Server.

2.3.2. Spezifische Prozedur für Deployment auf JBoss

Wenn Sie einen JBoss Anwendungsserver benutzen, ist die Prozedur den Execution Server zu Deployen wie folgt:

© Bosch Software Innovations 14/71

Kapitel 2. Aufsetzen des Execution Servers

JBoss kann den vorkonfigurierten JNDI Namen für die Datenbank des Execution Servers nicht auflösen.

1.

Fügen Sie die executionserver.war WAR Datei als neue Enterprise Application hinzu. Mappen Sie den

Context-Root, z.B. auf /executionserver.

2.

Um den JNDI Namen für den Execution Server in der Execution Server Propertiesdatei anzupassen, gehen

Sie wie folgt vor:

• Starten Sie die Execution Server Anwendung. Die Execution Server Konfigurationsdatei wird mit initialen

Werten angelegt.

• Stoppen sie die Execution Server Anwendung.

• Die Execution Server Konfigurationsdatei befindet sich im Execution Server Home Verzeichnis (siehe

Abschnitt 2.6.1, „Execution Server Home“ ) unter config/executionserver.properties. Passen

Sie in dieser Datei folgendes Property an: executionserver.jndi.name=java:jboss/jdbc/ executionserverDS

3.

Starten Sie den Execution Server.

2.4. Installation des Execution Servers

Wenn die benötigte Datenbank, das Identity Management und die Execution Server Anwendung gestartet sind, können Sie den Execution Server installieren. Die Installation des Execution Servers beinhaltet folgende Schritte:

• Die Datenbank aufsetzen.

• Den Execution Server im Identity Management registrieren.

Beide Schritte werden durch den Installations-Wizard unterstützt. Dies ist die empfohlene Vorgehensweise,

welche beschrieben wird in Abschnitt 2.4.1, „Installieren des Execution Server mit dem Installationsassistenten“

.

Wenn Sie die Datenbankoperationen überprüfen und manuell ausführen möchten, benutzen Sie das Maintenance

Tool um die Datenbank anzulegen. Dies ist beschrieben in Abschnitt 2.4.2, „Installieren des Execution Servers mit dem Maintenance Tool“

.

2.4.1. Installieren des Execution Server mit dem Installationsassistenten

Sie können den Visual Rules Execution Server mithilfe des Installationsassistenten installieren.

Beim Installieren des Execution Server mit dem Installationsassistenten werden die wesentlichen

Installationsschritte automatisch durchgeführt.

Sobald der Execution Server bereitgestellt wurde, ist der Installationsassistent im Web Browser erreichbar mit einer Adresse im Format <protocol>://<server>:<port>/<context-name>, z.B. http://localhost: 8080/executionserver-6.x.y.

1.

Öffnen Sie den Installationsassistenten.

2.

Die Seite Identity Management Verbindung öffnet sich:

© Bosch Software Innovations 15/71

Kapitel 2. Aufsetzen des Execution Servers

3.

Geben Sie die URLs vom Backend und der Webkonsole des Identity Management in den entsprechenden

Feldern an.

4.

Geben Sie in den entsprechenden Feldern Benutzernamen, Passwort und Mandant für einen Administrator an, der berechtigt ist, Anwendungen im Identity Management zu installieren.

Die Execution Server Anwendung wird mit dem betreffenden Benutzer im Identity Management registriert.

5.

Klicken Sie auf Vorwärts>>.

6.

Die Seite Datenbankverbindung öffnet sich:

7.

Füllen Sie die folgenden Felder oder ändern Sie ggfs. die Einträge:

• Marke: Hersteller der Datenbank

• Globales Datenbankschema: Name des Datenbankschemas, welches die Datenbanktabellen für die

Schemaverwaltungskomponente, die von allen Visual Rules Suite Anwendungen verwendet wird.

• Benutzerdefinierter Tabellenpräfix: Präfix der Execution Server-spezifischen Datenbanktabellen

8.

Klicken Sie auf Vorwärts>>.

9.

Die Seite Anwendungseinstellungen öffnet sich:

© Bosch Software Innovations 16/71

Kapitel 2. Aufsetzen des Execution Servers

10. Füllen Sie die folgenden Felder oder ändern Sie ggfs. die Einträge:

• Domänenname: Name der Domäne, unter der Ihr Execution Server im Identity Management installiert werden wird

• Anwendungsname: Anwendungsname, mit dem Ihr Execution Server im Identity Management installiert werden wird

• Administrator: Administrator, der berechtigt ist, Anwendungen im Identity Management zu installieren

11. Klicken Sie auf Vorwärts>>.

12. Die Seite Summary öffnet sich:

13. Klicken Sie auf Installation starten.

14. Der Execution Server wird installiert.

2.4.2. Installieren des Execution Servers mit dem Maintenance Tool

2.4.2.1. Schritte zum Anlegen der Datenbanktabellen und Schemas mit dem Maintenance Tool

Es sind mehrere Schritte notwendig, um Tabellen und Schemas in der Datenbank vollständig zu initialisieren. Im

Folgenden wird davon ausgegangen, dass alle Mandanten bereits im

Identity Management angelegt wurden. Die

notwendigen Schritte sind:

• Anlegen des globalen Schemas und Tabellen für die Verwaltung

Dieser Schritt muss nur einmal durchgeführt werden für alle Applikationen, die in einem mandantenfähigen Szenario eingesetzt werden.

© Bosch Software Innovations 17/71

Kapitel 2. Aufsetzen des Execution Servers

• Anlegen eines Schema für einen Mandanten

• Zuordnung des Schemas zu einem Mandanten

• Anlegen der Datenbanktabellen für die Applikation in dem Schema des Mandanten

Sofern der Datenbankbenutzer, der später von der Applikation verwendet wird, nur eingeschränkte Berechtigungen hat, ist es erforderlich, weitere Berechtigungen auf den angelegten Schemas und Datenbanktabellen zu vergeben. Näheres dazu ist in

Abschnitt 2.4.2.5,

„Berechtigung auf Datenbankschemas vergeben“ zu finden.

Das

Maintenance Tool

verfügt über entsprechende Kommandozeilenargumente für jeden Schritt. Anstatt jedes

Argument angeben zu müssen, kann alternativ auch eine

Properties-Datei

verwendet werden.

Im Folgenden werden die Kommandozeilenargumente pro Schritt aufgeführt. In jedem Schritt ist es notwendig den

Namen der Datenbank mit dem Kommandozeilenargument -db <arg> oder --dbBrand <arg> anzugeben.

Dafür gültige Werte sind: mssql, mysql, h2 und oracle. Für die bessere Übersicht wird das Argument und die

Argumente zum

Ausführen

oder

Ausgeben

der notwendigen SQL Befehle im Folgenden weggelassen.

1.

Zum Erzeugen der Befehle um das globale Schema und die Tabellen zur Verwaltung anzulegen, werden folgende Kommandozeilenargumente verwendet:

--dumpGlobalSchemaDDL --globalSchemaName <arg>

Um die SQL Befehle für eine H2 Datenbank auszugeben, bei der das globale Schema den Namen 'VR' bekommen soll, würde die Kommandozeile auf einem Microsoft Windows Betriebssystem beispielsweise so aussehen:

MaintenanceTool -db h2 --dumpGlobalSchemaDDL --globalSchemaName VR --sqlDumpFile d:\out.sql

Beispiel 2.3. Ausgeben von DDLs

Dieser Schritt muss nur einmal durchgeführt werden für alle Applikationen, die in einem mandantenfähigen Szenario eingesetzt werden.

2.

Zum Erzeugen eines Schemas für einen Mandanten, wird folgendes Kommandozeilenargument verwendet:

--dumpTenantSchemaDDL

3.

Um das Schema einem Mandanten zuzuorden, ist es notwendig die eindeutige ID (UUID) des Mandanten

aus dem Identity Management

zu ermitteln. Mit diesem Wert kann die Zuordnung mit folgenden

Kommandozeilenargumenten eingerichtet werden:

--dumpTenantBindingSQL --tenantSchemaName <arg> --tenantId <arg> --globalSchemaName <arg>

Die Werte für die Argumente sind:

--tenantSchemaName <arg>

--tenantId <arg>

--globalSchemaName <arg>

Der Name des Datenbank Schemas, in dem die

Tabellen für den Mandanten angelegt werden sollen.

Der Name wird in Schritt 4 wieder benötigt.

Die eindeutige ID (UUID) des Mandanten.

Der Name des globalen Schemas. Dies ist normalerweise der gleiche Name wie in Schritt 1.

4.

Zum Erzeugen von Tabellen für die Applikation im Schema des Mandanten werden folgende

Kommandozeilenargumente verwendet:

--dumpExecutionPlatformDDL --tenantSchemaName <arg> --tablePrefix <arg>

Für diesen Fall sind die Werte:

© Bosch Software Innovations 18/71

Kapitel 2. Aufsetzen des Execution Servers

--tenantSchemaName <arg>

--tablePrefix <arg>

Der Name des Datenbank Schemas des

Mandanten. Das ist der gleiche Name wie in Schritt

3.

Der benutzerdefinierte Tabellenpräfix für die

Tabellen der Applikation.

2.4.2.2. Ausgeben von SQL Befehlen

Das Maintenance Tool kann SQL Befehle in eine Datei ausgeben, damit diese geprüft werden können. Sie sollten aber nicht geändert werden. Zum Ausgeben wird folgendes Kommandozeilenargument in Kombination mit anderen dump... Argumenten (z.B. dumpGlobalSchemaDDL) verwendet:

--sqlDumpFile <arg>

Dabei ist <arg> ein gültiger Dateipfad. Existiert die Datei nicht, so wird sie angelegt. Existiert bereits eine, werden die SQL Befehle angehängt.

2.4.2.3. Ausführung von SQL Befehlen

SQL Befehle können nicht nur ausgegeben, sondern auch gleich ausgeführt werden. Grundsätzlich sind folgende

Kommandozeilenargumente dafür notwendig:

--sqlDumpFile <arg> --executeSql

Dabei ist <arg> der Dateipfad zu einer existierenden Datei mit SQL Befehlen, die vorher mit dem Maintenance

Tool ausgegeben wurde.

Die SQL Befehle sollten nicht geändert werden. Das kann zu unvorhersagbarem Verhalten zur

Laufzeit führen.

Um SQL Befehle auszuführen, wird eine JDBC Verbindung verwendet. Neben dem

erwähnten JDBC-Treiber

im driver

Verzeichnis, benötigt dies weitere Kommandozeilenargumente:

-dbDriverClass <arg> -dbUser <arg> -dbPassword <arg> -jdbcUrl <arg>

Dabei sind die Werte:

-dbDriverClass <arg>

-dbUser <arg>

-dbPassword <arg>

-jdbcUrl <arg>

Vollqualifizierter Klassenname der JDBC-Treiberklasse

Name des Datenbankbenutzers

Passwort des Datenbankbenutzers

JDBC URL für die Verbindung zur Datenbank

2.4.2.4. Verwendung von Properties anstatt von Kommandozeilenargumenten

Als Alternative zum Setzen von jedem Kommandozeilenargument ist es möglich, eine Properties-Datei mit

Standardwerten mit dem Maintenance Tool zu verwenden. Der Befehl um die Datei anzulegen ist:

--writeOptionProperties <arg>

Die Datei kann mit folgendem Kommandozeilenargument wieder eingelesen werden:

--readOptionProperties <arg>

Es ist möglich Werte in der Properties-Datei zu übersteuern, in dem sie als Kommandozeilenargument angegeben werden. Wenn im nachfolgenden Beispiel die Properties-Datei den Wert "mysql" für -db enthält, wäre der Wert der zur Anwendung kommt "h2":

© Bosch Software Innovations 19/71

Kapitel 2. Aufsetzen des Execution Servers

MaintenanceTool.cmd --dumpExecutionServerDDL -db h2 –-readOptionProperties myvalues.properties

Beispiel 2.4. Übersteuern von Werten

2.4.2.5. Berechtigung auf Datenbankschemas vergeben

Falls der Datenbankbenutzer, mit dem die Applikation später ausgeführt wird, über eingeschränkte

Berechtigungen verfügt, ist es notwendig auf dem globalen Schema, den Schemas für die Mandaten und den

Tabellen, Berechtigungen zu vergeben.

Die folgende, beispielhafte Abfrage für die Oracle Datenbank erzeugt SQL Befehle, welche Berechtigungen auf

Datenbank-Objekte im globalen Schema vergibt:

-- Take the result of this select statement and execute it, to grant the necessary privileges select grant_statements||owner||'.'||db_obj.object_name||' to <username>;' as grant_statements from ( select 'grant select on ' as grant_statements, v.owner, v.VIEW_NAME as object_name from sys.all_views v union all select 'grant select,insert,update,delete on ', t.owner, t.table_name

from sys.all_tables t

) db_obj where db_obj.owner = '<globalSchemaName>'

Beispiel 2.5. Oracle Beispiel: Berechtigungen für das globale Schema

Die folgende, beispielhafte Abfrage für die Oracle Datenbank erzeugt CRUD-Berechtigungen für die angelegten

Datenbank-Objekte für die Tabellen mit dem angegebenen tablePrefix im Schema tenantSchemaName:

-- Take the result of this select statement and execute it, to grant the necessary privileges select grant_statements||owner||'.'||db_obj.object_name||' to <username>;' as grant_statements from ( select 'grant select on ' as grant_statements, v.owner, v.VIEW_NAME as object_name from sys.all_views v union all select 'grant select,insert,update,delete on ', t.owner, t.table_name

from sys.all_tables t

) db_obj where db_obj.owner = '<tenantSchemaName>' and db_obj.object_name like '<tablePrefix>%'

Beispiel 2.6. Oracle Beispiel: Berechtigungen für Schema eines Mandanten

2.4.2.6. Registrierung der Applikation in Identity Management

Das Maintenance Tool kann verwendet werden, um die Applikation in Identity Management zu registrieren.

Dies erzeugt eine Konfigurationsdatei anstelle einer Datei mit SQL Befehlen. Diese wird an eine andere Stelle geschrieben, damit eine Kombination mit anderen Befehlen der Kommandozeile möglich ist. Díe folgenden

Kommandozeilenargumente werden benötigt, um die Applikation zu registrieren:

-initApp <arg0> -domainName <arg1> -applicationName <arg2> -owner <arg3>

-adminUser <arg4> -adminPassword <arg5> -adminTenant <arg6> -imBackendUrl <arg7>

-imFrontendUrl <arg8> -db <arg9> --globalSchemaName <arg10> --tablePrefix <arg11>

Die Werte um die Applikation zu registrieren sind:

-initApp <arg0>

-domainName <arg1>

Der Dateipfad, wo die Konfigurationsdatei erzeugt werden soll. Diese Properties-Datei enthält alle notwendigen Konfigurationseinstellungen.

Name der Domäne unter der die Applikation im Identity

Management registriert wird.

© Bosch Software Innovations 20/71

Kapitel 2. Aufsetzen des Execution Servers

-applicationName <arg2>

-owner <arg3>

-adminUser <arg4>

-adminPassword <arg5>

-adminTenant <arg6>

-imBackendUrl <arg7>

Name unter dem die Applikation im Identity

Management registriert wird.

Name des Benutzers dem die Applikation, Rollen und

Berechtigungen im Identity Management als Besitzer zugeordnet wird. Dieser Benutzer ist dann in der Lage die Applikation zu administrieren. Falls nicht gesetzt, wird der Benutzer von der Anmeldung verwendet

(siehe unten). (optional)

Wird eine Applikation mehr als einmal registriert, so wird die bestehende Registrierung wiederverwendet und nicht aktualisiert. In manchen Fällen kann es notwendig sein, die Registrierung zu überschreiben. Dies kann durch Angabe von overwriteApplication auf der Kommandozeile erreicht werden.

Die folgenden Werte werden für die Anmeldung in Identity Management benötigt:

Name eines Benutzers mit administrativen Rechten um die Applikation zu registrieren.

Passwort eines Benutzers mit administrativen Rechten um die Applikation zu registrieren.

Mandant eines Benutzers mit administrativen Rechten um die Applikation zu registrieren.

URL der Identity Management Backend Anwendung.

Um eine Konfiguration zu erzeugen, sind folgende Werte notwendig:

-imFrontendUrl <arg8>

-db <arg9>

--globalSchemaName <arg10>

--tablePrefix <arg11>

URL der Identity Management Webkonsolen

Anwendung. (optional)

Name der verwendeten Datenbank.

Name des globalen Datenbankschemas das für die

Verwaltung verwendet wird.

Benutzerdefinierter Tabellenpräfix für die Tabellen der

Anwendung.

Dieser Befehl kann mit anderen des Maintenance Tool kombiniert werden, um den Execution Server zu installieren, ohne den Installations Wizard benutzen zu müssen. Für diesen Zweck kann die erzeugte Datei in das config

Verzeichnis im Execution Server Home Verzeichnis kopiert werden. Sofern die Datei richtig benannt ist,

kann sie als Konfigurationsdatei verwendet werden.

2.5. Installation der Lizenz

Der Execution Server benötigt eine gültige Lizenzdatei, da ansonsten keinerlei Anfragen bearbeiten werden. Mit der

Lizenz Verwaltung

auf der Sicht Wartung, können Lizenzen hinzugefügt werden. Es gibt zwei Möglichkeiten, wie der Server eine Lizenzdatei finden kann:

1.

Die Lizenzdatei liegt im Ordner .visualrules6 im Benutzerverzeichnis des Benutzers der den Server ausführt. Dort wird standardmäßig nach Lizenzdateien gesucht.

2.

Es kann ein Dateipfad zur Lizenzdatei mit der Einstellung license.file angegeben werden. Dies

wird nur benötigt, wenn sich keine Lizenzdatei im Standardverzeichnis befindet. Lesen Sie Abschnitt 2.6,

„Konfiguration des Execution Servers“

, um mehr Details darüber zu erhalten, wie dies bewerkstelligt werden kann.

Im Fall einer ungültigen oder fehlenden Lizenz wird nach der Anmeldung automatisch zur Lizenz

Verwaltung weitergeleitet. Ebenso wird eine Fehlermeldung in das Log geschrieben. Dort finden

© Bosch Software Innovations 21/71

Kapitel 2. Aufsetzen des Execution Servers sich ebenfalls Informationen zu den Stellen, an denen der Execution Server nach Lizenzen sucht. Dafür muss Logging eingeschalten und auch für den Level INFO konfiguriert sein.

2.6. Konfiguration des Execution Servers

Nach erfolgreicher Installation des Execution Servers ist keine weitere Konfiguration notwendig. Dieses Kapitel beschreibt wie Sie den Execution Server konfigurieren, falls Sie die Konfiguration zu einem späteren Zeitpukt

ändern wollen oder Einstellungen vornehmen wollen, die nicht im Installations-Wizard möglich sind (z.B. für spezielle Anforderungen in Produktionsumgebungen).

2.6.1. Execution Server Home

Das Execution Server Home ist ein Ordner der für die Speicherung von Daten und Konfigurationen des Execution

Server benutzt wird. Der Ordnername entspricht normalerweise dem Kontext-Root den Sie beim Deployment der Execution Server Anwendung gewählt haben. Er befindet sich in einem Verzeichnis visualrules im

Benutzerverzeichnis des Betriebssystembenutzers, der den Execution Server startet. Bei Bedarf wird der Ordner automatisch angelegt.

Es ist ebenfalls möglich, ein anderes Verzeichnis als /<user.home>/visualrules/ zu verwenden durch das Setzen einer System Property für die Java VM, welche den Applikations Server betreibt. Der Schlüssel ist visualrules.executionserver.home

und der Wert ist ein gülter Dateipfad der auf ein schreib- und lesbares

Verzeichnis zeigt. Beispielsweise könnte das folgendermaßen aussehen, wenn der Wert per Kommandozeile angegeben wird: -Dvisualrules.executionserver.home=D:\my_es_home

Tabelle 2.1. Execution Server Home Inhalt

config/executionserver.properties

config/vr_logging.config

logs

Die Execution Server Konfigurationsdatei

Konfigurationsdatei für die

Laufzeit Protokollierung

Ordner der die Protokoll Dateien des Execution

Servers enthält

2.6.2. Execution Server Konfiguration

Der Execution Server wird durch den Installationsassistenten installiert und konfiguriert. Alle Einstellungen werden in einer Datei im

Execution Server Home

Verzeichnis persistiert. Es ist möglich, diese Werte zu editieren für den

Fall, dass nach der Installation eine Änderung notwendig ist. Hat sich beispielsweise eine URL für das Identity

Management (IM) geändert, so kann dies in der Konfigurationsdatei geändert werden, ohne die Anwendung erneut zu installieren. Änderungen an der Konfigurationsdatei dürfen nicht vorgenommen werden, wenn der

Execution Server in Betrieb ist.

Bei Eingabe von Werten in eine Properties Datei, müssen unter Umständen bestimmte Zeichen maskiert werden.

Unten aufgelistet finden Sie die möglichen Optionen zur Konfiguration des Execution Servers.

Die typischen Konfigurationseinstellung, wie sie vom Installationsassistenten erstellt werden, sind: executionserver.jndi.name

Der JNDI Resource Name der zu verwendenden Datenbank.

artifactstorage.db.brand

Der Name der verwendeten Datenbank. Gültige Werte sind: H2, MYSQL, ORACLE, MSSQL (Groß-/

Kleinschreibung wird nicht beachtet) artifactstorage.custom.prefix

Der benutzer-definierte Tabellenpräfix, der bei der

Trennung der Anwendungsdaten

Verwendung findet. Der

Wert muss zwischen ein und drei Zeichen lang sein, mit einem Buchstaben anfangen und aus Zahlen oder einfachen Buchstaben bestehen. Etwas formeller, es muss dem folgenden regulären Ausdruck Genüge getan sein: [A-Z][0-9A-Z]{0,2}

© Bosch Software Innovations 22/71

Kapitel 2. Aufsetzen des Execution Servers mts.schema.name

Der Wert ist der Name des Datenbankschemas, welches für die Verwaltung von verschiedenen

Anwendungen und Mandanten verwendet wird, wie in

Abschnitt 1.4.2.1, „Trennung der Mandantendaten“

beschrieben.

im.application.id

Die eindeutige ID (uuid) mit der diese Anwendung beim Identity Management (IM) registriert ist. Zu beachten

ist, dass dies nicht der Name der Anwendung ist und der Wert nur von IM geliefert werden kann.

im.frontend.url

Die URL der Webkonsolen Anwendung von

Identity Management .

im.backend.url

Die URL der Backend Anwendung von Identity Management

.

Es gibt weitere, wenn auch optionale Konfigurationseinstellungen, welche nicht vom Installationsassistenten gesetzt werden: license.file

Gültiger Dateipfad zu der Lizenzdatei des Execution Servers. Wird nur benötigt, wenn sich die Lizenz nicht im Standardverzeichnis befindet.. Es ist ebenfalls möglich, eine Lizenz in der

Lizenz Verwaltung in der Sicht

Wartung hinzuzufügen.

localstorage.workingdir

Ort, wo der Execution Server Artefakte als Jars speichert. Standardmäßig wird dafür das temporäre Verzeichnis des Web Containers benutzt, welches durch das Kontextattribut javax.servlet.context.tempdir

bestimmt ist. Der Wert muss ein Pfad zu einem les- und beschreibbaren Ordner sein.

metadata.custom.mapper

Der voll qualifizierte Klassenname eines benutzer-definierten Metadata Mappers. Die Benutzung eines benutzerdefinierten Metadata Mappers ist in

Abschnitt 8.2.1.3, „Benutzerdefinierter Metadata Mapper“

genauer beschrieben.

audit.log.enabled

Bestimmt, ob das Audit-Protokoll

aktiviert ist. Erlaubte Werte sind true (Standardeinstellung) und false.

audit.log.propagate.failures

Bestimmt das Verhalten, wenn beim Schreiben eines

Audit-Protokoll

Eintrags ein Fehler auftritt. Erlaubte

Werte sind true und false (Standardeinstellung). Falls true gesetzt ist, wird die Ausnahme weiter propagiert. Falls false gesetzt ist, wird die Ausnahme ignoriert. In jedem Fall werden die Ausnahme und der

Audit-Protokoll Eintrag in das Laufzeitprotokoll

geschrieben.

2.6.3. Laufzeitprotokollierung

Die Laufzeitprotokollierung wird vom Execution Server automatisch eingerichtet. Beim Startvorgang wird die

Laufzeitprotokollierung initialisiert und Nachrichten werden in eine Protokolldatei (auch log genannt) geschrieben, welche sich im logs Ordner im

Execution Server Home

befindet. Eine Protokoll Datei wird bis zu 3 Megabyte

(MB) groß und wird dann archiviert. Es gibt maximal drei Archive die eine Nummer im Dateinamen tragen. Zum

Beispiel ist "3" das dritte und somit älteste Archiv. Der Execution Server schreibt zwei unterschiedliche Protokolle:

• executionserver.log enthält die Nachrichten vom Execution Server und verwendeter Komponenten von

Drittanbietern

• performance.log wird für die Analyse der Leistungsfähigkeit verwendet. Die Datei wird automatisch angelegt. Die Datei ist leer, da die Analyse standardmäßig abgeschalten ist.

Die Ausgabe von Nachrichten mit Aktionen des Typs "Log Eintrag schreiben" ist weitestgehend deaktiviert, um die Ausgabe von mandatenspezifischen Informationen zu verhindern. Wird jedoch die Kategorie Eigenschaft von Aktionen vom Typ "Log Eintrag schreiben" verwendet, so werden die Nachrichten in die executionserver.log Datei geschrieben.

Die Protokoll Datei kann in der Webkonsole eingesehen werden, wo es auch möglich ist, Einstellungen für die

Laufzeitprotokollierung vorzunehmen. Mehr Informationen dazu finden sich in

Abschnitt 5.5.2, „Konfiguration und

Anzeige von Nachrichten der Laufzeitprotokollierung“ .

© Bosch Software Innovations 23/71

Kapitel 2. Aufsetzen des Execution Servers

Sollte der Fall eintreten, dass der Execution Server nicht starten kann oder es aus anderen Gründen nicht möglich ist, auf die Webkonsole zuzugreifen, dann kann die Laufzeitprotokollierung in der vr_logging.config Datei im

Execution Server Home

konfiguriert werden.

Das sollte nur in Ausnahmesituationen benutzt werden und ist nicht für die Verwendung im

Normalbetrieb gedacht. Diese Einstellung ist nur möglich, wenn der Execution Server nicht läuft. Die

Konfigurationsdatei wird nur beim Startvorgang eingelesen und Einstellungen in der Webkonsole

überschreiben Werte in der Datei.

Bevor die Protokollierung in der Konfigurations Datei vorgenommen werden kann, muss sichergestellt sein, dass der Execution Server nicht läuft. Dann kann die vr_logging.config Datei in einem Texteditor geöffnet werden.

Die Datei enthält XML Elemente names loggers und logger. Diese haben Attribute names level welche den Protokollierungsgrad (log level) spezifizieren, die ähnlich zu den in Simple Logging Facade for Java (SLF4J) sind. Der Wert kann geändert werden zu: TRACE, DEBUG, INFO, WARN oder ERROR. Für die Fehlersuche eignet sich DEBUG. Nach dem Speichern der Änderung, sollte die Protokolldatei geleert werden, damit Fehler leichter zu finden sind. Beim anschließenden Start des Execution Servers wird die neue Konfiguration angewendet und

Nachrichten mit dem eingestellten Protokollierungsgrad sollten in der Protokolldatei zu finden sein.

© Bosch Software Innovations 24/71

Kapitel 3. Aktualisierung einer bestehenden Version

Kapitel 3. Aktualisierung einer bestehenden Version

Vor dem Starten einer Migration ist es notwendig, ein vollständiges Backup aller verwendeten

Datenbank Schemas durchzuführen. Sofern eine Aktualiserung von Berechtigungen, Rollen und

Angeboten des Identity Management mit dem Maintenance Tool durchgeführt wird, so wird ebenfalls empfohlen, die Daten des Identity Management zu sichern.

Mit dem Maintenance Tool kann eine ältere Version des Execution Server 6 auf eine aktuelle migriert werden. Die

Migration von Version 4 oder 5 wird nicht unterstützt.

Die grundlegenden Schritte einer Migration sind:

1.

Backup des verwendeten Datenbank Schemas als auch der vorgenommen Konfigurationseinstellungen.

2.

Backup der Daten des Identity Management sofern dies notwendig ist.

3.

Ausführung des

Maintenance Tool

, um das Datenbank Schema und die Daten zu migrieren.

4.

Ausführung des

Maintenance Tool

, um Berechtigungen, Rollen und Angebote des Identity Management zu aktualisieren sofern dies notwendig ist.

5.

Erneutes Bereitstellen der neuen Version des Execution Servers auf dem Application Server

Es wird angenommen, dass das Identity Management bereits auf eine kompatible Version aktualisiert wurde. Weitere Information findet sich in den Systemvoraussetzungen Dokument der

Execution Platform.

3.1. Migrieren von der Version 6.0

Bei einer Migration von der Version 6.0 sind folgende Punkte zu beachten, da diese manuelle Schritte erfordern können:

• Eine neue Berechtigung Zugriff auf die Applikationsinstanz wurde hinzugefügt. Diese

Berechtigung steuert, welche Benutzer auf die Execution Server Instanz zugreifen können. Da existierende

Benutzer in Identity Management diese Berechtigung nicht haben, kann kein Benutzer auf die Instanz zugreifen.

Durch die Schritte, die in Abschnitt 3.3, „Aktualisieren von Berechtigungen, Rollen und Angeboten in Identity

Management“ beschrieben sind, wird die Berechtigung in Identity Management hinzugefügt. Diese wird

ebenso zu allen Rollen und Angeboten hinzugefügt, welche dem Execution Server selbst gehören. Dies betrifft nicht Gruppen, Rollen und Angebote die von Benutzern selbst definiert wurden. In diesem Fall muss die

Berechtigung manuell den jeweiligen Entitäten in Identity Management hinzugefügt werden.

• Mit der Version 6.1 wurden

Zugriffsrechte im Execution Server eingeführt. Diese basieren auf einem

sogenannten Whitelist-Ansatz, was bedeutet, dass Zugriffsrechte für Benutzer vergeben werden müssen, damit diese Rule Services nutzen können. Eine neue Berechtigung Zugriffsrechte verwalten und eine

entsprechende Rolle ACL Manager werden durch Ausführung der Schritte in Abschnitt 3.3, „Aktualisieren von Berechtigungen, Rollen und Angeboten in Identity Management“

hinzugefügt. Da Benutzer nach der

Migration keine Zugriffsrechte zugewiesen haben, muss ein Benutzer mit der Berechtigung Zugriffsrechte verwalten

die Zugriffsrechte für Rule Services den Benutzern noch vergeben. Weitere Information ist in

Abschnitt 5.2.11, „Verwalten von Zugriffsrechten für einen Rule Service“

zu finden.

• Das

Standard-Berechtigungspaket

Angebot das in Version 6.0 erstellt wurde, wird automatisch jedem

Mandanten im Anwendungsbereich des Empfängers zugewiesen. Dieses Verhalten wird von der Migration nicht angepasst, um bestehende Vereinbarungen nicht zu verändern. Die Konsequenz davon ist, dass es nicht möglich ist zu bestimmen, welcher Mandant das Angebot erhalten soll, wie dies mit der aktuellen Version der

Fall ist. Um dies zu ändern, sind folgende Schritte in Identity Management notwendig:

1.

Melden Sie sich in Identity Management mit einem Benutzer an, der die Administrator Rolle besitzt.

2.

Legen Sie eine neue Mandantenbeziehung für den Visual Rules Execution Server an.

3.

Weisen Sie das Visual Rules Execution Server Angebot "Standard-Berechtigungspacket" der neuen

Mandantenbeziehung für den Visual Rules Execution Server zu.

© Bosch Software Innovations 25/71

Kapitel 3. Aktualisierung einer bestehenden Version

4.

Weisen Sie die neue Mandantenbeziehung für den Visual Rules Execution Server allen Mandanten zu, denen der Visual Rules Execution Server angeboten werden soll.

5.

Entfernen Sie die Zuweisung des Visual Rules Execution Server Angebots "Standard-

Berechtigungspacket" zu der Mandantenbeziehung "Tenant Creation Relation".

• Ausführungen, die mit der Version 6.0 aufgezeichnet wurden, haben keine Informationen über den Benutzer gespeichert, der den Rule Service ausgeführt hat. Nach der Migration, wird bei diesen Ausführungen

<unkown>

für die Information über den Benutzer angezeigt.

Weitere Änderungen sind in den Release-Informationen der Execution Platform dokumentiert.

3.2. Migrieren von Databank Schemas und Daten

Mit dem Maintenance Tool ist es möglich, direkt Schemas und Daten in einer Datenbank zu migrieren.

Um alle Datenbank Schemas und Daten zu migrieren, werden folgende Kommandozeilenargumente benötigt:

-eEPMig --allTenantSchemas -db <arg0> --tablePrefix <arg1> --globalSchemaName <arg2>

Die Werte sind:

-db <arg0>

--tablePrefix <arg1>

--globalSchemaName <arg2>

Name der verwendeten Datenbank

Benutzerdefinierter Tabellenpräfix für die Tabellen der

Anwendung

Name des globalen Datenbankschemas das für die

Verwaltung verwendet wird

Es ist ebenso möglich nur ein Datenbankschema und dessen Daten zu migrieren durch Ersetzen von

--allTenantSchemas

mit --tenantSchemaName. In diesen Fall ist es notwendig den Namen des

Datenbankschemas als Wert für --tenantSchemaName anzugeben.

Bei der Ausführung einer Migration wird eine JDBC Verbindung aufgebaut. Dafür ist es notwendig, dass ein

passender JDBC Treiber verfügbar ist

und folgende Kommandozeilenargumente ebenfalls angegeben sind:

-dbDriverClass <arg3> -dbUser <arg4> -dbPassword <arg5> -jdbcUrl <arg6>

Hierbei sind die Werte:

-dbDriverClass <arg3>

-dbUser <arg4>

-dbPassword <arg5>

-jdbcUrl <arg6>

Vollqualifizierter Klassenname der JDBC-Treiberklasse

Name des Datenbankbenutzers

Passwort des Datenbankbenutzers

JDBC URL für die Verbindung zur Datenbank

3.3. Aktualisieren von Berechtigungen, Rollen und Angeboten in Identity Management

Berechtigungen, Rollen und Angebote in Identity Management können mit dem Maintenance Tool

aktualisiert werden. Dies betrifft nicht benutzerdefinierte Rollen oder Angebote, welche eventuell manuell angepasst werden müssen.

Wenn die Applikation in Identity Management mit anderen Produkten wie dem Execution Core geteilt wird, so muss die Aktualisierung von Berechtigungen, Rollen und Angeboten nur einmal durchgeführt werden. Es ist hierbei zu beachten, dass es dabei nicht zu einer Vermischung der

Version kommt (bspw. wenn gleichzeitig Version 6.0 und 6.1 verwendet wird) da dies zu Problemen führen kann.

Die Kommandozeilenargumente für die Aktualisierung in Identity Management sind:

© Bosch Software Innovations 26/71

Kapitel 3. Aktualisierung einer bestehenden Version

-updateIM -imBackendUrl <arg0> -esInstanceId <arg1>

Hierbei sind die Werte:

-imBackendUrl <arg0>

-esInstanceId <arg1>

URL der Identity Management Backend Anwendung

Die ID der Instanz wie sie in der Konfigurations des

Execution Servers zu finden ist.

Das Aktualisieren der erwähnten Entitäten erfordert eine Authentifizierung in Identity Management mit einem

Benutzer der über administrative Berechtigungen verfügt. Die folgenden Argumente sind notwendig für die

Authentifizierung:

-adminUser <arg2> -adminTenant <arg3> -adminPassword <arg4>

Die Aktualisierung wird neue Berechtigungen, Rollen und Angebote hinzufügen. Nicht mehr benötigte

Berechtigungen, werden entfernt. Bestehende Rollen und Angebote werden aktualisiert, sofern sie vom Execution

Server angelegt wurden.

© Bosch Software Innovations 27/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

Kapitel 4. Erstellung und Bereitstellung von Rule Services

4.1. Konzepte

4.1.1. Rule Service

Der Visual Rules Execution Server ist eine Ausführungsumgebung für Regeln. Regeln werden mit dem Visual

Rules Modeler erstellt und können dann auf dem Visual Rules Execution Server bereitgestellt werden. Einmal bereitgestellt, stehen die Regeln für jegliche andere Applikationen oder Systeme, welche die Regeln aufrufen möchten, zur Verfügung. Der Visual Rules Execution Server stellt eine Web Service Schnittstelle zur Verfügung, um Regeln aufzurufen. Auf diese Weise wird jede Regel zu einem separaten Service - ein sogenannter Rule

Service.

Die Regeln für einen Rule Service müssen für die Anwendung in eine Regelbibliothek gepackt werden.

Diese Bibliothek und die entsprechenden Services haben Versionsnummern, um eindeutig während des

Lebenszyklusses eines Regelprojektes identifiziert werden zu können. Mehrere Versionen des gleichen Rule

Service können im Visual Rules Execution Server bereitgestellt und zur gleichen Zeit ausgeführt werden.

Ein Rule Service wird durch eine WSDL Datei (Web Service Description Language) beschrieben, die automatisch durch Visual Rules während der Erstellung der Regelbibliothek generiert wird, um dann nach der Bereitstellung verfügbar zu sein. Auf die WSDL Dateien aller eingesetzten Rule Services kann über die Execution Server

Webkonsole zugegriffen werden.

Weiterführende Konzepte.

Abschnitt 4.1.2, „Regelbibliothek“

Abschnitt 4.1.3, „Versionen von Regelbibliothek und Rule Service“

Weiterführende Arbeitsschritte.

Abschnitt 4.2.1, „Regeln festlegen, die als Rule Service exportiert werden sollen“

Abschnitt 5.2.5, „Anzeige der WSDL-Datei eines Rule Service“

4.1.2. Regelbibliothek

Um einen Rule Service im Visual Rules Execution Server zu verwenden, muss das entsprechende Regelprojekt in eine sogenannte Regelbibliothek gepackt werden. Regelbibliotheken sind JAR Dateien, die den generierten

Regelcode für alle Regelmodelle, die im Regelprojekt enthalten sind, beinhalten (siehe Abbildung 4.1,

„Regelprojekt, Regelbibliothek und Rule Service“ ).

Die Regelbibliothek beinhaltet somit die WSDL Datei (und XML Schemas) für das Regelmodell, das als Web

Service exportiert wird (es kann nur ein Regelmodell eines Regelprojekts als Rule Service exportiert werden, die anderen Regelmodelle bleiben intern). Die WSDL und XML Schema Dateien werden automatisch von Visual

Rules erstellt, wenn es eine Regelbibliothek paketiert.

© Bosch Software Innovations 28/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

Abbildung 4.1. Regelprojekt, Regelbibliothek und Rule Service

Der Visual Rules Modeler paketiert Regelbibliotheken, so dass sie den Regelcode von allen

Regelmodellen im Projekt UND den Regelcode von allen abhängigen Regelmodellen enthalten.

Die Regelbiblothek beinhält auch alle Klassen von anderen Bibliotheken und Java Projekten auf dem Erstellungspfad des Projekts. Auf diese Weise enthält die resultierende Regelbibliothek alle benötigten Klassen für die Regeln zur Ausführung. Beachten Sie jedoch, dass die Visual

Rules Laufzeit Bibliotheken nicht in die Regelbibliothek gepackt werden. Sie werden zur Laufzeit automatisch zum Klassenpfad des Execution Servers hinzugefügt.

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.3, „Versionen von Regelbibliothek und Rule Service“

Weiterführende Arbeitsschritte.

Abschnitt 4.2.1, „Regeln festlegen, die als Rule Service exportiert werden sollen“

4.1.3. Versionen von Regelbibliothek und Rule Service

Eine Regelbibliothek hat immer eine Versionsnummer. Diese Versionsnummer wird verwendet, um eine spezifische Regelbibliothek und Rule Service während der Bereitstellung und der Ausführung von Regeln zu identifizieren.

Die Versionsnummer besteht aus drei individuellen Nummern, die durch Punkte getrennt sind, d.h. 1.0.0 oder

12.4.11

. Versionsnummern werden verwendet, um eindeutig eine spezifische Version einer Regelbibliothek zu identifizieren. Dies ist notwendig, weil während des Lebenszyklusses eines Regelprojekts viele verschiedene

Versionen für die Ausführungsumgebung zur Verfügung gestellt werden können. So können mehrere Versionen des gleichen Regelprojekts zur gleichen Zeit eingesetzt werden. Durch Verwendung der Versionsnummer, kann ein Aufrufer genau spezifizieren, welche Version der Regel aufgerufen werden soll.

Die drei Komponenten einer Versionsnummer werden "major", "minor" und "micro" genannt. Höhere Nummern werden als "neuere" Versionen angesehen. Die micro und/oder minor Komponenten können weggelassen werden und werden dann als 0 behandelt, beispielsweise entspricht die Versionsnummer 2.6 der Nummer 2.6.0, und 1 entspricht 1.0 beziehungsweise 1.0.0.

Optional kann nach der "micro" Komponente, eine weitere Komponente angegeben werden, die "qualifier" genannt wird. Der Qualifier wird durch einen Bindestrich (-) getrennt und kann zusätzlich zur Identifikation verwendet werden, beispielsweise kann dies ein Zeitstempel sein. Der Qualifier kann nicht nur Nummern enthalten, sondern

© Bosch Software Innovations 29/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services auch Buchstaben (A-Z, a-z), Unterstriche (_) und Bindestriche (-). Qualifier werden lexikographisch geordnet, um zu bestimmen, welche Version "neuer" ist.

Unter Umständen kann es dazu kommen, dass zwei Rule Services die gleiche Version haben, aber nur einer der beiden einen "qualifier" hat. Wenn in so einem Fall der Rule Service ohne eine spezifizierte Version aufgerufen wird, dann wird der Rule Service ohne "qualifier" als "neuer" angesehen.

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.2, „Regelbibliothek“

Weiterführende Arbeitsschritte.

Abschnitt 4.2.4, „Bereitstellen von Regelprojekten vom Visual Rules Modeler“

4.1.4. Visual Rules Archiv

Der Execution Server unterstützt auch das Visual Rules Archiv, welches neben dem Rule Service auch noch alle weiteren Bibliotheken, die zur Ausführung eines Rule Services notwendig sind, und eine

Abhängigkeitsbeschreibung enthält.

In dieser Form können Rule Services von einem Visual Rules Execution Server herunter- bzw. hochgeladen werden (z.B. um Rule Services von einer Test- auf eine Produktionsumgebung zu übertragen).

Die zugehörige Archivdatei besitzt die Endung VRA.

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.2, „Regelbibliothek“

Weiterführende Arbeitsschritte.

Abschnitt 5.2.6, „Herunterladen eines Rule Service“

Abschnitt 5.2.3, „Hinzufügen eines Rule Service mittels Visual Rules Archiv“

4.1.5. Rule Service Einstellungen

Rule Services können zusätzliche Einstellungen haben, die im folgenden beschrieben sind.

4.1.5.1. Aktiv

Ein Rule Service ist standardmäßig aktiv und kann somit aufgerufen werden. Es kann allerdings auch Situationen geben, in denen Rule Services zwar bereitgestellt sind, aber nicht aufgerufen werden sollen. Für solche Zwecke kann ein Rule Service deaktiviert werden, wodurch dieser nicht mehr aufgerufen werden kann. Für Aufrufer ist es dann nicht unterscheidbar, ob der Rule Service gelöscht wurde oder nur deaktiviert wurde.

4.1.5.2. Gültig von und Gültig bis

Diese Werte werden vom

Standard-Metadata Mapper in einer

generischen Rule Service Anfrage

verwendet. Beim

Einsatz eines benutzerdefinierten Metadata Mappers, wie in Abschnitt 8.2.1.3, „Benutzerdefinierter Metadata

Mapper“ beschrieben, kann das ebenfalls genutzt werden.

4.1.5.3. Name der aktiven Konfiguration (Active Configuration Name)

Im Visual Rules Modeler können mehrere Konfigurationen für die Regelausführung auf einem Regelmodell definiert werden. Diese können beispielsweise in der Visual Rules Rule Execution API verwendet werden, um

Implementierungen von Aktionen auszutauschen. Mehr Informationen zu diesem Thema finden sich im Java

Integration Handbuch.

© Bosch Software Innovations 30/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

Der Execution Server bietet Aufrufern ebenfalls die Möglichkeit, den Namen der zu verwendenden Konfiguration anzugeben. Im Englischen und den technischen Schnittstellen wird hierfür der Begriff active configuration name

verwendet. Zu beachten ist hierbei, dass diese Angabe im Aufruf in älteren Versionen der Visual Rules Rule

Execution API und im Execution Server als binding bezeichnet wird.

Jeder Rule Service kann konfiguriert werden, einen speziellen Namen als Standardwert für die aktive

Konfiguration zu verwenden. Dieser kann anders sein, als derjenige, der normalerweise in der Visual Rules Rule

Execution API verwendet wird. Dies wird dann als active configuration name verwendet, wenn ein Rule

Service ausgeführt wird. Ein Aufrufer kann ein active configuration name auch in der Rule Service Anfrage angeben (für Details siehe

Abschnitt 6.1.2, „Format der Rule Service Anfrage“ ). Die Einstellung in der Anfrage

übertrumpft in diesem Fall immer den Wert der am Rule Service eingestellt wurde.

4.1.5.4. Statistiklevel

Der Statistiklevel erlaubt es, den Detaillierungsgrad der aufgezeichneten Statistiken einzustellen. Das ist eine

Eigenschaft der Visual Rules Rule Execution API, die detailliert im Java Integration Handbuch beschrieben wird.

Der Execution Server sammelt Informationen von Ausführungen von Rule Services. Im Rahmen dieser

Funktionalität können auch Statistiken von Regeln aufgezeichnet werden. Das kann auf zwei Arten verwendet werden. Zum einen kann der Statistiklevel pro Rule Service eingestellt werden, welcher dann als Standardwert bei der Ausführung verwendet wird. Zum anderen können Aufrufer einen Statistiklevel auch in der Rule Service

Anfrage spezifizieren (siehe

Abschnitt 6.1.2, „Format der Rule Service Anfrage“ ), welcher dann statt der

Einstellung des Rule Service verwendet wird.

Generell gilt: je höher der Detaillierungsgrad, desto mehr Information wird aufgezeichnet. Die folgenden

Detaillierungsgrade sind verfügbar:

Quiet: Statistiken der Regeln werden nicht aufgezeichnet und sind nicht zum Herunterladen verfügbar.

Low: Besuche von Regelelemente werden gezählt.

Medium: Zeit, die in einem Regelelement verbracht wird, wird gemessen.

High: Minimale und maximale Zeit, die in einem Regelelement verbracht wird, wird gemessen.

Zusätzlich zu den Leveln in der Visual Rules Rule Execution API, hat der Execution Server den Level Quiet, mit dem die Aufzeichnung der Statistik abgeschalten werden kann. Durch die Einstellung Switched off, kann ein Rule

Service so konfiguriert werden, dass keine Ausführungen aufgezeichnet wird. Ein spezifizierter Statistiklevel eines

Aufrufers hat somit keine Auswirkung.

4.2. Arbeitsschritte

4.2.1. Regeln festlegen, die als Rule Service exportiert werden sollen

Nur exportierte Regeln können durch einen Rule Service Client aufgerufen werden. Somit muss mindestens eine

Regel eines Regelmodells exportiert werden, um einen Rule Service zu erstellen. Um zu spezifizieren, welche

Regeln exportiert werden sollen, führen Sie folgendes durch:

1.

Im Projekt Explorer oder Regel Explorer wählen Sie eine Regel zum Exportieren aus.

2.

Gehen Sie auf die Seite Web Service in der Sicht Eigenschaften.

3.

Aktivieren Sie das Kästchen Regel als Web Service bereitstellen (WSDL operation).

© Bosch Software Innovations 31/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.2, „Regelbibliothek“

4.2.2. XML Namespace für Rule Services definieren

Die generierte WSDL und die XML Schemata für einen Rule Service verwenden einen spezifischen XML

Namespace. Wenn Sie die Namespace URI für einen Rule Service anpassen möchten, führen Sie folgende

Schritte durch:

1.

Im Projekt Explorer oder Regel Explorer wählen Sie das entsprechende Regelmodell aus. Dies ist das

Regelmodell, welches für den Rule Service exportiert wird.

2.

Gehen Sie auf die Seite Web Service in der Sicht Eigenschaften.

3.

Geben Sie den XML Schema Namespace Präfix ein. Dies muss eine gültige URI sein (typischerweise wird http:// als Schema verwendet).

Der vollständige Namespace URI im WSDL und XML Schema wird später aus diesem Präfix gebildet, gefolgt vom Segment /vrpath, gefolgt vom Pfad der spezifischen Regel.

Ist kein Präfix angegeben, wird http://www.visual-rules.com als Standardwert verwendet.

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.2, „Regelbibliothek“

Abschnitt 6.1.2, „Format der Rule Service Anfrage“

Abschnitt 6.1.3, „Format der Rule Service Antwort“

4.2.3. Einstellen von Aktionen als Rückgabewert

Aktionen sind ein Teil des Ergebnisses eines Regelaufrufs. Somit sind sie auch Teil der Rückgabe der generierten

XML Schema Dateien für einen Rule Service. Es ist möglich einzustellen, ob Aktionen als Rückgabewert behandelt werden. Das führt dann zu unterschiedlichen XML Schema Definitionen für einen Web Service. Um dies einzustellen, führen Sie folgende Schritte durch:

1.

Im Projekt Explorer oder Regel Explorer wählen Sie das entsprechende Regelmodell aus. Dies ist das

Regelmodell, welches für den Rule Service exportiert wird.

2.

Gehen Sie auf die Seite Web Service in der Sicht Eigenschaften.

3.

Durch Einstellen der Checkbox kann das Verhalten umgestellt werden. Das hat einen Effekt auf die Elemente, welche in der

Antwort zurückgeliefert werden.

© Bosch Software Innovations 32/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

4.2.4. Bereitstellen von Regelprojekten vom Visual Rules Modeler

Regelprojekte können direkt im Visual Rules Modeler paketiert und auf dem Execution Server bereitgestellt werden. Diese Funktionalität ist auch in Visual Rules Builder und Visual Rules Team Platform (beide separat verfügbar) enthalten.

Für die Bereitstellung muss der Benutzer über die erforderliche Berechtigung verfügen. Siehe auch

Abschnitt 1.3, „Berechtigungs-Konzept“

.

1.

Im Regel Explorer oder Projekt Explorer machen Sie einen Rechtsklick auf das Regelprojekt, das bereitgestellt werden soll.

2.

Wählen Sie den Visual Rules > Als Web Service bereitstellen Menüeintrag. Der Assistent für die

Bereitstellung erscheint.

3.

Die Artefakt-ID, Gruppen-ID und Version sind auf der ruleproject.vr definiert und werden zur

Identifizierung des Artefakts (JAR) verwendet. Diese Version gilt für die Regelbibliothek selbst und den Rule

Service, der bereitgestellt wird.

4.

Wenn das Regelprojekt mehrere Regelmodelle enthält, müssen Sie auswählen, welches Regelmodell exportiert werden soll. Erweitern Sie den Abschnitt Exportiertes Regelmodell und wählen Sie das Regelmodell zum Exportieren aus. Dies ist nicht notwendig, wenn das Regelprojekt nur ein einziges Regelmodell hat.

5.

Im Abschnitt Optionale Rule Service Einstellungen können Werte für die Gültigkeitsdauer eingestellt und der

Rule Service aktiviert bzw. deaktiviert werden.

6.

Erweitern Sie den Abschnitt Execution Server Einstellungen und prüfen Sie die Werte für die Execution

Server URL, den Benutzer, das Passwort und den Mandant.

© Bosch Software Innovations 33/71

Kapitel 4. Erstellung und Bereitstellung von Rule Services

Die URL endet immer mit /admin/upload. Der Host Name und der Kontext Name hängen von

Ihrer Installation des Execution Server ab.

In der Abbildung oben läuft der Execution Server auf dem lokalen Rechner mit dem Port 8080 und der Webapplikations-Kontext wurde executionserver genannt.

7.

Klicken Sie auf Fertig stellen.

8.

Visual Rules Modeler wird nun die Abhängigkeiten des Regelprojekts analysieren, den Regelcode generieren und diesen in eine Regelbibliothek mit allen anderen Abhängigkeiten auf dem Erstellungspfad der involvierten

Projekte packen. Die Regelbibliothek wird dann zum Execution Server hochgeladen.

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Abschnitt 4.1.2, „Regelbibliothek“

Weiterführende Arbeitsschritte.

Abschnitt 4.2.1, „Regeln festlegen, die als Rule Service exportiert werden sollen“

© Bosch Software Innovations 34/71

Kapitel 5. Arbeiten mit der Webkonsole

Kapitel 5. Arbeiten mit der Webkonsole

Die folgenden Abschnitte enthalten Beschreibungen verschiedener Aufgaben, die mit der Webkonsole ausgeführt werden können, z.B. bereitgestellte Rule Services verwalten.

5.1. Aufruf der Webkonsole

Nach erfolgreicher Installation des Execution Servers kann die Webkonsole in einem Web Browser aufgerufen werden. Sie ist unter der Adresse http://<server>:<port>/<context-name> erreichbar, wobei die Werte meist durch den Application Server vorgegeben sind.

Bei einer Bereitstellung auf einem Apache Tomcat, unter Verwendung dessen Standardkonfiguration, lautet die

Adresse beispielsweise http://localhost:8080/executionserver-6.x.y (wobei x und y Platzhalter für die Versionsnummern aus dem Dateinamen der WAR Datei des Execution Servers darstellen).

Es erscheint die folgende Startseite zur Anmeldung:

Wenn beim Start des Execution Servers keine gültige Lizenz zur Verfügung stand, erscheint die Startseite mit einer entsprechenden Fehlermeldung.

Weiterführende Aufgaben.

Abschnitt 2.5, „Installation der Lizenz“

5.1.1. Einstellung einer bestimmten Sprache

Die Seiten der Webkonsole werden in der Sprache angezeigt, die Sie als bevorzugte Sprache in Ihrem Web

Browser eingestellt haben. Sollte diese Sprache von der Webkonsole noch nicht unterstützt werden, dann werden die Seiten in Englisch angezeigt.

Es ist möglich, explizit die deutsche bzw. englische Sprache für die Webkonsole einzustellen:

1.

Öffnen Sie eine Seite der Webkonsole in Ihrem Web Browser.

2.

Bewegen Sie die Maus über das Flaggensymbol im rechten Teil der Menüleiste.

3.

Klicken Sie im Kontextmenü auf die Flagge , wenn Sie die deutsche Sprache einstellen wollen bzw. auf die Flagge , wenn Sie die englische Sprache wünschen.

5.2. Verwaltung bereitgestellter Rule Services

In der Sicht Rule Services des Visual Rules Execution Servers können Sie bereitgestellte Rule Services verwalten.

Wählen Sie in der Menüleiste der Webkonsole den Eintrag Rule Services, um diese Sicht zu öffnen.

Hier haben Sie folgende Möglichkeiten:

Abschnitt 5.2.1, „Anzeige bereitgestellter Rule Services“

Abschnitt 5.2.2, „Filterung angezeigter Rule Services“

© Bosch Software Innovations 35/71

Kapitel 5. Arbeiten mit der Webkonsole

Abschnitt 5.2.3, „Hinzufügen eines Rule Service mittels Visual Rules Archiv“

Abschnitt 5.2.4, „Löschen eines bereitgestellten Rule Service“

Abschnitt 5.2.5, „Anzeige der WSDL-Datei eines Rule Service“

Abschnitt 5.2.6, „Herunterladen eines Rule Service“

Abschnitt 5.2.7, „Anzeige der Eigenschaften und Änderung der Einstellungen eines Rule Service“

Abschnitt 5.2.8, „Verwaltung der Metadaten eines Rule Service“

Abschnitt 5.2.9, „Anzeige der Ausführungen eines Rule Service“

Abschnitt 5.2.10, „Anzeige der erforderlichen Bibliotheken eines Rule Service“

Abschnitt 5.2.11, „Verwalten von Zugriffsrechten für einen Rule Service“

5.2.1. Anzeige bereitgestellter Rule Services

Wählen Sie in der Menüleiste der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu

öffnen.

Die geöffnete Übersichtsseite zeigt alle auf dem Visual Rules Execution Server bereitgestellten Rule Services an:

Standardmäßig werden folgende Eigenschaften der Rule Services angezeigt:

Aktiviert oder deaktiviert

• Version

• Artefakt-ID

• Bereitgestellt von

• Bereitgestellt am

Sie können das Layout der angezeigten Eigenschaften beeinflussen, indem Sie beispielsweise

• bestimmte Eigenschaften ein- bzw. ausblenden. Neben den standardmäßig angezeigten Eigenschaften gibt es noch weitere Eigenschaften wie Gruppen-ID und Metadaten, die eingeblendet werden können. Besitzt ein Rule

Service die zur Anzeige konfigurierten Metadaten nicht, dann werden die betreffenden Spalten in der Tabelle leer gelassen. (siehe

Abschnitt 5.6.1, „Ein- und Ausblenden von Spalten“ )

• zugehörige Spalten verschieben (siehe

Abschnitt 5.6.2, „Verschieben einer Spalte“

)

• das Sortierkriterium und die Sortierreihenfolge ändern (siehe

Abschnitt 5.6.3, „Verändern des Sortierkriteriums und der Sortierreihenfolge“

)

Weiterführende Konzepte.

Abschnitt 4.1.1, „Rule Service“

Weiterführende Aufgaben.

Abschnitt 5.2.2, „Filterung angezeigter Rule Services“

Abschnitt 5.2.3, „Hinzufügen eines Rule Service mittels Visual Rules Archiv“

© Bosch Software Innovations 36/71

Kapitel 5. Arbeiten mit der Webkonsole

Abschnitt 5.2.4, „Löschen eines bereitgestellten Rule Service“

Abschnitt 5.2.5, „Anzeige der WSDL-Datei eines Rule Service“

Abschnitt 5.6, „Konfiguration der Anzeige von Tabelleninhalten“

5.2.2. Filterung angezeigter Rule Services

Auf der Übersichtsseite der Sicht Rule Services können Sie Filterkriterien spezifizieren, um nur Rule Services, die von Interesse sind, anzuzeigen:

In diesem Abschnitt können Sie den Namen des Rule Service als Filterkriterium angeben.

Sie haben die Möglichkeit, weitere Filterkriterien für die Anzeige der Rule Services zu spezifizieren:

• Version

• Bereitstellungszeitraum

Dazu steht ein erweiterter Eingabedialog zur Verfügung:

Mehr Informationen zur Eingabe der Filterkriterien und der Anwendung des Filters finden Sie in Abschnitt 5.7,

„Filterung angezeigter Objekte“ .

5.2.3. Hinzufügen eines Rule Service mittels Visual Rules Archiv

Der Execution Server unterstützt das Hochladen eines Visual Rules Archivs. Dieses enthält neben dem Rule

Service selbst auch alle weiteren, zur Serviceausführung erforderlichen Bibliotheken.

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Klicken Sie auf die Schaltfläche .

Diese Schaltfläche ist nur dann aktiviert, wenn Sie ausreichende Berechtigungen haben. Der

Standardbenutzer Admin hat diese Erlaubnis. Siehe auch Abschnitt 1.3, „Berechtigungs-

Konzept“ .

Der folgende Dialog erscheint:

© Bosch Software Innovations 37/71

Kapitel 5. Arbeiten mit der Webkonsole

3.

Klicken Sie auf die Schaltfläche .

Es öffnet sich ein Dialog zum Hochladen des Visual Rules Archivs. Er ermöglicht Ihnen die Spezifikation einer

Visual Rules Archiv-Datei (mit der Endung .vra). Das Aussehen des Dialoges ist abhängig von Ihrem Web

Browser.

Der Pfad der ausgewählten Datei wird anschließend im Eingabefeld angezeigt.

4.

Klicken Sie auf die Schaltfläche , um die spezifizierte Datei hochzuladen.

Wenn die Operation abgeschlossen ist, wird eine Statusmeldung angezeigt. Zudem erscheint nach erfolgreicher Operation ein Dialog, in dem alle hinzugefügten Rule Services und Bibliotheken aufgelistet sind:

Weiterführende Konzepte.

Abschnitt 4.1.4, „Visual Rules Archiv“

5.2.4. Löschen eines bereitgestellten Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Klicken Sie auf das Symbol des Rule Service, den Sie löschen möchten.

Dieses Symbol ist nur verfügbar, wenn Sie ausreichende Berechtigungen haben. Der

Standardbenutzer Admin hat diese Erlaubnis. Siehe auch Abschnitt 1.3, „Berechtigungs-

Konzept“ .

3.

Es öffnet sich ein Dialog, in dem Sie bestätigen können, dass Sie die Aktion wirklich durchführen möchten.

Klicken Sie zur Bestätigung auf die Schaltfläche .

© Bosch Software Innovations 38/71

Kapitel 5. Arbeiten mit der Webkonsole

5.2.5. Anzeige der WSDL-Datei eines Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Klicken Sie auf das Symbol des Rule Service, dessen WSDL-Datei angezeigt werden soll.

3.

Die WSDL-Datei wird im Web Browser geöffnet.

Falls Sie die Detailseite eines Rule Service geöffnet haben, können Sie auch dort die Anzeige der WSDL-Datei veranlassen:

1.

Klicken Sie auf im oberen Bereich der Detailseite.

2.

Die WSDL-Datei wird im Web Browser geöffnet.

Die URL für die WSDL lautet: http://<server>:<port>/<context-name>/services/<tenant-id>/<rule-model>/<version>/

<rule-model>.wsdl

Das WSDL importiert zusätzliche XML Schema-Dateien, welche wiederum andere Schema-Dateien importieren können. Alle diese Ressourcen können vom Execution Server heruntergeladen werden.

Sie können diese WSDL für jeden Web Service Client verwenden, um ein Regelmodell aufzurufen.

Weiterführende Konzepte.

Abschnitt 6.1.6, „Abbildung des Regelmodells auf WSDL“

5.2.6. Herunterladen eines Rule Service

Sie können einen Rule Service als Visual Rules Archiv herunterladen. Ein Visual Rules Archiv enthält neben dem

Rule Service auch noch alle weiteren, zur Serviceausführung erforderlichen Bibliotheken und kann auf einem anderen Visual Rules Execution Server hochgeladen werden.

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, den Sie herunterladen wollen, indem Sie auf den zugehörigen

Link klicken.

3.

Klicken Sie im oberen Bereich der Detailseite auf .

4.

Es öffnet sich ein Dialog zum Herunterladen der Datei. Er ermöglicht Ihnen das Speichern der Datei. Das

Aussehen des Dialoges ist abhängig von Ihrem Web Browser.

Weiterführende Konzepte.

Abschnitt 4.1.2, „Regelbibliothek“

Abschnitt 4.1.4, „Visual Rules Archiv“

5.2.7. Anzeige der Eigenschaften und Änderung der Einstellungen eines Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, dessen Eigenschaften/Einstellungen Sie sehen wollen, indem Sie auf den zugehörigen Link klicken.

Auf der Detailseite werden im Abschnitt "Übersicht" allgemeine Eigenschaften des Rule Service angezeigt:

© Bosch Software Innovations 39/71

Kapitel 5. Arbeiten mit der Webkonsole

Neben den Eigenschaften werden auch (veränderbare) Einstellungen des Rule Service angezeigt (siehe

Abschnitt 4.1.5, „Rule Service Einstellungen“

):

Die Änderung einer Einstellung können Sie folgendermaßen vornehmen:

1.

Führen Sie für die einzustellende Eigenschaft die entsprechende Eingabe/Auswahl aus:

Name der aktiven Konfiguration : Eingabe des Namens der zu verwendenden Konfiguration

Statistiklevel : Auswahl eines Statistiklevels aus der Dropdown-Liste

Gültigkeitszeitraum : Eingabe eines Start- und/oder Endzeitpunktes (siehe

Abschnitt 5.7.1.1, „Eingabe von

Datum und Uhrzeit“ )

Aktiv : Selektieren/Deselektieren der CheckBox um den Rule Service zu aktivieren/deaktivieren

Möchten Sie alle vorgenommenen Eingaben wieder auf die ursprünglich gespeicherten Werte zurücksetzen, dann klicken Sie auf die Schaltfläche .

2.

Bestätigen Sie die Änderungen, indem Sie auf die Schaltfläche

Weiterführende Konzepte.

Abschnitt 4.1.5, „Rule Service Einstellungen“

klicken.

© Bosch Software Innovations 40/71

Kapitel 5. Arbeiten mit der Webkonsole

5.2.8. Verwaltung der Metadaten eines Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, dessen Metadaten Sie verwalten wollen, indem Sie auf den zugehörigen Link klicken.

3.

Klicken Sie auf Metadaten, worauf die Metadatenseite geöffnet wird.

Es gibt modellbezogene Metadaten eines Rule Service, die im Regelmodell gespeichert sind und nach der

Bereitstellung des Rule Service nicht mehr verändert/gelöscht werden können. Name und Wert dieser Metadaten werden auf der Metadatenseite des Rule Service im Abschnitt "Modellbezogene Metadaten" angezeigt:

Zudem gibt es zusätzliche Metadaten, die Sie über die Webkonsole einem Rule Service nach dessen

Bereitstellung zuordnen können. Diese Metadaten sind editierbar und werden im Abschnitt "Zusätzliche

Metadaten" der Metadatenseite angezeigt:

5.2.8.1. Hinzufügen von Metadaten

Sie haben die Möglichkeit, einem Rule Service weitere Metadaten hinzuzufügen:

1.

Klicken Sie im Abschnitt "Zusätzliche Metadaten" auf die Schaltfläche

Tabellenzeile wird hinzugefügt.

2.

Geben Sie in der Spalte Name den neuen Metadatennamen ein.

. Eine leere

3.

Geben Sie in der Spalte Wert den Metadatenwert ein.

4.

Klicken Sie auf die Schaltfläche . Die Metadatenliste wird um diesen Eintrag erweitert.

5.2.8.2. Löschen von Metadaten

Löschbare Metadaten bekommen im Abschnitt "Zusätzliche Metadaten" das Symbol zugeordnet.

1.

Klicken Sie auf das Symbol des Metadatums, das Sie löschen möchten.

© Bosch Software Innovations 41/71

Kapitel 5. Arbeiten mit der Webkonsole

2.

Es öffnet sich ein Dialog, in dem Sie bestätigen können, dass Sie die Aktion wirklich durchführen möchten.

Klicken Sie zur Bestätigung auf die Schaltfläche .

5.2.8.3. Editieren von Metadatennamen und –werten

An den zusätzlichen Metadaten lassen sich der Name und der Wert nachträglich editieren.

1.

Klicken Sie auf den Metadatennamen bzw. -wert, um die Eingabe direkt in der grafischen Darstellung vorzunehmen.

2.

Geben Sie den Metadatennamen bzw. -wert ein.

3.

Klicken Sie auf die Schaltfläche , um die Änderungen zu speichern.

Weiterführende Konzepte.

Abschnitt 8.1, „Konzept Metadaten“

5.2.9. Anzeige der Ausführungen eines Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, dessen Ausführungen Sie sehen wollen, indem Sie auf den zugehörigen Link klicken.

3.

Klicken Sie auf , worauf die Ausführungsseite geöffnet wird.

Die Ausführungsseite zeigt alle Aufrufe dieses Rule Service an. Zudem gibt es den Abschnitt "Filter

Ausführungen", in dem Sie die Anzeige der Ausführungen einschränken können. Eine genauere Beschreibung finden Sie in

Abschnitt 5.3.1, „Anzeige der Ausführungen von Rule Services“

.

5.2.10. Anzeige der erforderlichen Bibliotheken eines Rule Service

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, dessen erforderliche Bibliotheken Sie anzeigen möchten, indem

Sie auf den zugehörigen Link klicken.

3.

Klicken Sie auf Erforderliche Bibliotheken, worauf die Seite "Erforderliche Bibliotheken" geöffnet wird.

Die Seite "Erforderliche Bibliotheken" zeigt alle Bibliotheken an, die dieser Rule Service benötigt. Eine genauere

Beschreibung finden Sie in

Abschnitt 5.4.1, „Anzeige bereitgestellter Bibliotheken“ .

5.2.11. Verwalten von Zugriffsrechten für einen Rule Service

Wie bereits in Abschnitt 1.3, „Berechtigungs-Konzept“ erwähnt, gibt es

Execution-Server-Zugriffsrechte , welche für

einen Benutzer, Team oder Mandanten für einen bestimmten

Rule Service

gesetzt werden können. Im folgenden wird die Verwaltung dieser Rechte beschrieben:

1.

Wählen Sie in der Webkonsole den Eintrag Rule Services aus, um die Sicht Rule Services zu öffnen.

2.

Öffnen Sie die Detailseite des Rule Service, dessen Zugriffsrechte Sie verwalten wollen, indem Sie auf den zugehörigen Link klicken.

3.

Klicken Sie auf

öffnen.

am oberen Seitenrand, um die Seite zur Verwaltung der Zugriffsrechte zu

Diese Seite enthält jeweils einen Abschnitt für Benutzer, Teams und Mandanten:

© Bosch Software Innovations 42/71

Kapitel 5. Arbeiten mit der Webkonsole

Jeder Abschnitt enthält eine Tabelle, in welcher die Zugriffsrechte für die jeweiligen Entitäten aufgelistet werden.

Der Execution Server verfolgt einen sogenannten white-list Ansatz. D.h. es bestehen keine Zugriffsrechte für eine

Entität, solange kein Eintrag für diese gemacht wurde.

Nur ACL Manager können den gesamten Inhalt der Tabellen sehen oder Einträge editieren. Einem

normalen Benutzer werden nur die für ihn relevanten Einträge angezeigt, ohne diese editieren zu können.

Um einer Tabelle einen Eintrag hinzuzufügen, klicken Sie auf am oberen, linken Rand der

Tabelle. Abhängig vom jeweiligen Abschnitt, in dem Sie sich befinden, öffnet dies einen Dialog, welcher die

Auswahl eines Benutzers, Teams oder Mandanten ermöglicht. Jede eingetragene Entität erhält automatisch das

ANZEIGEN-Recht. Weiterhin besitzt jeder Eintrag drei CheckBoxen, mit denen zusätzlich das AKTUALISIEREN-,

HERUNTERLADEN- oder AUSFÜHREN-Recht gesetzt werden kann.

Um einen Eintrag zu löschen, klicken Sie einfach auf das entsprechende Symbol in der linken Spalte der

Tabelle.

Bitte beachte Sie, dass sich die tatsächlichen Zugriffsrechte eines Benutzers aus einer Kombination der Rechte des Benutzers, Teams und Mandaten ergeben. Dies wurde bereits in

Abschnitt 1.3.3,

„Execution-Server-Zugriffsrechte“ beschrieben.

5.3. Verwaltung der Ausführungen von Rule Services

In der Sicht Ausführungen des Visual Rules Execution Servers können Sie Ausführungen von Rule Services verwalten.

Wählen Sie in der Webkonsole den Eintrag Ausführungen, um diese Sicht zu öffnen.

Hier haben Sie folgende Möglichkeiten:

Abschnitt 5.3.1, „Anzeige der Ausführungen von Rule Services“

Abschnitt 5.3.2, „Filterung angezeigter Ausführungen“

Abschnitt 5.3.3, „Löschen von Ausführungen von Rule Services“

Abschnitt 5.3.4, „Herunterladen einer Statistik zur Ausführung eines Rule Service“

5.3.1. Anzeige der Ausführungen von Rule Services

Wählen Sie in der Webkonsole den Eintrag Ausführungen aus, um die Sicht Ausführungen zu öffnen.

Die geöffnete Übersichtsseite zeigt die Aufrufe aller auf dem Visual Rules Execution Server bereitgestellten Rule

Services an:

© Bosch Software Innovations 43/71

Kapitel 5. Arbeiten mit der Webkonsole

Standardmäßig werden folgende Eigenschaften der Ausführungen angezeigt:

• Ausführungszeitpunkt

• Name des aufgerufenen Rule Service

• Version des Rule Service

• Regelpfad

• Ausführungszeit

• Request-ID

Sie können das Layout der angezeigten Eigenschaften beeinflussen, indem Sie beispielsweise

• bestimmte Eigenschaften ein- bzw. ausblenden. Neben den standardmäßig angezeigten Eigenschaften gibt es noch weitere Eigenschaften wie ID, Artefakt-ID und Gruppen-ID, die eingeblendet werden können. (siehe

Abschnitt 5.6.1, „Ein- und Ausblenden von Spalten“ )

• zugehörige Spalten verschieben (siehe

Abschnitt 5.6.2, „Verschieben einer Spalte“

)

• das Sortierkriterium und die Sortierreihenfolge ändern (siehe

Abschnitt 5.6.3, „Verändern des Sortierkriteriums und der Sortierreihenfolge“

)

Falls bei der Ausführung eines Rule Service eine Statistik erstellt wurde, wird in der ersten Tabellenspalte das

Symbol angezeigt.

Sind Sie nur an den Aufrufen/Ausführungen eines Rule Service interessiert, dann können Sie sich

diese Ansicht über die Detailseite des Rule Service anzeigen lassen (siehe Abschnitt 5.2.9, „Anzeige der Ausführungen eines Rule Service“ ).

Weiterführende Aufgaben.

Abschnitt 6.2.1, „Aufrufen eines Rule Service“

Abschnitt 5.3.4, „Herunterladen einer Statistik zur Ausführung eines Rule Service“

Abschnitt 5.3.3, „Löschen von Ausführungen von Rule Services“

Abschnitt 5.6, „Konfiguration der Anzeige von Tabelleninhalten“

5.3.2. Filterung angezeigter Ausführungen

Auf der Übersichtsseite der Sicht Ausführungen können Sie Filterkriterien spezifizieren, um nur Ausführungen, die von Interesse sind, anzuzeigen:

In diesem Abschnitt können Sie die Request-ID der Ausführung als Filterkriterium angeben.

Sie haben die Möglichkeit, weitere Filterkriterien für die Anzeige der Ausführungen zu spezifizieren:

• Name des aufgerufenen Rule Service (in der Ausführungsseite eines Rule Services nicht verfügbar)

• Version des aufgerufenen Rule Service (in der Ausführungsseite eines Rule Services nicht verfügbar)

• Regelpfad

• Ausführungszeitraum

Dazu steht ein erweiterter Eingabedialog zur Verfügung:

© Bosch Software Innovations 44/71

Kapitel 5. Arbeiten mit der Webkonsole

Mehr Informationen zur Eingabe der Filterkriterien und der Anwendung des Filters finden Sie in Abschnitt 5.7,

„Filterung angezeigter Objekte“ .

5.3.3. Löschen von Ausführungen von Rule Services

Sie haben die Möglichkeit, eine bestimmte Ausführung oder alle in der Sicht Ausführungen angezeigten

Ausführungen zu löschen. Möchten Sie beispielsweise alle Ausführungen, die vor einem bestimmten Zeitpunkt liegen, löschen, dann können Sie sich durch Filterung der Ausführungen (Filterkriterium Ausführungszeitraum) die entsprechenden Ausführungen anzeigen lassen und darauf die Löschoperation ausführen.

1.

Wählen Sie in der Webkonsole den Eintrag Ausführungen aus, um die Sicht Ausführungen zu öffnen.

2.

Wenn Sie eine einzelne Ausführung löschen möchten, dann klicken Sie auf das Symbol der Ausführung, die Sie löschen möchten oder wenn Sie alle aktuell angezeigten Ausführungen löschen möchten, dann klicken Sie dort auf die Schaltfläche

Löschen.

3.

Es öffnet sich ein Dialog, in dem Sie bestätigen können, dass Sie die Aktion wirklich durchführen möchten.

Klicken Sie zur Bestätigung auf die Schaltfläche

Weiterführende Aufgaben.

Abschnitt 5.3.1, „Anzeige der Ausführungen von Rule Services“

.

5.3.4. Herunterladen einer Statistik zur Ausführung eines Rule Service

1.

Wählen Sie in der Menüleiste der Webkonsole den Eintrag Ausführungen aus, um die Sicht Ausführungen zu

öffnen.

2.

Klicken Sie bei der Ausführung, deren Statistik Sie herunterladen wollen, auf das Symbol . Das Symbol wird in der ersten Tabellenspalte nur angezeigt, wenn bei der Ausführung eine Statistik erstellt wurde.

3.

Es öffnet sich ein Dialog zum Herunterladen der vrstatistic-Datei. Er ermöglicht Ihnen das Speichern der

Datei. Das Aussehen des Dialoges ist abhängig von Ihrem Web Browser.

Die heruntergeladene Statistik kann vom Visual Rules Modeler geladen und angezeigt werden.

Weiterführende Aufgaben.

Abschnitt 5.3.1, „Anzeige der Ausführungen von Rule Services“

5.4. Verwaltung bereitgestellter Bibliotheken

In der Sicht Bibliotheken des Visual Rules Execution Servers können Sie bereitgestellte Bibliotheken verwalten.

© Bosch Software Innovations 45/71

Kapitel 5. Arbeiten mit der Webkonsole

Wählen Sie in der Webkonsole den Eintrag Bibliotheken, um diese Sicht zu öffnen.

Hier haben Sie folgende Möglichkeiten:

Abschnitt 5.4.1, „Anzeige bereitgestellter Bibliotheken“

Abschnitt 5.4.2, „Filterung angezeigter Bibliotheken“

Abschnitt 5.4.3, „Anzeige von Eigenschaften und Verwendung einer Bibliothek“

Abschnitt 5.4.4, „Löschen einer bereitgestellten Bibliothek“

5.4.1. Anzeige bereitgestellter Bibliotheken

Wählen Sie in der Webkonsole den Eintrag Bibliotheken aus, um die Sicht Bibliotheken zu öffnen.

Die geöffnete Übersichtsseite zeigt alle auf dem Visual Rules Execution Server bereitgestellten Bibliotheken an:

Standardmäßig werden folgende Eigenschaften der Bibliotheken angezeigt:

• Artefakt-ID

• Version

• Gruppen-ID

Sie können das Layout der angezeigten Eigenschaften beeinflussen, indem Sie beispielsweise

• bestimmte Eigenschaften ein- bzw. ausblenden. Neben den standardmäßig angezeigten Eigenschaften gibt es noch weitere Eigenschaften wie Bereitgestellt von und Bereitgestellt am, die eingeblendet werden können.

(siehe Abschnitt 5.6.1, „Ein- und Ausblenden von Spalten“

)

• zugehörige Spalten verschieben (siehe

Abschnitt 5.6.2, „Verschieben einer Spalte“

)

• das Sortierkriterium und die Sortierreihenfolge ändern (siehe

Abschnitt 5.6.3, „Verändern des Sortierkriteriums und der Sortierreihenfolge“

)

Sind Sie nur an den Bibliotheken interessiert, die ein bestimmter Rule Service benötigt, dann können

Sie sich diese Ansicht über die Detailseite des Rule Service anzeigen lassen (siehe Abschnitt 5.2.10,

„Anzeige der erforderlichen Bibliotheken eines Rule Service“

).

Weiterführende Aufgaben.

Abschnitt 5.4.4, „Löschen einer bereitgestellten Bibliothek“

Abschnitt 5.6, „Konfiguration der Anzeige von Tabelleninhalten“

5.4.2. Filterung angezeigter Bibliotheken

Auf der Übersichtsseite der Sicht Bibliotheken können Sie Filterkriterien spezifizieren, um nur Bibliotheken, die von

Interesse sind, anzuzeigen:

© Bosch Software Innovations 46/71

Kapitel 5. Arbeiten mit der Webkonsole

In diesem Abschnitt können Sie die Artefakt-ID der Bibliothek als Filterkriterium angeben.

Sie haben die Möglichkeit, weitere Filterkriterien für die Anzeige der Bibliotheken zu spezifizieren:

• Gruppen-ID

• Version

• Bereitstellungszeitraum

Dazu steht ein erweiterter Eingabedialog zur Verfügung:

Mehr Informationen zur Eingabe der Filterkriterien und der Anwendung des Filters finden Sie in Abschnitt 5.7,

„Filterung angezeigter Objekte“ .

5.4.3. Anzeige von Eigenschaften und Verwendung einer Bibliothek

1.

Wählen Sie in der Webkonsole den Eintrag Bibliotheken aus, um die Sicht Bibliotheken zu öffnen.

2.

Öffnen Sie die Detailseite der Bibliothek, deren Eigenschaften/Verwendung Sie sehen möchten, indem Sie auf den zugehörigen Link klicken.

Auf der Detailseite werden im Abschnitt "Übersicht" allgemeine Eigenschaften der Bibliothek angezeigt:

Neben den Eigenschaften werden auf dieser Seite im Abschnitt "Rule Services" alle Rule Services angezeigt, die diese Bibliothek verwenden:

Eine genauere Beschreibung der Tabelle finden Sie in

Abschnitt 5.2.1, „Anzeige bereitgestellter Rule Services“

.

© Bosch Software Innovations 47/71

Kapitel 5. Arbeiten mit der Webkonsole

5.4.4. Löschen einer bereitgestellten Bibliothek

1.

Wählen Sie in der Webkonsole den Eintrag Bibliotheken aus, um die Sicht Bibliotheken zu öffnen.

2.

Öffnen Sie die Detailseite der Bibliothek, die Sie löschen wollen, indem Sie auf den zugehörigen Link klicken.

3.

Klicken Sie auf die Schaltfläche Ungenutzte Bibliothek löschen.

Diese Schaltfläche ist nur dann aktiviert, wenn diese Bibliothek von keinem anderen

Rule Service mehr benötigt wird und wenn Sie ausreichende Berechtigungen haben. Der

Standardbenutzer Admin hat diese Erlaubnis. Siehe auch Abschnitt 1.3, „Berechtigungs-

Konzept“ .

4.

Es öffnet sich ein Dialog, in dem Sie bestätigen können, dass Sie die Aktion wirklich durchführen möchten.

Klicken Sie zur Bestätigung auf die Schaltfläche .

5.5. Wartung des Execution Servers

5.5.1. Lizenzen verwalten

1.

Wählen Sie in der Webkonsole den Eintrag Wartung aus, um die Sicht Wartung zu öffnen.

2.

Klicken Sie auf die Schaltfläche , worauf die Seite "Lizenz-Verwaltung" geöffnet wird:

Sie zeigt die Lizenzdateien für den Visual Rules Execution Server. Dabei sind für jede Lizenzdatei folgende

Informationen angegeben:

• Name der Lizenzdatei

• Lizenznehmer

• Lizenztyp

• Wartungsende

• Gültigkeit

• Version

Außerdem haben Sie die folgenden Möglichkeiten:

Abschnitt 5.5.1.1, „Lizenz hinzufügen“

Abschnitt 5.5.1.2, „Lizenz löschen“

5.5.1.1. Lizenz hinzufügen

Um eine Lizenz hinzuzufügen, gehen Sie vor wie folgt:

1.

Klicken Sie auf der Seite "Lizenz-Verwaltung" auf Lizenz hinzufügen.

2.

Der folgende Dialog erscheint:

© Bosch Software Innovations 48/71

Kapitel 5. Arbeiten mit der Webkonsole

3.

Klicken Sie auf Durchsuchen und wählen Sie eine Lizenzdatei von Ihrem Dateisystem.

4.

Klicken Sie auf Hinzufügen.

5.5.1.2. Lizenz löschen

Um eine Lizenz zu löschen, klicken Sie auf der Seite "Lizenz-Verwaltung" auf vor der betreffenden Lizenz.

5.5.2. Konfiguration und Anzeige von Nachrichten der Laufzeitprotokollierung

Wählen Sie in der Menüleiste der Webkonsole den Eintrag Wartung aus, um die Sicht Wartung zu öffnen. Klicken

Sie danach auf Logging.

Die geöffnete Seite besteht aus zwei Teilen. Der obere, mit "Detaillierungsgrad" beschriebene Teil, dient zur

Konfiguration der Laufzeitprotokollierung des Execution Server. Dazu dient ein Schieberegler:

Der Schieberegler kontrolliert die Einstellung des Detaillierungsgrades der Laufzeitprotokollierung. Je höher der Grad, desto mehr Nachrichten werden produziert. Zu beachten ist, dass ein hoher Detaillierungsgrad einen negativen Einfluss auf die Leistungsfähigkeit des Systems hat. Neben dem Schieberegler wird eine genaue

Beschreibung für den momentan eingestellten Detaillierungsgrad angezeigt.

Der untere Teil der Seite ist mit "Logs" beschrieben und zeigt hauptsächlich Protokolldateien (Log) an:

Die Dropdown-Liste wählt die Protokolldatei aus, deren Einträge angezeigt werden sollen. Eine Datei kann

auch leer sein. Informationen zu existierenden Protokolldateien ist in Abschnitt 2.6.3, „Laufzeitprotokollierung“

beschrieben. Mit dem "Log-Datei herunterladen" beschrifteten Link, kann die ausgewählte Protokolldatei heruntergeladen werden.

5.6. Konfiguration der Anzeige von Tabelleninhalten

Die tabellarische Anzeige von Informationen in der Webkonsole kann oftmals auf folgende Art und Weise verändert werden:

Abschnitt 5.6.1, „Ein- und Ausblenden von Spalten“

© Bosch Software Innovations 49/71

Kapitel 5. Arbeiten mit der Webkonsole

Abschnitt 5.6.2, „Verschieben einer Spalte“

Abschnitt 5.6.3, „Verändern des Sortierkriteriums und der Sortierreihenfolge“

5.6.1. Ein- und Ausblenden von Spalten

In vielen Tabellen ist es möglich, die Anzeige bestimmter Spalten zu aktivieren/deaktivieren:

1.

Bewegen Sie die Maus über die Überschrift einer beliebigen Spalte der Tabelle. Klicken Sie auf , um das

Kontextmenü zu öffnen.

2.

Gehen Sie mit der Maus auf den Menüpunkt Spalten, worauf sich ein weiteres Kontextmenü öffnet, in dem ausblendbare Spalten aufgeführt werden.

3.

Aktivieren/Deaktivieren Sie die Checkbox der Spalten, die Sie ein-/ausblenden möchten.

5.6.2. Verschieben einer Spalte

In vielen Tabellen haben Sie die Möglichkeit, die Reihenfolge der Spalten zu verändern:

1.

Eine Spalte kann per Drag&Drop an eine andere Position verschoben werden. Klicken Sie auf die Überschrift der Spalte, die Sie verschieben möchten, und halten Sie die linke Maustaste gedrückt.

2.

Bewegen Sie die Maus nach links bzw. rechts. Während der Mausbewegung erscheinen Symbole, die signalisieren, ob es sich bei der aktuellen Position um eine mögliche oder unerlaubte Position handelt.

Zusätzlich zeigen Pfeile die genaue (mögliche) Position an.

3.

Haben Sie die gewünschte Spaltenposition erreicht, dann lassen Sie die Maustaste los. Die Spalte wird nun dorthin verschoben.

5.6.3. Verändern des Sortierkriteriums und der Sortierreihenfolge

1.

Klicken Sie auf die Spaltenüberschrift, um die zugehörige Eigenschaft als Sortierkriterium festzulegen. Das

Symbol bedeutet, dass aufsteigend sortiert wird.

2.

Falls Sie eine absteigende Sortierreihenfolge möchten, dann klicken Sie erneut auf die Spaltenüberschrift.

Das Symbol bedeutet, dass absteigend sortiert wird.

Alternativ können Sie die Sortierreihenfolge auch über das Kontextmenü der Spalte festlegen:

1.

Bewegen Sie die Maus über die Spaltenüberschrift und klicken Sie auf , um das Kontextmenü zu öffnen.

2.

Selektieren Sie den Menüpunkt bzw. .

5.7. Filterung angezeigter Objekte

Durch die Anwendung eines Filters kann die Zahl der angezeigten Objekte in einer Tabelle reduziert und der

Fokus auf bestimmte Objekte gelegt werden.

5.7.1. Eingabe von Filterkriterien

Filterkriterien werden in einem eigenen Abschnitt der Benutzeroberfläche spezifiziert. Der Filterabschnitt befindet sich meist vor der Tabelle, auf deren Objekte sich die Filterung beziehen soll. Initial ist die Eingabe eines

(wichtigen) Filterkriteriums möglich.

Um weitere Filterkriterien eingeben zu können, können Sie in einen erweiterten Eingabedialog mit zusätzlichen

Eingabefeldern wechseln. Dazu gibt es im Filterabschnitt die Schaltfläche .

© Bosch Software Innovations 50/71

Kapitel 5. Arbeiten mit der Webkonsole

Den erweiterten Dialog können Sie wieder verlassen, indem Sie dort auf die Schaltfläche klicken.

Sie können die Eingabe aller Filterkriterien rückgängig machen, indem Sie auf die Schaltfläche klicken. Die Filtereingabefelder sind danach leer. Zudem wird die Anzeige der zugehörigen Tabelle aktualisiert.

5.7.1.1. Eingabe von Datum und Uhrzeit

Die Eingabefelder zur Spezifikation eines Datums und einer Uhrzeit haben folgendes Aussehen:

Zur Eingabe eines Datums klicken Sie auf das Symbol , sodass sich ein Kalender öffnet:

Hier können Sie per Mausklick ein Datum auswählen, das dann automatisch in das Datumsfeld übernommen wird.

Der Kalender bietet auch die Möglichkeit, den Monat und das Jahr zu wechseln. Klicken Sie dazu auf die

Monatsüberschrift im Kalender, sodass sich folgende Ansicht zur Auswahl öffnet:

In dieser Ansicht können Sie mit der Maus einen Monat in einem bestimmten Jahr auswählen. Bestätigen Sie Ihre

Wahl anschließend mit OK.

Zur Eingabe einer Uhrzeit klicken Sie auf das Symbol neben dem zweiten Eingabefeld. Es öffnet sich eine

Liste, aus der Sie einen Zeitpunkt (Stunden und Minuten) auswählen können.

5.7.2. Anwenden eines Filters

Soll die Filterung der Objekte einer Tabelle ausgeführt werden, klicken Sie im Filterabschnitt auf die Schaltfläche

. Anschließend wird die Anzeige der zugehörigen Tabelle aktualisiert und es werden nur solche

Objekte angezeigt, deren Eigenschaften mit den spezifizierten Filterkriterien übereinstimmen.

© Bosch Software Innovations 51/71

Kapitel 6. Aufrufen von Regeln im Execution Server

Kapitel 6. Aufrufen von Regeln im Execution Server

6.1. Konzepte

SOAP Nachrichten werden verwendet, um Rule Services im Execution Server aufzurufen. Der SOAP Envelope einer Nachricht umfasst einen SOAP Header, der Authentifizierungsdaten beinhaltet, und einen SOAP Body, der zur Spezifikation der Rule Service Anfrage verwendet wird.

6.1.1. Authentifizierung für eine Rule Service Anfrage

Der SOAP Header enthält Elemente, die in der Spezifikation der Web Service Security definiert sind. Es gibt ein

Security

Element zur Übermittlung sicherheitsrelevanter Informationen in einer SOAP Nachricht. Das enthaltene

UsernameToken

Element dient dazu, einen Benutzernamen und zusätzliche Attribute, die zur Authentifizierung nötig sind (Passwort und Mandant des Benutzers), zur Verfügung zu stellen.

Beispielsweise kann dies so aussehen:

<soapenv:Envelope ...>

<soapenv:Header xmlns:wsse=

"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<wsse:Security soapenv:mustUnderstand="1">

<wsse:UsernameToken>

<tenant>BOSCH</tenant>

<wsse:Username>USER</wsse:Username>

<wsse:Password Type=

"http://www.visual-rules.com/wss#PasswordText">PASSWORD</wsse:Password>

</wsse:UsernameToken>

</wsse:Security>

</soapenv:Header>

<soapenv:Body>

...

</soapenv:Body>

</soapenv:Envelope>

Beispiel 6.1. SOAP Envelope mit Header zur Authentifizierung

Weiterführende Konzepte.

Abschnitt 1.2, „Identity Management“

6.1.2. Format der Rule Service Anfrage

Das äußerste Element einer Anfrage an eine Regel wird VRRequest genannt. Der Namespace dieses Elements reflektiert die Position der Regel im Regelmodell und in der Regelpakethierarchie. Diese Information wird vom

Execution Server verwendet, um die Anfrage an das gewünschte Regelmodell und an die darin gewünschte Regel weiterzuleiten.

Der vollständige Namespace für den URI des VRRequest besteht aus dem Präfix, der im

Regelmodell konfiguriert werden kann, gefolgt vom Segment /vrpath, gefolgt von dem Pfad der Regel, die aufgerufen werden soll. Der Pfad besteht aus dem Namen des Regelmodells, desweiteren den Namen der Regelpakete und schliesslich des Namens der Regel selbst.

Der Namespace URI Präfix ist standardmäßig http://www.visual-rules.com und wird in den folgenden Beispielen verwendet.

Die nachfolgende Beschreibung bezieht sich auf die aktuelle Version. Bei der Verwendung von migrierten Rule Services ist die Web Service Schnittstelle immer noch richtig, enthält aber nicht alle hier beschriebenen Elemente.

Das VRRequest Element kann ein optionales target Element beinhalten, mit dem eine spezifische Version des aufzurufenden Regelmodells angeben werden kann. Ebenso kann innerhalb dieses Elements mit einem

© Bosch Software Innovations 52/71

Kapitel 6. Aufrufen von Regeln im Execution Server provider

Element der Mandant spezifiziert werden, dem der Rule Service gehört. Dies ist im Falle eines

Angebots im

Anwendungsbereich des Anbieters notwendig.

Wenn das version Element nicht vorhanden ist, ist es das Standardverhalten des Execution Server, die neueste

Version des Regelmodells aufzurufen. Ist das provider Element nicht gesetzt, wird davon ausgegangen, dass der Rule Service dem Mandanten des Benutzers aus der Anmeldung gehört.

Als nächstes kommt das configuration Element, dass Einstellungen zur Ausführung des Rule Services spezifiziert und ebenfalls optional ist.

Alle Elemente haben eine definierte Reihenfolge. Ist das target Element spezifiziert, so muss es das erste Element im VRRequest sein und das configuration Element käme als nächstes, wenn es spezifiziert ist.

Schließlich werden die Eingabedaten der Regel in einem Element input spezifiziert. Die Elemente in diesem

Abschnitt haben den gleichen Namen wie die Eingaben einer Regel. Der Wert jedes Datenelements wird innerhalb

dieser Elemente spezifiziert. Der Abschnitt 6.1.5, „XML Repräsentation von Datentypen“

beschreibt die XML

Repräsentation für diese Werte, abhängig von den Datentypen (einschließlich Strukturen, Aufzählungen, Listen,

Mengen und Maps).

<pricing:VRRequest xmlns:vr="http://www.visual-rules.com"

xmlns:pricing="http://www.visual-rules.com/vrpath/Movie%20Ticket%20Pricing/Pricing">

<vr:target>

<!-- Falls weggelassen, wird Visual Rules Execution Server die

"letzte" Version verwenden -->

<version>1.0.1</version>

<!-- Optionaler, kurzer Name des Anbieters des Rule Service -->

<provider>A_PROVIDER</provider>

</vr:target>

<!-- Spezifiziert optionale Einstellungen für die Ausführung eines Rule Service. -->

<vr:configuration>

<!-- Eine requestId kann spezifiziert werden, um die Statistik auf dem Server

zu identifizieren. Falls weggelassen, wird eine eindeutige ID generiert. -->

<requestId>uniqueRequestId</requestId>

<!-- Der Name der aktiven Konfiguration (active configuration name) der während der

Ausführung verwendet werden soll.

Wird dieser weggelassen, wird der Standard verwendet. -->

<activeConfigurationName>test</activeConfigurationName>

<!-- Für ältere Aufrufer, kann anstatt activeConfigurationName auch binding noch

verwendet werden. -->

<!-- Ebenso sollte dies für Rule Services verwendet werden, die mit einer

Version vor 5.2 gebaut wurde. -->

<binding>test</binding>

<!-- Der verwendete Statistik Level. Mögliche Angaben sind: high, medium und low -->

<!-- Falls weggelassen, werden keine Statistiken aufgezeichnet und sind

auch nicht herunterladbar. -->

<sessionStatistics>

<level>medium</level>

</sessionStatistics>

</vr:configuration>

<input>

<auditorium_no>1</auditorium_no>

<seat_no>199</seat_no>

<show_date>2008-08-22</show_date>

<coupon>true</coupon>

<student>true</student>

<bonus_card>GOLD</bonus_card>

</input>

</pricing:VRRequest>

Beispiel 6.2. VRRequest Format

Weiterführende Konzepte.

Abschnitt 6.1.5, „XML Repräsentation von Datentypen“

© Bosch Software Innovations 53/71

Kapitel 6. Aufrufen von Regeln im Execution Server

6.1.3. Format der Rule Service Antwort

Das äußerste Element einer Antwort auf eine Regel Anfrage wird VRResponse genannt. Der Namespace ist der gleiche wie für die Anfrage.

Die VRResponse hat ein Element mit dem Namen output, dass die Werte für alle Ausgabedatenelemente einer

Regel enthält. Im Normalfall enthält die Antwort auch Aktionen. Es ist zu beachten, dass dies konfiguriert werden kann, wie in

Abschnitt 4.2.3, „Einstellen von Aktionen als Rückgabewert“

erläutert. Der

Abschnitt 6.1.5, „XML

Repräsentation von Datentypen“ beschreibt die XML Repräsentation für die Werte hier.

Schließlich gibt es ein Element trace, das die Informationen darüber zurückgibt, welche Regel in welcher

Version von welchem Regelmodell gerade aufgerufen wurde. Dies dient dem Zweck der Nachverfolgbarkeit, so dass immer klar erkenntlich ist, welche Regeln ausgeführt wurden, beispielsweise wenn in der Anfrage die zu verwendende Version nicht festgelegt wurde.

Um die Statistiken nach der Ausführung auf dem Execution Server zu identifizieren, wird die angegebene oder generierte requestId zurückgeliefert. Mehr zu Statistiken ist in

Abschnitt 5.3.1, „Anzeige der Ausführungen von

Rule Services“

zu finden. Als letztes Element wird der Name der aktiven Konfiguration (active configuration name

) ausgegeben, der entweder in der Anfrage oder als Einstellung des Rule Service spezifiziert wurde. Auch hier wird aus Kompatibilitätsgrüunden für ältere Rule Services das Element binding zurückgeliefert.

<pricing:VRResponse xmlns:vr="http://www.visual-rules.com"

xmlns:pricing="http://www.visual-rules.com/vrpath/Movie%20Ticket%20Pricing/Pricing">

<output>

<price>7</price>

</output>

<vr:trace>

<ruleModel>Movie Ticket Pricing</ruleModel>

<rulePath>/Movie Ticket Pricing/Pricing</rulePath>

<version>1.0.1</version>

<requestId>3919c5b8-5bfc-11de-b728-d56c9d794642</requestId>

<!-- Optional -->

<activeConfigurationName>test</activeConfigurationName>

<!-- oder -->

<binding>test</binding>

</vr:trace>

</pricing:VRResponse>

Beispiel 6.3. VRResponse Format

Weiterführende Konzepte.

Abschnitt 6.1.5, „XML Repräsentation von Datentypen“

6.1.4. Generische Rule Service Anfragen

Der gewöhnliche Weg um einen Rule Service aufzurufen, besteht darin eine Anfrage aus der spezifischen

WSDL zu erzeugen und diese abzuschicken. Dieses Vorgehen bedeutet auch, dass sich der Aufrufer bereits für einen Rule Service und den damit verbundenen Regeln entschieden hat. Es gibt jedoch auch Fälle, in denen es gewünscht ist, gegen eine für alle Rule Services gleiche WSDL zu arbeiten und die Anfrage daraus zu erstellen. Dies setzt eine implizite Kenntniss der Daten, die zu übergeben sind, voraus. Die zweite Anwendung der generischen Anfrage ist das Weiterleiten einer Anfrage zu einem Rule Service anhand von Metadaten.

Es ist ebenso möglich eine spezifische WSDL anhand von Metadaten abzuholen. Mehr dazu in

Abschnitt 8.2.1.2, „Eine WSDL durch Angabe von Metadata abholen“

6.1.4.1. Generisches VRRequest Format

Der generische VRRequest ist in einer speziellen WSDL Datei spezifiziert, die auf dem Execution Server unter http://<server>:<port>/<context-name>/services/visualrules_generic.wsdl

verfügbar ist. In einer Standard Installation auf einem lokalen Rechner könnte dies beispielsweise so aussehen (wobei x und y der

Versionsnummer der WAR Datei des Execution Servers entsprechen):

© Bosch Software Innovations 54/71

Kapitel 6. Aufrufen von Regeln im Execution Server http://localhost:8080/executionserver-6.x.y/services/visualrules_generic.wsdl

Es gibt einige Ähnlichkeiten zwischen dem spezifischen und dem generischen Anfrage Format. Das VRRequest

Element ist ebenfalls das äußerste Element in der generischen Anfrage allerdings mit einem festen Namespace.

Weil die Information des Regel Modells und der aufzurufenden Regel nicht mehr im Namespace vorhanden sind, müssen diese nun mit ruleModel und rulePath im target Element spezifiziert werden. Deswegen ist target auch nicht mehr optional. Es kann optional eine version angegeben werden, was die gleiche Bedeutung wie im spezifischen VRRequest hat.

Als Alternative zur version kann ein Element effectiveDate angegeben werden, welches die Anfrage anhand der Metadaten zu einem Rule Service leitet. In

Abschnitt 8.2.1.1, „Standard-Metadata Mapper“ ist die

Funktionsweise genauer erklärt. Zu beachten ist, dass die Elemente, welche unter target eingetragen werden ebenfalls angepasst werden können, wenn ein benutzerdefinierter Matadata Mapper eingesetzt wird, wie das in

Abschnitt 8.2.1.3, „Benutzerdefinierter Metadata Mapper“ beschrieben ist.

Das nächste Element ist configuration, dass genau dasselbe ist, wie in Abschnitt 6.1.2, „Format der Rule

Service Anfrage“

beschrieben. Als nächstes kommt das input Element, welches beliebige Elemente akzeptiert.

Das ist der Nachteil des generischen Ansatzes und dies ist zugleich der größte Unterschied zur spezifischen

Anfrage, die genau beschriebt, welche Elemente und Typen enthalten sind.

<gen:VRRequest xmlns:vr="http://www.visual-rules.com"

xmlns:gen="http://www.visual-rules.com/generic" >

<target>

<ruleModel>Movie Ticket Pricing</ruleModel>

<rulePath>/Movie Ticket Pricing/Pricing</rulePath>

<!--Eines der beiden Elemente kann angegeben werden:-->

<effectiveDate>2009-10-03</effectiveDate>

<!-- oder -->

<version>1.0.1</version>

</target>

<!-- Optional -->

<vr:configuration>

<!-- Die gleichen Elemente wie in der spezifischen Anfrage -->

</vr:configuration>

<input>

<!-- Diese Elemente werden nicht vom XML Schema definiert. Die hier verwendeten

Daten und Typen müssen vom Regelinterface akzeptiert werden. -->

<auditorium_no>1</auditorium_no>

<seat_no>199</seat_no>

<show_date>2008-08-22</show_date>

<coupon>true</coupon>

<student>true</student>

<bonus_card>GOLD</bonus_card>

</input>

</gen:VRRequest>

Die Antwort einer generischen Anfrage unterscheidet sich nicht von der einer spezifischen Anfrage.

Related Concepts.

Abschnitt 6.1.5, „XML Repräsentation von Datentypen“

Beispiel 6.4. Generic VRRequest format

6.1.5. XML Repräsentation von Datentypen

6.1.5.1. Einfache Typen

Einfache Typen werden auf folgende XML Schema Typen abgebildet:

Visual Rules Datentyp

String

Integer xsd:string xsd:integer

XML Schema Typ

© Bosch Software Innovations 55/71

Kapitel 6. Aufrufen von Regeln im Execution Server

Visual Rules Datentyp XML Schema Typ

Float

Boolean

Date

Time

Timestamp xsd:decimal xsd:boolean xsd:date xsd:time xsd:dateTime

String

Werte werden einfach als Text abgebildet (ohne Anführungszeichen). Zum Beispiel wird in diesem XML

Fragment für ein Datenelement name ein String Wert "Peter" angegeben.

<name>Peter</name>

Integer

Werte werden als Ganzzahlen abgebildet. Zum Beispiel wird in diesem XML Fragment 199 als der ganzzahlige Wert für ein Datenelement seat_no angegeben.

<seat_no>199</seat_no>

Float

Werte werden als Gleitkommazahlen dargestellt, unter Verwendung eines Punkt als Dezimaltrennzeichen.

Zum Beispiel wird in diesem XML Fragment für verschiedene Datenelemente jeweils eine Gleitkommazahl als Wert angegeben. Bitte lesen Sie die XML Schema Dokumentation für detaillierte Beschreibungen von xsd:decimal

.

<price>7.45</price>

<rate>-.4453</rate>

Boolean

Werte werden durch das Wort true oder false abgebildet. Der XML Typ ist xsd:boolean.

<student>true</student>

<coupon>false</coupon>

Date

Werte entsprechen dem Format: YYYY-MM-DD. Dabei stehen die ersten vier Zeichen für das Jahr, dann zwei Zeichen für den Monat und schließlich zwei Zeichen für den Tag, wobei alle durch Bindestriche (-) getrennt sind. Bitte lesen Sie die XML Schema Dokumentation für eine detaillierte Beschreibung von xsd:date.

<show_date>2008-08-22</show_date>

Time

Werte entsprechen dem Format: hh:mm:ss. Die ersten zwei Zeichen stehen für die Stunde, dann Minuten und Sekunden, jeweils getrennt durch Doppelpunkte (:). Kein Bestandteil kann weggelassen werden. Bitte lesen

Sie die XML Schema Dokumentation für eine detaillierte Beschreibung von xsd:time.

<alarm>15:47:23</alarm>

Timestamp

Werte werden entsprechend dem XML Schema Typ xsd:dateTime repräsentiert. Das Format ist YYYY-MM-DDThh:mm:ss, was das Datum und die Zeit getrennt durch den Buchstaben T darstellt. Kein

Bestandteil darf weggelassen werden. Bitte lesen Sie die XML Schema Dokumentation für eine detaillierte

Beschreibung für das Format von xsd:dateTime.

<startTimestamp>2009-05-30T09:30:10</startTimestamp>

Sofern Werte ausdrücklich als leer angegeben werden sollen (in Java durch null repräsentiert), kann dies durch

Angabe das xsi:nil Attributes erreicht werden. Dazu ist es erforderlich, in der Anfrage auch den Namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

zu importieren.

<myDate xsi:nil="true" />

Beachten Sie, dass die Angabe des xsi:nil Attributes nur für Datentypen funktioniert, die dies unterstützen. Diese Angabe ist beispielsweise wirkungslos, wenn es sich in Java um einen primitiven

Datentyp wie int handelt, da diese ihrer Natur nach immer einen Wert haben.

© Bosch Software Innovations 56/71

Kapitel 6. Aufrufen von Regeln im Execution Server

6.1.5.2. Strukturen

Werte von Strukturen in einer Anfrage oder einer Antwort werden einfach durch Elemente von jedem Attribut repräsentiert. Zum Beispiel repräsentiert das folgende XML Fragment den Wert des Datenelements customer mit zwei Attributen name und address. Dabei hat address selbst ein Attribut zip.

<customer>

<name>John Doe</name>

<address>

<zip>12345</zip>

</address>

</customer>

6.1.5.3. Listen und Mengen

Die Werte einer Liste oder Menge in einer Anfrage oder Antwort wird durch eine Reihe von element Tags abgebildet.

Zum Beispiel sieht eine Liste (oder Menge) von Strings so aus:

<names>

<element>John Doe</element>

<element>Peter Pan</element>

<element>Captain Hook</element>

</names>

Und dies ist eine Liste (oder Menge) von Kunden, wobei jeder Kunde die Attribute name und address hat:

<customers>

<element>

<name>John Doe</name>

<address>

<zip>12345</zip>

</address>

</element>

<element>

<name>Peter Pan</name>

<address>

<zip>99999</zip>

</address>

</element>

<element>

<name>Captain Hook</name>

<address>

<zip>99996</zip>

</address>

</element>

</customers>

6.1.5.4. Maps

Maps werden durch eine Reihe von entry Tags spezifiziert, jede davon hat zwei Elemente, key und value genannt. Zum Beispiel ist dies ein String -> Customer Mapping mit zwei Einträgen:

© Bosch Software Innovations 57/71

Kapitel 6. Aufrufen von Regeln im Execution Server

<customerMap>

<entry>

<key>8847-736-90</key>

<value>

<name>John Doe</name>

<address>

<zip>12345</zip>

</address>

</value>

</entry>

<entry>

<key>2234-993-77</key>

<value>

<name>Peter Pan</name>

<address>

<zip>99999</zip>

</address>

</value>

</entry>

</customerMap>

6.1.5.5. Aufzählungen

Der Wert für eine Aufzählung wird einfach durch Angabe des gewünschten Literals definiert. Im folgende Beispiel wird für eine Aufzählung für das Datenelement bonus_card der Wert GOLD angegeben:

<bonus_card>GOLD</bonus_card>

6.1.6. Abbildung des Regelmodells auf WSDL

Wird ein Regelmodell als Rule Service exportiert, so wird die WSDL Datei mit folgender Prozedur erstellt:

• Die WSDL enthält einen Service, der <rule-model>Service genannt wird.

• Jede exportierte Regel wird durch eine Operation (in einem portType) repräsentiert, die mit dem Regelnamen endet.

Die WSDL Datei importiert einige XML Schema Dateien. Die XML Schema Dateien werden folgendermaßen erstellt:

• Es gibt eine XML Schema Datei für jede Ebene im Regelmodell, d.h. eine für das Regelmodell selbst, eine für jedes Regelpaket und eine für jede Regel (Ablaufregel oder Entscheidungstabelle), die für das Exportieren als

Rule Service gekennzeichnet wurde.

• Jede XML Schema Datei beinhaltet die Definitionen der Datentypen, die auf dieser Ebene des Regelmodells vorhanden sind.

• Die Namespace URI jedes XML Schemas ist vom Regelpaketnamen abgeleitet, d.h. Sie werden im XML

Schema Namespace die gleiche Hierarchie der Regelpakete und Regeln finden.

• Die XML Schema Dateien für exportierte Regeln enthalten auch die Definitionen des Nachrichtenformats für die

Input und Output Datenelemente. Anders ausgedrückt wird damit die Schnittstelle der Regel, einschließlich der

Namen und Typen aller Eingabe/Ausgabe Datenelemente, beschrieben.

Weiterführende Arbeitsschritte.

Abschnitt 5.2.5, „Anzeige der WSDL-Datei eines Rule Service“

© Bosch Software Innovations 58/71

Kapitel 6. Aufrufen von Regeln im Execution Server

6.2. Arbeitsschritte

6.2.1. Aufrufen eines Rule Service

Um einen Rule Service im Execution Server aufzurufen, müssen Sie eine SOAP Anfrage an den HTTP Endpunkt schicken, der in der WSDL spezifiziert wurde. Standardmässig ist dieser Endpunkt der gleiche für alle Rule

Services (was es einfacher für generische Clients macht).

Das Vorgehen, um einen Web Service aufzurufen, hängt stark von der Programmiersprache oder dem Tool ab, das Sie verwenden und kann hier nicht beschrieben werden. So wird in den folgenden Beschreibungen lediglich erklärt, was technisch und im SOAP Protokoll geschieht.

1.

Im Header der SOAP Nachricht liefert der Web Service Client Authentifizierungsdaten, wie im Abschnitt 6.1.1,

„Authentifizierung für eine Rule Service Anfrage“ beschrieben.

2.

Im Body der SOAP Nachricht spezifiziert der Web Service Client einen VRRequest, wie im Abschnitt 6.1.2,

„Format der Rule Service Anfrage“ beschrieben. Beispielsweise kann dies so aussehen:

<pricing:VRRequest

xmlns:pricing="http://www.visual-rules.com/vrpath/Movie%20Ticket%20Pricing/Pricing">

<input>

<auditorium_no>1</auditorium_no>

<seat_no>199</seat_no>

<show_date>2008-08-22</show_date>

<coupon>true</coupon>

<student>true</student>

<bonus_card>GOLD</bonus_card>

</input>

</pricing:VRRequest>

Nur der XML Namespace des VRRequest Elements wird vom Execution Server verwendet, um die Anfrage an das korrekte Regelmodell weiterzuleiten. Die URL des Service Endpunkts oder der SOAPAction HTTP Header sind nicht relevant für die Weiterleitung.

3.

Optional kann das target Element als das erste Element im VRRequest hinzugefügt werden, um genau zu spezifizieren, welche Version des Regelmodells aufgerufen werden soll. Wenn dies weggelassen wird, ruft der Execution Server die "neueste" Version auf.

4.

Wenn der Regelaufruf erfolgreich ist, erhalten Sie eine VRResponse wie in

Abschnitt 6.1.3, „Format der Rule Service Antwort“

beschrieben. Die Ergebnisse des Regelaufrufs können im output Element der VRResponse gefunden werden. Das zusätzliche Trace-Element beinhaltet Informationen über das aufgerufene Regelmodell, die Regel und die Version.

<pricing:VRResponse xmlns:vr="http://www.visual-rules.com"

xmlns:pricing="http://www.visual-rules.com/vrpath/Movie%20Ticket%20Pricing/Pricing">

<output>

<price>7</price>

</output>

<vr:trace>

<ruleModel>Movie Ticket Pricing</ruleModel>

<rulePath>/Movie Ticket Pricing/Pricing</rulePath>

<version>1.0.1</version>

</vr:trace>

</pricing:VRResponse>

Wenn irgendetwas fehlschlägt, erhalten Sie eine SOAP Fehlernachricht. Die Fehlernachricht enthält unter anderem einen Java Stack Trace für die Fehlerdiagnose.

Weiterführende Konzepte.

Abschnitt 6.1.1, „Authentifizierung für eine Rule Service Anfrage“

Abschnitt 6.1.2, „Format der Rule Service Anfrage“

Abschnitt 6.1.3, „Format der Rule Service Antwort“

Weiterführende Arbeitsschritte.

© Bosch Software Innovations 59/71

Kapitel 6. Aufrufen von Regeln im Execution Server

Abschnitt 5.2.5, „Anzeige der WSDL-Datei eines Rule Service“

© Bosch Software Innovations 60/71

Kapitel 7. Verwendung der RESTful Web Services

Kapitel 7. Verwendung der RESTful Web Services

7.1. Über REST

Representational State Transfer (REST) ist ein Architekturstil, der häufig im Bereich von webbasierten

Applikationen eingesetzt wird. Der Execution Server stellt Web Services bereit, welche durch eine REST API definiert sind. Diese sogenannten RESTful Web Services sind ausführlich in der REST API Dokumentation beschrieben, die über die

Webkonsole

erreichbar ist.

Die RESTful Web Services des Execution Servers sind erreichbar unter einer Basis-URL:

<protocol>://<host>:<port>/<context-path>/rest/<rest-api-version>

Jeder Service hat einen eigenen URL Bestandteil, welcher in der REST API Dokumentation beschrieben ist.

Beispielsweise ist der ruleServices Service auf einem Execution Server, der auf localhost bereitgestellt ist, erreichbar unter: http://localhost:8080/executionserver/rest/1/ruleServices

7.2. Authentifizierung

Die meisten RESTful Web Services verlangen eine Authentifizierung. Dafür wird der Basic Authentication

Standard verwendet. Neben dem Benutzernamen und dem Passwort muss zusätzlich auch der Name des

Mandanten angegeben werden. Da Basic Authentication nur Benutzername und Passwort unterstützt, wird der

Name des Mandanten dem eigentlichen Benutzernamen als weiterer Teil vorangestellt. Beide Teile werden dann durch ein '\' abgegrenzt und somit ist der Benutzername folgendermaßen aufgebaut: <MANDANT_NAME>

\<USER_NAME>

Beispiel: Wenn ein Benutzer Admin, der dem Mandanten BOSCH zugeordnet ist, mit Basic Authentication authentifiziert werden soll, dann lautet der Benutzername:

BOSCH\Admin

Beispiel 7.1. Mandant und Benutzername in Basic Authentication

7.3. Format der Rückgabe

Im Allgemeinen unterstützt REST verschiedene Formate (media type) als Rückgabe - selbst für den gleichen

RESTful Web Service. Die RESTful Web Services des Execution Server bieten verschiedene Formate an, zu denen JSON, XML und das

Atom Syndication Format gehören. Dies ist für jeden Service unterschiedlich und ist in

der REST API Dokumentation beschrieben. Sofern mehrere Formate unterstützt werden, kann in der Anfrage der bevorzugte media type mit dem Accept HTTP Header angegeben werden.

7.3.1. Atom Syndication Format

Manche der RESTful Web Services des Execution Server liefern Antworten im Atom Syndication Format , welches zusätzliche hypermediale Informationen in Form von Verlinkungen enthält. Das folgt der Idee von Hypermedia as the Engine of Application State (HATEOAS) .

Um eine Antwort im Atom Syndication Format zu erhalten, muss gegebenenfalls der media type in der HTTP

Anfrage an den RESTful Web Service spezifiziert sein. Der entsprechende media type für den Accept HTTP

Header ist: application/atom+xml

Das Atom Syndication Format spezifiziert zwei Elemente:

Atom Feed Document

und

Atom Entry Document

.

© Bosch Software Innovations 61/71

Kapitel 7. Verwendung der RESTful Web Services

7.3.1.1. Atom Feed Document

Wenn ein RESTful Web Service eine Liste von Ressourcen liefert, wird in der Antwort dafür das

Atom Feed

Document

eingesetzt. Werden zum Beispiel alle Versionen des Rule Service Movie Ticket Pricing angefragt, so könnte die Antwort ähnlich aussehen wie:

<feed xmlns="http://www.w3.org/2005/Atom">

<title>Versions of Movie-Ticket-Pricing</title>

<id>http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions?tenant=Bosch</id>

<updated>2005-07-31T12:29:29Z</updated>

<link rel="self" type="application/atom+xml"

href="http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions?tenant=Bosch"/>

<entry>

<title>Movie-Ticket-Pricing 6.0.1</title>

<id>http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions/6.0.1?tenant=Bosch</id>

<updated>2005-07-31T12:29:29Z</updated>

<link rel="alternate"

href="http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions/6.0.1?tenant=Bosch"/>

<link rel="wsdl"

href=".../services/<tid>/Movie-Ticket-Pricing/6.0.1/Movie-Ticket-Pricing.wsdl"/>

<author><name>6a8c5a50-dd2f-11e1-84b6-d4bed92ae488</name></author>

</entry>

<entry>

<title>Movie-Ticket-Pricing 5.4.3</title>

<id>http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions/5.4.3?tenant=Bosch</id>

<updated>2004-07-31T12:29:29Z</updated>

<link rel="alternate"

href="http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions/5.4.3?tenant=Bosch"/>

<link rel="wsdl"

href=".../services/<tid>/Movie-Ticket-Pricing/5.4.3/Movie-Ticket-Pricing.wsdl"/>

<author><name>7b9c5a50-dd2f-11e1-84b6-d4bed92ae488</name></author>

</entry>

</feed>

Beispiel 7.2. Atom Feed Document

In der Antwort wird die Liste der Versionen durch mehrere entry Elemente repräsentiert. Jedes entry Element enthält Links, welche eine weitere Navigation erlauben. Der Hyperlink link mit rel="alternate" zeigt auf eine alternative Darstellung, welche das

Atom Entry Document

für die Version im entry Element ist. Der Hyperlink link

mit rel="wsdl" zeigt auf die WSDL Datei des Rule Service in einer spezifischen Version und kann verwendet werden, um

Regeln aufzurufen

.

7.3.1.2. Atom Entry Document

Das Atom Entry Document wird verwendet, wenn nur eine einzige Ressource angefragt wird. Wird beispielsweise eine spezifische Version des Rule Service Movie Ticket Pricing angefragt, so könnte die Anwort ähnlich aussehen wie:

© Bosch Software Innovations 62/71

Kapitel 7. Verwendung der RESTful Web Services

<entry xmlns="http://www.w3.org/2005/Atom"

xmlns:vr="http://www.visual-rules.com">

<title>Movie-Ticket-Pricing 6.0.1</title>

<id>http:.../rest/1/ruleServices/Movie-Ticket-Pricing/versions/6.0.1?tenant=Bosch</id>

<updated>2005-07-31T12:29:29Z</updated>

<link rel="wsdl"

href=".../services/<tid>/Movie-Ticket-Pricing/6.0.1/Movie-Ticket-Pricing.wsdl"/>

<author><name>6a8c5a50-dd2f-11e1-84b6-d4bed92ae488</name></author>

<content xsi:type="vr:serviceAtomContent" vr:type="application/vnd.bosch-com.vr+xml">

<vr:name>Movie-Ticket-Pricing</vr:name>

<vr:version>6.0.1</vr:version>

<vr:active>true</vr:active>

<vr:activeConfiguration>Production</vr:activeConfiguration>

<vr:statisticsLevel>Quiet</vr:statisticsLevel>

<vr:metadata><key>Mode</key><value>fast</value></vr:metadata>

<vr:metadata><key>Language</key>value>german</value></vr:metadata>

</content>

</entry>

Beispiel 7.3. Atom Entry Document

Die Antwort ist ein entry Element und enthält mehr Details als es im Atom Feed Document der Fall ist. Die

zusätzlichen Informationen sind im content Element enthalten, welches spezifisch pro Ressource ist.

© Bosch Software Innovations 63/71

Kapitel 8. Arbeiten mit Metadaten

Kapitel 8. Arbeiten mit Metadaten

8.1. Konzept Metadaten

Metadaten werden durch einfache Schlüssel-Wert Paare abgebildet und können zu jedem Rule Service hinzugefügt werden. In erster Linie dienen sie als erweiterte Informationen für ein Regelmodell. Beispielsweise könnte dies der Name eines bestimmten Algorithmus sein, der für eine Berechnung eingesetzt wird, oder auch einfach nur der Autor der Regeln.

Wenn Sie in einem multinationalen Team arbeiten, sollten Sie passende Namen für Metadaten wählen, damit diese von jedem verstanden werden.

Mit Hilfe von Metadaten ist es möglich eine WSDL für einen Rule Service abzuholen und der Execution Server ist in der Lage damit generische Anfragen zu einem Rule Service zu leiten. Das hängt von der eingesetzten

Implementierung der Metadata Mapper Komponente ab. Eine Standardimplementierung einer Metadata

Mapper

Komponente ist in

Abschnitt 8.2.1.1, „Standard-Metadata Mapper“ beschrieben. Es ist auch möglich

eine benutzerdefinierte Implementierung zu verwenden. Letzteres ist in Abschnitt 8.2.1.3, „Benutzerdefinierter

Metadata Mapper“ beschrieben.

8.2. Metadaten definieren

Metadaten bestehen aus einer Menge eindeutiger Schlüssel und zugehöriger Werte. Es gibt zwei Wege, um

Metadaten zu bearbeiten. Sie können nach der Bereitstellung in der Webkonsole eingegeben werden (was in

Abschnitt 5.2.8, „Verwaltung der Metadaten eines Rule Service“ beschrieben ist) oder vor der Bereitstellung im

Visual Rules Modeler. Dabei werden die Metadaten im Regelmodell gespeichert und bilden eine feste Definition, die nach der Bereitstellung nicht mehr geändert werden kann. Das garantiert, dass die Metadaten immer existieren, auch wenn die Regelbibliothek auf mehreren Servern zum Einsatz kommt. Zu beachten ist, dass es weiterhin möglich ist, zusätzliche Metadaten über die Webkonsole anzugeben.

Um Metadaten im Visual Rules Modeler anzugeben führen Sie folgende Schritte aus:

1.

Im Projekt Explorer oder Regel Explorer, wählen Sie das Regelmodell aus, welches als Rule Service exportiert werden soll.

2.

Wechseln Sie zur Seite Metadaten in der Sicht Eigenschaften.

3.

Drücken Sie den Knopf neben der Execution Server Tabelle. Ein Eintrag in der Schlüssel Spalte wird angelegt, mit einem default Namen. Der Schlüssel kann durch einen Doppelklick bearbeitet werden. Mit dem

Knopf kann ein Schlüssel und sein Wert gelöscht werden.

4.

Mit einem Doppelklick in die Wert Spalte neben dem Schlüssel kann ein Wert hinzugefügt oder bearbeitet werden.

© Bosch Software Innovations 64/71

Kapitel 8. Arbeiten mit Metadaten

Schlüssel und Wert müssen in einem bestimmten Format angegeben werden. Die Länge muss mindestens ein

Zeichen, aber maximal 255 Zeichen sein. Leerzeichen sind innerhalb des Elements erlaubt, jedoch nicht am

Anfang oder am Ende. Zu beachten ist, dass nur Schlüssel und Werte in der Execution Server Tabelle für die

Bereitstellung verwendet werden.

8.2.1. Zuordnung von Metadaten zu Rule Services

Der Execution Server ist in der Lage, anhand von Metadaten eine WSDL zu liefern oder eine generische Anfrage zu einem Rule Service zu leiten. Dies wird dadurch bewerkstelligt, dass Metadaten einem bestimmten Rule

Service zugeordnet werden. Die Komponente, die dafür verantwortlich ist, heißt Metadata Mapper.

Abhängig davon, welche Werte in den Metadaten definiert sind und was in der Anfrage angegeben wurde, kann es dazu kommen, dass es keine eindeutige Zuordnung gibt. Je nachdem, welches Protokoll verwendet wird, führt das in so einem Fall zu einem SOAP oder HTTP Fehler.

8.2.1.1. Standard-Metadata Mapper

Die Standardimplementierung des Metadata Mapper benutzt ruleModel, rulePath und optional version für die Weiterleitung einer Anfrage. Damit kann eine generische Anfrage anstelle einer spezifischen verwendet

werden, wie das in Abschnitt 6.1.4, „Generische Rule Service Anfragen“

beschrieben wird. Abgesehen davon ist es möglich, effectiveDate in Kombination mit ruleModel und rulePath zur Weiterleitung einer Anfrage zu benutzen. In diesem Fall soll ein Rule Service ausgeführt werden, der zu einem bestimmten Datum gültig ist.

Der rulePath hat das gleiche Format, wie es in der Generischen Regel Ausführung API verwendet wird, die im Java Integration Handbuch beschrieben ist.

Der Standard-Metadata Mapper benutzt die Rule Service Einstellungen gültig von (validFrom) und

gültig bis

(validTo). Ein Rule Service ist gültig, falls sich effectiveDate zwischen den Grenzen von gültig von

und gültig bis (inklusive) befindet. Ist eine der Grenzen nicht gesetzt, wird dies als "immer" interpretiert. Sind beide Grenzen nicht gesetzt, dann ist ein Rule Service immer gültig.

Der Hauptanwendungsfall sind Rule Services in unterschiedlichen Versionen, die zu unterschiedlichen Zeiten gültig sind. Gibt es zum Beispiel ein Movie Ticket Pricing in Version 1.0, das ein gültig bis auf

2008-12-31 gesetzt hat und es gibt ein weiteres in Version 2.0, dessen gültig von auf 2009-01-01 gesetzt ist, dann wird eine Anfrage mit einem effectiveDate auf einen Wert vor dem 2009-01-01 die Version 1.0 ausführen und im anderen Fall die Version 2.0.

Aus Gründen der Abwärtskompatibilität werden weiterhin zwei spezielle Metadaten, nämlich effectiveFrom und effectiveTo

unterstützt. Jeder Wert repräsentiert ein Datum und folgt dem Format yyyy-mm-dd. Zu beachten ist, dass diese Metadaten nur verwendet werden, wenn weder gültig von noch gültig bis gesetzt sind.

© Bosch Software Innovations 65/71

Kapitel 8. Arbeiten mit Metadaten

8.2.1.2. Eine WSDL durch Angabe von Metadata abholen

Der Execution Server erlaubt es, eine WSDL für einen Rule Service durch die Angabe von Metadaten abzuholen.

Die dafür benutzte URL hat die Form http://<server>:<port>/<context-name>/services/<tenantid>/wsdl

und Metadaten Elemente werden als Parameter angefügt. Die akzeptierten Werte hängen von der

Implementierung des Metadata Mapper ab.

Im folgenden Beispiel wird eine Standardinstallation des Execution Servers, die unter der URL http:// localhost:8080/executionserver-6.x.y/

verfügbar ist, und ein Mandant mit ID 00ef-02394 angenommen. Wegen der Lesbarkeit wurden Zeilenumbrüche eingefügt. Normalerweise würde die URL in einer

Zeile eingegeben. Die Platzhalter x und y entsprechen dabei der Versionsnummer aus dem Dateinamen der WAR

Datei des Execution Servers.

http://localhost:8080/executionserver-6.x.y/services/00ef-02394/wsdl

?ruleModel=Movie%20Ticket%20Pricing

&rulePath=/Movie%20Ticket%20Pricing/Pricing

&effectiveDate=2008-01-01

In der URL im Beispiel wird eine WSDL für das Regelmodell Movie Ticket Pricing mit der Regel Pricing angefragt, das gültig ist am 2008-01-01. Zu beachten ist, dass Sonderzeichen maskiert werden müssen, wenn sie in einer URL verwendet werden.

Beispiel 8.1. Beispiel einer URL mit dem Standard Metadata Mapper

8.2.1.3. Benutzerdefinierter Metadata Mapper

Die Anpassung des Metadata Mapper ist ein fortgeschrittenes Thema, da dies die Anpassung der Execution

Server Installation, die Erweiterung einer abstrakten Java Klasse und die Änderung einer XML Schema Datei erfordert. Der Vorgang wird anhand eines Beispiels dargestellt.

Der angepasste Metadata Mapper wird mit dem Metadatum rating (was die Kurzform für "Rating Verfahren" ist), der version und dem Metadatum rulePath (welches die Regel spezifiziert, die das Rating Verfahren ausführt) arbeiten. Letzteres wird aus technischen Gründen benötigt, weil dies erlaubt, eine generische Anfrage zu formulieren, ohne das zu verwendende Regelmodell oder Regel angeben zu müssen. Für diesen Fall ist es also erforderlich, dass rulePath auf jedem Rule Service definiert wird, der auch rating unterstützt.

Das einzige notwendige Element in einer generischen Anfrage ist rating. Weil dies unter Umständen nicht ausreicht, um zu entscheiden, welcher Rule Service auszuführen ist, wird im Beispiel auch die Angabe version wie auch andere Metadaten verwendet.

Im ersten Schritt muss die meta.xsd geändert werden, um valide generische Anfragen zu erlauben. Die

Schlüssel und Typen der Metadaten gehören innerhalb des target Elements. Der untere Ausschnitt zeigt, wie das aussehen könnte.

...

<xsd:complexType name="Target">

<xsd:sequence>

<xsd:element name="rating" type="xsd:string" />

<!-- Jeglicher Wert erlaubt -->

<xsd:sequence>

<xsd:any />

</xsd:sequence>

</xsd:sequence>

</xsd:complexType>

...

Als nächstes wird eine Java Klasse RatingMetaDataMapper erzeugt, welche die abstrakte Klasse de.visualrules.execution.core.spi.metadata.AbstractMetaDataMapper

erweitert. Da das Object später per Reflection geladen wird, muss ein default Konstruktur aufrufbar sein. Die abstrakte

Klasse fordert die Implementierung von zwei Methoden, nämlich mapRuleModelArtifact(..) und mapRuleInvocationTarget(..)

. Die erste Methode wird aufgerufen, sobald eine WSDL angefragt wird und die zweite, wenn eine generische Anfrage zu einem Rule Service weitergeleitet werden soll.

Die mapRuleModelArtifact(..) Methode bekommt zwei Argumente übergeben: die Metadaten als java.util.Properties

und eine Instanz des IArtifactStorageReadAccess. Als erstes wird

© Bosch Software Innovations 66/71

Kapitel 8. Arbeiten mit Metadaten geprüft, ob ein Wert für rating angeben wurde, ansonsten wird eine Ausnahme geworfen. Danach wird mittels der Metadaten ein IServiceView gesucht. Sofern einer gefunden wurde, wird dieser zu einem

RuleModelArtifact

konvertiert und zurückgegeben.

public RuleModelArtifact mapRuleModelArtifact(Properties metaData,

IArtifactStorageReadAccess artifactStorage)

throws AmbiguousRuleModelArtifactException

{

String rating = metaData.getProperty("rating");

if (rating == null)

{

throw new IllegalArgumentException("A rating must be set.");

}

IServiceView serviceView = findByMetaValues(metaData, artifactStorage);

return serviceView != null ? new RuleModelArtifact(serviceView) : null;

}

Die findByMetaValues(..) Methode benutzt die

IArtifactStorageReadAccess#listServicesWithMetaValue(..)

Methode um Rule Services zu finden, in deren Metadaten es einen passenden Wert für den Schlüssel rating gibt. Dies kann bei einer großen

Anzahl von Services der Fall sein. Zusätzlich werden solche aussortiert, deren Metadaten nicht zu denen passen, die in der Anfrage übergeben wurden. Danach bleibt im günstigsten Fall genau ein IServiceView übrig, der zurückgegeben werden kann. Es gibt jedoch auch die Möglichkeit, dass es mehrere Services oder gar keine gibt.

In letzterem Fall wird null zurückgeben, was impliziert, dass nichts gefunden wurde. Für mehrere Ergebnisse wird eine Ausnahme geworfen, die Informationen zu den gefundenen Services und ihren Metadaten enthält. Für dieses Beispiel macht dies durchaus Sinn. Die Anwendungslogik benutzt die Metadaten der Anfrage um einen passenden Rule Service zu finden. Um genauer zu werden, reicht die Angabe weiterer Werte in der Anfrage. Je spezifischer das wird, desto mehr Services können ausgefiltert werden, bis nur noch einer übrig ist.

Die Art und Weise, wie mit mehreren gefundenen Rule Services umgegangen wird, kann natürlich anders gehandhabt werden als im Beispiel. Es sollte nur sichergestellt werden, dass es das gleiche Verhalten ist wie bei der Implementierung der mapRuleInvocationTarget(..) Methode.

private static IServiceView findByMetaValues(Properties metaData,

IArtifactStorageReadAccess artifactStorage)

throws AmbiguousRuleModelArtifactException

{

String ratingValue = (String) metaData.get("rating");

if (ratingValue != null)

{

List services = filter(artifactStorage.listServicesWithMetaValue("rating", ratingValue),

metaData);

final int size = services.size();

if (size == 1)

{

return (IServiceView) services.get(0);

}

else if (size > 1)

{

IServiceView[] serviceViews = (IServiceView[]) services.toArray(

new IServiceView[size]);

throw new AmbiguousRuleModelArtifactException(

"There are multiple rule models that fit the requested meta values.",

serviceViews);

}

}

return null;

}

Die filter(..) Methode liefert nur die Services, deren Metadaten zur Anfrage passen, was mit der Methode matches(..)

geprüft wird.

© Bosch Software Innovations 67/71

Kapitel 8. Arbeiten mit Metadaten private static List filter(List services, Properties metaData)

{

List retVal = new ArrayList(services.size());

for (Iterator it = services.iterator(); it.hasNext();)

{

IServiceView serviceView = (IServiceView) it.next();

Map metaValues = serviceView.getMetaValues();

if (metaValues != null && matches(metaData, serviceView))

{

retVal.add(serviceView);

}

}

return retVal;

}

Die matches(..) Methode vergleicht jedes Schlüssel-Wert Paar aus der Anfrage mit denen von jedem

IServiceView

. Die Schlüssel in den Metadaten der Anfrage müssen eine Teilmenge der auf dem Service definierten bilden. Zudem müssen die Werte übereinstimmen. Die einzige Ausnahme ist die version, da diese kein Metadatum ist.

private static boolean matches(Properties metaData, IServiceView serviceView)

{

Map metaValues = serviceView.getMetaValues();

for (Iterator it = metaData.entrySet().iterator(); it.hasNext();)

{

Map.Entry me = (Map.Entry) it.next();

String key = (String) me.getKey();

String value = (String) me.getValue();

if ("version".equals(key))

{

if (value != null && !value.equals(serviceView.getVersion()))

{

return false;

}

}

else if (!metaValues.containsKey(key))

{

return false;

}

else if (!matchesValue(value, (IMetaValue) metaValues.get(key)))

{

return false;

}

}

return true;

}

Die matchesValue(..) Methode vergleicht nur die Werte unter Berücksichtigung von null.

private static boolean matchesValue(String value, IMetaValue metaValue)

{

if (value == null)

{

return metaValue.getValue() == null;

}

else

{

return value.equals(metaValue.getValue());

}

}

Damit ist der notwendige Code geschrieben, um eine WSDL mittels Metadaten abzuholen. Zum Beispiel ist es jetzt möglich, eine WSDL für einen Rule Service anzufragen, der ein Rating Verfahren PD benutzt und von John

Doe

erstellt wurde (die Platzhalter x und y entsprechen der Versionsnummer aus dem Dateinamen der WAR Datei des Execution Servers und 00ef-02394 stellt die ID des Mandanten dar).

http://localhost:8080/executionserver-6.x.y/services/00ef-02394/wsdl?rating=PD&author=John Doe

© Bosch Software Innovations 68/71

Kapitel 8. Arbeiten mit Metadaten

Der letzte Schritt für das Beispiel ist die Implementierung der Methode mapRuleInvocationTarget(..).

Diese wird aufgerufen, wenn eine generische Anfrage an den Execution Server geschickt wird. Weil hierbei etwas ausgeführt wird, spezifiziert der Rückgabewert auch die Regel, die ausgeführt werden soll. Im Beispiel wird hierfür das rulePath Metadatum verwendet. Die grundlegende Idee ist, dass jeder Rule Service "weiß", was seine

Einstiegsregel ist. Das erlaubt die Benutzung von Metadaten für die Weiterleitung einer Anfrage, ohne dass dabei ein Regelmodell oder dessen Regel angegeben werden muss.

Der folgende Ausschnitt zeigt die Implementierung der Methode mapRuleInvocationTarget(..). Auch hier wird zuerst die Existenz eines Werts für rating geprüft. Danach wird ein IServiceView für die Metadaten gesucht. Das erfordert genau die gleiche Zuordnung, wie sie in mapRuleModelArtifact(..) verwendet wird, weshalb die vorher geschriebene findByMetaValues(..) Methode wiederverwendet wird. Danach wird das

Metadatum rulePath ausgelesen, ein RuleInvocationTarget erzeugt und zurückgegeben.

public RuleInvocationTarget mapRuleInvocationTarget(Properties metaData,

IArtifactStorageReadAccess artifactStorage)

throws AmbiguousRuleModelArtifactException

{

String rating = metaData.getProperty("rating");

if (rating == null)

{

throw new IllegalArgumentException("No rating provided");

}

IServiceView serviceView = findByMetaValues(metaData, artifactStorage);

if (serviceView != null)

{

Map metaValues = serviceView.getMetaValues();

if (metaValues != null)

{

IMetaValue metaValue = (IMetaValue) metaValues.get("rulePath");

if (metaValue != null)

{

String rulePath = metaValue.getValue();

RuleInvocationTarget target = new RuleInvocationTarget(serviceView, rulePath);

return target;

}

}

throw new RuntimeException("No rulePath provided in service: " + serviceView);

}

return null;

}

Dieses Beispiel beachtet nicht, ob ein Rule Service aktiv ist oder nicht. Damit lassen sich somit auch eigentlich inaktive Rule Services aufrufen. Das kann durch eine Anpassung der filter(..)

Methode geändert werden, indem dort inaktive Services ausgefiltert werden.

Als nächstes muss der Execution Server konfiguriert werden, um das Beispiel

RatingMetaDataMapper

zu benutzen. Das wird erreicht durch die Einstellung visualrules.executionserver.metadata.custom.mapper

wie es in

Abschnitt 2.6, „Konfiguration des

Execution Servers“ beschrieben ist. Der Wert ist der vollqualifizierte Klassenname von RatingMetaDataMapper.

Mit dieser Konfiguration wird der Execution Server die Klasse beim Hochfahren laden. Es ist daher notwendig, dass sich die Klasse auf dem Klassenpfad befindet. Dies hängt vom eingesetzten Application Server ab.

Beispielsweise kann dies im Tomcat erreicht werden, indem die Klasse in ein JAR gepackt und in das Verzeichnis

WEB-INF/lib

der ausgepackten Webapplikation gelegt wird.

© Bosch Software Innovations 69/71

Anhang A. Rule Service Klassenlader and -Hierarchie

Anhang A. Rule Service Klassenlader and -Hierarchie

A.1. Rule Service Klassenlader

Der Execution Server ist in der Lage mehrere Versionen von Rule Services gleichzeitig zu betreiben. Das wird erreicht durch die Erzeugung eines Klassenladers für jeden Rule Service. Diese Klassenlader sind voneinander isoliert um Probleme beim Klassen laden zu vermeiden.

Jeder Rule Service hat Information über erforderliche Abhängigkeiten für die Ausführung. Diese wird zum

Zeitpunkt der Erstellung erzeugt und in der Webkonsole kann diese eingesehen werden. Wird ein Rule Service

zum ersten Mal angefragt

1

, dann wird ein Klassenlader erzeugt. Dieser lädt Klassen aus der Regelbibliothek und allen abhängigen Bibliotheken inklusive der Visual Rules Runtime. Falls eine Bibliothek nicht bereitgestellt wurde, wird eine Ausnahme geworfen, welche die Gruppen Id, Artefakt Id und Version der fehlenden Bibliothek enthält.

Das ist ein Früherkennungs-Mechanismus der Fehler wie die ClassNotFoundException bei der Ausführung von

Rule Services verhindert, deren Ursache schwer zu ermitteln sind.

Die Erzeugung eines Klassenladers benötigt seine Zeit. Damit dies nicht bei jeder Anfrage geschieht, werden die Klassenlader vom Execution Server in einem Cache vorgehalten. Nachfolgende Aufrufe des Rule Service werden dadurch schneller ausgeführt, da ein Klassenlader bereits verfügbar ist. Der Cache ist so lange aktiv wie der Rule Service verwendet wird. Wird innerhalb einer längeren Zeit der Rule Service nicht aufgerufen, wird der Klassenlader entfernt um Speicher frei zu geben. Wird der Rule Service danach wieder angefragt, wird der

Klassenlader automatisch neu erzeugt.

A.2. Klassenlader Hierarchie

Obwohl jeder Rule Service seinen Klassenlader hat, gibt es immer auch einen vorgelagerten Klassenlader. Da auch der Anwendungsserver mehrere Klassenlader verwendet, wird dadurch eine Hierarchie gebildet.

Abbildung A.1. Klassenlader Hierarchie

Die Hierarchie beeinflusst das Klassen laden. Klassen werden typischerweise vom vorgelagerten Klassenlader zuerst geladen

2

. Ist beispielsweise ein JDBC Treiber auf dem Klassenpfad des Anwendungsservers, so wird

1

Entweder bei einem Web Service Aufruf oder der Anforderung der WSDL

2

Manche Anwendungsserver können die Reihenfolge des Klassen ladens einstellen. Informationen dazu sollten sich in der

Dokumentation des Anwendungsservers befinden.

© Bosch Software Innovations 70/71

Anhang A. Rule Service Klassenlader and -Hierarchie dieser vom Anwendungsserver Klassenlader zuerst geladen. Sofern in diesem Beispiel der JDBC Treiber von einem Rule Service Klassenlader geladen werden soll, wird stattdessen die Klasse verwendet, die vom

Anwendungsserver Klassenlader zuerst geladen wurde. Daher ist es empfehlenswert, den Klassenpfad und

Einstellungen des Anwendungsservers genau zu prüfen.

© Bosch Software Innovations 71/71

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents