Database Integration

[cjs1976]

Hallo,

ich versuche gerade unsere 3CX V18 Enterprise mit einer MySQL-Datenbank zu verbinden um eine Anruferidentifizierung aufzubauen (sieh https://www.3cx.com/docs/sql-database-pbx-integration). Leider hat unsere Warenwirtschaft keine API und somit muss ich mir etwas Eigenes aufbauen.

MySQL (Postgre, MS-SQL usw.) sind eigentlich kein Problem, aber ich verstehe nicht, wie viele Tabellen und welche Spalten (und Typen) man braucht.

Kennt hier zufällig jemand diese Date, oder weiß wo ich die finden kann?

Danke,
Christian.

 

[fxbastler]

Hallo,

schau dir bitte die dazu passende Anleitung von 3CX an. Da sind auch Beispiele anbei.

 

[cjs1976]

Hallo fxbastler,

ja das ist genau der selbe Link den ich gepostet habe. Den habe ich, aber damit komme ich nicht klar. Ich bräuchte ein paar mehr Informationen.

Danke,
Christian.

 

[fxbastler]

Ja, richtig - da stehen doch aber alle notwendigen SQL Selects, um eine DB Abfrage (nach anrufenden Nummer) durchzuführen, komplett drin.

Bei dieser Art der Anbindung einer 3CX an eine DB geht es (für die 3CX) primär darum, Anrufer an Hand einer SQL Datenbank zu ermitteln, in der 3CX anzuzeigen und in deren Telefonbuch zu übernehmen. Das war auch deine Frage.

Es wird per SQL in der Textvariablen %[Number]% von der 3CX die anrufende Nummer am SQL Server angefragt und die 3CX bekommt einen Sack voll Daten (wieder alles Text) für sich zurück. Was du aus 'dieser SQL Abfrage' machst und was an realen Daten zurückgegeben wird ist deine Sache. Wieviele Tabellen du in deiner DB für diese Abfrage brauchst hängt ja von deiner DB, deren Tabellen und Organisation ab. Das interessiert die 3CX nicht. Die will nur saubere Rückgabewerte wie in der Doku angegeben bekommen.

Das Einzige was unklar sein könnte sind evtl. die max. Längen der einzelnen Textfelder die auch wirklich in die 3CX übernommen werden. Dazu hier der originale Teil eines SQL Dump der 3CX DB an dieser Stelle (das was wirklich bleibt):

CREATE TABLE public.phonebook (
    idphonebook integer DEFAULT nextval('public.sqphonebook'::regclass) NOT NULL,
    firstname character varying(255) DEFAULT ''::character varying,
    lastname character varying(255) DEFAULT ''::character varying,
    phonenumber character varying(255) DEFAULT ''::character varying,
    fkidtenant integer,
    fkiddn integer,
    company character varying,
    tag character varying,
    pv_an5 character varying,
    pv_an0 character varying,
    pv_an1 character varying,
    pv_an2 character varying,
    pv_an3 character varying,
    pv_an4 character varying,
    pv_an6 character varying,
    pv_an7 character varying,
    pv_an8 character varying,
    pv_an9 character varying,
    CONSTRAINT phonebook_check CHECK (((fkiddn IS NOT NULL) OR (fkidtenant IS NOT NULL)))
);

Aber diese Felder selber sind nicht interessant. Der Rückgabewert des Select pflegt die ggf. selber ein und schneidet ggf. ab.

Das muss ja auch kein reines Select sein. Da kann man ja die Nummer, das akt. Datum und die akt. Uhrzeit in ein 'Update' einpacken um so neben der Abfrage für die 3CX auch eine neue Zeile in den Bewegungsdaten der DB zu erzeugen. Das mal so als Denkanstoss für später. Achtung: so eine Abfrage wird nicht unbedingt bei jedem Anruf durchgeführt. Wenn die 3CX einen Select dieser Art durchführt und der trifft, dann wird die nächste derartige SQL Abfrage (weil gleicher Anrufer) auf Grund des Treffers erst nach x Minuten (ich glaube 10, kann man mit Tricks verringern) ausgeführt. Das würde sonst zu Lücken im Protokoll der SQL DB führen. Hatten wir schon. Hat genervt und Zeit gekostet das rauszubekommen.