- SAP Managed Tags:
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) 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’
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.
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.
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.
😎 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.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.
b) Go to transaction SMQR and deregister CSA*[System generated internal CRM queue] and R3A* [If you want to debug inbound queue] queue.
c) Now create an activity on WEB UI.
d) Go to transaction SMQ2 (Inbound queue) . You will find that an CSA queue is stuck.
Double click on the queue (screen like below screenshot will open)
Again double click on queue below screen will open with an debugging symbol click on it.
You will enter into debugging window.
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.
14 Comments
