Registered Program hangs - status 'waiting'

[Former Member]

I have created a scenario involving a RFC sender communication channel and file adapter (Receiver). When i activate the communication channel, it registers a server program in XI. When i call an RFC using a RFC destination pointing to the registered program, it works for the first time and i get 'successful' status in XI Message monitoring. but the status of registered program in 'smqs' transaction code, changes to 'waiting' and any RFC destination pointing to the registered program gives "program ZBWIP24_3 not registered / CPI-C error CM_ALLOCATE_FAILURE_RETRY". In otherwords, the registered program and RFC destination points to it hangs completely. Do any one experienced the same issue and solved it?. Can anyone throw some light on that issue?.

[MichalKrawczyk · Accepted solution]

hi,

try restarting the XI server

and then have a look at question 25 SAP note: 821267

Regards,

michal

-

---

<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions">XI FAQ - Frequently Asked Questions</a>

[Former Member · Accepted solution]

Hi Restarting the server did not solve the problem and my problem is nothing do with File adapter. The RFC destination on R/3 and register server program for the communication channel does not accept more than one connection.

[sam_raju · Accepted solution]

Hi ArulRaja,

Increase the number of connections on your Sender RFC Adapter. The maximum number can be upto 50 connections.

Rgds,

Sam Raju

[Former Member · Accepted solution]

Hi Sam Raju,

I have tried the same but no luck..Any other ideas

[Former Member · Accepted solution]

Hi,

my views...

The scenario is RFC(R/3) --> XI --> File.

it is an Sync call(RFC) getting forwarded to an ASYNC call to the File. Is it waiting for the reposne ?

Could you pls send the RFC request to a BPM, open a sync-async bridge, and send a response back to the R/3 system after the file is written...steps in the BPM would be

1. Receive RFC call(open a sync-async bridge)

2. map to file message(if required)

3. send file

4. map to rfc response

5. send rfc response(close the sync-async bridge)

As for the current status of the destination. Change the sender comm. channel program id....activate it...

switch it back to the original value and activate again...this should hopefully bring the status of the Destination to a working condition.

Thanks,

Renjith.

[Former Member · Accepted solution]

Hi Ranjith,

You are correct about the scenario. it is RFC->Xi->file. But it is not synchronous. I am calling the RFC asynnchronously. Do you think i still have to do this sync-async bridge?.

Arul

[Former Member · Accepted solution]

Hi Arul,

How are you making sure that the RFC call is asynchronous?

Are you using the "CALL FUNCTION func STARTING NEW TASK task " ?

IF yes, the documentation says the following

<b>The asynchronous RFC does not support communication with external systems or programs in other programming languages.</b>

and a TCP/IP destination denotes an external system....

Thanks,

Renjith.

[Former Member · Accepted solution]

Hi Ranjith,

I am using "CALL FUNCTION <FUNC> in background task".

Regards,

Arul

[sam_raju · Accepted solution]

Hi Arul,

Make sure you have the 'COMMIT WORK' statement after the function call in background task.

Rgds,

Sam Raju

[Former Member · Accepted solution]

we have the commit work statement immediately after the function call but no light yet!