APAR status
Closed as unreproducible.
Error description
The following issue was tested against Maximo 7503 with Service Provider 7511 installed. When an Escalation updates the Service Request (SP) the Escalations Change By and Change Date are being updated with the user name from the SR and the time the update was made. Steps to reproduce the issue are as follows: First we will need to create a simple work flow process that will be used to apply the response plan. Work Flow Set up. 1. Create a new WF against the SR Object. 2. Add a task node, in the line leading to the task node add an action of PLUSPSRAPPRESPL. This will be used to add the response plan to the SR. 3. Add a role to the task node, save and enable and activate the work flow process. Now we need to create the escalation that will be used to apply the work flow process to the SR. 1. Create a new Escalation: Applies to : SR Condition: location = 'BLK1000' and siteid = 'BEDFORD' Schedule: 5 min Escalation Point: repordate Escalation point condition: 1=1 Action: PLUSPSRAPPRESPL save and activate the escalation. We are now going to have to create a new response plan that will be applied to the SR once created. 1. Create a new Response Plan Provide it with a star and end date, under the Response section have it assign an owener. Make sure the owner will be a user other than who created the above escalation. Move to the Locations tab and add the location of BLK1000, site bedford and Organization of Eaglena, now activate the response plan. We are now going to create the Service Request (SP) we are going to use for testing. The SR will need to be created by a user other then who created the Escalation as this will show that the Change by on the escalation updates based on who created the SR. Create a new SR. 1. Reported by add user name as needed. 2. add a classification I used End USer Issues (1) 3. add a site of Bedford 4. Add a location of BLK1000, complete the GL account and save. now wait 5 minutes for the Escalation to run and complete. Check the Escalation via the database and look at the change by field and notice that the change by now has the name of the user who created the SR. Create another SR using yet another user with the same criteria as before. Check the Escalation once again and notice that it updates yet again. This will lead to issues when you have many users creating SR that require the same response plan to be used. The users will end up with an error message of: A nested exception caused the work flow process to fail. Record Escalation XXX has been updated by another user. Your changes have not been saved. Refresh the record and try again.
Local fix
n/a
Problem summary
**************************************************************** * USERS AFFECTED: * * Service Desk users * **************************************************************** * PROBLEM DESCRIPTION: * * ESCALATION XXX HAS BEEN UPDATED BY ANOTHER USER. YOUR * * CHANGESHAVE NOT BEEN SAVED REFRESH THE RECORD AND TRY AGAIN. * **************************************************************** * RECOMMENDATION: * * This is not reproducible in 7.5.0.5. Tried the scenario on a * * Service Provider environment with 7.5.0.5, could not see the * * Change By field change. * ****************************************************************
Problem conclusion
Temporary fix
Comments
APAR Information
APAR number
IV39367
Reported component name
WORK & MTRL APP
Reported component ID
TIVOWRKMM
Reported release
750
Status
CLOSED UR5
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-04-05
Closed date
2013-07-26
Last modified date
2013-07-26
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
R750 PSY
UP
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSLKT6","label":"IBM Maximo Asset Management"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"750","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
Document Information
Modified date:
26 July 2013