I want to report an issue with our SAS stored procedures exposed via the SAS BI WS as an rest API which we are currently not able to solve.
The issue is as follows:
We are currently exposing 4 APIs via the SAS BI WS to other application within our organisation. These APIs are consumed via an API proxy gateway, meaning that the consumer will call the API gateway, and that will in turn call the endpoint of the web service on our server running SAS.
Three out of four APIs are built by using x-www-form-urlencoded key-value pairs. The keys are defined via de stored procedure definition as input prompts.
The problem arises when one of the keys is spelled wrong (i.e in the above case countryCode1 instead of countryCode).
The stored procedure runs in to error ( as expected) and an HTTP 500 message is returned. However, when a new call is made to the API proxy with the correct parameters, or even a call to one of the other APIs that we host on the server, still http 500 is returned, even though the input is correct. The stored procedure is never executed nor produces any log ( so it goes wrong before that)
I have done some analysis on the SAS server logs and access logs (path = /opt/sas/local/config/web/Lev1/Web/WebAppServer/SASServer1_1/logs) , and the calls do seem to be reaching our server as I can see entries in our logs (so the calls are not stopped at the proxy).
What I do notice is when the second call ( with correct parameters) is made:
Server.log / Catelina.out:
2024-09-19 15:58:09,321 ERROR (tomcat-http--32) [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/SASBIWS].[mvc]] Servlet.service() for servlet [mvc] in context with path [/SASBIWS] threw exception [Request processing failed; nested exception is com.sas.svcs.security.authentication.client.TicketCreationException: Unable to acquire ticket: <400 Bad Request,{Date=[Thu, 19 Sep 2024 13:58:09 GMT], Server=[Apache], X-UA-Compatible=[IE=edge], Content-Length=[0], X-Frame-Options=[SAMEORIGIN], X-XSS-Protection=[1; mode=block], X-Content-Type-Options=[nosniff],
To me it seems like that whenever a bad call was made (with wrong input parameters), it blocks the connection from that consumer (the proxy in this case) and is no longer able to issue a ticket from SASLogon ( HTTP 400 response from SASlogon – “Unable to acquire ticket”).
Whenever I make a call via postman directly on our server endpoint (so circumventing the proxy) it ‘resets’ and the proxy will again be able to call the SAS BI WS as normal.
Could you please assist here on what we can do to allow new correct calls from a consumer after a wrong request was made?
FYI we are using the following setup:
SAS 9.4 M7( will be upgraded to M8 soon) running on Linux RHEL 6.8 (this will be upgraded to 8.10)
