Enable Delta on Enhanced Custom Field in Change Pointer Based Datasource – Multiple Target Systems
Hello Gurus, recently I faced an issue with one of the change pointer based datasource so wanted to share the solution for it. It might be helpful to some as it applies to a scenario where we have multiple target systems connected to SAP ECC…in my case its SAP BW and Informatica.
- Here is the scenario:
Let’s say for Datasource 0MAT_PLANT_ATTR an enhancement for new fields was done some time back. However it is noticed that when ONLY new fields are changed in SAP then no delta records are generated. This cause an inconsistency between SAP ECC and target system. In my case the datasource is extracted in SAP BW and Informatica both either parallel or sequential.
Pre-requisite for Enhanced Field: At Data Element Level it should be ‘Change Document’ enabled.
Some Background for change pointer datasources extracted in multiple target systems –
When a datasource is extracted in multiple target systems different logical systems are assigned for each target system.
So for each datasource separate logical systems and message types.
More details can be found in below document:
Taking an example of enhancing 0MAT_PLANT_ATTR and enhancing it with EISBE (Safety Stock) –
Now there are two ways to do it:
- Unhiding it from ROOSFIELD table and then in RSA6 – No ABAP Code is required in this case
- Using User exit and adding a Z field and writing ABAP code.
We are not going to discuss any of the above method in this document. So let’s assume we have enhanced the datasource with EISBE.
- Recreating the issue:
Step1: We create a material with safety stock limit as 100 and it is extracted in SAP BW/INFA systems successfully in 0MAT_PLANT_ATTR.
Step2: Change the material with only its safety stock limit (EISBE) to 200.
- Issue Caused: After step 2, we notice that NO Delta Record is generated for this change and hence now we have different values in SAP ECC and Target system causing out of sync data.
- Solution: To fix this we need to add an entry in the table V_TBD62 via transaction code BD52. Now notice that BD52 only allows to make an entry for each message type.
About Message Type in SAP transaction BD52:
These are similar to message types for IDOCs in SAP but auto generated when we first replicate the datasource from target system.
For example, if I have replicated datasource from SAP BW and Informatica we will have 2 message types generated for each logical system.
We can check these message types in table ROOSGEN for each datasource per logical system.
Coming back to issue and solution…So when we start making an entry in BD52 we will first have to enter Message Type and then make the corresponding entry for field by clicking ‘New Entries’.
- Tricky Part – Transporting the changes to Higher Enviornments:
The tricky part is transporting the entries into higher environments like Quality/Production system.
As I said earlier that the message type is auto-generated in SAP ECC for each datasource and target system so same message type may not be preset in Development system than in Quality or in Production system.
Meaning, when we replicated datasource in Dev system it generated message type ‘RS0088’ and same datasource generated ‘RS0148’ in Quality/Production system. So in Dev system you cannot make any entry for ‘RS0148’ message type because it is not present in it at all and if you make entry for ‘RS0088’ in Dev and transport it, it will not make any changes because ‘RS0088’ is not present in quality system. So this is a Disconnect in the objects.
Now we have two options:
- Make direct changes in Quality and Production – ‘Not Likely’
- Create the message type and then transport it.
I took the second option as I myself rejected first option straight out, and our Basis team too rejected it
- To Achieve Option 2 –
Remember? – For datasource 0MAT_PLANT_ATTR – we have ‘RS0148’ message type in Quality system and ‘RS0088’ in Dev system.
Step1: Create the message type ‘RS0148’ in transaction WE81 in Dev system.
Since SAP reserves RS* message types for datasources so you can create it.
Here a Workbench transport will be generated – Save it in transport
Step2: Now add the field in BD52 for this message type RS0148 – System will allow you this time because you created it in WE81.
Here also a transport request will be generated but a Customizing Transport request – Save the new fields in new customizing transport
Step3 (Important): Transport Only the Customizing request in Quality system and ignore the workbench transport request in step1.
This will allow your fields to be added in the message type ‘RS0148’ in quality system without making any direct changes in Quality or Production system.
- Caution: DO NOT import the workbench request else it will overwrite your message type in Quality and you can end up with bigger problem so don’t import it to Quality.
1. Since it is applicable per message type per datasource per target system so we have freedom to apply changes independently and it will not affect any other objects or target system mechanism.
2. No need to re-initialize the datasource – it will work right with next delta. But better do FULL repair load to refresh the data.
3. If only the enhanced field is changed you will have delta records generated for it.
- Side Note:
1. Shortcut way to find/ensure that datasource is Change Pointer Based or Use Message Type:
Check in table ROOSGEN for corresponding datasource, if the field ‘MSGTYP’ is not blank then it uses then it is change pointer based datasource.
Else you can check in RSA2 and check if Delta Type is NEWE, E etc.
2. Supporting SAP Note – 2177126
I hope this helps someone. Let me know if there are any questions.
Nicely documented. Keep up the good work. 🙂
Your document really helped us in of our recent project.We followed the same steps as mentioned and successfully enabled delta for the enhanced field.
Thanks for sharing it.
this is an older post, but was exactly what I was looking for.
There is one problem I think I can see, though.
I has to do with the auto-generated message types in each system.
We have a 3 system landscape (DEV, QA, PROD). I want my Z-fields to be relevant for the change pointer in both QA and PROD. So I create the necessary message types for both QA and PROD in DEV. When I now assign the Z-fields to the message types taken from both QA and PROD, the problem I can see arising is that message type RSXXX may exist in both systems (QA and PROD), but may be assigned to totally different delta queues and/or logical systems.
So by assigning my Z-field MARA-ZFIELD to RS123 (assigned to my 0MATERIAL_ATTR delta in PROD) I may cause a situation in QA, where a change to MARA-ZFIELD updates the change pointer in the QA-system for delta queue 0VENDOR_ATTR, because message type RS123 has been auto-assigned to that queue in QA.
Am I missing something or is this a real problem?