• No results found

configure the GUIBB

Exercise Objectives

After completing this exercise, you will be able to:

• Define the feeder class for the FORM GUIBB.

• Implement the source code of the feeder class methods.

• Use a central data model.

• Configure the FORM GUIBB.

Business Example

You would like to define the customer form of your OIF application via configuration of the corresponding generic UIBB. However, this also means that you have to create the feeder class and you have to implement the methods of this class. In addition, you need to exchange data between this feeder class and the OIF component. Thus, you need to use a simple central data model.

Template Feeder Class: Central Data Model Class:

CL_NET313_CENTRAL_DATA

Solution Component Configuration:

NET313_CUSTOMER_S7_CC1 (FPM component) NET313_CUSTOMER_S7_CC_FORM (FORM GUIBB)

Task 1:

OPTIONAL TASK:

Complete the feeder class to be used by the FORM GUIBB. Copy the template CL_NET313_FORM_GUIBB_T. Name your copy ZCL_##_NET313_FORM.

The template contains the all methods and attributes needed to implement the feeder class. You only need to complete the methods FLUSH( ), GET_DATA( ), and GET_DEFINITION( ).

Implement the source code: The feeder class should not support parameters. All fields of the DDIC structure SCUSTOM but the field MANDT should be available for the configuration process. All fields should not be editable. The labels of the fields and the lengths of the fields should be obtained from the DDIC description.

The feeder class should allow to replace the customer form of your application by the FORM GUIBB.

1. Create the feeder class to be used by the FORM GUIBB by copying the template CL_NET313_FORM_GUIBB_T. Name your class ZCL_##_NET313_FORM.

2. Implement the source code of feeder class method GET_DEFINITION( ).

The source code consists of the following steps:

Get the RTTI description of the DDIC structure SCUSTOM (use method CL_ABAP_TYPEDESCR=>DESCRIBE_BY_NAME( ) ).

Pass this description to the exporting parameter EO_FIELD_CATALOG.

Get the components from the RTTI description of the DDIC structure SCUSTOM (use method GET_COMPONENTS( ) for RTTI structure description).

Loop over the component list.

For each component, define a new line of the exporting parameter ET_FIELD_DESCRIPTION.

Set NAME = name of structure component.

Set VISIBILITY = CL_WD_UIELEMENT=>E_VISIBLE-VISIBLE for all structure components but the component MANDT. Set VISIBILITY = CL_WD_UIELEMENT=>E_VISIBLE-NONE for the component MANDT.

Set READ_ONLY = ABAP_TRUE, LABEL_BY_DDIC = ABAP_TRUE, and LENGTH_BY_DDIC = ABAP_TRUE for all structure components.

3. Complete the source code of feeder class method FLUSH( ). This consists

If this internal table is not empty, proceed processing the method. Get the current form data from the reference variable IS_DATA. De-reference this data reference into a field symbol of type SCUSTOM. Store the customer data in the feeder class attribute GS_CUSTOMER.

Store the information, that the customer data has been changed by the user: Set the central data model attribute GO_CENTRAL_DATA->GV_SAVE_DATA to ABAP_TRUE.

Call the methods SET_IDR_TICKET( ) and SET_IDR_ITEMS( ). Pass the customer data set to the first method and the literal 'M' (modified) to the second method.

4. Complete the source code of feeder class method GET_DATA( ). This consists of the following steps:

Check, whether the value of the feeder class attribute GS_CUSTOMER has been changed during the current dialog step (GV_DATA_CHANGED

= ABAP_TRUE).

In this case, set CS_DATA = GS_CUSTOMER and EV_DATA_CHANGED

= ABAP_TRUE. This will force the WD runtime to actualize the form data displayed to the user. In addition set GV_DATA_CHANGED = ABAP_FALSE.

Set the readOnly property of the form fields according to the current value of the feeder class attribute GV_READ_ONLY:

Loop over the changing parameter CT_FIELD_USAGE. Modify the value of the field READ_ONLY for each data set. In addition set

EV_FIELD_USAGE_CHANGED = ABAP_TRUE. This will force the WD runtime to update the form field properties.

Enable the button labeled Display/Change Customer.

5. Save and activate your feeder class.

Continued on next page

Task 2:

Adapt your OIF component assuming that the customer form is defined by the FORM GUIBB:

Delete all WD entities which are not needed any more.

Delete all component controller methods, attributes, and context nodes that are not needed any more.

Adapt the remaining component controller methods of your OIF component.

Work on attributes of the central data model

(GO_CENTRAL_DATA->GV_SAVE_DATA, GO_CENTRAL_DATA->GV_CUSTOM_ID) instead of component controller attributes.

Add a component controller attribute to store the reference to the central data model. Set the value of this attribute in the controller method WDDOINIT( ).

Implement the component controller method FLUSH( ). If the last interface view displayed to user was INTRO_WINDOW, pass the customer ID selected by the user to the central data model attribute GO_CENTRAL_DATA->GV_CUSTOM_ID.

1. Delete the view CUSTOMER_VIEW and the window CUSTOMER_WIN-DOW.

2. In the component controller context, delete the context node UI_ELEM_PROPERTIES.

3. Delete the component controller attribute GO_CONTEXT. Delete all coding sections referring to this attribute.

4. Delete the component controller methods INIT_IDR( ), TOGGLE_EDIT_MODE( ), UPDATE_CUSTOMER( ),

GET_CUSTOMER( ) and - if you have created them in the related optional exercise - SET_IDR_ITEMS( ) and SET_IDR_TICKET( ).

5. Create the controller attribute GO_CENTRAL_DATA of reference type CL_NET313_CENTRAL_DATA. Get the reference to the central data model in method WDDOINIT( ).

6. Implement the source code of the component controller method FLUSH( ).

Replace the existing source code as follows:

If the last interface view displayed to user was INTRO_WINDOW, read the customer ID from the context (node CUSTOMER_ID).

Copy the customer ID to the central data model attribute GO_CENTRAL_DATA->GV_CUSTOM_ID.