Unfortunately, there are application that do not create messages. This is especially true for master data applications. However, most applications fire a workflow event during update,which can easily be used to trigger the IDoc distribution.
Many SAP R/3 applications issue a call to the function SWE_EVENT_CREATE during update. This function module ignites a simple workflow event.Technically a workflow event is a timed call to a function module, which takes the issuing event as the key to process a subsequent action.
If an application writes regular change documents (ger.: Änderungsbelege) to the database, it will issue automatically a workflow event. This event is triggered from within the function CHANGEDOCUMENT_CLOSE.
The change document workflow event is always triggered, independent of the case whether a change document is actually written.In order to make use of the workflow for IDoc processing, you do not have to go through the cumbersome workflow design procedure as it is described in the workflow documentation. For the mentioned purpose, you can register the workflow handler from the menu, which says Event Coupling from the BALD transaction.
Triggering the IDoc from a workflow event has a disadvantage: if the IDoc has to be repeated for some reason, the event cannot be repeated easily. This is due to the nature of a workflow event, which is triggered usually from a precedent action.
Therefore you have to find an own way how to make sure that the IDoc is actually generated, even in the case of an error. Practically this is not a very big problem for IDocs. In most cases the creation of the IDoc will always take place. If there is a problem, then the IDoc would be stored in the IDoc base with a respective status. It will shown in transaction WE05 and can be resend from there.
Workflow Event From Change Document:
Most application fire a workflow event from the update routine by calling the function
FUNCTION swe_event_create
You can check if an application fires events by activating the event log from transaction SWLD. Calling and saving a transaction will write the event’s name and circumstances into the log file.If an application does not fire workflow events directly, there is still another chance that a workflow may be used without touching the R/3 original programs.
Every application that writes change documents triggers a workflow event from within the function module CHANGEDOCUMENT_CLOSE, which is called form the update processing upon writing the change document. This will call the workflow processor.
FUNCTION swe_event_create_changedocument:
Both workflow types are not compatible with each other with respect to the function modules used to handle the event.Both will call a function module whose name they find in the workflow linkage tables. swe_event_create will look in table SWETYPECOU while
swe_event_create_changedocument would look in SWECDOBJ for the name of the function module.If a name is found, the function module will then be called dynamically. This is all to say about the linkage of the workflow.The dynamic call looks like the following.
CALL FUNCTION swecdobj-objtypefb
EXPORTING
changedocument_header = changedocument_header
objecttype = swecdobj-objtype
IMPORTING
objecttype = swecdobj-objtype
TABLES
changedocument_position = changedocument_position.
RELATED POSTS
No comments :
Post a Comment