Raising events based on changed document

Introduction:

Many business objects are changed frequently. Often we are required to trace the changes made. We do this by tracking the change documents.

To be able to log changes to a business object in a change document, an appropriate change document object must be defined in the system. In its definition, a change document object has tables, which represent a business object in the system. Changes to table fields designated as change document-relevant are logged by writing a change document.

We assign a change document object to an object type/event pairing and determine the action (create, change or delete) on the application object for which the event is to be created. We can classify the event in order to create three different events for a change document i.e. create, change & delete.

The change document is written only when change is updated, this ensures that the event is not created until the change has actually been made.

The Assignment between a change document and event is maintained through transaction SWEC.

When the particular event is triggered, then we can carry out the further processing by assignment of a receiver function module and a receiver type to a particular combination of object type and event, this is done through the transaction SWETYPV.

In the receiver function module we can do the custom coding to achieve the functionality which is needed whenever the business requirement demands that certain work needs to be done when a change is made. Our processing may stop at the receiver function module itself or we may proceed to trigger a workflow.

This procedure can also be considered as an alternate way of achieving functionality that at present is fulfilled using Exits, BADIs and BTEs.

Suppose the requirement needs certain action to be performed when the changes to any transaction are saved. The first approach that generally is followed is to look for exits or BADIs, but mostly the problem faced is, that all tables may not be updated at the point where the exit is being called, or the changes may be cancelled after the exit call which may then require to take back our actions which we performed inside the exit. So in such cases a much better and cleaner approach is to make use of events, which trigger on change document.

This association we do in SWEC, where we assign the business object type, event and the change type to a change document.

SWEC:

We can also put field restrictions to put conditions on triggering of the event.

Now when the event is triggered, to carry out the further processing we assign a receiver function module to the event in transaction SWETYPV.

SWETYPV:

The receiver function module must have the interface as this fm SWW_WI_CREATE_VIA_EVENT.

Now we can perform the required action inside the receiver function.

Scenario:

Consider the following scenario where we can use the concept of triggering events based on changes made to business objects.

Business Requirement:

To trigger a mail to be sent to the Sales Order creator whenever any changes are done to the schedule lines and the indicator “Fixed date and Qty” is checked.

Technical Solution:

The change document for sales order related changes is VERKBELEG, and the business object is BUS2032.

So we create an event SCH_CHANGED and assign it the change document VERKBELEG in transaction SWEC.

Now assign a receiver fm to the bus/event - BUS2032/SCH_CHANGED in transaction SWETYPV.

Inside this function module we write the code to trigger the mail.