EDUCAÇÃO E TECNOLOGIA

One chain-reacting example after a connection issue

One order update integration has been set up between ERP and Salesforce through BOOMI. It’s run ning smoothly for quite a long time and one day morning complaint emails from different regions come like snowflakes.

  • Why is the order status not been updated at SalesForce?
  • Why has the order not been created at SAP?
  • Why is XXX processing so slow?

It’s a very typical issue in the Cloud era and here just list down the story of one case as a reference, hope it may help for similar investigations in the future.

  1. As SFDC had some updates that need to sync data back to SAP through BOOMI by IDOC. Check SM58 with parameters like User name/TRFC destination if you know, here I use Function module ‘IDOC_INBOUND_ASYNCHRONOUS’ as TRFC Function. Then find out one of Idoc’s partners has a connection issue like ‘connection to partner ‘xxx.xxx CPIC-CALL: ‘ThSAPCMRCV’.
  2. On the BOOMI side, checking the log at Integration->Manage->Excecutions will get errors like ‘ProcessException: Process terminating — some documents reached an exception which is set to halt all documents: Unable to execute SAP Get; Caused by: Exception in SAP Get operation; Caused by: CPIC-CALL: SAP_CMKEEPALIVE on convId: xxx no SAP ErrInfo available’.
  3. We can see both Errors from SAP and BOOMI mentioned ‘CPIC’. What is CPIC?

CPIC stands for Common Programming Interface for Communication. SAP uses Common Programming Interface for Communication (CPIC) protocol to transfer data between systems. CPIC is an SAP-specific protocol. RFC is a communications interface based on CPIC. It has more functions and it is easier for application programmers to use.

I check SAP help about CPIC but find no entry at the system in table TXCOMSECU or RFCDESSECU… Very few results for ‘SAP_CMKEEPALIVE’ as well at GOOGLE. But from this blog and its literal meaning of KEEPALIVE, it’s very likely related to waiting for returns between systems and could have limitations on how long keep this waiting active before time out.

As more and more requests came, those requests related to this specific partner which have connection issues will fail and keep trying/waiting within the KEEPALIVE limitation period until they reach the limit of timeout. Meanwhile, new data keeps increasing, single execution takes more time to get error feedback and the queue will be much slower compared with normal time. It can be monitored at Queue Management in Environments of BOOMI.

Until then, this could explain all those three questions mentioned at the beginning. There could be various reasons for poor system performance especially involving integration among different systems. It’s fun to trace them back among various systems. Experience is gained this time and finally will improve efficiency for next time, maybe~ I hope so~ haha