Using component configuration in FPM stops cross-component context sharing

[ChrisPaine]

Hello,

Has anyone come across this before - and have a solution?

I have an FPM GAF app. I use the IF_FPM_GAF_CONF_EXIT interface in one component to control the overall flow of the app.

This has links to the contexts of one of the components use in the FPM app. this component (Component A) is a IF_FPM_SHARED_DATA component.

in the "vanilla" FPM app I use this to read a specific context attribute from this component - it reads it fine.

in another version I use the same display component, same controller component, but within the GAF config I select a different component configuration for the component A. (I do this to simply change a text of the component).

When I do this I no longer get access to the same context within the controller component. but a different instance.

It seems that the instance of component A that my controller component is binds to and the instance that is created by the FPM are different when I use a configuration ID in the FPM config.

Perhaps this is why these shared data components should be faceless! The FPM doesn't handle the sharing of the instances well if it has to recreate the instance with a new configuration id.

I know I'd not have the same issue if I shared data using a singleton class - please don't suggest that!

I'm going to try creating a faceless component to share the data - although that seems like a needless abstraction to me. But at least it means I should be able to use the component configuration.

If you have any ideas, please let me know.

Cheers,

Chris

[Former Member]

Hallo Chris,

I am not entirely sure about your problem. I have done some thing like this .See if it suits to your case.

• Usually the FPM takes care of instanciating and attaching the shared

• data component automatically. But in this case it is necessary to attach

• it manually. The reason for this is that later within this method it is necessary

• to access node data of the shared data component (e. g. node progress). By accessing data of the

• shared data component, the WD runtime checks whether an instance of the

• SD component already exists. The point is that in that point of time, the FPM

• runtime did not create an instance and therefore the WD runtime creates an

• instance of it. But at a later point of the time the FPM creates automatically

• an instance of the SD and attaches is to the usage. Therefore two instances

• of the SD would exist. This is why here an instance of the SD is created and

• attached to the usage. Later the FPM will check wether and instance was already

• created and attached to the usage and if yes will not create a second instance of it.

• So we let the FPM do it, before the WD runtime does it. If you don't need access

• to the SD compoment during startup-methods (such as WDDOINIT) you don't need to do this.

data lo_componentinterface type ref to if_wd_component_usage.
  lo_componentinterface = wd_this->wd_cpuse_usage_vh_persoon( ).
  call method wd_this->go_fpm->attach_component_to_usage
    exporting
      iv_component_name  = 'ZMOCK_IZRM_ZOEKEN'
      io_component_usage = lo_componentinterface.