Resolving incidents via REST API does not trigger business rule.

mikeder
Kilo Explorer

Hello, I have written a Shinken integration for our SN instance and currently I resolve an incident by updating the following: close_notes, close_code, state, incident_state and comments. The problem is the business rule that is supposed to run when incident state changes to either 6 or 7 doesn't get triggered. This in turn causes the calender_stc field to not get updated until our close audit runs 48hrs later. Looking at the History list for two incidents, one resolved via the UI and one resolved via REST API, shows me that the Duration, Resolve Time, Business Duration, Business resolve time are not updated by the mark_resolved business rule when resolve via REST.

Can anyone shed some light on why an update to the incident table via REST API is handled differently than one made via UI?

6 REPLIES 6

Mike Allen
Mega Sage

Is this a table API, or import set?   I know in import set, you can, in the transform map, mark it to run business rules:



Capture.PNG


We're using the table API in this case


I was able to test in both the REST API explorer and the Advanced REST client in chrome and both ran business rules when I manipulated records using the table API.


ciprianmalaia
Kilo Contributor

I experienced the same behavior described in OP. Closing a Problem record via REST API does not update the Duration and Business duration fields. Same for Incident table. The business rule "mark_closed" is being invoked, however not all fields which are set in the rule are updated.



I was able to get around this by changing the Read Only setting for Duration and Business duration fields in Problem table definition. By default both fields are Read Only, as soon as I unchecked the setting, the fields started being updated when closing the record by REST update.



It's also worth mentioning that creating a new Problem record with State=Resolved/Closed, results in Duration and Business duration being updated as expected, even when these fields are Read Only. It's not a realistic scenario but it's interesting to see that the REST implementation can get past the Read Only restriction when the record is created but not when it's updated.