on 2012 Jun 27 1:24 PM
HI All,
First off I know nothing about BSP, just thought I would get that one out the way.
With that said I have tried to follow this wiki :- http://wiki.sdn.sap.com/wiki/display/BSP/Handling+Binary+Data with some success.
Now what I am trying to achieve is simply reproduce this small piece of php code :-
<?php
header("Content-type: application/octet-stream");
header("Content-Disposition: attachment; filename=\"my-data.csv\"");
$data=stripcslashes($_REQUEST['csv_text']);
echo $data;
?>
in a BSP application.
I have tried the following in the layout tab and in the Event OnInitialization:-
<%
IF request->get_form_field( 'csv_text' ) IS NOT INITIAL.
response->set_header_field( name = 'Content-Type' value = 'application/octetstream' ).
response->set_header_field( name = 'Content-Disposition' value = 'attachment; filename=csv_text.csv' ).
response->set_header_field( name = 'Connection' value = 'close' ).
DATA: file_content TYPE string. file_content = request->get_form_field( 'csv_text' ).
response->set_header_field( name = 'Expires' value = '0' ).
response->set_header_field( name = 'Pragma' value = 'no-cache' ).
response->set_header_field( name = 'Cache-Control' value = 'max-age=0' ).
REPLACE ALL OCCURRENCES OF ' ' IN file_content WITH ''.
response->set_cdata( file_content ).
RETURN.
ENDIF.
%>
The only problem is that I get the desired download dialog box but I am directed to a blank BSP screen with "Your request is being processed" message instead of simply leaving me on my current page and showing a download dialog like with PHP.
I am POSTING some CSV data from a table page in SAP BW to this BSP application that I want to download as a CSV text file.
I can't simply use the export to CSV function of SAP BW because of the modifications I have made in javascript to change the tables.
I am utilising this piece http://www.kunalbabre.com/projects/table2CSV.php of jQuery utility to get what I require from the client side. Option 3.1 is what I am trying to achieve.
Any help please?
Thanks
Craig
Request clarification before answering.
Rüdiger
I tried it outside of BW and sure enough it works as expected.
I have also discovered why it's not working properly, but I don't know how to resolve it.
Basically my form action is set to "../bc/bsp/sap/zsavecsv/download.htm" but when you submit it you end up with something like this "/sap(bD1lbiZjPTIwMA==)/bc/bsp/sap/zsavecsv/download.htm" in the form that's generated. Presumably this is the session encode in the URL.
I have however managed to cheat and use javascript XMLHttpRequest to initially get the request and get the BSP page to send me the "runtime->PAGE_URL" as the responseText. I then update the form action with the returned value and this works.
Can you think of an easier way of doing this?
Cheers
Craig
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Craig:
bD1lbiZjPTIwMA== is base64 for your client and language (decoded, it is l=en&c=200). It's not the session id but the essential login information that the SAP-System needs in addition to user and password. (If cookies are enabled, the session id is stored as a cookie and not in the URL.) They can also be passed as form fields (sap-client and sap-language) in the request or in the URL query part.
ICF sends a redirect with this information "mangled" into the URL, immediately after the first node of the URL path. But this is a real redirect with HTTP-statuscode, not a form!
In my eyes, you still haven't solved the mystery of that form above, with the tell-tale text "No Applicable Data Found". I still would bet that this form doesn't come from the ICF or BSP framework!
Usually, when a relative URL is specified which doesn't replace the top level node, this information is preserved (since it's part of the top level node!), and no redirect is necessary. It's inconceivable to me why the system triggers such a redirect in your case.
Regards,
Rüdiger
Rüdiger,
Ignore the "No Applicable Data Found" message as this is just part of the table content passed into the form value. It was test data.
Essentially I believe it's the BSP framework generating the form after the redirect with the action set to the same URL but with the client and language mangled into the URL. Nothing from BW is doing this since BW is not even aware of the posting. The page I use to post the data is completely manipulated by javascript on the client.
I can only assume since the client and language are missing from the initial request it requires these to make the request and since it's receiving posted data it generates the form and submits it to itself.
EDIT
This is only when I call the service directly in a browser.
I can see that there are 2 calls when we make the posting
1st GET request to /sap/bc/bsp/sap/zsavecsv/download.htm receives status "302 Moved Temporarily" then the 2nd GET request to /sap(bD1lbiZjPTIwMA==)/bc/bsp/sap/zsavecsv/download.htm receives status "200 OK"
If I use the BW template and check the posting I see a POST request to /sap/bc/bsp/sap/zsavecsv/download.htm with a status of "200 OK". And thats it no redirect occurs here.
I will test this outside of both BSP and BW to prove it's BSP doing it.
I'll come back with the results.
The results are, if I try to post a table of results from an html file locally the same problem occurs!
Basically BSP is generating this page for some reason.
How do I go about stopping the base64 encoding? Or can we simply pass the language and client in the URL?
Cheers
Craig
Hi Craig,
the two replies, the first with status 302, the second with 200, is precisely what is to expect. You can avoid the redirect by providing language and client with your first request. So the question is why the first request is addressed to /sap/bc... and not to /sap(...)/bc... If you specified a relative URL in your action, the /sap(...)/... would be copied from the actual, current URL from which the form is submitted.
- Rüdiger
http://migzm630.migros.ch:8000/sap/bc/bsp/sap/zz_test_dl/submit.htm
Rüdiger
Even if I specify the URL as /sap/bc/bsp/sap/zsavecsv/download.htm?sap-language=en&sap-client=200 it still doesn't work!
Normally I'd like to get to the bottom of a problem, but now I am losing the will to live and have a solution albeit it's a work around that works, I might just leave it.
Cheers
Craig
Rüdiger,
Do me a favour and try the below in a local html file, obviously replacing the <host> and <port> etc.
<html>
<head>
<title>Test submit download</title>
</head>
<body>
<h1>Test Submit Download</h1>
<form method="post" action="<host>:<port>/sap/bc/bsp/sap/zsavecsv/download.htm">
<input type="text" name="csv_text" value="a;b;c">
<input type="submit" value="Submit">
</form>
</body>
</html>
This reproduces the problem I am having.
Perhaps it's a system thing, we are running BW 7 (EHP1).
Cheers
Craig
Craig,
with the HTML file as local file, I can reproduce your problem - now I get the suspicious form, too.
So you are right, it comes from the ICF! It appears only when the mangling part of the URL is missing, and when the method is "POST", not "GET". With "GET", the system behaves differently, passing back an HTTP 302 Redirect in order to navigate to the mangled URL.
When the requested URL contains the (...) part, no redirect or hidden form is sent, but the request is served directly.
But an URL beginning with /sap/bc is absolute, not relative! What about passing a relative URL? Then the foremost parts of the URL are taken from the URL that is currently visible in the browser's address bar. Since you are on the same system, the mangling part will be copied from there, and your request can be served directly.
If your current path begins with /sap(...)/bw/BEx, say, then by starting with sufficiently many "../", you can make the browser copy the first node, including the bracket part (which is part of the first node, syntactically), and then going down to .../bc/bsp/sap/... instead.
Alternatively, at "onload", you could copy the current mangling string into the action attribute of the form.
You could rewrite the URL even earlier, in the view that generates the form, by using the CL_HTTP_UTILITY=>IF_HTTP_UTILITY~REWRITE_URL (which accepts a table of name/value-pairs)
But the easiest approach will probably be using the relative URL (i.e. a URL starting with a certain number of '../' or './') for the form's action attribute.
Regards,
Rüdiger
Rüdiger,
Thanks for your invaluable input.
But the problem I have is I am using the relative URL in my BW template, issue becomes the fact that the mangled URL of the BSP has no equivalent in SAP BW. BW contains the session ID in that part of the URL!
I'll stick with my current solution.
Thanks very much for your time.
Cheers
Craig
| User | Count |
|---|---|
| 8 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.