ServiceApi throwing Unauthorize for valid token

Matias

Vote:

We had CMS & Commerce solution
We created an PIM integration to sync data -> azure functions calling Optimizely Service Api.

Before goLive we we tested it with all 3 DXP environments, and it works fine.

Once we goLive with the production page, the unexpected thing started to happen on PRODUCTION:
Calling ServiceApi returns `Response status code does not indicate success: 401 (Unauthorized)`
(and it also startetd to happen on PREP once it was more used by the customer)

Context:
- once authorized, we store the token in azure table
- we also log the token for each call (for debugging purposes only right now)
- we tried with polly-retry (didn't work)
- we tried both, dxp url & domain prod url (doesnt seems to matter)

BUT what is mindblowing, once you take tak token from table/consoleLog - it works just fine if used in hoppscotch/postman call to
Other thing is that the repeated the exact calls to ServiceApi (in tool like hoppscotch), sometimes return Unauthorized also, and then the next call was just fine (that is why we tried with polly retry, but didn't work there)
Support didn't clear the clouds from there...

Any clue what is happening there?

#317514

Edited, Feb 22, 2024 6:30

Quan Mai

Vote:

How did you install ServiceAPI? Is it on one instance or on multiple? I'm thinking about the request hitting a different instance each time

#317522

Feb 22, 2024 7:24

Matias

Vote:

Yes we had such thoughts also... but question what we should do about it?

But what do you mean `How did you install ServiceAPI?` ? - we had single project/app deployed to DXP, containing all CMS/COMMERCE/SERVICEAPI setup in startup.

Not sure what can we do about it or how could we manipulate there around the PROD, as that env azure setup is afaik simply unaccesible for us.

#317523

Edited, Feb 22, 2024 7:32

Quan Mai

Vote:

the common way to deal with it is to enable service API on sch- app (which usually has 1 instance) instead of normal app which could be scaled out to multiple instances, then you can request to that end point instead.

You don't have direct access to DXP env but you can always make requests via zendesk

#317524

Feb 22, 2024 7:53

Matias

Vote:

thanks, that could be usefull.

We had already a really long Optimizely Support Ticket for that, and they didn't suggest any solution for that.

So to confirm if I get you correctly: We should ask for enabling serviceApi only on the one instance on the production? And/or configure load balancer to only point to single instance when it comest to the ServiceApi calls?

#317525

Feb 22, 2024 8:12

Quan Mai

Vote:

There is unfortunately no official guideline, but as I said it is common to only enable it on sch-app (normally you get a different app for scheduled jobs and the like, but that is not guaranteed) - check with support if you already have that and use it for ServiceAPI

#317526

Feb 22, 2024 8:15

Matias

Vote:

I could confirm solution now,
We went with Support creating new slot in each env, callest `sch-dxpname` meant to be used by scheduler to process heavy recurring jobs, but it remains single instance always - matching perfectly our serviceApi usecase - no more unathorized issue.

#317749

Feb 26, 2024 11:44