I had a requirement where I wanted to update a Z table in ECC once complaint is created in CRM.

I wanter to handle this with standard approach what SAP follows.

It took me some time to explore satandard approach, hence here I am sharing a piece of knowledge with you all.

Requirement:

Update Z table in ECC as soon as a complaint is created in CRM.

Once activity in CRM is created with OPEN Status ‘Z Table’ will be updated in ECC. And once same activity is completed a ‘Complete Flag’ should be updated in Z table against same object ID.

Approach:

Approach 1:

You develop an RFC enabled FM and put your logic to update ‘Z Table’ in ECC.

Approach 2:

Update Z table in ECC with standard approach where an CSA* queue is generated (Collects data from CRM) and against that R3* queue is called (An RFC is called which update Z table)

Note: Approach 1 is an conventional and we have used multiple times. Hence we are not discussing this.

Benefits:

i) By using this you are using SAP standard approach. As whenever standard CRM communicates with ECC it does it by using middleware.

ii) Suppose your ECC is down in such cases your queue will accumulate and once ECC is up it will update records in FIFO [First in first out] manner.

iii) If you use middleware approach in such case suppose user A made an activity and from some other location User B is also creating activity for both

the cases separate queue will be generated none of them have to wait for their RFC to complete its job.

BADI is available CRM_BUS20001_R3A – This BAdI is used in all components in which a data transfer from SAP CRM to SAP ECC must be completed. You can transfer data from SAP CRM to SAP ECC with this BAdI.

Before creating an implementation for BADI CRM_BUS20001_R3A check standard implementation CRM_GOODS_MOVE_R3A.[Almost same approach we will use in our requirement]

DM_MOVEMENT_FILTER : For adding filter like on particular status changes should be transferred to ECC

DM_MOVEMENT_UPLOAD : To update a flag for stopping a response from ECC end.

Let us look at the code how we are filling the structure.

As you are reading value of service_h, customer_h and status needless to say add same parameters in method GET_MBDOC_PROPERTIES.

Now rest for the coding for filling the structure is done in MBDOC_FILL_BAPI [as shown in above code]

1) 7) Now here you filled the structure you want to send to ECC.

8) Next step is to invoke a queue and call the ECC RFC for updating. For this we will write code in DM_MOVEMENT_INVOKE method.

9) Now since we have a requirement that on particular status (i.e. OPEN and CLOSE) only an update should be done in ECC table and it should happen only in case of particular transaction type we need to code in method DM_MOVEMENT_FILTER

11)Since we don’t want to take response from ECC we have to change the value of flag CV_RESPONSE_FROM_R3 to FLASE.

If you want to read the response from ECC you need to keep flag TRUE, and necessary code changes need to be done from ECC side.

12) Debugging : Now an important step

NOTE: Never try this in Production system. As if you forget to register the queue your queue size will get increase and it may impact your performance.

If you want to debug your scenario first and foremost thing you need to do is to deregister your queue.