Problems with Punchout Catalog in SRM 7.0

[Former Member]

Hi,

We are on SRM 7.0 SP Stack 8. We are implementing several new punchout catalogs with different suppliers, and we are having problems with 1 catalog returning from the supplier site. I have done an HTTP Watch trace of the problem site and a punchout catalog that is working. The main difference I see is, for the problem site, just before it attempts to transfer back to our SRM system, the site is attempting to do an HTTP redirect and gets a 302 error. I also do not see any OCI fields in the POST statements on the supplier side.

Does anyone have any suggestions, tips, etc for troubleshooting this? I have shared wth the supplier the SAP OCI 4.0 document, but that does not seem to be helping much. Is anyone aware of any other documentation that might be of help?

Thank you,

Kevin

[Former Member · Accepted solution]

Hi

1 Please check the call structure

2 if all are fine than check the filed values transfered to SRM from Supplier site via View Source

Thanks

Trinath

[Former Member]

Hi Jsaon,

Here are our ICM settings:

services:

icm/service_port_0 = PROT=HTTP, PORT=80, TIMEOUT=60, PROCTIMEOUT=1800, EXTBIND=1

icm/service_port_1 = PROT=SMTP, PORT=0, TIMEOUT=30

icm/service_port_2 = PROT=HTTPS, PORT=443, TIMEOUT=60, PROCTIMEOUT=1800, EXTBIND=1

Hard Limits

icm/max_services = 30

icm/listen_queue_len = 512

icm/req_queue_len = 500

icm/max_conn = 500

icm/max_sockets = 2048

Thread handling

icm/min_threads = 10

icm/max_threads = 50

icm/min_spare_threads = 3

Tracing and statistics

rdisp/Trace = 1

icm/tracefile = dev_icm

icm/log_level = 0

icm/stat_level = 1

icm/security_log = LOGFILE=dev_icm_sec,MAXSIZE=500

Monitoring

icm/ccms_monitoring = 1

icm/ccms._refresh_rate (sec.) = 30

Timeout handling

icm/keep_alive_timeout (sec.) = 90

icm/conn_timeout (sec.) = 5000

HTTP settings

icm/HTTP/max_request_size_KB = 102400

Is there anything in particular in the ICM settngs we should be looking at?

Thank you,

Kevin

[jason_boggans]

Hi Kevin,

Not too sure about the ICF settings, one question though about the Badi, did you implement code into your own implementation of the Badi Method GET_PROXY_DETAILS?

See note 1553735 for more details.

Regards,

Jason

[Former Member]

Hi Jason,

Thank you for the suggestions. We did activate the Badi but it did not make a diifference. I ran an HTTP Watch trace while the Badi was active and accessed the problem punchout catalog. But we still had the same problem and the trace did not reveal any additional inforation to me. For nowI have de-activated the Badi, but I can turn it back on if you have other things you think I should try with the Badi

The supplier says that the HOOK_URL value they received is not able to access our network, and I have asked them to send me the HOOK_URL value so that I can confirm it's correct and not truncated.

As for the specific ports for HTTPS on the inbound server, I am waiting for feedback from my internal Basis team and will let you know what they say.

Thank you,

Kevin

[Former Member]

Hi,

First thank you to Trinath, Jason and Donald for the feedback. We did a View Source and confirmed at least that the OCI fields are being correctly populated by the punchout catalog site. We have compared the call structure of this punchout to the call structure of another punchout that is working. The only difference is that the working call structure specifies Username and Password, where the call structure that is not working does not have those parameters. The supplier stated they are not necessary.

As Jason suggested we are investigating note 1456659 - Badi SRM_CAT_GETPROXYINFO. Is it possible that this 1 punchout catalog in question is having a proxy issue where the other punchout catalogs do not? We did an HTTP Watch trace of a working punchout and this non-working punchout. The 1 main difference I noticed is that for the non-working punchout, just before it tries to transfer the data back to our SRM application, the punchout site is doing an HTTP re-direct. Could that be causing this issue.

We are requesting the vendor make the change suggested by Donatd re: session ID and I hope to have feedback on that in the next day or so.

Thank you,

Kevin

[jason_boggans]

Hi Kevin,

It is possible for one of these external catalogs to be performing some protocol switching or perhaps even verify with your ICM administrator that there are no specific ports on your inbound server destined for HTTPS, it may be that the switching is done by your own ICM / webdispatcher.

I nany case, I believe the Badi should be effective in resolving this as you can just specify a protocol and port etc for use on catalog return.

Regards,

Jason

[Former Member]

Hi Kevin,

No sure if this is the cause of your problem. Please see if vendor catalog application lost the session communicating with SRM shopping cart. In order to preserve session ID across different domain, please add P3P header, e.g. "CP=CAO PSA OUR", which can apply to ASP, JSP, PHP etc, to vendor catalog application.

Regards,

Donald

[jason_boggans]

Hi Kevin,

It is possible that you could use the Badi SRM_CAT_GETPROXYINFO to 'force' specific proxies/ports to be used on call and return, check the note 1456659 for details.

Regards,

Jason