Einbindung einer View >>> Customer

[schorschi]

Hallo,

ich habe gestern erfahren, dass man die Kunden mittels einer View in OTRS einbinden kann. Kann mir jemand detailliert erklären wie man das konfigurieren muss - oder einen Verweis im Internet nennen?? Google bietet mir leider nicht so wirklich praktische Hilfe an!
Wäre über jede Hilfe dankbar!

Gruß Schorschi

[ElPato]

Was genau meinst du?

[schorschi]

Was genau meinst du?

Entschuldigung für die schwamige Formulierung. Ich meine, wie bringe ich OTRS bei die View zu erkennen?? Das wird ja sicherlich in der Config.pm konfiguriert. Welche Paramenter werden denn dann benötigt?? Gibs zu dem Thema vielleicht ne Vorlage die man an seine eigenen Bedürfnisse anpassen kann??

[jojo]

Den entsprechenden CustomerUser Teil aus der Defaults.pm in die Config.pm kopieren. Sollte auch ggf. hier schon mal beschrieben worden sein.

[noeggeL]

Eine View ist eine in der DB gespeicherte select Anweisung.

Nehmen wir mal an, wir wollen in OTRS Kundenbenutzerdaten von einer externen Datenbank verwenden.
OTRS kann das sehr schön realisieren und dies ist auch gut im Kapitel 11 im Handbuch (und auf den FAQ von OTRS.org) beschrieben.
NUR...
Wenn die abzufragenden Daten in der externen Datenbank NICHT in der gleichen Tabelle gespeichert sondern auf 3, 4, 5 oder mehr Tabellen verteilt sind, wirds etwas schwierig.

Die Parameter werden im OTRS pro backend definiert und sehen nur jeweils eine Tabelle vor, wo die Daten gesucht werden.

$Self->{CustomerUser} = {
Name => 'DatenbankName',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
DSN => 'DBI::mysql:database=customerdb;host=customerdbhost',
User => 'customerdbhostuser',
Password => 'customerdbhostuserpassword',
Table => 'customerdbtable'
...

In diesem Beispiel versucht nun OTRS eine MySQL DB anzusprechen. Die Parameter bedeuten:
Name: irgendein sinnvoller Name, wird im Adminbereich unter dem Punkt "Customer Users" und dort unter "Source" angezeigt.
DSN (database): der Name wie die DB selber heisst
DSN (host): der (FQDN) des DB Servers
User: der DB User, der (mindestens) read Access auf die DB hat
Passwort: das zum DB ser passende Passwort (naja, eigentlich selbsterklärend)
Table: die Tabelle, wo alle abzufragenden Informationen in der Datenbank abgelegt sind.

Wenn ich nun für das OTRS z.B. "Anrede", "Vorname", "Familienname", "Login", "Passwort", "E-Mail", "Telefonnummer", "CustomerID", "CustomerName" und "Valid" abfragen will, müssen all diese Felder innerhalb der gleichen Tabelle stehen.

Nun kommt die Herausforderung: Die Felder stehen eben nicht in der gleichen Tabelle, sondern:

Tabelle "credentials": Login, Passwort und Valid
Tabelle "person": Anrede, Vorname, Familienname
Tabelle "customer": CustomerID, CustomerName
Tabelle "contact": E-Mail, Telefonnummer

also kann ich in der OTRS Config.pm nur einen Teil der benötigten Informationen ansprechen, was in diesem Fall natürlich nicht genügt.

Die Lösung ist eben eine View (wobei MySQL Views erst ab Version 5 unterstützt). Man definiert eine View (eben ein select Statement, welches alle benötigten Informationen umfasst). Diese View erscheint wie eine normale Tabelle, aber eben nur wie EINE Tabelle. Beim Zugriff auf die Felder der "View-Tabelle" übersetzt das DBMS die Anfrage. So kann man mit einem einfachen select von aussen ein kompliziertes select mit mehreren Joins und Bedingungen konstruieren. Die genaue Ausarbeitung der View kommt natürlich auf das jeweilige Datenbankdesign an.

So, ich hoffe, das ist einigermassen zu verstehen...
Gruss, noeggeL

[schorschi]

Eine View ist eine in der DB gespeicherte select Anweisung.

Nehmen wir mal an, wir wollen in OTRS Kundenbenutzerdaten von einer externen Datenbank verwenden.
OTRS kann das sehr schön realisieren und dies ist auch gut im Kapitel 11 im Handbuch (und auf den FAQ von OTRS.org) beschrieben.
NUR...
Wenn die abzufragenden Daten in der externen Datenbank NICHT in der gleichen Tabelle gespeichert sondern auf 3, 4, 5 oder mehr Tabellen verteilt sind, wirds etwas schwierig.

Die Parameter werden im OTRS pro backend definiert und sehen nur jeweils eine Tabelle vor, wo die Daten gesucht werden.

$Self->{CustomerUser} = {
Name => 'DatenbankName',
Module => 'Kernel::System::CustomerUser::DB',
Params => {
DSN => 'DBI::mysql:database=customerdb;host=customerdbhost',
User => 'customerdbhostuser',
Password => 'customerdbhostuserpassword',
Table => 'customerdbtable'
...

In diesem Beispiel versucht nun OTRS eine MySQL DB anzusprechen. Die Parameter bedeuten:
Name: irgendein sinnvoller Name, wird im Adminbereich unter dem Punkt "Customer Users" und dort unter "Source" angezeigt.
DSN (database): der Name wie die DB selber heisst
DSN (host): der (FQDN) des DB Servers
User: der DB User, der (mindestens) read Access auf die DB hat
Passwort: das zum DB ser passende Passwort (naja, eigentlich selbsterklärend)
Table: die Tabelle, wo alle abzufragenden Informationen in der Datenbank abgelegt sind.

Wenn ich nun für das OTRS z.B. "Anrede", "Vorname", "Familienname", "Login", "Passwort", "E-Mail", "Telefonnummer", "CustomerID", "CustomerName" und "Valid" abfragen will, müssen all diese Felder innerhalb der gleichen Tabelle stehen.

Nun kommt die Herausforderung: Die Felder stehen eben nicht in der gleichen Tabelle, sondern:

Tabelle "credentials": Login, Passwort und Valid
Tabelle "person": Anrede, Vorname, Familienname
Tabelle "customer": CustomerID, CustomerName
Tabelle "contact": E-Mail, Telefonnummer

also kann ich in der OTRS Config.pm nur einen Teil der benötigten Informationen ansprechen, was in diesem Fall natürlich nicht genügt.

Die Lösung ist eben eine View (wobei MySQL Views erst ab Version 5 unterstützt). Man definiert eine View (eben ein select Statement, welches alle benötigten Informationen umfasst). Diese View erscheint wie eine normale Tabelle, aber eben nur wie EINE Tabelle. Beim Zugriff auf die Felder der "View-Tabelle" übersetzt das DBMS die Anfrage. So kann man mit einem einfachen select von aussen ein kompliziertes select mit mehreren Joins und Bedingungen konstruieren. Die genaue Ausarbeitung der View kommt natürlich auf das jeweilige Datenbankdesign an.

So, ich hoffe, das ist einigermassen zu verstehen...
Gruss, noeggeL

oh, super vielen Dank für deine verständlichen Worte!
Gruß schorschi

[InXone]

Vielen, vielen Dank für diese ausführliche Erklärung. Hat mir sehr weitergeholfen!