Hi folks,
I'm at the verge of using UPDATE TABLE <dbtable>. Let me elaborate why:
System Info:
NW AS 7.03 ABAP Stack 731 Level 13, ECC 606 (EHP 6) with SAP_HR 604 Level 81 and EA_HR 607 (HR-Renewal 1) Level 32
Background:
I want to manually implement a pseudy-integration with the PT module in our FI-TV. Our business process allows for the fact, that there's only need for a manipulation of IT 2002 ST0027 for two Events of BUS2089 (handled via Workflow), i.e. the scope of the implementation is quite small.
Problem:
The first thing that came to mind was creating a standard task which reuses good ol' FM HR_INFOTYPE_OPERATION (yes, I am aware it's not released for customers). However, this doesn't work because the FM decides to crash upon a problem in the programming which seems to be older than a decade (according to my research):
I found the following SCN dicussions amongst others: HR_INFOTYPE_OPERATION Precondition Violated, Uncaught exception in HR_INFOTYPE_OPERATION, CX_HRPA_VIOLATED_PRECONDITION using HR_INFOTYPE_OPERATION to insert record.
As far as I understood, the problem occurs because the factory method is wrongly called several times in case of a mixtured usage of the coupled and decoupled infotype framework (that applies for my company, we use both). Unfortunately, none of the mentioned workarounds, i.e. calling it in an RFC wrapper with "DESTINATION 'NONE'", executing in new task, submitting a program, executing that magical form routine "do nothing" in SAPFP50P worked for me. It still crashed. After searching for notes (none of the found notes apply for my system anymore, the corrections are all already implemented) and finding KBA #2093195 I gave up on this approach. To whomever created this KBA: I hereby declare you wisenheimer (even though I sympathyize with you, since you are probably an employee in Support who gets 50 incidents for this non-released FM per day).
My alternative approach was using BDC instead (yes I know BDC shouldn't be used within workflows), which also didn't work, because the processed logic is not commited, i.e. nothing is written to the database into the PA*-Tables, not even when using a heretic explicit COMMIT WORK.
Both approaches work perfectly when used outside of the workflow.
Yet another idea was stealing the idea from the leave request business logic, converting stuff a billion times from BLOP to Attabs and vice versa until the system is so confused things just have to work. But that would have been to expensive due to its complexity.
I've now fallen back to creating a job which uses HR_INFOTYPE_OPERATION yet again and this works, but I find this to be horribly inelegant and I'm not happy with it, because it deviates from my workflow design and skips its protocolling and... meh.
So, folks, what do you do when you need to manipulate infotypes within a workflow? What magically elegant solution did I miss?
Cheers, Lukas
P.S. Maybe it's all so damn expensive, because I forgot to offer a sacrifice to the Workflow Goddess ? :<