One quick solution - rather then using change pointer create an ABAP prog. to trigger the idoc by identifying/comparing record date condition and schedule it on required frequency.
Hi SAP Tech,
Thank you for your answer.
Can you please describe a little more detailed how this can be done? If you could share some code or refer me to some article/forum/blog that shows the steps it would be much appreciated.
Thanks again.
there are many on sdn, one such forum is http://scn.sap.com/thread/103198 ...
The data in IDoc can be manipulated via user exit to send only some entries, but, since you're using change pointers, that would cause loss of data. Change pointers are generated at the time when a change is made. A change might be in the record that is valid today or valid months from now. But change pointers are normally retained only for the short period of time in SAP (there is a "cleanup" program that normally runs in background and deletes processed and old change pointers). Also after a change pointer has been processed, it's status changes. So, plain put, the change pointers can't be reused (and they shouldn't actually).
It's not feasible in SAP to send changes at later time, to my knowledge. To do so, you'd have to throw away the standard solution and create some custom program, which is not a good idea.
I would rather check with "3rd party systems" if they could hold on to the records until later time. Some major payroll companies like ADP are using these same IDocs "out of the box" to interact with SAP systems and it works fine for them. Also you might want to check in the HR forum, maybe someone had similar experience.
Good luck!
Hi,
Resend data later will cause data inconsistency. If you want to use the standard ALE soltion for HR master data distribtion, you'd better setup the same data structure as sap to record all the changed data at the target system side.
If you just want to get the current valid information, why not try direct function call to the get the real-time HR data from biz-talk by date? There also standard solutions existed for third-party system integration with Java\.Net\C...
Chen Jian
Hi Chen Jian,
Thank you for your answer.
Since all changes happens in SAP, we want SAP to initiate (push) the communication of changes to other systems, hence the change pointers. The problem is not the current valid records that changes (we have control of that filtering the change pointers by dates), but changes that are scheduled for a future date. Since we need those to be communicated as well, we are looking for a mechanism to help us take care of that on the SAP side.
Setting up the same data structure or a repository to duplicate the records in SAP is out of the question and really unnecessary as it will only create more work, having to build an API/service layer to govern changes, doing comparisons, new etc. It will require to much work and maintenance.
I hope this clarifies matters a bit.
Moses, with "out of the box" change pointers + IDoc solution available in SAP it's not feasible to send out changes on their effective date, as I've already explained. So if you want to send only the changes and only on the date when they become effective, someone would have to take a hit, so to say, and make some additional effort. It'd have to be SAP, Biztalk or 3rd party, so pick your poison.
Since you're posting question instead of your SAP team members, I can only guess they have low availability. So, as much as you'd like this to be solved on the SAP side, I'd suggest to check first if it's even a possibility.
It is not difficult to send all the current information, as Jian suggested (which might actually be an option). But it is difficult to send just the changes.
Hello
Generally change pointers are used to send the real time updates. Since this is custom enhancement where you want to send the data on the effective data, we would require to implement the user-exit/spot. Change pointers are logged in BDCD2/BDCP whenever you make any changes to any master data, and we use BD21/PFAL to generate the IDOC's from change Unprocessed change pointers. This program would choose all the unprocessed change pointers for a given message type and creates a IDOC. So the idea of user exit would be to leave the change pointers as unprocessed till the date matches the begin date. Though everyday till then this change pointer might be picked up, but they should never be converted to IDOC and leave the change pointer marked as unprocessed.
Hope this helps.
- Ranganath
