Categories
Client received soap fault from server:Token based login not supported for API : 'logoff'
We did an in-place upgrade from OAS 7.0 to OAS 7.6. We have company customized process which runs events on oas through jdbc call the bi reports are executed. After the upgrade I am getting below error. "Client received soap fault from server:Token based login not supported for API : 'logoff'. Please see the server log to find more detail regarding exact cause of the failure. " can u help me find the prbm. Did SOAP API change for OAS 7.6 version?
Answers
-
Hi @User_FWBDT
Can you share me more details about your API,are you using any REST/SOAP methods ?
Regards,
Arjun
0 -
I am using SOAP methods. see below oracle doc. Process uses jdbc connection and logon logout and couple other methods to modify, save and run the report. it was working fine in OAS 7.0 version. it started throwing error after in-place upgrade to OAS 7.6 . Any help would be appreciated.
Description of Services and Methods in Oracle BI EE Web Services
Thanks
0 -
Please could you log an SR with the details of your code (for example) is it's stopped working after an upgrade. The SOAP web services have introduced the ability to get a sessionID by using an access token as an Authorization header to the login SOAP service but I assume you're using a name/pwd to get a session ID?
0 -
Hi
I have this SR. it stopped working after the upgrade from OAS 7.0 to OAS 7.6. It was workign fine in OAS 7.0 version.
SR 3-38641628211 : Client received SOAP Fault from server: Token based login not supported for API : 'logoff'.
The error can be reproduced by following below steps:-
- install soapui
- trigger logon call:
- trigger logoff
- and i get the error (Below Screenshots)
0 -
As a quick fix I would say you can just comment out the call to the logoff at the end of your script: the open session will timeout and be closed anyway.
I didn't use the webservice in OAS 7.6 (2024), but based on Mike's comment above, I see a connection.
The error seems to be saying that you can't call the logoff method if you did use a token instead of user/password. But this isn't your case, therefore it could absolutely be a regression introduced in the webservice when they did add the token option.
If this is what happened, I would also complain that Oracle didn't update the WSDL to a newer version: the v12 was already there with OBIEE 12c, in OAS 7.6 v12 is still the newest version available. If the webservice changed, I would have liked a v13, allowing for the documentation to be explicit on which version supported what method and feature. (And keeping the older versions as they were, without any change or regression.)
The SR should give you the answer, it would be nice if you can just post back here an update when you get an answer, because you will maybe not be the only one facing issues if there is a regression.
1 -
I have logged an SR with Oracle but seems like they are not ablet reproduce the issue on there side asking us to check SSO and SSL. also Oracle mentioned, My url is without 'ws:
http://server:9502/analytics/saw.dll?SoapImpl=nQSessionService
they are suggesting to use -ws in URL.
http://server:9502/analytics-ws/saw.dll/
However, my concern is we didnt have that in oas 7.0 then why do we need it now. They are investigating it further.
0 -
Starting with OBIEE 12c, the webservice is generally called via the /analytics-ws url, because of the security implementation of /analytics. It's just like with Catalog Manager, where you also need to use the /analytics-ws url instead of /analytics.
It is related to the lightweight SSO implemented that can make things challenging in /analytics (and I believe there is also a different implementation of timeout or things like that, that's why all the webservice calls have been moved to their own URL).
You can also see that back in OBIEE 12.2.1.2 they documented it as /analytics-ws:
You should try to use that url as it's how the web service is expected to be accessed.
The fact it was working before in OAS 7.0 with /analytics can be for many reasons, but still the official URL for he webservice was already analytics-ws, therefore you should first try with /analytics-ws to see if you have the have same behavior.
1
