Intermittent error received back from Hornbill API "Security Error: 1" when attempting to add value to Requests h_custom_d

[Berto2002]

We have a power automate job that we fire through iBridge and that then uses the API to come back and update a custom field. It works 95% of the time. It's adding our users to shared mailboxes (and removing).

In Power Automate we have this code for updating the Request with the custom field value:

INPUT {   "params": {     "requestId": "SR00134328",     "customFields": "{\"h_custom_d\" :\"Success\"}"   },   "@service": "apps/com.hornbill.servicemanager/Requests",   "@method": "update" }

The usual output to that is:

OUTPUT { "@status": true }

However, occasionally we are getting this:

OUTPUT {   "@status": false,   "state": {     "code": "0200",     "service": "apps",     "operation": "update",     "error": "FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/update): Security Error: 1"   } }

As a result of the error, the custom D field is not being updated so workflow goes down the manual processing route to service desk (assuming failure) despite the Power Automate successfully adding/removing from the mailbox.

As I say, this is intermittent so most of these are working indicating it not an issue with the configuration; something is giving a Security error from the Hornbill side on occasions.

Can you help please?

@Ben C

[Victor]

29 minutes ago, Berto2002 said:

It works 95% of the time

The other 5% is when the session is invalid (this is what error 1 means) which is usually a result of somebody or something else using that (user) context which invalidates your session.

[Berto2002]

@Victor Are you saying that the error means another API call was being made at the same time with the same user; and the system can only cope with one API call session per user at a time (no queuing)?

If so this means:

• as we grow our automation use of API we are going to get more and more clashes so
• we will need build retry capability into all of our API calls and/or
• we need to start consuming more licenced users that can accept API calls so we don't hit clashes?

What resources have we got in the system for me to see what was the clash or when a clash occurs please? Could you indicate what log and what to search for?

[Steve Giller]

35 minutes ago, Berto2002 said:

Are you saying that the error means another API call was being made at the same time with the same user; and the system can only cope with one API call session per user at a time (no queuing)?

No, @Victor is saying that something invalidated the session. That can be for a wide variation of reasons and as we can have no idea what actions are being taken by your PowerAutomate we're not in a position to comment further.

 

[Gerry]

@Berto2002

From Power Automate, how are you creating a valid session before you make the API calls? Are you using an API key?

So you make an iBridge call to trigger a Power Automate job, that power automat job then calls back to the Hornbill instance to update the request?  From within Power Automate, how are you establishing a valid session before you make the API call back to the Hornbill instance? Are you using an API key?

[Gerry]

@Berto2002

"Are you saying that the error means another API call was being made at the same time with the same user; and the system can only cope with one API call session per user at a time (no queuing)?"

When you make an API call to the Hornbill ESP services, these API calls are concurrent, thats not the problem.  What the server is reporting "Security Error: 1" is, there is an attempt to clone the session you have established in order to process that API call you have made, and for some reason, the session (or API key) you have used to make the API call with is invalid.  

Why its invalid I am not sure, it depends on a number of things, but understanding how you are establishing the session to make the API call from Power Automate would help us understand that

 

[Ben C]

The Power Automate flow works as follows - Trigger is a get HTTP request, this URL is supplied to Hornbill so when the shared mailbox request ticket type is raised it fires over to the power automate flow. We then grab the details from the Hornbill ticket (Shared mailbox email address, user requested email address, level of permissions required, ticket number). This then runs through Azure automation to apply the permissions via a PowerShell script. Then composes the status results and grabs the api key from our Azure Vault. Finally on success we fire back 2 actions to Hornbill, we use 2x HTTP connectors to POST back to hornbill using the API key and the ticket number, one for the timeline update to state the permissions were set successfully and another to update our custom field D with a success for the hornbill workflow to proceed and close the ticket. 

 

Success -

{
"@@service": "apps/com.hornbill.servicemanager/Requests",
"@@method": "updateReqTimeline",
"params": {
"requestId": "Body TicketID",
"content": "Shared mailbox permissions have been amended successfully",
"visibility": "trustedGuest"
}
}

 

Custom word D -

{
"@@service": "apps/com.hornbill.servicemanager/Requests",
"@@method": "update",
"params": {
"requestId": "Body TicketID",
"customFields": "{\"h_custom_d\" :\"OUTPUTS\"}"
}
}

[Berto2002]

^^ Ben is in my org but more technical and does or automations. That first 'trigger' is iBridge (note, this bit always works ok)

The bit that seems to give this Security Error 1 is the code Ben posts that comes in to the Request during the "suspend 3 mins" period.

PS when we set this up, the "wait for custom field" node was not working so we went for suspend since this was not time critical.

[Gerry]

@Berto2002

So in relation to this "grabs the api key from our Azure Vault" that sounds correct to me, but it does not make sense why there would be an invalid session reported, that seems odd. I think we would, at the point of failure have a look at the Hornbill instance logs.

The way in which this works is pretty simple,  When you make an API call to our service, using an API key, our service validates that key and then looks for an existing session associated with that API key, if it finds one, it binds to that session for the purpose of processing the API request.  If, a session does not exist for that API key, then, it will use the validated API key to create a new session associated with that API key, and then use that.   Under either condition, if the API key valid and the account the API key is associated with is also valid there is no reason to fail. 

So looking at the logs (EspServerService and api logs) should provide us with more of a clue as to whats going on here, its not something I would expect could happen.   We have updated the error message, so that will include the originating session ID (the one that should be recovered by the API key verification), so that would be useful to search the logs. 

Gerry

[Berto2002]

@Steve Giller, @Victor given the above additional logging, should we log a support request to follow-up on this? We had the issue occur again (it's intermittent) but this time there is more information about the session ID as Gerry suggested.

{   "@status": false,   "state": {     "code": "0200",     "service": "apps",     "operation": "update",     "error": "FlowCode Exception (com.hornbill.servicemanager/entities/Requests/fc_ops/update): Security error cloning session: U2025010300313626.215 (invalid session)"   } }

@Ben C

[Berto2002]

For now we have added an error checking into our API code and a repeat call if we get the above in the hope it doesn't happen the second time.