cancel
Showing results for 
Search instead for 
Did you mean: 

/queryplan returns HTTP 204

Joe_Peters
Active Contributor
0 Kudos

I was able to successfully get the SQL from one report.  Upon trying it on the second report:

GET /biprws/raylight/v1/documents/316875/dataproviders/DP0/queryplan

I get:

HTTP/1.1 204 No Content

Date: Fri, 26 Feb 2016 21:42:45 GMT

Server: Apache-Coyote/1.1

Content-Type: text/xml

Content-Length: 0

Keep-Alive: timeout=5, max=88

Connection: Keep-Alive

I was able to open the report in WebI and view the SQL, so there is nothing wrong with the report.

Accepted Solutions (0)

Answers (1)

Answers (1)

eric_festinger
Contributor
0 Kudos

hi Joe,

Could you please share some more details, like the version you are running, the data provider type, + any other information you might find useful?

(Can that be related to the "Keep-Alive" header?)

Regards,

eric

daniel_paulsen
Active Contributor
0 Kudos

I think the request for the queryplan should be application/xml and not text/xml

Dan

Joe_Peters
Active Contributor
0 Kudos

Thank for for your reply, Eric.

It's BI4.1 SP06 Patch 5.  The report has standard universe-based SQL data providers.

The keep-alive header was coming from my Apache reverse proxy.  But I just tried going direct to port 6405; the response did not include the keep-alive heard but I still got the 204 response with no content.

Joe_Peters
Active Contributor
0 Kudos

Thank you for your reply, Dan.

I am requesting ti as application/xml but it is coming back as text/xml.  Here is a full request and response from a report that produces a valid response:

GET http://xxx:6405/biprws/raylight/v1/documents/317042/dataproviders/DP0/queryplan

Accept: application/xml

X-SAP-LogonToken: "...."

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Date: Tue, 01 Mar 2016 14:26:01 GMT

Content-Type: application/xml

Content-Length: 1309

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<queryplan editable="true" custom="false">

    <statement index="1">SELECT  ...</statement>

</queryplan>

and a request on a different report that produces a 204:

GET http://xxx:6405/biprws/raylight/v1/documents/1417531/dataproviders/DP0/queryplan

Accept: application/xml

X-SAP-LogonToken: "...."

HTTP/1.1 204 No Content

Server: Apache-Coyote/1.1

Date: Tue, 01 Mar 2016 14:26:02 GMT

Content-Type: text/xml

daniel_paulsen
Active Contributor
0 Kudos

Hi Joe,

Does the failing report have context parameters that might need to be answered prior to the queryplan being able to be set?

check if:  GET  /documents/1417531/parameters  returns any unanswered parameters of type "context"

If so, provide a value for the context prompt and try getting the queryplan again.

Its odd that the response is text/xml.  Can you enable "Show Error Stack" on the WACs to hopefully get a better idea of what's happening?

Dan

Joe_Peters
Active Contributor
0 Kudos

I do have the stack trace option enabled, but it is not producing any content for this request.

There are query prompts in the report, but no context prompt.

Strange - with one of the reports that had the problem, I was able to get it working by opening the report and immediately saving.  But not with another report that I'm testing with.  I will continue to try others.

Joe_Peters
Active Contributor
0 Kudos

Yay!

Calling GET ... /parameters before /queryplan causes the SQL to be returned successfully.

daniel_paulsen
Active Contributor
0 Kudos

Hi Joe,

That's great news.  Out of curiosity, what are the parameter types?  "prompt" or "sapVariable"?
I'm just trying to make sense of it.

Dan

Joe_Peters
Active Contributor
0 Kudos

They're all "prompt".

former_member197386
Active Contributor
0 Kudos

Thanks for the tip Joe, that's weird indeed. Probaly need a fix for that!

Best regards,

Anthony

former_member197386
Active Contributor
0 Kudos

Hello Joe,

We investigated again this issue but we didn't find the workflow and resources to make this problem occurred.

If you have a chance to try on more recent version of BI4 or try to find out what axactly could lead to this error, it would be great.

Best regards,

Anthony

Joe_Peters
Active Contributor
0 Kudos

Ok, I'll give it a try.  It hasn't really been a problem for me recently, since I discovered that calling /parameters first will produce the SQL.

former_member197386
Active Contributor
0 Kudos

Ok, thank you Joe.