Q
Problem solve Get help with specific problems with your technologies, process and projects.

IDoc in status 03 but nothing received at destination

A customer of ours has an ALE Server receiving IDocs from their SAP server. As soon as either a DIA or BTC job...

start to generate the IDocs, there are entries written to the SAP System Log (SM21) as follows:

* R64 > CPI-C function: CMINIT(SAP)

* R49 Communication error, CPIC return code 002, SAP return code 679

As you can see, there are typically 2 lines per IDoc in the Outbound queue (SM58). These messages continually appear until the IDoc is actually received by the ALE server - during this time the ALE is running AND receiving IDocs - but usually the SAP system is generating them faster than the ALE server is receiving them.

The customer is concerned that the excessive system log entries will cause other more-critical messages to be missed due the system log being truncated (as is currently happening).

The only way that we have been able to re-create this problem is if we stop the ALE Server - during this time messages will be created in the SAP system log but do stop as soon as the ALE server is restarted and then they stop. Is there anyway to suppress these messages or maintain better control of them? The messages are produced by the kernel and are kernel logs, so suppressing them is not tolerable.

There is only one proper way to solve your problem: Find the cause of the CPIC error. This is an ERROR message, no joke! The log file won't be an issue, this is an annoyance for now. The problem is that the CPIC error could hide a severe problem in your network, including a security hole, in any case it will put a load on your performance.

From experience there is a rule of thumb:

* An obvious error must be solved ASAP.

* A warning must be solved immediately, until you do not know the cause.

A warning of unknown origin mostly hides a more severe problem. Only by investigating its cause you will find something really wry that might lead to major problems in the future.

In your case the message indicates "TP is not registered", so your CPIC tries to send to a non registered port, i.e. an unknown destination. Have a look on OSS note 63347 for more details.

In your cause it appears that the problem is the ALE server being too slow to handle the requests and is incapable to serve incoming messages while it processes an already received one. This problem should be resolved in the ALE server. If this is not possible, you should consider putting a message queue between R/3 and the ALE server or find a way to send the IDocs in slower intervals.

I know this is not satisfactory, but I see no other ways unless you want to temper with the R/3 kernel which is everything but wise.

This was last published in May 2003

Dig Deeper on SAP ABAP

PRO+

Content

Find more PRO+ content and other member only offers, here.

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close