Discussions

One of our EMS-on-prem clients is making heavy use of the REST API to pull date for their main portal site. iMIS is not their website, but their portal site makes multiple REST calls to gather information to display on the first page after a login. They are big on redundancy and load distribution. The portal site is served by multiple web servers, which send requests to a "Finance API" server, which then performs all REST calls. The Finance API server may have many concurrent requests in process at once.

In the two weeks since they went live, they have had multiple occasions where a request with a non-expired API token returned an Unauthorized. Through experimentation and help from Tech Support, we learned that these are some of the reasons tokens will be invalidated:

1. The website or app pool restarts
2. A user pushes the "Purge System Cache" button
3. When a new token is requested for the same user, the previous token for that user is expired.

What else can cause a token to be invalidated?

For item #1: Is there a way to configure EMS so that issued tokens will be remembered across restarts? For example, this client would be willing to configure their own Redis cluster, so two EMS web servers can share their pool of known tokens.

For item #2: Could the tokens be excluded from the purge button?

For item #3: What is the intended way for a third party process to acquire and manage tokens when that process may be multi-threaded? Ideally, they would like the Finance API to be multiple servers, each managing its own token. If requesting a token invalidates other tokens for the same user, will we need distinct user/password pairs for each process that is accessing REST?