BDocs held up in INTERMEDIATE state

[Former Member]

Hi All

I have been facing an unusual problem of outbound BDocs being held up in INTERMEDIATE state in the CRM system. These are BUPA_MAIN and BUPA_REL DELTA related Bdocs, carrying newly created Business Partners and cotacts for BPs or changes to exisiting BPs.

These BDocs are not erroneous and once I reprocess them manually, they are successfully processed and Business Partner information flows to ECC.

Also, this is not the case with all BDocs. This happens in the production environment for once for say every 1000 BDocs.

Since the status of the BDoc is: Written to qRFC (intermediate state) I am unable to identify the reason for the BDocs being held up.

Kindly provide your suggestions on what could the reason be and what should be done in order to preven this.

[Former Member]

Hi All

I am still facing this issue of a few BDocs regularly running into Intermediate State I02. I am still unable to find the cause of the problem. I am facing this ever since we have upgraded CRM from 5.2 to 6.0 and R/3 has been upgraded from ERP 4.6c to ECC 6.0

Also, I have found an alternative solution to manually reprocessing the BDocs, by executing the transaction SMW20 as a background job to check for Intermediate BDocs on an hourly basis and automatically reprocess them.

Please help if anyone have faced a similar problem.

Thanks in advance

Regards

Sushanth

[Former Member]

Did you check ST22 for any dumps? I encountered the same issue and found the cause of the intermediate state in ST22.

[former_member190996]

Hi Ram,

Was scheduling the SMW20 as the background job only the solution for this? I'm having similar issue. Would appreciate if you could share your solution?

Regards,

SB

[Former Member]

Hi Srinu

I am aware of this.

My BDocs are in intermediate state, I02--Written to qRFC Queue (intermediate state)

Yes, the queue start with CSA. They carry BP and BP Relationship delta data.

My question is: Since this has been occuring quite regularly, Can we the reason as to why the BDoc is held up and what can be done to prevent the same

Thanks in advance

Regards

Sushanth

[Former Member]

Hi Srinu

Thanks for your response.

As I said, once I reprocess the BDoc, it is getting succesefully processed and the data is flowing to from CRM to ECC.

I actually wanted to know as to why this is happening. If it happens rarely or so, thenj it can be understood, but i see this happening happenig reularly, once in 3-4 days (say once for every 1000 BDocs or so)

Everytime it would not possible to reprocess the BDoc

Thanks in advacne

Regards

Sushanth

[Former Member]

HI,

1. I01-Received (intermediate state).

The message reached the receiver system in the qRFC-queue. A short dump (e.g. caused by a coding error or timeout) occurred on receiver part. The queue entry will be deleted automatically.

2.I02--Written to qRFC Queue (intermediate state).

An entry is created in a qRFC queue to enable processing of the mBDoc message in the receiver system. Such queues start usually with CSA*.

3.I03--After qRFC step (intermediate state).

The flow processing of the mBDoc is started and the entry in the inbound queue is removed.

4. I04--BDoc Message was not written to qRFC queue, yet. Search update tasks in transaction SM13. The sender creates a BDoc message to post data to the receivers. The application calls the messaging flow.

Regards

Srinu

[Former Member]

HI,

Try to reprocess the bdoc.

Regards

Srinu

[Former Member]

Hi Kai

Thanks for your response.

I can rule out Point # 2 and 3... The outbound Q is not stuck, nor there is any short dump...

Can you elaborate on Point # 1. Here also the remote systerm is very much avaialble... A similar BDoc carry similar content has been successfully processed in and around (before/ after) the same time.

Thanks in advance.

Regards

Sushanth

[Former Member]

When BDocs stay in intermediate status, usually one of the following is the reason:

1. Processing in source or target system last a long time or the remote system is not available. This happens with R/3 systems sometimes, and with groupware more often.

2. The data gets stuck in the inbound or outbound queues (SMQ1 / SMQ2 tx., eventually register queues with SMQS / SMQR)

3. Processing ends unexpectedly, usually in a short dump. In this case check tx. ST22 for details.

Hope this helps,

Kai