Unit 7: Creating the Method Edit Without Parameters (SAP Library

Unit 7: Creating the Method Edit Without Parameters

Use

In this unit, you will create and implement the method Edit as a method without a parameter.

You must implement this method if your object type supports the IFEDIT interface.

Prerequisites

The Edit method enables you to edit the object. This is one of the methods that your object type inherits from the IFEDIT interface.

Although this method is defined for the interface, it is not yet implemented. In other words, the program of your object type must be extended accordingly. To do this, the object-specific transaction (or function module) is called in the implementation of the method Edit , with which the object can be edited. For sales orders, this is transaction VA02 .

Inherited Object Methods

If you want to edit a method that your object type has inherited from an interface or a supertype, note the following:

An inherited method can only be edited if you release this method for overriding.
You cannot change the name of the inherited method any longer.
You cannot delete any parameters. You can only add non-mandatory parameters to the interface.
When you maintain inherited methods, it is important that the entries you make for the ABAP functionality, call attributes, and result type are correct, since automatic program generation depends on this.

The following properties and exceptions of the method Edit are inherited from the interface IFEDIT :

Method properties

The method Edit is a synchronous method, which runs with dialog, is instance-dependent and does not return a result. (The task in which this method is referenced will usually have the property Confirm end of processing.)

Procedure

Position the cursor on the method Edit .

Choose

This graphic is explained in the accompanying text

The color of the entry changes.

Double-click the method name to open the method definition.

On the tab page ABAP/4, enter the transaction VA02 in the field Name and select Transaction.

Choose

Position the cursor on the method Edit .

Choose Program. Let the system create the template for the missing method.

An (almost) complete implementation is created from the specifications on the ABAP function type:

The method is implemented between the macro instructions
BEGIN_METHOD <method name> CHANGING CONTAINER and END_METHOD .

When the calls are implemented, the unique ID of the object is available in the structure of the key fields under the variable name OBJECT-KEY-SALESDOCUMENT . Using SET/GET parameters, the input field in the first screen of the transaction is filled from this key field. This first screen is then skipped when the transaction is called ( ... AND SKIP FIRST SCREEN ).

Add the line SWC_REFRESH_OBJECT SELF to the implementation of the method Edit . You can find the source text in the appendix in lines 98-102.

The standard buffering of attribute values can give rise to the situation where attribute changes that occur when an object is edited are not "noticed" by the runtime system.

Therefore, after the execution of methods that could have changed attributes (methods Edit , Update , Change , and so on), call the macro in the form SWC_REFRESH_OBJECT SELF before END_METHOD . This means that the attributes will be refreshed before the next read access, and not read from the internal table.

Choose and exit the Program Editor.

Result

Testing a method without parameters

The object type must first be generated so that it can be instantiated and tested. Choose This graphic is explained in the accompanying text

The system informs you if the object type still contains errors. Try to correct these errors in the error overview (Goto ® Error list).

To test the method, choose .

The Test Object Type <Object Name>: No Instance screen appears.

Choose

Instance.

Identify an object of the type sales order by entering the number of a sales order of your choice. Use the F4 input help if necessary.

Choose

The Test Object Type <Object Name> screen then appears, in which you can test your object type (execute methods, check attribute values).

Notes on the calling and reporting behavior of this method

In order for the method to be used in a workflow, it must be encapsulated in a task. This task is represented at runtime by a work item.

If this work item is executed by one of its recipients, the runtime system calls the method and thus, indirectly, the transaction. As the method Edit is a synchronous method without results, the work item is completed as soon as the method has been executed once. This system behavior is not generally desirable:

The actual agent does not receive any information as to whether anything was changed or not.

It is not possible to call the method several times for multiple changes.

If you want to be sure that the work item only assumes the status completed if changes were actually made to the sales order, the method should not be defined as a synchronous object method. Instead, you must define the method as an asynchronous method and provide a terminating event for the task, which is created when a change is made to an object.

Note

This event can be implemented by linking the event creation to the writing of change documents.

If the work item is to be executed several times, you must set the flag Confirm end of processing in the task definition.