Topic
  • 8 replies
  • Latest Post - ‏2013-04-18T23:14:32Z by 7R5M_Juan_Mora_Rodriguez
7R5M_Juan_Mora_Rodriguez
5 Posts

Pinned topic Worklog notification not bringing associated worklog

‏2013-04-17T15:07:47Z |

Good Morning,

In TSRM, I've been creating an escalation whose purpose is to notify the service request affected user and owner of a new worklog insertion. The notification is something like this:

:affectedusername:

A new workflow record has been established for your service request No.: :ticketid:

Username:    :affectedusername
Description :description
Details:
:DESCRIPTION_LONGDESCRIPTION

Worklog:
  
:WORKLOG.DESCRIPTION
  
:WORKLOG.DESCRIPTION_LONGDESCRIPTION

Clic on the following link to go directly to the service request:
http://127.0.0.1/maximo/ui/maximo.jsp?event=loadapp&value=sr&uniqueid=:ticketuid

However, the worklog.description and :worklog.description_longdescription variables are not bringing up the last worklog record for this particular service request, but the first that was generated since the beginning of the times on TSRM.

I created an alternative escalation which is associated with the worklog object, marked the worklog object as a main object, but then I don´t know how to make the escalation sql condition to call up the ticket related to this particular worklog.

Thanks for your much needed help.

Updated on 2013-04-17T15:11:17Z at 2013-04-17T15:11:17Z by 7R5M_Juan_Mora_Rodriguez
  • bob@work
    bob@work
    19 Posts
    ACCEPTED ANSWER

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T13:31:52Z  

    Thanks for your response. How can I obtain the last worklog entry in a relation condition? My limited knowledge tells me it is not possible. The second condition is in effect created for the worklog object, so I will test those changes in off hours, and tell here what happened.

    Create a new TICKET relationship to the WORKLOG table with the following condition:

    recordkey = :ticketid and class = :class
    and createdate = (select max(createdate)
      from worklog mwl where mwl.recordkey = worklog.recordkey and mwl.class = worklog.class)

    If you need to filter on the work log type or whether it is viewable to the client you'll have to add those conditions.  Then use the new relationship in your template.

  • bob@work
    bob@work
    19 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-17T20:40:40Z  

    Your first solution would have worked if you created a new relationship that would have obtained the last WORKLOG entry.

    For the second solution you would use a condition where:

    ticketid=recordkey and class=class

  • 7R5M_Juan_Mora_Rodriguez
    5 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-17T22:00:15Z  
    • bob@work
    • ‏2013-04-17T20:40:40Z

    Your first solution would have worked if you created a new relationship that would have obtained the last WORKLOG entry.

    For the second solution you would use a condition where:

    ticketid=recordkey and class=class

    Thanks for your response. How can I obtain the last worklog entry in a relation condition? My limited knowledge tells me it is not possible. The second condition is in effect created for the worklog object, so I will test those changes in off hours, and tell here what happened.

  • bob@work
    bob@work
    19 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T13:31:52Z  

    Thanks for your response. How can I obtain the last worklog entry in a relation condition? My limited knowledge tells me it is not possible. The second condition is in effect created for the worklog object, so I will test those changes in off hours, and tell here what happened.

    Create a new TICKET relationship to the WORKLOG table with the following condition:

    recordkey = :ticketid and class = :class
    and createdate = (select max(createdate)
      from worklog mwl where mwl.recordkey = worklog.recordkey and mwl.class = worklog.class)

    If you need to filter on the work log type or whether it is viewable to the client you'll have to add those conditions.  Then use the new relationship in your template.

  • 7R5M_Juan_Mora_Rodriguez
    5 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T14:31:57Z  
    • bob@work
    • ‏2013-04-18T13:31:52Z

    Create a new TICKET relationship to the WORKLOG table with the following condition:

    recordkey = :ticketid and class = :class
    and createdate = (select max(createdate)
      from worklog mwl where mwl.recordkey = worklog.recordkey and mwl.class = worklog.class)

    If you need to filter on the work log type or whether it is viewable to the client you'll have to add those conditions.  Then use the new relationship in your template.

    Thanks. it works perfectly. However, I was inclined to follow the second option (create a WORKLOG relationship to the TICKET table) and change the escalation, actions and comm templates accordingly to be associated with the WORKLOG object). It now sends the correct worklog within the notification, but the action in charge of changing the NOTIFIED status does not work, that is, the notification gets sent indefinitely.  What could be causing this?

  • bob@work
    bob@work
    19 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T14:50:38Z  

    Thanks. it works perfectly. However, I was inclined to follow the second option (create a WORKLOG relationship to the TICKET table) and change the escalation, actions and comm templates accordingly to be associated with the WORKLOG object). It now sends the correct worklog within the notification, but the action in charge of changing the NOTIFIED status does not work, that is, the notification gets sent indefinitely.  What could be causing this?

    You would need to create a WORKLOG relationship back to the TICKET object.  Just keep in mind that WORKLOG is used for multiple different objects (SR, INCIDENT, CHANGE, WORKORDER, etc.), and your escalation would need to filter based on the type of objects your dealing with in your related actions and templates.

    ticketid = :recordkey and class = :class

    When you check the repeat option on the escalation point you will need some other condition to stop this record from being picked up by the escalation.  Going in reverse from the WORKLOG to the TICKET should work, but you'll want to un-check the repeat option.

  • 7R5M_Juan_Mora_Rodriguez
    5 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T21:34:39Z  
    • bob@work
    • ‏2013-04-18T14:50:38Z

    You would need to create a WORKLOG relationship back to the TICKET object.  Just keep in mind that WORKLOG is used for multiple different objects (SR, INCIDENT, CHANGE, WORKORDER, etc.), and your escalation would need to filter based on the type of objects your dealing with in your related actions and templates.

    ticketid = :recordkey and class = :class

    When you check the repeat option on the escalation point you will need some other condition to stop this record from being picked up by the escalation.  Going in reverse from the WORKLOG to the TICKET should work, but you'll want to un-check the repeat option.

    Thanks Bob for all your advice.  I un-checked the repeat option on the escalation point and got the expected results. Thanks as always for your support.

  • bob@work
    bob@work
    19 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T21:51:45Z  

    Thanks Bob for all your advice.  I un-checked the repeat option on the escalation point and got the expected results. Thanks as always for your support.

    Keep in mind when the repeat option is unchecked it doesn't allow that escalation point to execute again for that record.  It tracks these in the occurrences in the ESCREPEATTRACK table.  The OWNERID column is the internal unique id for the object you have the escalation set up against.

    So if went with option to run the escalation against the SR object you would only get one execution of that reference point for each SR record when the condition occurred.

    Using the WORKLOG as the object for the ESCALATION would capture every time a new work log entry is added.  The only problem is if you have a production system with lots of existing data this escalation would fire for every existing record unless you restrict the records, or pre-populate the ESCREPEATRACK table before enabling your escalation.

     

  • 7R5M_Juan_Mora_Rodriguez
    5 Posts

    Re: Worklog notification not bringing associated worklog

    ‏2013-04-18T23:14:32Z  
    • bob@work
    • ‏2013-04-18T21:51:45Z

    Keep in mind when the repeat option is unchecked it doesn't allow that escalation point to execute again for that record.  It tracks these in the occurrences in the ESCREPEATTRACK table.  The OWNERID column is the internal unique id for the object you have the escalation set up against.

    So if went with option to run the escalation against the SR object you would only get one execution of that reference point for each SR record when the condition occurred.

    Using the WORKLOG as the object for the ESCALATION would capture every time a new work log entry is added.  The only problem is if you have a production system with lots of existing data this escalation would fire for every existing record unless you restrict the records, or pre-populate the ESCREPEATRACK table before enabling your escalation.

     

    First off, very helpful insight.

    I previously relied on the worklog object NOTIFIED attribute to track on the escalation condition whether the record had been notified or not some time in the past. Then, I set up an action to put a 1 in that attribute, in addition to sending a notification.

    What I am doing now is setting an escalation point condition which checks the new worklog records within a two minute frame and thereafter, it sends the desire notifications. Because the escalation runs every two minutes, there's no record left to watch. My only concern in this case is: what happens as my worklog data grows? will the escalation take up more resources from my server? if so, what are the counter measures to take into consideration?