Need expertice opinion on WebDynpro ABAP vs FPM for heavy custom apps

[Former Member]

Hi Experts,

I have a lot of custom UI development,.for external users in SAP. Most of these applications can be simply developed using WebDynpro ABAP framework. If I do the same development using FPM framework I may need to do lot of reaseach espcially controling the UI behaviours like hiding, changing table cell  colors based on the data, manipulating the UI behavior in the runtime, lot more like this.

The question I have is , which one is the right tool for my development FPM vs WebDynpro ABAP, what is the value in building the same apps in FPM rather then WebDynpro ABAP? If I develop these apps in WebDynpro ABAP does my client loose any new capabilities in he future releases? are any other drawbacks?

The challenge i see the FPM Feeder classses doesnt have lot of interfaces other then few like ( IF_FPM_GUIBB_FORM, IF_FPM_GUIBB_FORM_REPEATER,IF_FPM_GUIBB_LIST,IF_FPM_GUIBB_SEARCH,IF_FPM_GUIBB_TREE,IF_FPM_GUIBB_LAUNCHPAD )

to extend more custom UI functionalities, and the other thing I may need to invest lot of time in reseacrhing and analysing the framework events etc....Please can you shed some light on it and put me in right direction.

Appreciate your time and help.

Thanks

Krishna

[Former Member]

Hello Krishna,

the whole story revolves around reusability and abstraction, extensibility atleast in this context.

FPM offers more abstraction than Webdynpro. i am sure we all appreciate the standard webdynpro components for ALV, Value help, as this is something we could reuse and if we build our components that it manipulates itself with the help of configuration, customization and personalization.

So all the Standard SAP Dev could be enhanced (not modified) by simple, configuration, FPM is built around this concept.

So if you want to do custom development, which could be extended for your different customers with minimal efforts, you could go for FPM.

So here are some takeaways

1) FPM offers more abstraction than Webdynpro

2) FPM offers more reusability

3) Say manipulating the UI behaviour and say some customers wants view1 first and other doesnt want view 1 and wants only view 2. so in FPM you could simply do it with different configuration. and with Webdynpro, you need to manage this dynamically based on certain application parameter or you may end up copying certain comp,,or you use different usage,,,,and you could calibrate this.

Regarding limitation with FPM interfaces, could you explictly share what custom development you intend to do and in worst cases, you could always use freestyle UIBB,, which is webdynpro abap

in that scenario, atleast wiring, application config(app parameter, combination of webdynpro, with thier respective config),,could be reused.

Regards

Anurag Chopra

[frank_ruggaber]

Hello Krishna,

as we've developed many "core" Web Dynpro applications and many FPM applications in our team I could summarize our experience in this area as follows:

• FPM is overall much faster in the UI-development compared to "core" Web Dynpro
• the fewer interfaces the better - everyone knows where to search for e.g. processing the events => method porcess_event
• where the FPM-GUIBBs don't fit you could always use the so called "freestyle UIBB", which is a "core" Web Dynpro component
• the standard functions provided by FPM simplify the applications => e.g. switching between read and edit mode

We in our team decided to use FPM in every new development. By the way: you shouldn't use the OIF-Floorplan anymore, because new development will be made in the OVP.

Hope I could help a bit.

Regards

Frank