|Home • Trainings • Quiz • Tips • Tutorials • Functional • Cert Q's • Interview Q's • Jobs • Testimonials • Advertise • Contact Us|
Raising events based on change document (Workflow)
By Kartik Tarla, Infosys
business objects are changed frequently. Often we are required to trace the
changes made. We do this by tracking the change documents.
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.
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.
change document is written only when change is updated, this ensures that the
event is not created until the change has actually been made.
Assignment between a change document and event is maintained through transaction
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.
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.
procedure can also be considered as an alternate way of achieving functionality
that at present is fulfilled using Exits, BADIs and BTEs.
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.
association we do in SWEC, where
we assign the business object type, event and the change type to a change
can also put field restrictions to put conditions on triggering of the event.
when the event is triggered, to carry out the further processing we assign a
receiver function module to the event in transaction SWETYPV.
receiver function module must have the interface as this fm SWW_WI_CREATE_VIA_EVENT.
we can perform the required action inside the receiver function.
Consider the following scenario where we can use the concept
of triggering events based on changes made to business objects.
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.
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.
Please send us your feedback/suggestions at webmaster@SAPTechnical.COM
©2006-2007 SAPTechnical.COM. All rights reserved.
product names are trademarks of their respective companies. SAPTechnical.COM
is in no way affiliated with SAP AG.
Graphic Design by Round the Bend Wizards