Nutzerdefinierte SQL-Variablen und ihre Einsatzmöglichkeiten in WINcontact

Variablen als Platzhalter für spezifische Informationen haben in WINcontact einen hohen Stellenwert. Mit ihrer Hilfe lassen sich fast alle Informationen, die irgendwie in der WINcontact - Datenbank verfügbar sind, in Gesprächsleitfäden oder in Fragenkatalogen verwenden. Am besten, wir schauen uns dazu ein Beispiel an:

Hier sehen Sie eine Seite des Gesprächsleitfadens im Designmodus im Administration-Center. Wie leicht zu erkennen ist, sind Teile des Textes durch "Platzhalter" in Form von SQL-Variablen ersetzt worden. Diese Variablen sind immer in geschwungenen Klammern eingeschlossen und beginnen mit dem Präfix VAR.USER. Zur "Laufzeit", also wenn der Callagent in seinem Clientprogramm diese Gesprächsleitfadenseite aufblendet, sind selbstverständlich nicht mehr diese "Variablenbezeichner" auf dem Bildschirm zu sehen. Stattdessen werden deren Inhalte (die sich, wie wir noch sehen werden, aus jeweils einer SQL-Anweisung ergeben) ausgegeben. {VAR.USER_Ansprechpartner} wird z. B. durch den Namen der Person ersetzt, der gerade aktuell angerufen wird. Und die SQL-Variable {VAR.USER_NACHNAME} liefert offensichtlich den Familiennamen des angemeldeten Callagenten zurück. 

Derartige Variablen können Sie in WINcontact selbst erstellen. Dazu dient ein spezieller Variableneditor für SQL-Variablen.

Wo können überall in WINcontact SQL-Variablen eingesetzt werden?

Das Variableninterface haben wir so konzipiert, daß es an allen Stellen im Programm, wo es Sinn macht, verfügbar ist:

• Gesprächsleitfaden (Platzhalter)
• Fragenkatalog (sowohl für Label als auch für Vorgaben von Eingabeelementen)
• SQL-Manager
• Reportdesigner
• Ereigniseditor (diverse Befehle)
• Textbausteineditor (z. B. für E-Mail-Texte mit Platzhaltern)

Was ist eine SQL-Variable?

Der Inhalt einer SQL-Variable wird über eine vom Nutzer definierte SQL-Anweisung erzeugt, was im einfachsten Fall eine SELECT-Anweisung ist, die aber nur einen Wert zurückliefern darf:

{VAR.USER_NACHNAME}
SELECT NACHNAME FROM TMGLOBAL..NUTZER
WHERE NUTZERID={USERID}

{VAR.USER_Ansprechpartner}
SELECT LTRIM(ISNULL(ANREDE,'')+' '+NACHNAME) AS Ansprechpartner
FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Die bereits vordefinierten Variablen {USERID} und {ADRESSENID} enthalten jeweils die ID's des gerade angemeldeten Nutzers bzw. die Adressen-ID der gerade in Bearbeitung befindlichen Adresse.

Genau in dieser Form lassen sich eigene Abfragen erstellen, die genau die Daten zurückliefern, wie man sie in einem konkreten Projekt z.B. im Gesprächsleitfaden oder im Fragenkatalog benötigt. Die einzige Kunst besteht darin, eine entsprechende Abfrage zu entwickeln und sie dann mit einem Variablennamen zu verbinden. Und genau dazu dient der SQL-Variableneditor. Er enthält übrigens bereits eine umfangreiche Bibliothek vordefinierter SQL-Variablen, die sich bei Bedarf sofort in ein Projekt übernehmen lassen.

SQL-Variableneditor

Der Variableneditor läßt sich in dem jeweiligen Kontext (z. B. im Gesprächsleitfaden oder einem Label im Fragenkatalog) jeweils über das Kontextmenü (rechte Maustaste) öffnen:

Der Editor selbst ist recht schlicht und einfach gehalten:

Er besteht aus zwei Teilen. Im oberen Teil befindet sich der eigentliche Editor. Darin wird die jeweilige SQL-Anweisung formuliert. Erst nach der "Übernahme" erfolgt die Bindung mit einem Variablennamen:

Als Variablenname wird standardmäßig "VARIABLE+fortlaufende Nummer" vorgegeben. Sie sollte anschließend durch einen "sinnvollen" Namen ersetzt werden, hier z.B. KURZNAME_FIRMA.  Wenn dann auch der Test noch erfolgreich verlaufen ist, steht die neue SQL-Variable nach Schließen des Editors im Kontextmenü zur Verfügung:

Ab jetzt kann diese Variable, die immer den Kurznamen der gerade aktiven Adresse zurückliefert, in jedem verfügbaren Kontext in WINcontact verwendet werden.

Verwendung von SQL-Variablen aus der Template-Bibliothek

Wir bieten im Variableneditor eine kleine Bibliothek bereits vordefinierter SQL-Variablen an, die sich mit wenigen Mausklicks in ein Projekt übernehmen lassen. Um an diese Bibliothek zu gelangen,  müssen Sie zuerst den Variablen-Editor und dann im unteren Variablenbereich das Kontextmenü (rechte Maustaste) öffnen:

Die Variablen können aus drei Kategorien ausgewählt werden.

1. Angemeldeter Agent

2. Aktuelle Adresse

3. Aktuelles Projekt

(Erweiterungen sind in den Folgeversionen möglich)

Zur Übernahme in den Variableneditor brauchen Sie nur die gewünschte Variable aus dem Kontextmenü auswählen. Sie wird dann in den Variablenbereich übernommen. Ein Klick darauf zeigt Ihnen dann auch die dazugehörige SQL-Anweisung im Editorbereich an, wo Sie eventuell Änderungen oder Anpassungen vornehmen können:

Typen von nutzerdefinierten SQL-Variablen

Es gibt zwei Typen von nutzerdefinierten Variablen in WINcontact. Standard ist der Typ (erkennbar am „Häuschen-Icon“), der bewirkt, dass die Variable im Clientprogramm immer bei einem Adreßwechsel aktualisiert wird. Es gibt aber auch Variablen, die brauchen im Client nur einmal, und zwar beim Projektwechsel aktualisiert werden (z. B. Variablen, die Daten über den angemeldeten Callagenten oder das aktuelle Projekt zurück liefern). Dazu müssen Sie über die entsprechende Funktion im Kontextmenü im Variablenbereich des Editors lediglich den Typ auf „bei Projektwechsel“ ändern. Darüber hinaus können Sie unter dem gleichen Menüpunkt noch festlegen, ob die Variable in allen Projekten des Mandanten oder nur in dem Projekt, in dem sie angelegt wurde, verfügbar sein soll.

Eigene SQL-Variablen anlegen

Eine SQL-Variable hat in WINcontact immer die Form

{VARIABLE}=SELECT-Anweisung, die genau einen Wert zurückliefert

Um z. B. den Namen des gerade am Client angemeldeten Callagenten zu erfahren, muss die entsprechende SQL-Anweisung

SELECT VORNAME+' '+NACHNAME FROM TMGLOBAL..NUTZER
WHERE NUTZERID={USERID}

lauten. Die Anschrift des Kunden, der gerade angerufen wird, läßt sich über folgende SQL-Anweisung in Erfahrung bringen:

SELECT LTRIM(CASE LAND
              WHEN '' THEN ''
              ELSE LAND+'-'
             END
+PLZ+', '+ORT+', '+STRASSE+' '+ISNULL(HNR,'')) AS Anschrift
FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Hinweis:

Sie können derartige Abfragen selbstverständlich im SQL-Manager von WINcontact entwickeln und austesten. Anschließend überführen Sie die fertige Anweisung über die Zwischenablage in den SQL-Variableneditor, der über das Kontextmenü in der SQL-Eingabeseite aufgerufen werden kann (Menüpunkt "Variablen").

Wichtig sind bei der Erstellung derartiger Anweisungen immer die in geschwungenen Klammern eingeschlossenen Hilfsvariablen, die über das Kontextmenü erreichbar sind (die Sie aber natürlich auch selbst eintippen können):

{ADRESSENID}  enthält die ADRESSENID der gerade aktuellen Adresse

{ALGID}  enthält die ALGID des gerade aktuellen Eintrags der Abarbeitungsliste

{EIGNERID} enthält die NUTZERID des Eigners (Callagen) der gerade aktuellen Adresse

{MANDANT} enthält den Datenbank-Namen des aktuellen Mandanten

{MANDANTID} enthält die ID des gerade aktuellen Mandanten

{PROJEKT} enthält den Datenbank-Namen des aktuellen Projekts

{PROJEKTID} enthält die ID des gerade aktuellen Projekts

{USERID} enthält die NUTZERID des aktuell angemeldeten Mitarbeiters

Wie diese Variablen anzuwenden sind, sehen Sie in den obigen beiden Beispielen.

Fertige SQL-Variablen werden jeweils im Kontextmenü bei "Nutzerdefiniert..." unterhalb des Eintrags „Editor …“ aufgelistet, von wo aus sie, wie jede andere Variable auch, ausgewählt und (z.B. in den Gesprächsleitfaden) übernommen werden können.

Arbeiten mit dem Variableneditor

Wenn Sie über das jeweilige Kontextmenü den Variableneditor öffnen, dann geht er automatisch in den Eingabemodus über. Sie erkennen das in der Statuszeile, wo das Wort „NEU“ darauf hinweist, dass Sie jetzt eine SQL-Anweisung für eine neue Variable eingeben können. 

Angenommen, Sie benötigen im Gesprächsleitfaden die vollständige Anschrift der gerade im Client aktuellen Adresse. Dann könnte die SQL-Anweisung folgendermaßen aussehen:

Wenn Sie jetzt „Übernehmen“ drücken, wird in diesem Beispiel (Screenshot) der Variablen VARIABLE4 genau diese Anweisung und später im Programm das Ergebnis dieser Anweisung zugeordnet:

Außerdem ist der SQL-Editor wieder leer und Sie können, wenn Sie möchten, eine weitere Variable (hier VARIABLE5) anlegen. Zuvor sollten Sie aber der eben erstellten SQL-Variablen einen anderen, möglichst aussagekräftigen Namen geben, z. B. VANSCHRIFT. Dazu brauchen Sie nur auf den Variablenbezeichner zu klicken und das Variablenfeld geht in den Editiermodus über. Selbstverständlich können Sie dafür auch den Eintrag „Umbenennen“ im Kontextmenü verwenden. 

Wie wir bereits erwähnt haben, gibt es zwei Typen von nutzerdefinierten Variablen in WINcontact. Standard ist der Typ (erkennbar am „Häuschen-Icon“), der bewirkt, dass die Variable im Clientprogramm immer bei einem Adresswechsel aktualisiert wird. Es gibt aber auch Variablen, die brauchen im Client nur einmal, und zwar beim Projektwechsel aktualisiert werden (im obigen Beispiel die Variable VCALLAGENT). Dazu müssen Sie über die entsprechende Funktion im Kontextmenü lediglich den Typ auf „bei Projektwechsel“ ändern. Darüber hinaus können Sie unter dem gleichen Menüpunkt noch festlegen, ob die Variable in allen Projekten des Mandanten oder nur in dem Projekt, in dem sie angelegt wurde, verfügbar sein soll.

Hinweis:

Sie sollten sich auf jeden Fall Gedanken über den Variablentyp machen. Sie könnten durchaus jede Variable auf dem Standardtyp „Bei Adresswechsel füllen“ belassen, sollten sich dann aber darüber im Klaren sein, dass jede solche Variable bei jedem Adresswechsel neu gefüllt wird, was mit einer zusätzlichen Datenbankabfrage verbunden ist. Bei umfangreichen Abfragen und einer großen Clientzahl kann dies durchaus die Performance des Servers negativ beeinflussen.

Über den Button „Test“ können Sie – soweit möglich und sinnvoll – bereits im Editor die Variablen probeweise mit Daten füllen. Sie werden dann in der Spalte „Inhalt“ aufgelistet. Im Kontextmenü finden Sie weiterhin die Funktionen Import und Export von Variablen. Damit können Sie alle nutzerdefinierten Variablen in eine Textdatei auslagern und z. B. in einem anderen Mandanten wieder einlesen. Um die SQL-Anweisung einer Variable zu editieren, brauchen Sie nur einen Doppelklick auf die Variable ausführen. Die SQL-Anweisung wird in den Editor geschrieben und in der Statusleiste erscheint EDIT. Wenn Sie den Variableneditor schließen, stehen Ihnen alle damit angelegten Variablen im Variablenkontextmenü zur Verfügung.

Häufig in Projekten benötigte Informationen müssen ab sofort nur noch einmalig als Abfrage formuliert werden und können ab dann mit Hilfe der zugeordneten Variable jederzeit wieder verwendet werden. Da die SELECT-Anweisung, welche zum Füllen einer Variablen benötigt wird, beliebig kompliziert sein kann, ist über einen Verbindungsserver so sogar der Zugriff auf Informationen aus anderen Datenbanken (z. B. MySQL oder MS Access bzw. MS Excel) möglich.

Nachdem wir nun gesehen haben, wie in WINcontact SQL-Variablen angelegt werden, wollen wir jetzt einige Einsatzmöglichkeiten behandeln. In diesem Abschnitt soll es dabei in erster Linie um die Verwendung derartiger Variablen im Gesprächsleitfaden gehen.

Gesprächseinstieg mit persönlicher Anrede des Ansprechpartners

Ein typischer, vorformulierter Gesprächseinstieg ist z. B. folgender:

Schönen Guten Tag, Mein Name ist ... von der Firma Hotzenplotz.

Spreche ich mit ... aus ...?

...

Schönen Dank für das angenehme Gespräch.

Im Normalfall kennen die Callagenten natürlich ihren Gesprächseinstieg "im Schlaf". Trotzdem kann es günstig sein, dass man z. B. für noch unerfahrene Anrufer den Gesprächseinstieg - gewissermaßen als ablesbaren "Spickzettel" - in Form eines vorformulierten Einstiegstextes im Clientprogramm zur Verfügung stellt. Damit der Callagent nicht aus Versehen "... Mein Name ist Punkt, Punkt, Punkt ..." sagt, wäre es günstig, wenn man die variablen Teile, also hier den Namen des Callagenten sowie den Namen und den Wohnort des Ansprechpartner, direkt in den Text integriert. Und das lässt sich ganz einfach mit SQL-Variablen realisieren.

Erstellung der notwendigen SQL-Variablen

Wir benötigen für unser Beispiel drei Variable. Eine davon muß den Namen des am Client angemeldeten Callagenten und die anderen einmal den vollständigen Namen des aktuellen Ansprechpartners und zum anderen dessen Wohnort zurück liefern. Die dazu notwendigen Anweisungen sind im Variableneditor schnell geschrieben:

Callagent  - Ändern bei Projektwechsel

SELECT NACHNAME AS CallAgent FROM TMGLOBAL..NUTZER
WHERE NUTZERID={USERID}

Ansprechpartner - Ändern bei Adreßwechsel

SELECT LTRIM(ISNULL(ANREDE,'')+' '+NACHNAME) AS Ansprechpartner FROM {MANDANT}..ADRESSEN

WHERE ADRESSENID={ADRESSENID}

Ort_AP - Ändern bei Adreßwechsel

SELECT ORT FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Jetzt können wir in den Gesprächsleitfadendesigner wechseln, wo wir die Gesprächseinstiegsseite entwerfen können. Dort stehen dann auch die eben erstellten Variablen als "nutzerdefinierte Variablen" im Kontextmenü zur Auswahl zur Verfügung:

Jetzt brauchen nur noch anstelle der "..." die entsprechenden Variablen aus dem Kontextmenü eingefügt werden:

Und im Client sieht dann die Einstiegsseite des Gesprächsleitfadens z.B. so aus:

Aber damit ist die Anwendbarkeit von Variablen im Gesprächsleitfaden noch lange nicht erschöpft. Deshalb geht es im nächsten Blogbeitrag zu diesem Thema auch weiter ...

Jetzt wollen wir mit dem Einsatz von nutzerdefinierten Variablen im WINcontact - Gesprächsleitfaden fortfahren und an Beispielen zeigen, wie man ganze Textblöcke auf einer Gesprächsleitfadenseite austauschen kann. Anwendungsfälle könnten z.B. geschlechtsspezifische Texte oder Texte in unterschiedlichen Sprachen sein (soweit sie sich mit lateinischen Buchstaben schreiben lassen), wobei Letzteres in der Schweiz oft benötigt wird.

Beispiel 1:

Größere Textpassage in Abhängigkeit der Anrede des Ansprechpartners

Text, wenn AP männlich ist

Wir führen eine Umfrage über das Konsumverhalten von Männern in der Altersgruppe zwischen 30 und 40 Jahren durch in Bezug auf trockene Weine. Gehören Sie, ..., altersmäßig in diese Zielgruppe? Wenn ja, könnten Sie uns bitte drei Fragen beantworten?

Text, wenn AP weiblich ist

Uns interessiert das Konsumverhalten von jungen Frauen im Alter zwischen 30 und 40 Jahren bezüglich lieblicher Weine und möchten Sie, ..., fragen, ob Sie in die genannte Altersgruppe fallen und ob Sie uns dazu drei Fragen beantworten würden?

Die Variablen, die diese Texte liefern, müssen offensichtlich anhand eines Merkmals in den Stammdaten erkennen, welcher Text beim Aufblenden der entsprechenden Gesprächsleitfadenseite anzuzeigen ist. Ein dafür geeignetes Merkmal wäre z.B. die Anrede, soweit sie bei jeder Adresse vorhanden ist und nur die Alternativen "Herr" und "Frau" bestehen.

Nutzerdefinierte Variable:   

{VAR.USER_TextBlock}
SELECT
 CASE ANREDE
 WHEN 'Herr' THEN (SELECT 'Wir führen eine Umfrage über das Konsumverhalten von Männern in der Altersgruppe zwischen 30 und 40 Jahren durch in Bezug auf trockene Weine. Gehören Sie, ..., altersmäßig in diese Zielgruppe? Wenn ja, könnten Sie uns bitte drei Fragen beantworten?')
ELSE (SELECT 'Uns interessiert das Konsumverhalten von jungen Frauen im Alter zwischen 30 und 40 Jahren bezüglich lieblicher Weine und möchten Sie, ..., fragen, ob Sie in die genannte Altersgruppe fallen und ob Sie uns dazu drei Fragen beantworten würden?')
  END AS TEXTBLOCK
FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Hinweis:

Sie können in dem in Hochkommas eingeschlossenen Text auch SQL-Variablen einfügen - wie z.B. im ELSE-Zweig den Ansprechpartnernamen an der Position der "drei Punkte" ...

...

ELSE (SELECT 'Uns interessiert das Konsumverhalten von jungen Frauen im Alter zwischen 30 und 40 Jahren bezüglich lieblicher Weine und möchten Sie, {VAR.USER_Ansprechpartner}, fragen, ob Sie in die genannte Altersgruppe fallen und ob Sie uns dazu drei Fragen beantworten würden?')

...

Je nachdem, ob "Herr" oder "Frau" (oder sonstewas - ELSE-Zweig) bei der aktuellen Adresse in den Stammdaten eingetragen ist, wird der eine oder der andere Textblock im Gesprächsleitfaden an der Variablenposition angezeigt.

Eine analoge Methode kann natürlich verwendet werden, um z. B. den Gesprächsleitfaden in einer bestimmten Sprache anzuzeigen (z. B. deutsch, italienisch und französisch in der Schweiz, wenn in den Adreßstammdaten die Sprache der Person eingetragen ist, z. B. in einem der ASTATUS-Felder).

Beispiel 2:

Verwendung von in der WINcontact Datenbank gespeicherten Texten

Wenn Sie mit E-Mails in WINcontact arbeiten, ist ihnen sicher schon der Textbausteineditor aufgefallen, in dem sich beispielsweise auch komplette Mailtexte ablegen lassen. Dieser Editor kann natürlich auch verwendet werden, um Textpassagen für den Gesprächsleitfaden zur Verfügung zu stellen. Wir wollen jetzt die im Beispiel 1 vorgestellte Funktion nachbauen, wobei der entsprechende Text als Textbausteine (die zuvor im Textbausteineditor angelegt wurden) der globalen Textbausteintabelle TEXTBLOCK entnommen wird.

1. Schritt

Wir legen für jeden Text einen Textbaustein an und benennen ihn "Umfrage (m)" bzw. "Umfrage (w)"

(der Textbausteineditor ist in WINcontact etwas versteckt. Das Einfachste ist, man öffnet einen E-Mail-Client (z. B. Hauptmenü "Kommunikation" - "Auftraggeber kontaktieren" - "E-Mail") und startet ihn dort über das Kontextmenü des Text-Feldes)

2. Schritt

Um einen Textbaustein auszulesen, muß lediglich deren Name (z.B. "Umfrage (m)") oder dessen TextblockID bekannt sein:

SELECT TEXTBLOCK FROM TMGLOBAL..TEXTBLOCK
WHERE NAME='Umfrage (w)'

Eine solche Anweisung nutzen wir nun aus, um die SQL-Variable zu definieren:

SELECT 

   CASE ANREDE

    WHEN 'Herr' THEN (SELECT TEXTBLOCK FROM TMGLOBAL..TEXTBLOCK                            WHERE NAME='Umfrage (m)')

    ELSE (SELECT TEXTBLOCK FROM TMGLOBAL..TEXTBLOCK 

          WHERE NAME='Umfrage (w)')

END AS TEXTBLOCK

FROM {MANDANT}..ADRESSEN

WHERE ADRESSENID={ADRESSENID}

Diese neue Variable (der Sie noch einen sinnvollen Namen geben sollten) können Sie jetzt in ihren Gesprächsleitfaden einfügen. Das Ergebnis ist das Gleiche wie in Beispiel 1.

Hinweis:

In Texten des Textbausteineditors eingebaute nutzerdefinierte Variablen werden im Gesprächsleitfaden nicht durch dessen Inhalt ersetzt!

Sie können sich leicht vorstellen, dass man diese Methode auch für mehrsprachige Gesprächsleitfäden nutzen kann, wenn im Stammdatensatz des Ansprechpartners immer dessen Sprache (z. B. 1=Deutsch, 2=Franzäsisch, 3=Italienisch, 4=Räteromanisch, 5=Englisch etc.)  mit notiert ist (beispielsweise in einem Statusfeld). Die Sprache ist dann (ähnlich wie im Beispiel die Anrede) das Auswahlkriterium für den entsprechenden Textbaustein in der entsprechenden Sprache.

Manchmal kann es nützlich sein, wenn der Callagent über den Gesprächsleitfaden Zugriff auf Informationen im Internet erhält. Auch dafür sind u.U. nutzerdefinierte SQL-Variablen sehr nützlich. Als Einführungsbeispiel soll die Realisierung einer einfachen Telefonnummer-Recherche über das Portal "Das Örtliche" dienen. Der Hintergrund dafür ist Folgender. Wenn in den Stammdaten zu einem Ansprechpartner oder Firma keine Telefonnummer hinterlegt ist, kann man logischerweise diesen Ansprechpartner oder Firma nicht anrufen - es sei denn, man besorgt sich die Nummer durch Nachschlagen in einem Telefonbuch (antiquiert) oder über eine Recherche in einen der Telefonnummernverzeichnissen im Internet. 

Beispiel 3:  

Telefonnummer-Recherche über "Das Örtliche"

Zuerst ist etwas "Forschungsarbeit" angesagt. Die Webadresse für "Das Örtliche" ist

http://www.oertliche.de/

Sie enthält oben eine einfache Suchmaske, in die wir testweise eine bekannte Adresse eintragen:

Wenn jetzt [Finden] gedrückt wird, löst das eine Suche nach dieser Firma im Datenbestand des Web-Telefonbuchs aus. Uns interessiert aber vielmehr die URL, die er dabei erzeugt hat und die am Ende das Ergebnis zurück liefert:

http://www2.dasoertliche.de/?form_name=search_nat&

vert_ok=1&zvo_ok=4&

kgs=14626610&

rgid=&buab=&

zbuab=&

buc=1081&

topKw=0&

context=0&

choose=true&

page=0&

ci=Zittau&

rci=yes&

action=43&

kw=RMS-systems&

noList=false

Wenn wir uns diese URL genau anschauen, finden wir darin an bestimmten Stellen die in die Maske eingegebenen Informationen wieder:

http://www2.dasoertliche.de/?form_name=search_nat&

vert_ok=1&amp

;zvo_ok=4&

kgs=14626610&

rgid=&

buab=&

zbuab=&

buc=1081&

topKw=0&

context=0&

choose=true&

page=0&

ci=Zittau&

rci=yes&

action=43&

kw=RMS-systems&

noList=false

Wenn wir diese URL in unseren Gesprächsleitfaden einbauen, 

dann wird im Clientprogramm (oder im Testmodus des Fragenkatalogdesigners) nach Aufruf der Gesprächsleitfadenseite "TELEFONNUMMER-RECHERCHE" das Ergebnis der Recherche angezeigt:

Jetzt müssten Sie eigentlich die weitere Vorgehensweise bereits erahnen: Wir ersetzen die konkreten Werte "Zittau" und "RMS-systems" in der URL einfach durch nutzerdefinierte Variablen, welche jeweils den Ort bzw. den Adressnamen der aktuellen Adresse enthalten:

{VAR.USER_ORT_ADRESSE}
SELECT ORT FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

{VAR.USER_NAME_ADRESSE}
SELECT NAME1 FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Damit sieht dann die URL im Gesprächsleitfaden folgendermaßen aus:

Und diese URL ist nun allgemeingültig, da sie jeweils den Ort und den Namen der gerade im Clientprogramm aktuellen Adresse enthält.

Hinweis:

Natürlich lässt sich die Web-Anfrage noch weiter "verfeinern" (Forschungsauftrag), in dem z. B. auch noch die Postleitzahl oder die Straße übergeben wird. In diesem Blogbeitrag geht es aber nur um das Prinzip, welches sich so natürlich auch auf eine Vielzahl anders gelagerter Anwendungsfälle übertragen lässt.

Beispiel 4:  

Suche nach Firmen bestimmter (im Fragenkatalog auswählbarer) Branchen im Wohnort des Ansprechpartners mittels des Branchenbuches "Gelbe Seiten"

Das Prinzip, was wir hier anwenden, ist das Gleiche wie bei "Das Örtliche". Eine URL mit Testdaten sieht im Portal "Gelbe Seiten" folgendermaßen aus:

http://www.gelbeseiten.de/yp/122/subscriberlist_search.yp?sessionDataString=H4sIAAAAAAAAAEXMvQr

CMBRA4afpGMhP0ybcTUEdRcHBpcTklgZqlOaWVp%2FeoIPjGc4nai91E1rJfG9vrNZcMOsNsqDCjfe19lq1TP

BWK7Q9SAmqkrtMbqKMkbDE%2Ftz9G-pzrCc1mznMinBIOd0zgrpHIzVAgqMvxXmL2A6bvkX7EowBuzosbxo

5wJTA0uYBjzBRTwBU2Qghpq3YLBw5HDqeCXTj0kjfcaGOUhQ%2FhdGJdzQAAAA-e-e&kindOfSearch=tradesearch&subject=Busunternehmen&location

=02763+Zittau&x=50&y=5&distance=-1&execute=Suchen&suggest_choose=on&rz=122

Auch hier suchen wir nach den in die Abfragemaske eingegebenen Werten ("Busunternehmen" und "02763+Zittau") und ersetzen sie durch Variablen. Dabei wird die Branche aus einer Klappbox im aktuellen Fragenkatalog und der Ort mit Postleitzahl einer nutzerdefinierten SQL-Variablen entnommen:

{VAR.USER_PLZ_ORT_ADRESSE}
SELECT PLZ+'+'+ORT FROM {MANDANT}..ADRESSEN
WHERE ADRESSENID={ADRESSENID}

Die URL sieht dann so aus:

Zuerst muss im Fragenkatalog aus der Klappbox "Branche" ein Branchenbezeichner ausgewählt werden. Anschließend ist die Rechercheseite des Gesprächsleitfadens aufzublenden. Als Ergebnis werden alle §Gelbe Seiten" - Einträge der ausgewählten Branche im Ort der aktuellen Adressen auf der Webseite aufgelistet.

In einem zyklischen Projekt, wo bestimmte Firmen in festgelegten zeitlichen Abständen immer wieder angerufen werden, kann es günstig sein, dem Callagenten alle wesentlichen Informationen des letzten Kontaktes (z. B. Datum, Uhrzeit, eventuelle Notizen, Name des Callagenten, der den Kontakt bearbeitet hat, diverse Fragenkatalogeinträge etc.) auf einer Gesprächsleitfadenseite anzuzeigen. Dann kann er diese Informationen z. B. für einen (besonders) qualifizierten Gesprächseinstieg nutzen. Wie man solch eine Gesprächsleitfadenseite erstellt, wollen wir jetzt an einem Beispiel erläutern.

Aufgabenstellung:  Es sollen Sponsoren für den regionalen Fußballverein "Lokomotive Dödelbach" gewonnen werden

Es handelt sich dabei um ein zyklisches Projekt ("Sponsoren" werden halbjährlich einmal kontaktiert), bei dem um eine finanzielle Unterstützung für den Trägerverein geworben wird. Der Fragenkatalog könnte folgendermaßen aussehen:

Der Kontaktstatus "Sponsor" führt zu einer zyklischen Bearbeitung mit einer Zyklenlänge von 180 Tagen. Bei "Kein Interesse" wird die Zyklenlänge auf 365 Tage gesetzt. Nur "Will nie wieder angerufen werden" führt zu einer Sperrung der Adresse für spätere Anrufe.

Nutzerdefinierte Variablen

Die für den Callagenten wichtigste Information ist erst einmal, ab der Ansprechpartner vor einem halben Jahr gespendet oder ob er vor einem Jahr "Kein Interesse" geäußert hat. Diese Information ergibt sich aus dem Eintrag SPONSOR im Fragenkatalog, wobei wir aber genau den vorletzten Eintrag der entsprechenden Adresse heraussuchen müssen. Das ist der Eintrag, dessen Zyklus um 1 niedriger liegt als der aktuelle Zyklus. Die Variable könnte mit folgender Abfrage gefüllt werden

{VAR.USER_SPONSOR}
SELECT
   CASE SPONSOR
    WHEN 1 THEN 'SPONSOR'
    ELSE 'HATTE KEIN INTERESSE'
   END AS Typ
FROM {PROJEKT}..FK
WHERE ALG_ID=(SELECT ALGID FROM {PROJEKT}..ALG 

              WHERE ADRESSEN_ID={ADRESSENID}
AND ZYKLUS=(SELECT MAX(ZYKLUS)-1 FROM {PROJEKT}..ALG 

            WHERE ADRESSEN_ID={ADRESSENID}))

Jetzt müssen wir noch wissen, wie viel eventuell gespendet wurde. Außerdem ist noch der Eintrag im Bemerkungsfeld von Interesse:

{VAR.USER_BETRAG}

SELECT

  CASE BETRAG

   WHEN '' THEN ' - '

   ELSE CONVERT(varchar,BETRAG)+' €'

  END AS BETRAG 

FROM {PROJEKT}..FK

WHERE ALG_ID=(SELECT ALGID FROM {PROJEKT}..ALG 

              WHERE ADRESSEN_ID={ADRESSENID} 

AND ZYKLUS=(SELECT MAX(ZYKLUS)-1 FROM {PROJEKT}..ALG 

            WHERE ADRESSEN_ID={ADRESSENID}))

{VAR.USER_BEMERKUNG}

SELECT

 BEMERKUNGEN 

FROM {PROJEKT}..FK

WHERE ALG_ID=(SELECT ALGID FROM {PROJEKT}..ALG 

              WHERE ADRESSEN_ID={ADRESSENID} 

AND ZYKLUS=(SELECT MAX(ZYKLUS)-1 FROM {PROJEKT}..ALG 

            WHERE ADRESSEN_ID={ADRESSENID}))

Jetzt ist noch von Interesse, wann der letzte Anruf erfolgt ist und welcher Callagent mit dem entsprechenden Ansprechpartner gesprochen hat. Diese Informationen können dem Eintrag des letzten Kontaktes in der Abarbeitungsliste entnommen werden:

{VAR.USER_LAST_DATUM}
SELECT
LAST_DATUM
FROM {PROJEKT}..ALG WHERE ADRESSEN_ID={ADRESSENID}
 AND ZYKLUS=(SELECT MAX(ZYKLUS)-1 FROM {PROJEKT}..ALG 

             WHERE ADRESSEN_ID={ADRESSENID})

{VAR.USER_LAST_CALLAGENT}
SELECT
(SELECT ANREDE+' '+VORNAME+' '+NACHNAME FROM TMGLOBAL..NUTZER 

 WHERE NUTZERID=USER_ID) AS CALLAGENT
FROM {PROJEKT}..ALG
WHERE ADRESSEN_ID={ADRESSENID}
AND ZYKLUS=(SELECT MAX(ZYKLUS)-1 FROM {PROJEKT}..ALG 

            WHERE ADRESSEN_ID={ADRESSENID})

Damit haben wir alle Variablen zusammen und können nun die Gesprächsleitfadenseite gestalten:

Und im Client sieht dann der Gesprächsleitfaden beispielsweise so aus:

Sie können natürlich auch auf die Gesprächsleitfadenseite verzichten und die Informationen direkt in die Fragenkatalogseite integrieren (wenn kein Platz ist, vielleicht auf einen extra Reiter?). Da hat sie der Callagent sofort im Blick und braucht nicht erst den Gesprächsleitfaden-Tab drücken:

Und hier im Testmodus (Bild identisch mit Client):

Über den Einsatz nutzerdefinierter Variablen im Fragenkatalog werden wir im nächsten Blogbeitrag dieser Reihe berichten.

Auch im Fragenkatalog lässt sich die Technik der nutzerdefinierten SQL-Variablen unter vielerlei Gesichtspunkten einsetzen. Eine Methode haben Sie bereits im vorigen Posting (Teil 7) kennengelernt, wo Label mit SQL-Variablen "ausgestattet" wurden. Dazu nun ein weiteres Beispiel. Angenommen, der Callagent soll immer und zeitgenau über seine aktuellen Projektkennzahlen (also z. B. "wie viele Adressen hat er heute bearbeitet", "wie viele Kontakte waren erfolgreich" und (bei einem Verkaufsprojekt), "wie hoch ist der realisierte Umsatz") informiert werden. Dann ist es am Günstigsten, man blendet diese Kennziffern direkt in der Fragenkatalogmaske ein. Dazu müssen lediglich die dazu notwendigen Variablen entwickelt und die Fragenkatalogmaske angepasst werden, z. B.

Verwendete Variablen

{VAR.USER_AKT_CALLAGENT}

SELECT ISNULL(VORNAME,'')+' '+NACHNAME FROM TMGLOBAL..NUTZER

WHERE NUTZERID={USERID}

{VAR.USER_CA_ANZ_ADRESSEN}

SELECT COUNT(*) FROM {PROJEKT}..ALG 

WHERE LAST_DATUM BETWEEN CONVERT(varchar(10),getdate(),104) AND getdate()+1 AND USER_ID={USERID}

{VAR.USER_CA_ANZ_KONTAKTE}

SELECT COUNT(*) FROM {PROJEKT}..ALGKONT 

WHERE DATUM BETWEEN CONVERT(varchar(10),getdate(),104) AND getdate()+1 AND USER_ID={USERID}

{VAR.USER_CA_ANZ_NETTO}

SELECT COUNT(*) FROM {PROJEKT}..ALG 

WHERE LAST_DATUM BETWEEN CONVERT(varchar(10),getdate(),104) AND getdate()+1 AND LAST_STATUS='ABOVERKAUF' AND USER_ID={USERID}

{VAR.USER_CA_ANZ_WVG}

SELECT COUNT(*) FROM {PROJEKT}..ALG 

WHERE LAST_DATUM BETWEEN CONVERT(varchar(10),getdate(),104) AND getdate()+1 AND LAST_STATUS='Wiedervorlage' AND USER_ID={USERID}

Der "Infoblock" wird im Fragenkatalogdesigner mittels eines Rahmenelements und Labels, die u. a. SQL-Variablen enthalten, gestaltet:

Die Variablen fügen Sie als Labeltext einfach über das Kontextmenü "Variablen - nutzerdefiniert" ein (Achtung: Label muss sich dazu im "Editiermodus" befinden, d. h. keine "Ziehkästchen", dafür Strichkursor im Label). Was Sie in dem Infoblock anzeigen, ist natürlich Ihnen überlassen. Es müssen dazu lediglich die entsprechenden Informationen über SELECT-Anweisungen in der WINcontact - Datenbank erfragt werden. 

Variablen und E-Mailversand aus dem Fragenkatalog

Folgendes Beispiel zeigt, wie man in einem Fragenkatalog während eines Gesprächs den Namen des Ansprechpartners sowie dessen E-Mail-Adresse erfassen kann, um diese Information anschließend (d. h. noch während des Gesprächs) zum Verschicken einer E-Mail zu nutzen.

Problem:

Während des Gesprächs stehen die in die Fragenkatalogmaske eingetragenen Daten noch nicht in der WINcontact - Datenbank, da das Speichern erst beim Sichern des Kontaktes am Ende des Gesprächs erfolgt. Man kann deshalb diese Daten nicht über eine SQL-Anweisung einer nutzerdefinierten Variablen zuordnen, die sich dann z. B. im E-Mail-Client für eine personalisierte Anrede verwenden lässt.

Dieses Problem ist aber lösbar, wie wir im Folgenden zeigen werden.

1. Schritt: Fragenkatalogmaske entwerfen und Vorgaben definieren

Wir benötigen jeweils ein Eingabefeld für die Anrede (Klappbox), Vorname und Nachname des Ansprechpartners sowie ein Eingabefeld für dessen E-Mail-Adresse. Der Einfachheit halber werden diese Daten in der Fragenkatalogtabelle (FK) erfasst.

Da es sein kann, dass in den Stammdaten (ADRESSEN-Tabelle) bereits ein Ansprechpartner zur aktuellen Firma erfasst ist, sollte man ihn hier als Vorgabe (wenn vorhanden) eintragen:

Analog dazu sind natürlich auch Vorgaben für das Feld VORNAME und NACHNAME zur Verfügung zustellen (Objektinspektor).

2. Schritt: Notwendige SQL-Variablen definieren

{VAR.USER_ANSPRECHPARTNER}

SELECT 

  CASE ANREDE

   WHEN 'Herr' THEN 'Sehr geehrter Herr '+ISNULL(TITEL,'')

       +'    '+NACHNAME+','

   WHEN 'Frau' THEN 'Sehr geehrte Frau '+ISNULL(TITEL,'')

       +' '+NACHNAME+','

ELSE 'Sehr geehrte Damen und Herren,' END AS Ansprechpartner 

FROM {MANDANT}..ADRESSEN

WHERE ADRESSENID={ADRESSENID}

3. Schritt: Ereignis für den E-Mail-Versand festlegen

Für das Verschicken einer E-Mail verwenden wir ein Ereignis, welches über den Button [INFO-Mail] im Fragenkatalog aktiviert wird. Ereignis deshalb, weil, um das E-Mail zu verschicken, mehrere Zwischenschritte zu realisieren sind. Als Erstes müssen wir die Daten aus dem Fragenkatalog explizit in die Stammdaten der aktuellen Adresse zurück schreiben, damit wir auf sie über SQL-Variablen zugreifen können. Damit wird das eingangs beschriebene Problem gelöst. Man erreicht dies durch einfache Update-Anweisungen in der Form

UPDATE {MANDANT}..ADRESSEN

SET ANREDE=[FK.ANREDE],

VORNAME=[FK.VORNAME],

NACHNAME=[FK.NACHNAME]

WHERE ADRESSENID={ADRESSENID}

für ANREDE, VORNAME und NACHNAME. Und mit

IF EXISTS (SELECT TOP 1 ZUGANG FROM {MANDANT}..KOMMUNIKATION

WHERE ADRESSEN_ID={ADRESSENID} AND KOMMART='E'

AND BEZEICHNER='E-Mail1')

-- vorhandene E-Mailadresse überschreiben

UPDATE {MANDANT}..KOMMUNIKATION

SET KOMMART='E',

ZUGANG=[FK.EMAIL]

WHERE ADRESSEN_ID={ADRESSENID} AND BEZEICHNER='E-Mail1'

ELSE

-- neuen Datensatz anlegen

INSERT INTO {MANDANT}..KOMMUNIKATION (ADRESSEN_ID, APART_ID,
BEZEICHNER, KOMMART, ZUGANG)
VALUES ({ADRESSENID}, -1, 'E-Mail1', 'E', [FK.EMAIL])

für die E-Mailadresse. Dabei wird zugleich beachtet, daß eventuell bereits eine E-Mailadresse in der Kommunikations-Tabelle bei der aktuellen Adresse hinterlegt ist.

Damit stehen die Daten aus dem Fragenkatalog regulär in den Stammdaten der aktuellen Adresse (was sonst erst nach dem Speichern des Kontaktes der Fall wäre).

4. Schritt:  Im Ereignis nutzerdefinierte SQL-Variablen aktualisieren

Dafür gibt es im Ereignisbatcheditor einen speziellen Befehl. Er bewirkt, daß alle im Kontext gültigen SQL-Variablen aktualisiert werden.

Der Ereignisskript sollte jetzt folgendermaßen aussehen:

Nachdem diese "Vorarbeiten" beendet sind, fehlt nur noch ein Befehl im Ereignisbatch: Das Verschicken der E-Mail selbst.

5. Schritt:  E-Mail verschicken

Als "Empfänger" wird die eingegebene E-Mailadresse aus dem Fragenkatalog gewählt: {FK.EMAIL}

Im Text des Antwortschreibens kommt u.a. die SQL-Variable {VAR.USER_ANSPRECHPARTNER} zum Einsatz (personalisierte Anrede). Außerdem wird noch das angekündigte Prospekt als pdf-Anhang verschickt.

Und damit ist der Eventskript fertig und der Mailversand kann im Clientprogramm getestet werden.

Die in diesem Posting behandelten zwei Beispiele sollen nur als Anregung dienen, SQL-Variablen sowie Ereignisse auch einmal in Fragenkatalogen einzusetzen. 

Bekanntlich können bestimmte Eingabeelemente in einem Fragenkatalog mit Vorgabewerten quasi "vorbelegt" werden. Das dient in der Regel dazu, sowohl die Schreibarbeit zu minimieren als auch Eingabefehler zu vermeiden (z.B. wenn man bei Klappboxen nur die Auswahl über eine Auswahlliste zuläßt). Für diese Anwendungsfälle lassen sich natürlich in WINcontact auch nutzerdefinierte Variablen einsetzen. Zu beachten ist jedoch, daß sie nur in Form von "dynamischen" Vorgaben im Rahmen einer SELECT-Anweisung zu verwenden sind. "Feste" Vorgaben lassen sich mit nutzerdefinierten SQL-Variablen nicht realisieren.

Beispiel: Klappboxvorgaben mittels nutzerdefinierter Variablen

Eine "Klappbox" (Combobox) kann sowohl eine Auswahlliste als auch eine Vorgabe enthalten. Es reicht aber nicht aus, auf der Vorgabe-Seite des SQL-Eingabeeditors einfach die SQL-Variable einzutragen. Nutzerdefinierte SQL-Variablen können in diesem Fall nur innerhalb einer SELECT-Anweisung verwendet werden.

Angenommen, in die Klappbox soll als Vorauswahl der Ort der gerade aktiven Adresse eingetragen werden, die bereits als nutzerdefinierte SQL-Variable vorliegt:

VAR.USER_ORT_ADRESSE

SELECT ORT FROM {MANDANT}..ADRESSEN

WHERE ADRESSENID={ADRESSENID}

Dann lautet die Abfrage im SQL-Eingabeeditor:

Beachten Sie, dass der Variablenname in "Hochkommas" eingeschlossen sein muss. Der Grund dafür ist einfach zu verstehen. Der "Inhalt" der Variable ist eine Zeichenkette. Damit wird zur Laufzeit der Variablenname in der SELECT-Anweisung ersetzt, so dass der SQL-Server z. B. folgenden Befehl zur Abarbeitung übergeben bekommt:

SELECT 'Emsdetten'

(wenn die Variable "Emsdetten" zurückliefern würde)

Eine derartige Anweisung ist dagegen für die Generierung einer Auswahlliste nicht geeignet, da sie ja nur einen Wert zurückliefern kann. Man kann aber selbstverständlich eine derartige Variable als Vergleichswert in einer WHERE-Anweisung verwenden. Angenommen, in der Klappbox sollen alle Postleitzahlen eines namentlich bekannten Ortes aufgelistet werden. Dann könnte im einfachsten Fall eine SELECT-Anweisung, die eine derartige Liste liefert, wie folgt aussehen:

SELECT A.PLZ+' '+A.ORT
FROM TMGLOBAL..PLZ AS A
WHERE ORT='{VAR.USER_ORT_ADRESSE}'
ORDER BY 1

An diesen beiden Beispielen sehen Sie, dass Sie in SQL-Anweisungen im SQL-Vorgabeneditor nutzerdefinierte SQL-Variablen jederzeit als "Platzhalter" für konkrete Werte verwenden können.