cancel
Showing results for 
Search instead for 
Did you mean: 

Question concerning error handling of the phase model

Lukas_Weigelt
Active Contributor
0 Kudos

Hi folks,

System Info:

NW AS 7.03 ABAP Stack 731 Level 8, ECC 606 (EHP 6) with SAP_HR 604 Level 69 and EA_HR 607 (HR-Renewal 1) Level 20

Problem/Question:

I got a general and probably pretty easy to answer question concerning the error handling of the WDA phase model: In a standard WDA I have made some enhancements with extra fields that are rendered dynamically depending on certain actions in other fields. For example, when a certain standard checkbox is checked, my additional fields are set visible and additional plausibility checks are activated.

Unfortunately there are also some standard fields with a DATS type and a TIMS type, i.e. fields that have inbuilt type-specific and DDIC checks which are handled by the standard handlers and, in case there is any error, break the flow to the hook methods etc. This leads to the possibility that somebody actually enters nonsense like "abcde" in a DATS field, subsequently fills the rest of the WDA without any roundtrips, action handlers etc. and once done, corrects the error in the DATS field thus bypassing all my plausibility checks.

Since I've found no other threads where somebody whines about this, I guess I must be making some major design-technical mistake in my dynamic programming.

Any thoughts / advices? Anything goes.

Cheers, Lukas

Accepted Solutions (1)

Accepted Solutions (1)

ramakrishnappa
Active Contributor
0 Kudos

Hi Lukas,

You are in right direction as per design perspective.

Unfortunately, when these standard data type errors appear, phase model skips further methods.

I think, once the error of DATS field is fixed, there will be an action .. usually ENTER key press

I suggest you one work around solution as below


  • Create an attribute in view-->attributes.. ex. gv_action_name of type string
  • Save the action name in WDDOBEFOREACTION's post exit as below

        

          " save the current action name, only if attribute value is initial

          if wd_this->gv_action_name is initial.

               wd_this->gv_action_name = lo_action->name.

          endif.

  • Hope, you have written, logic for ui elements hide/visibility in WDDOMODIFYVIEW( )'S post exit

          Modify your code as below

        

               case wd_this->gv_action_name.

                    WHEN 'CHECK1'.

                         " Here logic goes for setting ui elements properties for action CHECK1

                    WHEN 'CHECK2'.

                        " Here logic goes for setting ui elements properties for action CHECK2

  •      Now, we must clear the attribute value

                    CLEAR WD_THIS->GV_ACTION_NANE.

Well, then let us understand how it works.

Let us say we have some invalid value inside the DATE field and pressed check box CHECK1, now control goes to WDDOBEFOREACTION( ) method and we get the action GV_ACTION_NAME = 'CHECK1' and system bypass all other methods.

User corrects value inside it and performs an action ENTER key pressed,

Again, wddobeforeaction( ) method gets called, but we are not capturing it because gv_action_name already has value in it.

Now, in wddomodifyview( ) method based on action name, the logic executes and clearing GV_ACTION_NAME,

Note: if user does not press ENTER key after correction of date value, and checked the CHECK2, now, ui logic is pending for both CHECK1 & CHECK2, in this case you can have string table gt_actions instead of GV_action_name and process accordingly.

Hope this helps you.

Regards,

Rama

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Rama,


thanks a lot for the quick and detailed reply.


I think I get it; so basically I'm building some kind of event queue from the supposedly called actions from WDDOBEFOREACTION() which are not called due to the type error and fire them in WDDDOMODIFYVIEW as a reaction of the rectified type error. Pretty cool stuff.

I'll try to implement this and will give you a feedback about how it turned out.

Cheers,

Lukas

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Rama,

I finally found some time to look into this more detailed and there was one question coming up pretty fast: How do I know within WDDOBEFOREACTION which action the framework would fire if the standard error handling wouldn't prevent it? There are no event parameters in WDDOBEFOREACTION, in fact there are no parameters at all; so how do I know what action I'm handling for?

In your above post in your coding sample you have a variable "lo_action", where do you get that one filled from?

Cheers, Lukas

ramakrishnappa
Active Contributor
0 Kudos

Hi Lukas,

You get the current action in WDDOBEFOREACTION as below


DATA lo_api_controller TYPE REF TO if_wd_view_controller.

 
DATA lo_action         TYPE REF TO if_wd_action.

  lo_api_controller
= wd_this->wd_get_api( ).

  lo_action
= lo_api_controller->get_current_action( ).

Hope this helps you.

Regards,

Rama

Lukas_Weigelt
Active Contributor
0 Kudos

Hi Rama,

arghs, forgot about polling the API, thanks for the hint

I implemented your approach for one specific action to try it out and it works just the way you described it. Cool! . Since I have a lot of logic in action handlers and not everything in WDDOMODIFYVIEW, I have to change quite a ton of complex coding, so I'll ask my special department if they are willing to take the risk of having to test the entire application anew before I change everything.

But in any case, thanks a lot for this very cool approach!

Cheers, Lukas

Answers (0)