Conditions mit Virtual.EffectedContact

Welcome to the POB User Group Online Community! Forums PUG DACH Conditions mit Virtual.EffectedContact

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #4921
    markushoberg
    Member

    Hallo PUGler, hi Jesper,

    ich möchte eine Condition anpassen und dabei CasePK True/False für ein neu eingerichtetes Feld des EffectedContacts per PQL ansprechen.

    Um mich der Sache anzunähern geht der Ausdruck derzeit auf den Contact.Customer. Hier kann der PK vom Case mit dem PK vom Contact gematcht werden. Das klappt, ist aber nicht das, was ich brauche.

    [1|Customer c|c.Virtual.Company='Extern' AND c.CustomerPK=[Contact.Customer.CustomerPK]]

    Aber wie muss ich den Part c.CustomerPK=[Contact.Customer.CustomerPK umbauen, damit es auch für das virtuelle Feld funktioniert. Der unfertige Ansatz ist bislang so:
    [1|Virtual v|v.EffectedContact.Virtual.Company='Extern' AND c.CustomerPK=[Contact.Customer.CustomerPK]]

    Beste Grüße,
    Markus

    #4922
    Stefan Reichelt
    Participant

    Hallo Markus,

    Eine wichtige Info dazu: “Virtual” ist keine Tabelle, sondern lediglich ein Präfix, damit man selbst angelegte Spalten wiederfindet. Diese Spalten sind nicht einmal virtuell, sondern tatsächlich als Datenbankspalten vorhanden (nur eben mit virtual_). Sieh das “Virtual.” einfach als Teil des HQL-Feldnamens an. Wenn das Feld also in der Case-Tabelle liegt, kannst du es einfach per [Virtual.EffectedContact.CustomerPK] ansprechen.

    Grüße,

    Stefan

    #4923
    markushoberg
    Member

    Hallo Stefan,

    vielen Dank für deine schnelle Reaktion, aber leider bekomme ich weiter in der WebForm eine “unbekannter Serverfehler”-Meldung.

    Das scheint noch nicht die Lösung zu sein, oder Fehler zu enthalten:
    [1|Virtual v|v.EffectedContact.Virtual.Company='Extern' AND c.CustomerPK=[Virtual.EffectedContact.CustomerPK]]

    Wahrscheinlich fehlen mir grundlegende Informationen, um die Zusammenhänge wirklich zu verstehen. Es ist also kein Feld, sondern eine Spalte Virtual.Company die ich dem Customer im CAO hinzugefügt habe. Okay, verstanden.

    Die Spalte könnte auch Custom.Company heißen, aber Wendia hat sich für den Tag “virtual” entschieden, um mich zu verwirren. 😉 Auch verstanden.

    Ich müsste jetzt wahrscheinlich den Spaltenwert als Hidden über meine WebForm in eine gleichnamige Spalte virtual.company des Case übergeben, die ich ebenfalls anlegen müsste. Dann hätte ich es zur Auswertung zur Verfügung. Richtig?

    Wenn ja, stehe ich vor der nächsten Herausforderung bzgl eines geeigneten Codes zum Transfer vom Customer zum Case.

    Vielleicht ist es doch besser das Thema mit Jesper zu klären, bevor ich hier Zeit ohne Ende verbrate… Ich kann nicht einschätzen, ob ich nahe dran oder weit daneben liege.

    Beste Grüße,
    Markus

    #4924
    Stefan Reichelt
    Participant

    Hallo Markus,

    der grundlegende Fehler ist, dass du da eine Query auf eine nicht existente Tabelle namens “Virtual” absetzt. Das kann nicht funktionieren.

    Kannst du noch ein paar Details zur Condition liefern? Und in welcher Tabelle hast du denn das Feld angelegt? Ohne den Hintergrund der funktionierenden Query zu kennen, würde ich sie erstmal so umschreiben:

    [1|Customer c|c.Virtual.Company='Extern' AND c.CustomerPK=[Virtual.EffectedContact.CustomerPK]]

    Das funktioniert natürlich nur, wenn das Feld in der Case-Tabelle liegt. Wenn du es in der Kontaktpersonentabelle hast, sieht es so aus:

    [1|Customer c|c.Virtual.Company='Extern' AND c.Virtual.EffectedContact.CustomerPK=[Contact.Customer.CustomerPK]]

    Grüße,

    Stefan

    #4925
    markushoberg
    Member

    Jetzt schreibst du auch Feld… Die Spalte habe ich bisher nur in der Tabelle Customer (unter CAO) angelegt. In der Case-Tabelle gibt es das Feld (noch) nicht. Die Query kommt beim einem Antrag auf Namensänderung eines Mitarbeiters zum Einsatz. Darüber muss eine Fallunterscheidung für interne und externe Mitarbeiter realisiert werden, weil darüber entschieden wird, ob unsere Personalabteilung (bei Internen) oder der direkte Vorgesetzte (bei Externen) die Genehmigung geben muss. Generell ist die Namensänderung eine Ausnahme vom Default, wo immer der Vorgesetzte genehmigen muss. Und Namensänderung bei Externen ist somit die Ausnahme von der Ausnahme.
    Der Wert für die Spalte wird im Customer über unseren AD-Import (DataLoad) befüllt. Dort steht dann “Company1”, “Company2”, … oder “Extern”.
    Und ich biete in der WebForm ein Auswahl des alten Namens über die SubView “Contact ID” für die Spalte “EffectedContact” an – einfach umschrieben ein Dropdown mit den Namen aller Personen. Der neue Vorname / Nachname wird über einfache Textfelder von Hand ausgefüllt und dann das Formular abgeschickt.
    Hast du noch Fragen?

    #4926
    Stefan Reichelt
    Participant

    “Feld” und “Spalte” sind an der Stelle synonym.

    Aber so richtig habe ich noch nicht verstanden, warum du die Spalte in der Tabelle Customer angelegt hast. Wenn ich dein Szenario richtig interpretiere, wäre sie idealerweise in der Tabelle Case aufgehoben, wo du ja die Änderung für Person X (aka “Effected Contact”) erfasst. Der Trigger wäre dann in der Falltabelle so:

    [1|Case cas|cas.CasePK=[PK] and cas.Virtual.EffectedContact.Company='Extern']

    (Dies unter der Voraussetzung, dass “Company” ein simples Textfeld ist).

    • This reply was modified 11 months, 3 weeks ago by Stefan Reichelt. Reason: Ok, das mit der Tabelle ist klar. Aber warum Customer?
    #4928
    markushoberg
    Member

    Zunächst mal kann ich bestätigen, dass Company ein simples Textfeld ist.

    Customer weil unser täglich laufender AD-Import das aus dem Windows-Benutzer in den POB-Customer schreibt.

    Ich stimme auch zu, dass das Feld idealerweise in der Tabelle Case aufgehoben wäre.
    Da steht es aber nicht zur Verfügung, könnte es aber auch dort gleichnamig zum Feld im Customer anlegen.

    Dann ist mir aber immer noch unklar, wie die Werte aus dem Customer-Feld ins Case-Feld auf sinnvoller Weise übertragen werden. In der WebForm, mit einem Insert-/Update-Trigger oder ganz anders? Denke ich zu kompliziert oder fehlt mir die richtige Idee?

    • This reply was modified 11 months, 3 weeks ago by markushoberg.
    #4930
    Stefan Reichelt
    Participant

    Spielen wir mal ein Beispielszenario durch:
    Jemand will seinen Namen ändern, ein anderer Mitarbeiter füllt das Formular aus.
    Dabei wählt er im Formular den richtigen Kontakt aus (einen Datensatz, der ganz normal in der Customer-Tabelle liegt). An der gewählten Kontaktperson enthält das Feld “Company” den Wert “Extern”. Ein Trigger findet genau das heraus und trifft die entsprechende Entscheidung.

    Die Frage ist für mich nun: Warum gibt es nun in der Tabelle für Kontaktpersonen ein Feld, das nochmal zurück auf dieselbe Tabelle führt? Und wie sieht dann eigentlich der Kontakt aus? Steht am Kontakt “Stefan Reichelt” im Feld “Effected Contact” nochmal “Stefan Reichelt”? Wenn ich es richtig verstehe, ist es tatsächlich viel zu kompliziert gedacht. Beide Kontakte liegen doch gemeinsam in derselben Tabelle. Ich verstehe nicht, warum sie miteinander verbunden sein sollten.

    Eine noch wichtigere Frage ist für mich aber, wie du das Webform gebaut hast, und welches Feld du da ziehst. Geht das Formular etwa direkt auf die Customer-Tabelle (wenn ja, wird dann bei jeder Übermittlung ein neuer Kontakt angelegt?), oder legt es doch nur einen Case an (wenn ja, wie holst du dir dann das Feld aus der Customer-Tabelle?).

    Wenn du (wie ich es für sinnvoll halte) einen Case anlegst, sehe ich überhaupt keinen Bedarf, irgendein Feld irgendwohin zu schreiben. Du brauchst es ja nur im Case, und zwar aufgrund der Logik “Person A (Contact.Customer) beantragt eine Namensänderung für Person B (Virtual.EffectedContact)”. Sobald das Webform übertragen wird, ist das Feld ja auch schon ausgefüllt.

    #4931
    markushoberg
    Member

    Hallo Stefan,

    ich lege mit dem WebForm einen Case an und keinen Customer.

    Das eigentliche Doing der Namensänderung wird nach Genehmigung durch das Benutzermanagement bzw. weitere andere Stellen vollzogen. Deshalb steht der neue Name in Freitextfeldern.

    Mein Problem ist einen Trigger zu bauen für die Company von Person B (Virtual.EffectedContact).

    Sobald das Webform übertragen wird, ist das Feld ja auch schon ausgefüllt.

    Davon gehe ich auch aus, bekomme aber das Feld nicht angesprochen.
    Ich hätte erwartet, dass dein Vorschlag von Post 4926 (Fr. 13:13 Uhr) funktioniert, aber leider bekomme ich da im Browser “Abfrageausführungs-Fehler”.

    Vielleicht frage ich besser bei Jesper an, damit der sich die Sache live ansieht.

    #4932
    markushoberg
    Member

    Hurra!

    Bei dem Code vom Freitag war nur ein kleiner Fehler enthalten.
    Statt
    [1|Case cas|cas.CasePK=[PK] and cas.Virtual.EffectedContact.Company='Extern']
    klappt es, wenn ich
    [1|Case cas|cas.CasePK=[PK] and cas.Virtual.EffectedContact.Virtual.Company='Extern']
    benutze.

    Herzlichen Dank, Stefan, dass du mich so geduldig unterstützt hast.

    Beste Grüße, Markus

    • This reply was modified 11 months, 2 weeks ago by markushoberg.
    #4934
    Stefan Reichelt
    Participant

    Glückwunsch!

    Verdammt – darauf hätte ich aber auch gleich kommen können. “Company” ist ja kein generisches Feld in der Tabelle Customer. 😀

    Sonnige Grüße aus Leipzig,

    Stefan

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.