SRM7 - Sourcing Cockpit steps and FPM

[matteo_montalto]

Hi all gurus,

in SRM7 there's a sourcing cockpit for purchase requisitions which is basically split in 4 main steps:

- in the first one (which corresponds to a specific WebDynpro/view) the user cah search for a PR; after the results are retrieved, the user can select PR's positions and proceed to the second step;

- the second step (second WD) represents the user's workarea; here positions from one or more PR can be selected to create a following document (contract or purchase order);

- the third step (third WD) let the user specify in depth which document should be made (e.g., the specific type of the contract);

- the fourth step (fourth WD) shows which document has been created.

By standard, navigation between steps (in both directions, as the user can go back from step 2 to step 1 and so on) is implemented via FPM buttons (e.g, NEXT_STEP).

In my task I have to work on step 2, and these are the requirements: each time the user goes from step1 to step2 (with some positions, of course) I have to perform a sketch of code.

The code is ready and works, but don't kwon how to restrict the execution on the clause "each time the user goes from step1 to step2" because:

- WDDOINIT of step2 is triggered only once, so it works for the first time the user goes from step1 to step2. If the user goes back to step1 and then proceed to step2, the code isn't triggered anymore.

- WDDOMODIFYVIEW of step 2: quite similar as before. Using the FIRST_TIME parameter I can execute correctly the code when the user proceed to step2, but if he goes back and then again to step2 the code isn't triggered anymore.

Outside the IF FIRST_TIME = 'X' condition is not a solution as well, since we'd like the code to be executed only when stepping from step1 to step2.

I guess the solution could be something related to FPM world, but I'm absolutely not an expert of it so I kindly ask for help to you gurus.

Thanks for your support.

[saravanan_narayanan · Accepted solution]

Hello Matteo,

FPM method -> Process Event will be called whenever there is a navigation happening from first step to second step. so here you can do the validation.

BR, Saravanan

[matteo_montalto · Accepted solution]

Hi mates, could you please be more specific and provide - if possible - a sketch of example?

@Baskaran, I've never worked on the component controller, I'll give it a go but I'm a bit scared, it's a standard Webdynpro

For what concerns moving the code to a method which can be called from WDDOINIT or WDDOMODIFYVIEW... I don't get the point; as far as I'm not able to identify when these methods are triggered by a NEXT_STEP pressed from step1, moving the code to another function leaves me the problem.

@Saravanan: question: FPM method -> Process Event is triggered only when passing from step1 to step2 or in other million of applications? I'd like to implement a solution which has a minimalistic impact of standard behaviour.

EDIT:

I'm quite confused about what to do in the component controller... what I'd need to get is an information which show that we're passing from step1 to step2; any other operation (step2->step3, as well as operations on the view like selections/deselections etc.) should not be taken into account.

For what concerns PROCESS_EVENT method in componentcontroller...it is triggered passing from every step to every step and, specifically, passing from step1 to step2 it is triggered 3 times (i've seen it via debug, the std method is... empty).

Edited by: Matteo Montalto on Sep 8, 2011 11:42 AM

[saravanan_narayanan · Accepted solution]

Hello Matteo,

Ideally all the validations are handled in the process event method. This method is provided with two import parameters.

1. io_event which contains a variable mv_event_id which will tell you the event that was fired

2. IT_interface_views - list of interface views.

Using these parameters you further can narrow down to specific event so that your logic wont be executed again and again.

hope this helps.

BR, Saravanan

[matteo_montalto · Accepted solution]

Saravanan, I've seen that PROCESS_EVENT method for componentcontroller; when I pass from step1 to step2, that method is executed 3 times and in each run mv_event_id is set as follows:

1) REFRESH_TOOLBAR

2) RENAME_STEP

3) RENAME_STEP

well, actually I passed from step 1 to step 2 exactly two PR items, that could explain redundancy in 2) and 3).

Anyway... time to go deeper in the specs I guess, as I don't see a path to find a solution using the componentcontroller.

My task is to remove the initial lead selection from the table that contains PR items in step2.

This seemed to be straightforward by removing the initialization of the lead selection from the context node which represents the table (even though this is a custom modification of a standard WD).

However, that did not work as the standard Webdynpro/view itself has been made on the specific assumption that a leadselection ALWAYS exists; it is used to initialize some properties on the table, so if I remove that "Initialization Lead Selection" flag the standard code dumps. So, this cannot be a solution.

However, I've seen that once the lead selection has been set and the screen has been rendered, the user can un-select it via CTRL+left click on the selection column.

I debugged a bit and was able to reproduce via code that behaviour; no more dumps. Here's the code (actually I put it in a post exit of WDDOMODIFYVIEW, when FIRST_TIME = 'X'.. not a solution anyway, as I explained before):

DATA:  lon_soco_workarea           TYPE REF TO if_wd_context_node.
    DATA:  lead_selelement             TYPE REF TO if_wd_context_element.
    DATA:  idx TYPE i.

    lon_soco_workarea = wd_context->get_child_node( name = 'SOCO_WORKAREA' ).
    CALL METHOD lon_soco_workarea->get_lead_selection
      receiving
        element = lead_selelement

    DATA wpr TYPE TABLE OF wdr_event_parameter.
    DATA wpr1 TYPE  wdr_event_parameter_list.
    DATA dref TYPE REF TO data.
    DATA nullref TYPE REF TO data.
    DATA did TYPE REF TO data.
    DATA didx TYPE REF TO data.

* Get element index - redundant, cause it's = wa_item_indexes-index
    CALL METHOD lead_selelement->get_index
      RECEIVING
        my_index = idx.

* Getting reference to DATA generic datatype in order to
* define a custom event parameters for the lead selection
    CREATE DATA dref TYPE REF TO if_wd_context_element.
    GET REFERENCE OF lead_selelement INTO dref.

    CREATE DATA nullref TYPE REF TO if_wd_context_element.

    CREATE DATA did TYPE REF TO string.
    DATA: idstring TYPE string VALUE 'WA_TABLE'.

    GET REFERENCE OF idstring INTO did.

    CREATE DATA didx TYPE REF TO i.
    GET REFERENCE OF idx INTO didx.

* Creation of custom wpr1 event
    DATA wps TYPE wdr_event_parameter.
    DATA newevt TYPE REF TO cl_wd_custom_event.

    wps-name = 'ID'.
    wps-value = did.
    INSERT wps INTO TABLE wpr1.
    CLEAR wps.

    wps-name = 'CONTEXT_ELEMENT'.
    CLEAR wps-value.
    INSERT wps INTO TABLE wpr1.
    CLEAR wps.

    wps-name = 'ROW'.
    wps-value = didx.
    INSERT wps INTO TABLE wpr1.
    CLEAR wps.

    wps-name = 'NEW_ROW_ELEMENT'.
    wps-value = nullref.
    INSERT wps INTO TABLE wpr1.
    CLEAR wps.

    wps-name = 'OLD_ROW_ELEMENT'.
    wps-value = dref.
    INSERT wps INTO TABLE wpr1.
    CLEAR wps.

    CREATE OBJECT newevt             "pass this event to that method.
     EXPORTING
       name = 'REMOVE_SEL'
       parameters = wpr1.

    wd_this->mo_dom_soco_gaf2->/sapsrm/if_cll_do_tree_mapper~handle_lead_select( newevt ).

* for other lead selection related actions
    wd_this->mo_dom_soco_gaf2->additional_act_on_lead_sel( io_wdevent = newevt ).

Problem: this code is related to the view's table management, how could I port such code to the componentcontroller? My guess is it's not possible; I should find a way to execute this code only "every time user switch from step 1 to step 2", maybe I could raise a "sign" from the method PROCESS_EVENT that i could catch in WDDOMODIFYVIEW?

Any help as always's welcome.

[saravanan_narayanan · Accepted solution]

Hello Matteo,

do the following

1. Create a singleton global class and create a boolean attribute to inidicate the navigation from Step 1 to Step 2

(Singleton - constructor is private and Static method should always return the single instance)

2. in the Process_event of the Component controller in Step 1, (if the event is CL_FPM_EVENT=>gc_event_next_step) instantiate this class and set the boolean indicator

(Note - you should do this in the process_event method of the Step 1's Component controller and not the Step 2' Component controller )

3. in the wdmodifyview of the Step 2's view check for this inidcator and perform your logic. Once its done clear the indicator.

Hope I'm clear.

BR, Saravanan

[Former Member · Accepted solution]

hi,

i would not change the node->initialize lead selection property.

You can for example ,set lead selection index to no_selection. See below for example.

lon_soco_workarea->set_lead_selection_index( lon_soco_workarea->no_selection )

[matteo_montalto · Accepted solution]

hi,
> 
> i would not change the node->initialize lead selection property.
> 
> You can for example ,set lead selection index to no_selection. See below for example.
> 
> 
lon_soco_workarea->set_lead_selection_index( lon_soco_workarea->no_selection )

Hi Baskaran,

tried that as first attempt, but did not work, as there's something (standard code) that is going to be executed later than WDDOMODIFYVIEW which requires the lead_selection to be set. I got some dumps, for example because the firstVisibleRow property of the item table is by standard binded to an attribute token from the lead selection.

Anyway, I don't know why, in the same point I used the above posted code (which I had stolen from standard method onActionOnLeadSelect, obviously adapting the event) and... that worked , probably the method additional_act_on_lead_sel( ) did the job.

The problem is now how to trigger that sketch of code once the user passes from step1 to step2. Other operations that will trigger WDDOMODIFYVIEW after that passage should not execute that code.

Thanks for your support!

Edited by: Matteo Montalto on Sep 8, 2011 2:28 PM

[matteo_montalto · Accepted solution]

> 1. Create a singleton global class and create a boolean attribute to inidicate the navigation from Step 1 to Step 2
> (Singleton - constructor is private and Static method should always return the single instance)
> 
> 2. in the Process_event of the Component controller in Step 1, (if the event is CL_FPM_EVENT=>gc_event_next_step) instantiate this class and set the boolean indicator
> (Note - you should do this in the process_event method of the Step 1's Component controller and not the Step 2' Component controller )
> 
> 3. in the wdmodifyview of the Step 2's view check for this inidcator and perform your logic. Once its done clear the indicator.
> 
> Hope I'm clear.

Hello Saravanan and thanks again,

well, the idea is clear and it seems a nice solution... How to do that is instead not that clear , hope you could further help me out with some examples.

In particular, forgive my noobyness, I don't know what a singleton global class is... could you please describe how to create it?

Point 2 and 3 comes of consequence and as far as I understand how to create and manage the singleton global class, that should be easy to implement. Do you think a similar solution could be done via enhancement, without having to modify the standard code?

Thanks again for both the patience and the help.

EDIT: forgot one thing... This method of accessing the indicator made via singleton's class attribute can work when different users are working on the Sourcing Cockpit? In other terms, is that attribute specific for each instance running or is this global for all users?

If so this could lead to problems... or am I wrong?

Edited by: Matteo Montalto on Sep 8, 2011 2:41 PM

[Former Member]

Solution could be to separate the data from presentation: Meaning that the code and business logic can be re-factor to the component controller and not in the view .

If this is not possible then move the code to some method and call the method from wddoinit or wddomodify method. I would move the code and logic to the component controller and share the context to the view.