topic Re: Why do I get response status 500 when calling a Batch API Macro? in Administration and Deployment

Why do I get response status 500 when calling a Batch API Macro?

alisio_meneses — Thu, 22 Dec 2022 15:06:30 GMT

Hello there!

I've created pipeline in a Forecasting project in SAS Model Studio and it runs fine. I've downloaded the batch API, put it on a SAS program and set the macro variables, but SAS Studio report an error when I press run. The log shows I am getting a Response status 500 in a PROC HTTP.

I've checked the execution log but was unable to extract a clue.

Anyone has a hint to why do I get response status 500 when calling a Batch API Macro?

Additional info:

I'm using a SAS Viya 3.5 environment
The Forecasting project creator and the batch API SAS program creator are the same
SAS programa and log attached (i've remover sensitive information)

Thank you!

Re: Why do I get response status 500 when calling a Batch API Macro?

SASJedi — Thu, 22 Dec 2022 15:35:35 GMT

HTTP Error 500 is a general web server error. I see your code attached, but not the log, so it's difficult to say which of your PROC HTTP steps generated the error. To help troubleshoot, instead of just writing the status code to the log with %PUT, also write the associated text:

%put NOTE: &=SYS_PROCHTTP_STATUS_CODE;
%put NOTE- &=SYS_PROCHTTP_STATUS_PHRASE;

If you could attach the log here, that would be helpful, too.

Mark

Re: Why do I get response status 500 when calling a Batch API Macro?

alisio_meneses — Thu, 22 Dec 2022 18:25:02 GMT

Hi @SASJedi, thanks for the reply.

I agree with you regarding the 500 error, but the fact that I can run the same pipeline fine from the Model Studio GUI is a bit puzzling.

Well, here you go. The sas with status phrase and log files.

Re: Why do I get response status 500 when calling a Batch API Macro?

SASJedi — Thu, 22 Dec 2022 21:55:19 GMT

Looks like the third PROC HTTP step is the one throwing the error. And just before that step, I see:

NOTE: The quoted string currently being processed has become more than 262 bytes long.  
You might have unbalanced quotation marks.

Is that expected? If not, the unbalanced quotes may be interfering with the code generated for the subsequent PROC HTTP step.

As an additional troubleshooting technique, I'd run the process with OPTIONS MPRINT set, so you can see the actual generated code, and give that last PROC HTTP step a good look. If you want, you can use the MFILE option to write the code to a separated .sas fille for easier review:

filename mprint '~/my_generated_code.sas';
options MPRINT MFILE;

Re: Why do I get response status 500 when calling a Batch API Macro?

alisio_meneses — Tue, 27 Dec 2022 19:04:14 GMT

Hello there, @SASJedi

Regarding the note " The quoted string currently being processed....", I suppose it is expected since the macro was copied from the node in the project pipeline.

Anyway, I figured out how to reproduce the error: It happens as soon as I share the Model Studio Project where I got the batch API from with a group. This explains the fact that only a few projects where affected. The private projects are working fine.

It raises the question: is this a limitation or a bug?

Re: Why do I get response status 500 when calling a Batch API Macro?

SASJedi — Mon, 02 Jan 2023 14:40:40 GMT

This looks more like a permissions issue than a coding issue - and I'm primarily a code-head. I'm going to move this message stream over to the Administration and Deployment group in hopes of raising your visibility with the SAS Administrators who tend to congregate there.

Re: Why do I get response status 500 when calling a Batch API Macro?

gwootton — Mon, 02 Jan 2023 15:37:31 GMT

I would engage SAS Technical Support for this.

A HTTP 500 response should have an associated error in the service that is returning that response. In this case the service serving the /forecastingGateway endpoint. Since this happens as a result of sharing that error might be coming from a failure from another service called by the gatweay, so would require looking at multiple service logs from that time.

You can look for errors in the logs for your microservices that coincide with when you encountered the 500 response.