The sm.update.affected.services RAD performs unnecessary updates to probsummary records.

  • Document ID:KM494309
  • Creation Date:04-Sep-2008
  • Modified Date:19-Dec-2016
    • Micro Focus Products:
      service manager 7.01

Summary

In ServiceManager 7.0.X, the sm.update.affected.services RAD that is automatically schedule after updating any Incident (probsummary) record. The result is the History tab of nearly every Incident Management record shows the updated.by as problem. SCR42003 has been opened to address this issue.

Error

The main error/issue is that all probsummary tickets will show the updated.by as 'problem'

RAD: ServiceManager 7
Binaries: SM7.0.1
Server OS: Windows Server 2003 Enterprise Edition
RDBMS: MS SQL Server
The sm.update.affected.services RAD that is automatically scheduled after updating any Incident (probsummary) record.   The result is that the History tab of nearly every Incident Management record shows the updated.by as problem. While it is reasonable to have problem update as necessary for Alert Stages.

Steps to Replicate:

1. Startup an SM 7.0.x system with all of the background processes running (lock on display disabled).
2. Create a new Incident Management record; be sure to populate logical.name with a CI Item.
3. Perform an update on the IM record opened in step 2 by clicking Save and remaining on the record.
4. Sit on the record for a few minutes - the problem process will run the sm.update.affected.services RAD via schedule record in the background.
5. After a few minutes, attempt to type in the record and note that the system prompts for it to be refreshed as it as been modified since last read.
6. Check the History tab and note that the problem user/process was the last process to update the record - in only a few minutes we have already lost the updated.by value!
7. Perform another update on the record, wait a few minutes for problem to re-run the sm.update.affected.services RAD.
8. Confirm that ANOTHER update was made by problem even though no data is actually changing within the affected.services array - why perform an unnecessary update and causing database activity and loss of useful historical information?

Cause

The RAD code does not successfully perform a check to see if the affected.services array actually needs to be updated, it updates the probsummary record regardless of whether data is changing or not. This can be seen by breakpointing within the workflow while executing through the test.schedule RAD App:
Breakpoint reached for Panel: verify.valid
|5| verify.valid
|5| RAD: sm.update.affected.services
d affected.services in $L.appl=$L.biz.services
false
d affected.services in $L.appl
{}
d $L.biz.services
{}

Fix

QCCR1E31306 Changes/incidents are updated by the 'sm.update.affected.services' application even when there are no new changes to save
https://softwaresupport.hpe.com/group/softwaresupport/search-result/-/facetsearch/document/LID/QCCR1E31306

Technical solution:
1) Process "im.save"
calls RAD "sm.schedule.update.affected.services"
Condition should contain
... and not same(logical.name in $L.file.save, logical.name in $L.file)

2) Process "cm.update.save"
initial expression should contain this:

$L.orgCis={};if (not null(logical.name in $L.file.save)) then (1 in $L.orgCis =logical.name in $L.file.save);if (lng(denull(assets in $L.file.save))>0) then ($L.orgCis=$L.orgCis +denull(assets in $L.file.save))

RAD call "sm.schedule.update.affected.services" should contain
pre expression
$L.saveCis={};if (not null(logical.name in $L.file)) then (1 in $L.saveCis=logical.name in $L.file);if (lng(denull(assets in $L.file))>0) then ($L.saveCis=$L.saveCis+denull(assets in $L.file))

and condition
... and  $L.saveCis ~=$L.orgCis