Timeout when retrieving document from Content Server

[Former Member]

Dear experts,

after the migration of an R/3 Enterprise system with a file-based Content Server (CS without database) we experience significant delays when a document shall be retrieved from the Content Server and displayed.

The repository, from which documents are retrieved, has the following properties:

Document Area = ArchiveLink

Storage Type = HTTP content server

Obviously the delay is caused by time-outs when R/3 tries to access the content sever.

The RFC trace recorded during the document retrieval contains the following entries:

• Trace file opened at 20100825 104048 CEST SAP-REL 640,0,304 RFC-VER 3
• Trace file opened at 20100825 104115 CEST SAP-REL 640,0,304 RFC-VER 3
• End of trace *****

======> CPIC-CALL: 'ThSAPCMRCV' : cmRc=20 thRc=456 Timeout beim Verbindungsaufbau (Partner vorhanden ?) ABAP Programm: SAPLSCMS_CLTFC (Transaction: ) Called function module: RFC_PING User: TSI0403 (Client: 007) Destination: SAPCMS (handle: 4, , {4C74C1A6-BD3B-3B59-E100-00001A5F0A18}) SERVER> RFC Server Session (handle: 1, 41571399, {4C74D031-BD2C-3B58-E100-00001A5F0A18}) SERVER> Caller host: cimpd38_MPD_38 SERVER> Caller transaction code: MIR4 (Caller Program: CL_GOS_TOOLBOX_VIEW===========CP) SERVER> Called function module: GOS_EXECUTE_SERVICE Error RFCIO_ERROR_SYSERROR in abrfcpic.c : 3268 CPIC-CALL: 'ThSAPCMRCV' : cmRc=20 thRc=456 Timeout beim Verbindungsaufbau (Partner vorhanden ?) Error RFCIO_ERROR_MESSAGE in abrfcio.c : 1660 ======> CPIC-CALL: 'ThSAPCMRCV' : cmRc=20 thRc=456 Timeout beim Verbindungsaufbau (Partner vorhanden ?) ABAP Programm: SAPLSCMS_FE_RFC (Transaction: ) Called function module: RFC_PING User: TSI0403 (Client: 007) Destination: SAPHTTP (handle: 6, , {4C74C1B4-BD3B-3B59-E100-00001A5F0A18}) SERVER> RFC Server Session (handle: 1, 41571399, {4C74D031-BD2C-3B58-E100-00001A5F0A18}) SERVER> Caller host: cimpd38_MPD_38 SERVER> Caller transaction code: MIR4 (Caller Program: CL_GOS_TOOLBOX_VIEW===========CP) SERVER> Called function module: GOS_EXECUTE_SERVICE Error RFCIO_ERROR_SYSERROR in abrfcpic.c : 3268 CPIC-CALL: 'ThSAPCMRCV' : cmRc=20 thRc=456 Timeout beim Verbindungsaufbau (Partner vorhanden ?) Error RFCIO_ERROR_MESSAGE in abrfcio.c : 1660

I wonder why R/3 first attempts to contact the Content Server via the SAPCMS RFC destination rather than using HTTP (SAPHTTP)? - The connection tests for both RFC connections are successful.

Is there a way to instruct R/3 to go via the SAPHTTP RFC destination as the first choice and NOT via SAPCMS when documents shall be retrieved and displayed?

Thank you,

Rainer Walter

Edited by: Rainer Walter on Sep 3, 2010 3:07 PM

[ashish_vikas]

Hi Rainer,

Can you please share solution for this problem.. we also have same problem. And also, i our case, it never goes to SAPHTTP RFC and we get HTTP-500 errors.

thanks

ashish

[former_member231712]

Hi Guys,

I hope you guys must have fixed this long back but if there are some guys who see this post for the same issue then please follow this note., by activating this parameter you can skip the SAPCMS & SAPHTTP RFC check which will in turn increase the performance in retrieving the document from content server.

Note 1783987:Long response time for document display in Attachment list

[Former Member]

Hi Rainer,

I hope the RFC is used to retrive the document in Archivelink and external content server case. While you are using SAP database as storage location it will not thru RFC.

Check and confirm with basis team. Hope this will help.

Regards,

Ravindra

[Former Member]

Hi Ravindra,

thank you for looking into this problem. The Content Server is not based on SAP DB/MaxDB. The repositories are represented as plain directory structures in a file system.

My issue is that R/3 is not using the SAPHTTP RFC connection as first choice although the repository is flagged as "HTTP Content Server" but uses another RFC destination instead. When this attempt is timed out, R/3 eventually picks the appropriate RFC destination. So it takes a considerable amount of time until a requested document is finally retrieved from the repository in the Content Server.

I am confused because the system where I experience this behaviour has been built from a system copy of a production system, and the Content Server for this new system has been built from scratch. In the original production system, no timeout is found when users are retrieving documents, and obviously the original R/3 system is using SAPHTTP right away. The original production system and the new system built from a system copy are accessing different Content Servers.

I am looking for a way to instruct the new R/3 system to immediately use the SAPHTTP connection when talking to the Content Server, and I would be grateful for a hint where I can configure this to get rid of these timeouts.

Best regards,

Rainer

[Former Member]

Hi ,

KIndly check in OAC0 where we define the new repositories , here maintain area document management, type as HTTP content server , IP address and port. Then goto CSADMIN and activate the certificate for the same.

The timeout isse related to bandwidth, is the location same for uplaoding and accessing doucments. If not in that case the bandwidth problem is there and you require cache server for data synchronization.

Kindly check for the solution and revert.

Hope this will help.

Regards,

Ravindra

[Former Member]

Hi Ravindra,

the timeout is not related to problems with the bandwidth. Both R/3 system and content server reside in the same IP subnet. A ping from the R/3 host to the ip address of the content server produces a response within one millisecond.

Changing the repository parameter "document area" from "ArchiveLink" to "Document Management" dramatically improves the response time - no time-out due to an unsuitable RFC connection occurs here. But the document is displayed in a browser rather than in the usual application that the customer is using in hiis original system. As the content server contains not only TIFfiles, but also CAD documents and other file types, I am afraid that this workaround is not acceptable for end users.

Best regards,

Rainer