Einfacher WF - Ticket neue Kategorie zuweisen

[Rico]

Moin,

ich bin noch nicht so WF erfahren. Die Aktion "weiterleiten", soll durch eine neue Aktion abgelöst werden. Diese soll das Ticket statt an Rollen, an Kategorien weiterleiten. Das soll für mehr Übersicht sorgen (Rollen entfallen in der Oberfläche kein gedanklicher switch zwischen Rollen und Kategorien) und die Tickets sind am Ende auch richtig kategorisiert (wird bei schließen gern übersehen).
Dazu gehe ich wie folgt vor:
Neuer WF > UI Action - WF Template
Zusätzliches Argument: Kategorie/ein/Guid

Im ForEach:
das Assign sollte bereits von dem gewählten Ticket die EOID beinhalten ? (genau das scheint nicht der Fall zu sein)
> Get Single Record Data (DD:SPSActivityClassBase/Where: [Expression-ObjectID] = @ExpressionObjectID(Variable CurrentObjectId)/ Output: ID in neue Variable TicketID )
> Update Task Task ID: variable TaskID; Category: variable Kategorie

Assistent in dem nur die neue Kategorie abgefragt wird.
Im WF Tracking ist die Kategorie ID zu sehen, aber die CurrentObjectId bleibt leer (00000000-0000-0000-0000-000000000000) demzufolge kann also auch keine Ticket ID ermittelt werden. Warum steht in der CurrentObjectId nicht die EOID des entsprechenden Tickets ?

[dodic]

Wieso ändert ihr nicht einfach die Kategorie über die normale Ticketmaske und hinterlegt bei den Kategorien die verantwortliche Rolle?

[Rico]

An den Kategorien sind die Rollen bereits hinterlegt, nur so funktioniert das gewünschte Konstrukt auch.

Das Ziel ist: Einfachheit. Es ist wesentlich leichter an einem Ticket direkt eine Aktion wie weiterleiten zu nutzen, als das Ticket zu öffnen und über den Bearbeiten-Dialog die Kategorie zu ändern.
Lieber gebe ich es Systemseitig intuitiv und idiotensicher vor, als zu versuchen sämtliche Kollegen über eine Anweisung dazu zu nötigen.

[dodic]

Erstell im WF ein neues Argument:

Name: TicketIDs
Argumenttyp: Guid[]
Direction: Ein

In der ForEach Aktivität dann:
foreach "item" in "TicketIDs"

Dann beim Assign:
Value: item
To: currentObjectID

Im Assistenten sollte dir unter "arguments" nun TicketIDs[] angezeigt werden. Hier die Eigenschaft bearbeiten:


Das sollte es gewesen sein.

Grüße

[Rico]

Danke für dein Ansatz.
Da es Validierungfehler gab habe ich TypeArgument des ForEach auf System.Guid gesetzt.

Die TicketIDs sind jetzt da, allerdings damit da bleibt der WF hängen mit "Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt."

[dodic]

Ich glaube die Get Single Record Aktivität kannst du dir sparen, da du die TaskID ja schon in der CurrentObjectID hast, wenn ich mich nicht täusche?

Grüße

[Rico]

Nach dem von dir vorgeschlagenen Umbau, stimmt.
Die Meldung ": Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt." bleibt davon aber unberührt.

[dodic]

Okay, dann will er eine andere ID beim Task. Versuch mal folgendes:

Doch wieder nen Get Single Record einbauen.

DataDefinition: SPSActivityClassBase
Where Expression: [Expression-ObjectID] = @ExpressionObjectID > Hier die CurrentObjectID
Outpup: T(SPSCommonClassBase).ID > TASKID

TASKID bei dem Task rein.

Grüße

[Rico]

Hmm, hab es endlich hinbekommen. Hab es mit EOID und der ID versucht, die waren die ganze Zeit richtig (in der DB gegengeprüft).
Habs dann mal mit Update Object versucht, gleiches Bild, er konnte die ID nicht zuordnen. Ich weiß immer noch nicht was die beiden Typen erwarten, aber mit Update Fragments klappt es wunderbar.

[Rico]

Hmpf, das Problem war, das ich die ganze Zeit versucht habe die Aktion für eine Serviceanfrage auszuführen. Anscheinend lässt sich aber mit Update Task, wie der Name schon sagt, nur der Typ Aufgabe handeln. Benötigt wird aber eine Aktion für alle Typen (wie beim weiterleiten), im Zweifel auch mehrere gleichnamige Aktionen die für den jeweiligen Tickettyp eingeblendet werden.

Nochmal Zusammengefasst: Eine Aktion die für alle Tickettypen (Ticket, Störung, Serviceanfrage, Aufgabe) die in einem Assistenten angegebene (1) Kategorie setzt, den passenden (2) Journaleintrag erzeugt (Kategorie wurde geändert von xxx auf xxx) und optional ein im Assistenten eingegebenes (3) Kommentar ins Journal schreibt.
Also eigentlich 1:1 die originale Funktion "weiterleiten" nur für Kategorien statt für Rollen.

Ich seh irgendwie keinen sauberen Lösungsansatz. Bisher habe ich folgendes probiert/zusammengetragen.

Über Webservices

• Activity: würde für alle Tickettypen greifen > sehe keine Möglichkeit damit Kategorien anzupassen.
  Incident/Update: scheint alles zu gehen > Nur für Störungen
  Servicerequest: bietet gar nichts an

Über WF

• Update Task: klappt > scheinbar nur für Aufgaben
  Update Objects: verhielt sich zumindest im ersten Test störisch
  Update Fragment: einzelne Einträge möglich, passende Journaleinträge werden nicht automatisch erzeugt

Ist das wirklich so kompliziert das es keine einheitliche Lösung gibt oder übersehe ich was ?
Für Störungen: Aktion, Assistent, Webservice
Aufgabe eventuell: Aktion, Assistent, WF - Update Task
Ticket, Serviceanfrage (oder gleich alle) eventuell über Update Fragment, dann muss ich noch gucken wie ich da die Journaleinträge dazu fummel.

[dodic]

Moin,

also ich hab es eben mal nachgebaut, bis auf den Assistenten - funktioniert mit Update Fragment einwandfrei.

Es geht an dieser Stelle auch nur mit Update Fragment, da Update Object sich auf ein spezifischen Typ bezieht. Bei Upate Fragement nutzt du als Data Definition "SPSActivityClassBase".






Um den Journal Eintrag zu setzen in Administration > Schema > Datendefiniton > Auswahllisten die "SPSJournalEntryPickupType" erweitert. Dort unter Daten einen Eintrag hinzufügen.
z.B.:
Anzeigetext: Kategorie geändert
Kopfzeile-Vorlage: Kategorie geändert
Textkörper-Vorlage: {journalComments}

im WF die Aktivität "Add Journal Entry" hinzufügen und den von dir angelegten Eintrag raussuchen.


Grüße

[Rico]

Danke für deine Hilfe, damit bin ich schon ziemlich weit gekommen.

Hab es jetzt erstmal so umgesetzt:
>Get (alte) Kategorie
>Get neue Rolle
>Set Kategorie Guid + zugehörige Rolle
>Get (neue) Kategorie
> Schreibe Journaleintrag (Die Kategorie wurde von xxx auf xxx geändert + Kommentar) - Journaleintrag war übrigens schon ein passender vorhanden (71).

WF.PNG

(20.18 KiB) Downloaded 154 times

Was mich die ganze Zeit verwirrt ist, das ich über das unveränderte Template von ObjectActionContext keine IDs bekomme.
Nehme ich einen frischen Workflow vom Typ Action (Also nur das ForEach und Assign drin) und führe dann die Aktion mit einem Ticket aus ist im Tracing der ObjectActionContext[], also leer. Woran liegt das ?

Baue ich es hingegen wie du gesagt hast, mit einem zusätzlichen Argument TicketIDs[] werden im WF Validierungsfehler angezeigt. Ändere ich dann die ForEach auf
TypeArgument: SystemGuid
Values: TicketIDs
sind die Fehler weg und der WF funktioniert auch.
Ich würde gern verstehen warum das so ist, bzw. was ich falsch mach um ObjectActionContext direkt zu verwenden.

Damit könnte ich z.B. direkt den Currentuser nutzen (CurrentObjectId.User) um diesen als Creator an das Journal übergeben zu können. Dazu muss ich mir jetzt anderweitig Gedanken machen.

Das wurmt mich:

• Warum klappt das mit den ID-übergabe von ObjectsContext nicht?

• (Wie) Bekommt man die neue und alte Kategorie so schön verlinkt wie es Matrix selbst im Journal reinschreibt?

• Wie ich alternativ den Currentuser raussuche gucke ich morgen

[dodic]

Ich hab hier noch ein Whitepaper gefunden, welches ich selbst mal hier im forum gefunden habe, dass beschreibt auch wie du den CurrentUser mit übergeben kannst:
download/file.php?mode=view&id=2405