After recent netweaver upgrade due to enhanced security checks ,few URLs which were working earlier are not accepted by the system now.
Actually in my scenario the URLs are shown as "Link to Actions" on the UI.
To avoid the dump first I am checking the validity of the "URL string" using this method.
If it is valid, only then the URL is binded on UI otherwise its ignored.
Following is an example of an invalid URL:
I checked, presence of extra characters '#' makes it invalid .
Is there any way to remove this extra character '#' from the URL ??
(I tried replacing all occurences of # and condense it: but that did not work ).
Is there any other way to convert this invalid URL to a valid format, accepted by system ???
Thanks a lot in advance..!!!!!
I can only thing of SPLIT AT '#' for now...
DATA: string(60) TYPE c, p1(20) TYPE c VALUE '++++++++++++++++++++', p2(20) TYPE c VALUE '++++++++++++++++++++', p3(20) TYPE c VALUE '++++++++++++++++++++', p4(20) TYPE c VALUE '++++++++++++++++++++', del(3) TYPE c VALUE '***'. string = ' Part 1 *** Part 2 *** Part 3 *** Part 4 *** Part 5'. WRITE string. SPLIT string AT del INTO p1 p2 p3 p4. WRITE / p1. WRITE / p2. WRITE / p3. WRITE / p4. The output appears as follows: Part 1 *** Part 2 *** Part 3 *** Part 4 *** Part 5 Part 1 Part 2 Part 3 Part 4 *** Part 5 Note that the contents of the fields p1 ...p4 are totally overwritten and that they are filled out with trailing blanks.
Code source SAP Help
Thanks for reply.
I tried breaking the URL using your approach , but this is not working. ( May be due to what Matt has suggested) .
The o/p i am getting if I break the same URL at # as :
and sy-subrc = 4 also
which means '#' is not found.
As has been observed MANY times in these forums, the # sign represents a non-displayable character. E.g. carriage return or somesuch.(So Javeen's split won't work)
Look at the value of the url in debugger, and post the hexadecimal representation. Non-displayable characters are never part of a valid URL, so the url really is invalid - in my view they can never have worked.
What is generating these URLs? It's all very well making the url's syntactically valid, but if they point to non-existant places, it's not going to help, is it?
Thanks for reply.
I checked in debugger .
'#' is represented by hexadecimal value '2300'H.
As you said, '#' represents a non-displayable character,
So thats why I think instuctions like Split or Replace are not working here.
These URLs are either links to a website or to a document, which is uploaded by a user in a different tool.
So they do not contain non-existant places.
I have to showcase the same URL on UI in my tool.
I know # is represented by 23x. What are the hashes in your url represented by?
Understand: if a url contains a character that means it is not a valid url, then it can't point to a real place, can it? What do the source urls have in the place of these #?
I.e. you have invalid https://portal.wdf.sap.corp/irj/go/km/docs/guid/600840f6-2d2d-2e10-5bb7-##fca7779a24cc
I'd guess, that somewhere between your source and output, some carriage return line-feeds are getting inserted.
Edited by: Matt on Sep 9, 2011 10:52 AM
You are correct.
2nd URL is the correct one. This URL opens a document.
I dont know about source URL, because its uploaded in other tool where i dont have any control.
But if it is accepted by the system then it must be reproduced again at the other end.
I got one alternative which seems working for this scenario:
I used cl_utility_abap again
First use escape URL, convert to hexa form :
Then replace hexa values of '#' or '##" or "###' by space and condense
Again unescape the URL
Now the new URL becomes valid always
<fs_url>-url = cl_http_utility=>escape_url( <fs_url>-url ).
REPLACE ALL OCCURRENCES OF '%23' IN <fs_url>-url WITH ' '. " ( '#' = '%23' )
REPLACE ALL OCCURRENCES OF '%0d%0a' IN <fs_url>-url WITH ' '. "( '##" = '%0d%0a' )
CONDENSE <fs_url>-url NO-GAPS.
<fs_url>-url = cl_http_utility=>unescape_url( <fs_url>-url ).
lv_is_link_ok = cl_http_utility=>is_valid_url( <fs_url>-url ).
Well this alternative is working, but how fool proof it is I dont know.
Kumar Ashesh wrote:
> 2nd URL is the correct one. This URL opens a document.
> I dont know about source URL, because its uploaded in other tool where i dont have any control.
> But if it is accepted by the system then it must be reproduced again at the other end.
Somehow the URL got into SAP. Find out where and make your corrections there to make sure you always have a valid URL stored.
So, Deepak. How do you know it's a horizontal tab?
He used SDN search and 9 out of 10 times it was about the horizontal tab.
While copying file from FTP server to R3 server we used to check value of Type Hexadecimals value for # i.e 09
upto 4.7 version . but during our upgrade Implementation we faced this problem due to Unicode conversion .
After lot of search during that time i came to this solution and used it .
We also got the same type of issue after the Support pack upgrade in SRM ,
We identified the below points in debugging the ITS.
Java Applet issue in non SSO environment,
Wth patch 23, SAP has tightened the security.
The new token ~XSRFCHECK when running the Java App from ITS.
We have to turn off this token from 1 to 0 as per OSS (1481392 ,1522651).
Let me know if there are any concerns.