cancel
Showing results for 
Search instead for 
Did you mean: 

How to do FPM Navigation from custom FPM Screen to MDG BOL FPM Detail Screen?

andreas_morf2
Explorer

Hi experts

I have the situation that I want to open a MDG BOL FPM detail screen from another custom FPM screen. Normally this functionality is easily done e.g. from a search screen with an object result list (USMD_SEARCH_RESULT_TEMPLATE), where a click on a certain object then opens the detail screen with the correct data in it (including all data in the linked UIBBs). The search screen has a wiring with a connector (CL_FPM_CONNECTOR_BOL_IDENTITY) and thus loads with a click the correct data in the detail screen.

Now if I want to achieve the exact same functionality via a custom FPM screen (not in the MDG domain with BOL). I already managed to open the detail screen and I have rewritten the feeder class (CL_MDG_BS_GUIBB_FORM) such that I read out URL parameters and load dynamically the data from the generated MDG table. However like this only the main UIBB data is refreshed and all associated UIBBs in the FPM OVP are still empty and unchanged. If I use the super->IF_FPM_GUIBB~GET_DATA method then only the first table element of the generic MDG table is loaded (together with the data for the associated UIBBs) and not the one that I pass via a URL parameter.

Is there a way how to pass in the FPM Navigation the ID of the MDG BOL entity to be loaded in the detail screen (mimic of the search screen => detail screen link)? Is it possible to set the correct entity to be loaded in the feeder class? Can you suggest on how to solve this problem or point to other blogs or answers available?

Accepted Solutions (1)

Accepted Solutions (1)

andreas_morf2
Explorer

I found the answer to the problem myself:

The class CL_USMD_CONNECTOR_BOL_QRY is responsible for handling all the connector related activities of a BOL entity. With some debugging I figured out that in the redefined DERIVE method, the initialization coding loops over the generic BOL entity field names and tries to extract them from the URL parameters. Hence if you have a BOL entity called ABC with an id field called ABC then in the generic table /1MD/MD____XYZ this field is represented by MDG as /1MD/DMABC where DM is the 2-char acronym of the data model. The loop over the BOL entity fields thus tries to read a URL parameter ABC and if you correctly pass this value as URL parameter, then the query service in the connector sets the correct entity via the interface IF_BOL_BO_PROPERTY_ACCESS~SET_PROPERTY ( iv_attr_name = ... iv_value = ... ). This seems to be working as a valid call from a non-MDG FPM Screen onto a MDG Detail View Screen and it opens the correct BOL entity together with its attached sub-level entities (type 4 entities). The standard Change Request workflow can also be triggered from the passed BOL entity and all the "usual" MDG functionality works well.

0 Kudos

Hi Andreas,

Thanks for the solution. It is very informative.

Thank you.

Answers (0)