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.

Extended notification configuration

Goto T-code SWNCONFIG.

Copy the STANDARD Category to ZMAILNOTIF and save as shown below.

Select the Category and choose Assigned Message Templates and choose One Message per Notification in Granularity and save as shown below.

Double click on Delivery Schedule in Dialog structure and create New Entries as shown below.

Double click on Subscription Basic Data and create New Entries for as shown below. Mention the delivery schedule which created previously.

Double Click on Subscription Settings in Dialog Structure and give ATTACH1 in SHOW_INBOX_AS if you need to open the inbox from the attachment of the mail. If you do not want any attachment to open work item, leave the values as blank.

Double click on Filter Basic Data and create New Entries for Workflow Scenario as shown below.

Double click on Filter Settings and give X to Delta parameter.

Double click on Schedule Selection and give the filter value and choose in which are all days it should schedule to send the notification and on what interval.

The below screenshots are as per standard settings and no need to do anything on that.

In SE38 tcode create a variant for program SWN_SELSEN and enable the check-box option No Time Check During Send and save the variant.

Schedule this program in background job in SM36 with variant for every 15 minutes or what interval needed.

Before testing, check whether the services provided in below link are active in SICF.

Debugging SAP events

By Saurabh Asthana, Infosys Technologies

Overview:

This document explains how receiver Function module can be used as a Substitute of BAPIs and Exits in particular cases and how to debug those events, as general debugging method can not be used for them.

This document is categorized into:

• Introduction of events

• About receiver FM

• How to debug related event

INTRODUCTION OF EVENTS:

§ Events indicate the occurrence of a status change of a Business objects.

§ Events always belong to an object and are therefore described as definition components in the object type

§ Events can have parameters & exceptions like methods

§ These events have listeners (outside the BO). E.g., workflow

§ We can create our own events also.

Procedure to create Events:

a) Position the cursor on the entry Events. And then press create

b) Now enter the following texts for the event to be created

C) Give Event, Name, Short description

§ Irrespective of whether you use uppercase and lowercase in the event name, the name is always entered in uppercase letters in the event receiver linkage table by the system.

§ The event has now been created and is available in the Business Object Repository.

§ You can now use this event in the other definition tools in SAP Business Workflow.

Position the cursor on the new event and choose Edit → Change release status → Object component → to implement.

§ The object type must first be generated so that it can be instantiated and tested.

About Receiver FM:

§ If we have a requirement like insertion of an entry in a table when material is changed in a sales order or we want some functionality to happen when a purchase order or sales order is created, generally in such cases we look for BADIs and exist, these are called after the save events are triggered and we place our logic there.

But we can also have a separate approach in which we link the event to a function module through Transaction SWETYPV and the logic are written in the FM to satisfy the requirement.

§ Now if we want to Debug that code, just by putting the break point there, we cannot reach their directly

So for this purpose below mentioned method should be followed, this procedure is very useful and can be utilized wherever we want to debug the events.

First go to transaction SWETYPV then new entries.

Here on changed event we have written our logic in (This function module is created by copying standard receiver FM SWW_WI_CREATE_VIA_EVENT) and put the break-point there and this ZRECEIVERFM is linked with the event by using transaction SWETYPV.

Here object type Bus2032 is taken which is for sales order, as here we are taking the case where

In a sales order while changing the quantity, the change event is triggered and then we are linking this event to ZRECEIVERFM where we put our logic.

Now we go to our transaction code VA02(change sales order)

How to debug the event:

Now we will change the quantity of item, from 916 to 917 then press enter and start debugger(/h) as shown:

It will come to the following screen there go in setting --> update debugging.

Note: Before switching on the debugger check that the default debugger should be classic debugger (check in SE38-->utilities-->debugging-->ABAP debugger)

Now press execute, then it will come to following screen, there go in setting --> Breakpoint at --> Method. A pop-up will appear, in that give the class name as CL_SWF_EVT_STRATEGY_BOR_FB and in Method give process.

Now press execute.

Now from here press F5, then after coming to CASE me->process_mode, here change the mode manually as D (for debugging) as shown below.

Then execute, then we come to the our own created ZRECEIVERFM, where break point is set and Logic is written.

Thus we can analyze and debug the logic.

Building a simple application using Web Dynpro for ABAP

Scenario: To create and run a simple WebDynpro Application. We would accept an input value from the user on first screen and display the value entered on the second screen.

Note: Please refer to the SAP® help for detailed information of the components used in this document.

Procedure:

1. Go to transaction SE80. Please note that there is no separate transaction for creation of WebDynpro application other than SE80.

2. Select “WebDynpro Comp./Intf” from the list (as shown below)

3. Create a new WebDynpro component by the name ZSAPTECHNICAL_DEMO.

Assign it to the local object.

4. Right click on the WebDynpro component “ZSAPTECHNICAL_DEMO” and create a view.

Save the application

5. Double-click on the COMPONENTCONTROLLER.

6. Check if the application is in change mode.

7. Create a node as shown below:

8. Create an attribute for the node as shown below:

Save the application.

9. Double-click on the view, FIRST_VIEW, created earlier.

In this step, we would be designing the first screen of our application with the following elements:

· Label for the input field

· Input field

· Button (for Submit)

Drag and drop the element “Label” onto the layout.

After dragging and dropping onto the layout, change the text of the “Label” to “Username” in the right side bottom of the window.

Now drag and drop the “input field” onto the layout.

Now click on the Label element created earlier and set the property of “LabelFor” to “INPUT_FIELD”.

Finally, drag and drop the element “Button” on to the layout.

In the properties window of the Button, do the following:

Change the text to “Submit”

Click on “Create” for the property “OnAction”.

Enter the Action and the Outbound Plug name.

Press “OK” for the creation prompt of Outbound Plug.

Click on “Context”tab. Drag and drop the Node on the right side to the context on the left side.

Click on ‘YES’ for the prompt for the node to copied and mapped.

Save the application.

Click on Layout tab now.

Double-click on the “Input_field” and in the properties:

a) For the property “Value”, select the attribute “Name” by clicking on the binding button.

We are done with designing of the first screen.

10. In this step, we would design the second screen of our application.

Right-Click on the WebDynpro component and create another view, SECOND_VIEW.

Create a label, “Entered Name” as mentioned in the earlier step.

We would display the value entered on the first screen in an element called “text view”.

Drag and drop the element “Text View” onto the layout.

Click on “Context” tab and map the nodes as in our earlier step.

Go to Tab “Inbound Plugs” and create an inbound plug as shown below:

Go back to the layout now.

Now double-click on the element “TextView” to open the properties. For the property “Text”, click on the binding button and select “Name”

________________________________________________________

same as in the second view also

LabelFor = select "Text_view"

Don't miss this

_____________________________________________________

11. In this step, we would embed the above created views in the window created in the first step.

a) Double-click on the window “MAIN_WINDOW”.

b) Right-click on the window name and select “EMBED VIEW”.

c) Embed both the views created earlier. Do not select the view “EMPTYVIEW” which is created by default.

d) Expand the tree.

e) Now right-click on “SUBMIT” and select “Create Navigation”.

f) Select “SECOND_VIEW” for the dest.view.

g) Now select the FIRST_VIEW and make it as default.

Save and activate the application (When activating, select all the six components related to this webdynpro application. If all six components are activated, only then your application executes) Now your application is ready to execute. Lets look at the method of testing this application

Testing your WebDynpro Component

1. Right-click on the WebDynpro Component and create WebDynpro Application.

2. Without changing any values, press SAVE.

3. Execute your WebDynpro application.