Choosing when to use GUIBBs over embedded UIBBs - design considerations

[former_member182500]

Hi folks,

Just wondering what your design considerations are when configuring the layout of a sub view of a component, in particular the moment when you decide whether to develop and assign your own custom developed view/window from your own WD4A component to your sub view UIBB, or you choose to implement a GUIBB.

Do you see any advantages of implementing a GUIBB, for example FPM_OIF_FORM, over developing your own web dynpro form layout and assigning to a UIBB in your sub view. Do you for example see added value an implemented feeder class brings. Or perhaps do you see too many limitations and restrictions in layout design using an implemented GUIBB - for example limited nunber of columns available to a form or alignment restrictions between form label and form field?

From my own experience I have been looking today at new WD4A applications delivered by SAP in PLM ECC6 EhP5, and although of course I can use the FPM to customise the configuration and choose when adding a new tab to apply custom UIBBs or implement GUIBBs, I note that SAP in a particular transaction (recipe creation) has developed UIBBs and assigned to the sub views - they did not utilise GUIBBs, even for simple forms with less than 20 fields.

I'd be interested in anyone's design/development experience in choosing between the two available options.

Cheers,

JP.

[Former Member · Accepted solution]

Hi Jp,

Last year we began to explore the possibilities of FPM itself . We are delivering Standard products to our customers, out thought were like this.

GUIBB is useful in case of customizing our products suiting to customers need at customer site with the help of our consultants.

UIBB - Flexibility to develop with Webdynpro for ABAP using FM's,OO classes etc. We have more existing FM's which we would like to reuse.

Since we are developping standard products our main focus turned to free style UIBB. We decided to do little Generic functions in GUIBB such a way that they can be easily customized to our customers need.

In our opinion feeder class utilize much of the RTTI and greatly replaces the Webdynpro component controller . Gives me impression that it runs faster than the same application with WDA( just my theory.. i have no metrics on that ).

[former_member182148]

Hi Jon-Paul,

using GUIBBs allows you to provide a harmonized look and feel. You don't need to care about layouting, spacing and so on. Also you are already taking care of certain product standards like accessibility.

How much this matters to you, depends of course on the target audience of what you develop. If it is just a small custom application, for a limited user base, this is maybe not a big issue. If you develop standard software, GUIBBs are probably worth considering.

Don't forget also that GUIBBs support enhancement concepts, to adapt them to specific customers.

I find it personally easier to develop GUIBBs, since you don't need to deal with WD components. The tool support is better for ABAP classes than for WD Components.

I don't have much choice, since I develop standard software which has to follow certain standards, but even if you are not, I would probably recommend to have a look at GUIBBs.

Regards

Bruno

[former_member182500]

I'm certainly interested in consistency of interface across an application. If I'm to implement a new tab (main view in OIF) within a SAP standard application, I want the same look/feel, so it's familiar to the user.

Here's some food for thought, I quote directly from the FPM Cookbook available on the net:

"The WD ABAP Floorplan Manager is up to now a framework which composes application-specific views (UIBBs) to form an application. This ensures homogenous high-level application structuring and interaction behaviour"

OK, so far so good in relation to consistency of frameworking structure. Onto design layout, I quote further from the same:

"However, as the UIBBs which typically comprise the major part of the screen are built using WD ABAP free-style there is still a lot of opportunities for inhomogeneous layout and interaction design. ..... generic UI Building Blocks (GUIBBs) now addresses this issue. GUIBBs are UIBBs that are delivered centrally, where the application only provides the data and a layout configuration. The rendering is done by the GUIBB. generic UI Building blocks provide a comprehensive way of creating or changing user interface compostitions such as forms and list components, without requiring changes to the underlying application code base and thereby offering a concept for modification free customer UI enhancements".

You do however still have to code the feeder class methods, but I do like the "plug in" service feel of it (similiar to generic services in HR P&F).

I do find it strange that some SAP std apps I've looked at still use the freestyle WD component UIBB method, rather than them configuraing GUIBBs themselves, for simple forms.

I think I'll take the approach that GUIBBs will be my standard mechanism unless complexity demands a freer more liberal design tool and thereofre use UIBBs.

Thanks for your comments guys, appreciated.

[former_member182148]

I do find it strange that some SAP std apps I've looked at still use the freestyle WD component UIBB method, rather than them configuraing GUIBBs themselves, for simple forms. 

Hi Jon,

I do not know the reasons for this. Something might not have worked as needed back than or somebody decided that it MUST look in a certain way or MUST offer some feature, which is not supported by FPM. I do not know the reasons, but for example in our area we have a pretty strict architerural guideline which requires the use of GUIBBs. Every other UIBB needs special approval.

Another thing to consider: Feeder classes have feeder parameters. So depending on what you need to do, you don't need one feeder per GUIBB. Many times you can use the same feeder class and configure it to access a certain business object, database table or whatever. Our ideal approach is to use only one feeder class. In practice it does not work always and we have to extend it, but the base logic is always the same.

Regards

Bruno

[former_member182500]

Hey Bruno,

Very interesting regards your strict architectural guidelines, and generic single feeder class for multiple GUIBBs.

Points awared to both you and Baskaran for your contributions to this, thank-you!

[former_member182500]

Hey Bruno,

Very interesting regards your strict architectural guidelines, and generic single feeder class for multiple GUIBBs.

Points awared to both you and Baskaran for your contributions to this, thank-you!

[former_member182500]

Bruno,

It was an interesting point you coveered regarding a more generic feeder class for multiple FPM GUIBBs, which of course makes sense.

Lets say we have implemented an OIF, with several GUIBBs on the same sub view. You want the same feeder class to supply catalog and runtime data information for all GUIBBs. I imagine you implement interface GET_PARAMETER_LIST to define your several GUIBBS, so that at configuration time the supplied field catalog with your field list only shows the fields relevant for your specific GUIBB. This would be set up in method INITIALISE and further amended in method GET_DEFINITION (as your FPM component is unknown at config time, so if we dont use parameetrs how else would we configure the field list specifically for the GUIBB when you configure the field group at design time?).

Just trying to make the class architecture more refined so we do not develop a feeder class for each GUIBB.

Cheers,

JP.

[former_member182500]

I have been speaking with SAP AG FPM guys and within my own organisation.

So far I have come up with the beginnings of a decision matrix for deciding between the two options:

GUIBBs

Consistency - UI guideline compliant

ABAP OO skills required

More FPM skills

Little WD4A skills

Performance - render configuration on the fly

More restrictive on layout

Limited to a set of GUIBBs (form, list, tree, tab, search)

UIBBs

Freestyle - Developer will not necessarily follow UI guideline compliance

Less FPM skills

More WD4A skills

Performance - pre-compiled objects

Less restrictive on layout

Need to implement IF_FPM_UI_BUILDING_BLOCK to hook into FPM framework loop

Any comments on the above?

[Former Member]

Hi JP

We have a very interesting thread here. I would like to know the path that you decided on for designing the application architecture.

We are leaning towards FPM based apps going forward. I would like to incorporate best practices/learnings from others who have already done so.

Thanks,

Puja