Rest API 403 Error after a few requests

[Paul_Hoecherl]

We are developing document operations against the OnBase (Foundation EP3) Rest API.

Per the docs, we generate a fresh bearer token with every request, and the server will respond normally for an number of requests (number varies).

However, the server will eventually start returning "403: The system is out of requested licenses or not licensed for the requested License Type." responses, refusing any further requests after a random number of sequential requests (sometimes it happens after < 10 requests).

When the Rest API server is in this "403 state", the session console shows many (many) sessions with "Concurrent Client" product license.

It also indicates that each of the sessions uses the same Username.

Each of these sessions appears to correspond to one of the previous test requests, based on the LoginTime it displays.

(The Identify provider remains unaffected, always returning valid bearer tokens.)

If we wait long enough (30 mins?) eventually the sessions clear and normal operations resumes.

Restarting IIS has the same effect.

It seems like there is something misconfigured on the Rest API service.

Is this a known issue?

Any ideas appreciated... 

[Paul_Hoecherl]

Thanks - this has helped for the single session scenario.

But load testing in our environment (60 seats) runs us out of seats after around 40 passes, each with a different auth/session. It seems like licenses are not being released quickly enough to allow for testing to complete any more passes than that (each pass fetching a test document).

I am concerned that this cannot scale to handle production.

Are there configuration settings on either the RestAPI or IDP service that can help with that problem?

Is there a "best practice" for session handling that will help release licenses more efficiently after a call-workflow is complete?

[David_Taylor]

@Paul Hoecherl (ClarkPUD) 

> we generate a fresh bearer token with every request

I think this is your issue. I believe you should be getting a new token per "session" and not per "request". As is mentioned elsewhere, if your application includes multiple calls by a user for a particular scenario, you should be able to use the same cookie & token for all calls made by that same user for that session instead of generating a new token/cookie on each request. If a long-running session does not fit your application model, it sounds like the query metering license would be a better fit for you. Pay attention that the license usage complies with the Hyland agreement (link below) but if your app makes a lot of rapid calls that are not all part of a single user session, then concurrent licensing will not work very well for you and you might look at query metering. In my opinion the concurrent licensing model for an API is an antiquated method and will rarely fit modern application architectures.

API Licensing Best Practices

In addition to Adam's link above about query metering, also see:

https://community.hyland.com/en/forum/threads/81178-license-types-for-rest-calls