Allowing updates to incidents through an API - update made as a passed in user

[Ben Lageson]

We have a team in our company that is writing an app that will integrate with ServiceNow allowing users in their system to create and update incidents.  They have asked us to allow them access to an API to do this work, but after discussion we don't want to let them use the Table API because there isn't validation. Our expectation is that there would be the same validation as our Platform UI on any updates coming through the API.  Another requirement that we have is that the update must be done by an ITIL user (not the API user) - meaning that the updated by and activity stream entries must all show up as done by the ITIL user that the pass along in the X-On-Behalf-Of header. 

How can I update an incident as the user that is passed in the header rather than as the API user? 

I've  tried GlideImpersonate() - and this would be perfect except for the race condition where one update comes in while another update is currently processing and fails ACLs because the API user is currently impersonating. 

[Ankur Bawiskar]

@Ben Lageson 

then did you check the approach I shared earlier?

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Ben Lageson]

@Ankur Bawiskar 
Thank you for your assistance! 
I have tried these two options:
 1 -  updating, and overriding the sys_updated_by user id - this is successful in updating the 'updated by' field. However the issue we're finding with this is that the Activity Stream still shows as being updated by the API user id. Comments & Worknotes also show as being added by the API user too which is not ideal. 
2- updating using impersonation -  this works perfectly if the POST requests come one at a time. But the race condition prevents this from being reliable.  Do you think there is another way to make this work by having the Scripted REST API pass the update to another runtime? not sure if that is a reasonable idea or not. 

[Ankur Bawiskar]

@Ben Lageson 

try this

1) call event using gs.eventQueue() and have that event on incident table

2) then use script action and use script there to update and use impersonation script there.

3) remember events when triggered and when script action processes it that's async process so possibly race condition will be gone.

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Ben Lageson]

@Ankur Bawiskar 
I have questions about doing impersonation inside a script action tied to an event.  Since the script action will be running as the system user - won't that impersonation cause anything else that is running as that user to now be running as the user that the system user is impersonating?