add UIBB in OVERRIDE_EVENT_OIF

[joerg_arndt]

Hi Friends,

I have a FPM with a coupla of Mainviews, Subviews and UIBB's.

When I start the application, in componentcontroller  of webdynpro component I use OVERRIDE_EVENT_OIF to add a new UIBB.

It works for the first time. It's proceeding GET_DEFAULT_CONFIG, GET_DEFINITION and GET_DATA.

Now I have a button and when I press this button I come to the  OVERRIDE_EVENT_OIF again.

There I remove the UIBB with io_oif->REMOVE_UIBB and I add a new one with io_oif->ADD_UIBB and

the same parameters.

But this time it only passes the GET_DATA method and it does not pass the GET_DEFAULT_CONFIG, GET_DEFINITION methodes.

It seems there is still something left.

Is there a way to go through the methods GET_DEFAULT_CONFIG, GET_DEFINITION again?

Thanks for help.

Rg. Joerg

[former_member193369 · Accepted solution]

Hello Jörg,

FPM only creates one component instance per UIBB Instance key, which is defined by structure FPM_S_UIBB_INSTANCE_KEY. If you remove a component via IO_OIF->REMOVE_UIBB, it is only removed from the View assembly - the component isn't destroyed. After adding it again the same instance will be reused and therefore it will not be instanciated again.

The best way to circumvent this behaviour depends on your basis release:

• Starting with 7.03/7.31 SP5 there is the concept of dynamic configurations for (G)UIBBs in FPM. Basically this works by adding the interface IF_FPM_GUIBB_DYNAMIC_CONFIG to your feeder class and returning ABAP_TRUE from it's only method. Then at runtime it's possible to enforce the re-instantiation by raising the FPM event IF_FPM_CONSTANTS=>GC_EVENT-INVALIDATE_UIBB and passing the list of UIBBs to be reinstantiated as event parameter  IF_FPM_CONSTANTS=>GC_EVENT-LIST_OF_INSTANCES (of type FPM_T_COMPONENT_INSTANCE_KEY).
• For 7.02 ff. there is the option to provide a new instance ID when re-adding the UIBB. This way you will get a new instance of your UIBB and GET_DEFAULT_CONFIG and GET_DEFINITION will be called again (but be aware that the old instance won't be destroyed, so whenever you add a UIBB with a new instance ID memory consumption will increase)

Please be aware that although you get a new UIBB instance only the WebDynpro component is reinstantiated. This will cause new calls to GET_DEFAULT_CONFIG and GET_DEFINITION. Nevertheless the feeder won't be reinstantiated as feeder instances are shared between all GUIBBs using the same class with the same parameter set (as long as wiring isn't used).

Best regards,

  Christian

[joerg_arndt · Accepted solution]

Thanks Christian,

the IF_FPM_GUIBB_DYNAMIC_CONFIG I do not have.

It looks like, dynamic programming in FPM is getting better in the future.

To point 2.

How can I provide or create a new instance?

With create object?

Thanks Joerg

[former_member193369 · Accepted solution]

Hello Jörg,

creating a new instance is quite simple. When calling IO_OIF->ADD_UIBB parameter IS_UIBB_KEY has a field INSTANCE_ID. Just provide there a different value as the UIBB you removed had and that's it. For example if the initial UIBB had INSTANCE_ID = space then use INSTANCE_ID = 1.

If you want to repeat the procedure use INSTANCE_ID = 2, ...

Best regards,

   Christian

[joerg_arndt · Accepted solution]

Thanks Christian,

from here I can go further.

RG. Joerg

[Former Member · Accepted solution]

Hello Christian,

Kindly let me know which feeder class we need to implement interface "IF_FPM_GUIBB_DYNAMIC_CONFIG".

Can we use this interface in wd component or assistance class?

Thanks

Pradeep

[former_member193369 · Accepted solution]

Hello Pradeep,
this interface is meant to be implemented in feeder classes for Generic UIBBs (GUIBBs) such as the List UIBB or the form UIBB, where the WD component is provided by the FPM framework, while the application provides only a feeder class. If you are using a freestyle UIBB, you can re-instantiate it using the same mechanism (by raising event IF_FPM_CONSTANTS=>GC_EVENT-INVALIDATE_UIBB) but there is no need to implement this interface (as there is no such thing as a feeder class).

This interface is only necessary to inform the framework that this feeder class is using a dynamic configuration (the interface's signature is quite small). The configuration editor then offers only very limited configuration options and at runtime FPM takes care that feeder method GET_DEFAULT_CONFIG is called at the appropriate point in time.

Best regards,

  Christian