No there is not. Just hit the authentication API each time. Don't make it more complicated than it is. 
I think my explanation was confusing.
So I have organized my situation below
--action of the external system----
1.Create AA token
2.Create a work item in a queue
<Loop(Execute every 3 minutes until the status become "failed" or "completed")>
3. Get AA workItem status
---------------------------------
When this external system is executed twice almost at the same time,
as shown below, "Execution1" fails because the token is invalidated.
pExecution1] 1.Create AA token > Done
tExecution1] 2.Create a work item in a queue
nExecution1] 3. Get AA workItem status > Done (status = "running")
rExecution1] 3. Get AA workItem status > Done (status = "running")
rExecution2] 1.Create AA token > Done
gExecution2] 2.Create a work item in a queue
iExecution2] 3. Get AA workItem status > Done (status = "running")
"Execution"1"] 3. Get AA workItem status > Failed 401 error (Token was invalideted )
Based on the above premise, could you tell me whether this solution works well or not?
tsolution]
- Enable multi-login for the API user in the Control Room settings
- Add parameter { “multipleLogin”: true} when isuue the token.
Hey @Ryutata , the Multi-Login doesn’t prevent your token from being overwritten by multiple executions. It allows you to have a UI and API connection simultaneously. This is primarily used so that a human can be logged in working while having bots do something, otherwise you get kicked off each time your bot authenticates!
There are a few solutions for you though:
- Follow this guide with your control room admins:
https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/administration/roles/cloud-control-room-apikey-role.html
API Keys can be used across multiple interactions simultaneously. There is some maintenance associated though since they expire after a few months by default. If your control control room admins allow you to generate keys that never expire, you could do this and forget about it forever.
- Externalize your token variable:
This is more difficult architecturally, but also requires no maintenance while setting up and no dependency on anyone else to do anything for you. The Bot needs do the following in this order: 1) Gather the token from the credential vault. 2) Attempt to do a transaction. 3) If it fails, get a new token. 4) Put it back in the credential vault via API 5) Use the token to do the transaction.
This means that all the instances of the bot are attempting to use the same token and will never invalidate the other’s use. And whichever bot execution happens to attempt to use it when it first becomes invalid will repair it for all other executions.
Hello,Matt.Stewart -san
Thank you for your response. I understand that the multi-login setup cannot solve the token overwriting issue.
Thank you very much for your proposal of solutions. We will continue to consider our response based on the information you have provided.