ServiceDesk

When I use this workaround in SD 7.1

http://www.symantec.com/business/support/index?page=content&id=HOWTO30369

I have this error in the sd.email.mointor log file.

Error,Mittwoch, 10. August 2011 16:30:11,Process Name: Email Monitoring  Model: Process Message Embedded Model  Component Name: GetIncidentByTrackingID  Component Class Name: SD.Components.DB.GetIncidentByTrackingID  Component ID: 1680fdf7-3717-4789-9bc3-649ae7ba6d32  Exception Class Name: System.IndexOutOfRangeException  Message: Der Index war außerhalb des Arraybereichs.  Stack Trace: System.IndexOutOfRangeException: Der Index war außerhalb des Arraybereichs. bei LogicBase.Core.Data.OrchestrationData.SetValue(String name, Object value) bei LogicBase.Core.Data.OrchestrationData.set_Item(String name, Object value) bei SD.Components.DB.GetIncidentByTrackingID.Run(IData data) bei LogicBase.Core.ExecutionEngine.MultiPathProcessComponentExecutionDelegate.Execute(IData data, IOrchestrationComponent comp, String& outputPath, IExecutionEngine engine, TLExecutionContext context) bei LogicBase.Core.ExecutionEngine.AbstractExecutionEngine.RunComponent(TLExecutionContext context, IData data, IOrchestrationComponent comp)

Have someone any ideas? For us is a must have.

Not absolutely sure...but the HOWTO30369 article might only be applicable to ServiceDesk 7.0.

It looks like you are missing your task assignees embeded model.

Send me an email and I will help work you through it.

I followed the same guide and it doesn't work fo me either. I know that the article is for 7.0 but I felt confident in trying it out in SD7.1.

I recieve an error in the log.

Also I noticed that variables from Incident data are missing when I configure the new send email component. I need at least Incident:ProcessID and Incident.IncidentName to make this customization sensible.

Any help is appreciated.

Application Name : SD.Email.Monitor
Process ID : 7224
Date :2011-12-08 16:20:02
Log Level :Error
Log Category :LogicBase.Components.Default.Logging.CreateLogEntryComponent
Machine Name : XXXXXX
Message :
Process Name: Email Monitoring  Model: Process Message Embedded Model  Component Name: GetIncidentByTrackingID  Component Class Name: SD.Components.DB.GetIncidentByTrackingID  Component ID: b41d6492-ce10-424e-9ad0-d1683d676422  Exception Class Name: System.NullReferenceException  Message: Object reference not set to an instance of an object.  Stack Trace: System.NullReferenceException: Object reference not set to an instance of an object. at LogicBase.Core.Data.OrchestrationData.SetValue(String name, Object value) at LogicBase.Core.Data.OrchestrationData.set_Item(String name, Object value) at SD.Components.DB.GetIncidentByTrackingID.Run(IData data) at LogicBase.Core.ExecutionEngine.MultiPathProcessComponentExecutionDelegate.Execute(IData data, IOrchestrationComponent comp, String& outputPath, IExecutionEngine engine, TLExecutionContext context) at LogicBase.Core.ExecutionEngine.AbstractExecutionEngine.RunComponent(TLExecutionContext context, IData data, IOrchestrationComponent comp)

I see the same thing. The process variables are not being brought in for the Email components and the GUID doesn't seem to be acceptible in the GetIncidentByTrackingID component. I will keep poking at it.

I may have found the issue but it needs testing....

In the "GetIncidentByTrackingID" there is no output variable. There needs to be one! I gave it an Output Variable of Incident and then all of the incident fields were available for me further down the path (such as in the Send Email Components). I imagine that Workflow will now allow the component to function correctly as the output would be handled correctly. I can't test fully until this evening so if someone can test now that would be great!

Oh, and one more thing....I would highly recommend adding an ExceptionTriggerByComponent, a Create Log Entry and a GoToComponentByName component to trap any errors that might come from the GetIncidentByTrackingID component as this modification isn't and shouldn't be fatal to the workflow as a whole. If this component errors the rest of the workflow should still function.

I just adjusted the customization according to your suggestion and now the variables are showing in further down.

I can also confirm that now all works fine.The assigned technician now recieves an email notification when the end user updates the incident through an email reply.

Good work!!!

Cheers!

One thing you could try is to use the search function when you're in the process variable picker.

I had no problems finding the GUID variable.

Good luck!

I just noticed, the notification goes out to all technicians instead of just the assigned one.

I don't have the time to continue analyzing this now, I need to close up for today.

Any help is much appreciated.

Thanks in advance!

Is the incident assigned to only a specific user or is it assigned to a user and a group or just a group? I would imagine that you would need to assign an incident to only individual users for only those users to receive emails. If an incident is assigned to a group then every member of that group would receive the email? I will have to play with it. Its a tough one as there is no easy way to debug this project.

I agree, it is not easy to debug.

The incident only has one assigned technician so I at this moment, have no clue where ServiceDesk gets the other technicians. I noticed that SD only gets real technicians, admin@logicbase.com isn't included and that account is part of both support I and II.

Well, i am off now but I will get back on the horse tomorrow morning again.

Good luck!!

I am still getting emails to all technicians instead of only the assigned one. I have gone through the components in this customization without being able to find a reason for this behavior. However it seems like the this modification returns all group members so I gather that there's at least one component that isn't properly configured or doesn't work as it should.

I find it hard to troubleshoot this further. Any help is appreciated.

Cheers.

I am still looking at this. I now have a need to implement it in production so will spend more time this week on this. I think one thing to try is to search for incindet assignees and then extract and differentiate a user type from a group type, discard the group type and send the email only to the user type. 

So a quick look over again this morning and it will email all members of the group based on this specific workflow. If you open the "Add Items To Collection" component and then open the dynamic model inside (ellipses next to Items to Add), there is a text contains rule. This rule is looking for "Group" and if it finds it it is looking for each member of the group and adding them to the "selectedAssignees" array. 

I think (haven't tested it yet) that if you remove the "GetUsersInGroup" component and simply send the output of the Text Contains Rule from Contains to End it will not add all of the group members to the array and instead will only add specific User assignees.

One alternative that I am looking to do is instead of getting all members of group, we do have email addresses assigned to groups in ProcessManager so we may add the group email to the assignees array so at least someone is being notified of an update via email if an incident is not currently assigned to any specific user.

That's the way I have mine configured at the moment. Basically the tasks are either Group or User and you get the info based on that. I use the GetGroupByName component and use the group email rather than the GetUsersInGroup to notify them.