Work flow based outbound Idoc's

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.

(67)

RELATED POSTS