cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP destination type G with scpecial characters in the path prefix

Former Member
0 Kudos

Hi guys,

I am having an issue with a RFC destination type G in a ECC 5, the HTTP service that I am trying to use is asking me for an authentication that needs to be embeded on the Path prefix, the user has an "@" and the pwd also contain a special character "!". So the complete uri that I want to access is in the form of https://server:443/path?user=MyUser@MyDomain.com&password=MyPwd! when I tried in my web browser I got authenticated but when I put the information in the RFC destination in the form described below I am not able to authenticate and I am getting an error of Unauthorized.

Target Host: server

Service: 443

Path prfix: /path?user=MyUser@MyDomain.com&password=MyPwd!

Logon procedure: No logon

SSL: Active

I also have tried with the basic authentication but I am still not able to authenticate.

I think the issue is the "@" in the user: MyUser@MyDomain.com , I also have tried replacing the "@" for "%40" and still not working.

Do you know how I can pass this special character?

Do you think it can be something else that it doesn't let me authenticate to the server?

My system is a non unicode ECC 5, SAP_Basis 640

Thanks

Omar Hernandez

Accepted Solutions (0)

Answers (1)

Answers (1)

markangelo_dihiansan
Active Contributor
0 Kudos

Hello,

Path prfix should only be: /path?

and place your logon details under the Logon fields.

Since you are getting an authorization issue, have you checked in SMICM regarding the logs? Right after you execute your RFC destination, go to SMICM and then click display all (shift+f5) and then scroll down to the last line. It will tell you more about your error.

Hope this helps,

Mark

Former Member
0 Kudos

Hi Mark,

Thanks for your response, the HTTP service that I am trying to access is not accepting a basic authentication but it is getting the authentication info from the parameters in the URL. Anyway I also have tried to use basic authentication but it is not working.

Regarding SMICM, I havent seem anything useful, maybe the just the "BINDUMP of content denied" string but I am not sure what does this mean.

[Thr 1076382016] IcmHandleNetRead(id=91/11638): pending SSL data: 0, rollout=0

[Thr 1076382016] <<- SapSSLReadPending(sssl_hdl=0x2aaaaf53f380)==SAP_O_K

[Thr 1076382016] out: pendlen = 0

[Thr 1076382016] NiIPeek: peek successful for hdl 79 / socket 46 (r)

[Thr 1076382016] <<- SapSSLRead(sssl_hdl=0x2aaaaf53f380)==SAP_O_K

[Thr 1076382016] result = "max=65312, received=88"

[Thr 1076382016] IcmReadFromConn(id=91/11638): read 259 bytes(timeout 250)

[Thr 1076382016] BINDUMP of content denied

[Thr 1076382016] PlugInHandleNetData: role: 2, status: 2, content-length: 0/88

##buf_len: 259, buf_offset: 171, buf_status: 0, conn reused

[Thr 1076382016] PlugInHandleNetData: read response body (len=88/88)

[Thr 1076382016] PlugInHandleNetData: response completely read(EOS=0)

[Thr 1076382016] IcmFlushBuf: Flushing 259 Bytes, buf_status: 6

[Thr 1076382016] flush buffer with mpi buffer id 10

[Thr 1076382016] MPI<1e8c9>1a#5 FlushOutbuf l10 1 1 1c14e8 311 6 -> 0x2b4bc7cd64e8 0

[Thr 1076382016] IcmConnRollInWP: no need to roll in WP status: ROLLED IN

[Thr 1076382016] PlugInHandleNetData: keep connection

[Thr 1076382016] IcmPlCheckRetVal: Next status: WRITE_REQUEST(3)

[Thr 1076382016] IcmHandleNetRead(id=91/11638): read_len: 88, HandleNetData returned: 3

[Thr 1076382016] IcmConnRollInWP: no need to roll in WP status: ROLLED IN

[Thr 1076382016] IcmWorkerThread: Thread 4: Waiting for event

markangelo_dihiansan
Active Contributor
0 Kudos

Hello Omar,

In that case, can you try using SOAP Receiver Adapter with the Do Not Use SOAP Envelope checked?

Regards,

Mark

Former Member
0 Kudos

Hi Mark,

My life would be easier if we could use PI and use your suggestion but in this case we want to do a direct connection from the ECC to avoid the latency that PI will bring us. But thanks anyway for your suggestion.

Omar

Former Member
0 Kudos

Have you tried with both HTTP version (i.e) 1.0 and 1.1?

can you try ? and also please increase the trace level into maximum level ( If you have not done already)