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.
Dig Deeper on SAP ABAP
Related Q&A from Axel Angeli
An SAP user is receiving an error message while integrating SAP iDoc PORDCR1 for a purchase order. Continue Reading
SAP expert Axel Angeli explains how to update the "further dates" tab information in am SAP transaction through an SAP IDoc. Continue Reading
An SAP R/3 4.7 user wants looking to post a document entry using different trading partner fields for credit and debit for function FB01. Continue Reading