Skip to Content

Hi Guys,

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]

1.JPG

2.JPG

1)      1) As highlighted in above image class cl_crm_goods_movement_upload [Contains sample code for data transfer]

2)      2) Copy  cl_crm_goods_movement_upload  to ZCL_CRM_DM_MW_UPLOAD

3)      3) Now created implementation of BADI CRM_BUS20001_R3A as ZCRM_DM_2001_R3A

4)      4) Now copy the code from standard implementation cl_crm_goods_movement_upload to your Z implementation

5)      5) And as shown below replace the class with ‘Z class you created’3.JPG

6         6)  Create a structure with same fields as you have in ECC table [Which you need to update]

          In current scenario we have ZDPT table in ECC which we are updating hence same type of structure ZCRM_DM_DPT_S we maintained.

         

      Find below the structure in CRM.

       4.JPG

     Now if you notice in copied class ZCL_CRM_DM_MW_UPLOAD multiple methods are available.

     MBDOC_FILL_BAPI           : Contains code for filling the relevant structure [Same type as ECC table]

     DM_MOVEMENT_INVOKE  : Calls ECC FM for  table updation

     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.

    5.JPG

   

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

       6.JPG

         7.JPG

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

          8.JPG

    

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

          9.JPG

          10.JPG

          11.JPG

        12.JPG

         

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.

                    13.JPG

            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

               14.JPG

                    15.JPG

                    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.

            

          16.JPG

               

                    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.

     a)  Go to transaction SMQS and deregister your R3 destination. [as shown in below screenshots].

    Once destination is deregistered you will notice against destination ‘U’ status.

           17.JPG

          

b)      Go to transaction SMQR and deregister CSA*[System generated internal CRM queue] and R3A* [If you want to debug inbound queue] queue.

18.JPG

c)      Now create an activity on WEB UI.

19.JPG

d)  Go to transaction SMQ2 (Inbound queue) . You will find that an CSA queue is stuck.

20.JPG

Double click on the queue (screen like below screenshot will open)

21.JPG

Again double click on queue below screen will open with an debugging symbol click on it.

You will enter into debugging window.

22.JPG

Now put breakpoint in the method MBDOC_FILL_BAPI, DM_MOVEMENT_INVOKE DM_MOVEMENT_FILTER of class ZCL_CRM_DM_MW_UPLOAD

And debug your code.

a)   Once you debug the CSA queue and R3* queue would be generated.

Go to transaction SMQ1 (Outbound queue)

Debug the queue in same manner you debugged inbound queue.

b)   Don’t forget to register destination and queue again.

1)      Adapter object :

     Please note as we want to send data of an transaction to ECC system we need to activate adapter object from R3AC1 .

     Object name – BUS_TRANS_MSG

Note: For every adapter object in CRM we have subsequent object in ECC even that needs to be activated from CRM end. Else update won’t happen.

     Now this is bit tricky as even we faced this issue. Here everything was fine but adapter object SALESDOCUMENT was not active it was creating a trouble.

     For this we debugged a lot and found some FM  where we could find that for Object BUS_TRANS_MSG subsequent object SALESDOCUMENT has to be activated. (as mentioned below)

·         SMW3_OUTBOUNDADP_CALLADAPTERS

·         SMOF_ERPSITE_OUTBOUNDADPGET

·         CRM_UPLOAD_TO_OLTP

·         CRM_BUS_MESSAGE_R3_UPLOAD_SRV

     Hence don’t forget to activate SALESDOCUMENT adapter object.

To report this post you need to login first.

14 Comments

You must be Logged on to comment or reply to a post.

  1. Amrita CRM

    Excellent. I really needed to appreciate your time and efforts in preparing this and it really so clear…We would expect few more from you like this..

    Have  a nice day.

    Amrita

    (0) 
  2. Karthi M R

    Excellent.. Appreciate your hard work and passion in exploring the possibilities. Thanks for sharing. Expecting more knowledge sharing in the future.

    Regards,

    Karthi M R.

    (0) 

Leave a Reply