Use of IF_FPM_UI_BUILDING_BLOCK interface in FPM and triggering sequence of its methods

In our earlier post we have create our first FPM OIF application and now we are aware about the terminology of FPM. You must have remembered that while creating the WD component we have re-implemented interface IF_FPM_UI_BUILDING_BLOCK at component level. 

So what is the exact use of this interface? If you remember while creating the component configuration, at one point of time we have given the component name and did F4 and all the windows of that component would come. Where do you think FPM framework gets this information? I mean what is the linkage between FPM application and our WD component. Exactly, you guessed it right. It is this interface. This interface actually brings our standalone WD component within the FPM circle. Of course we have to further give the FPM_OIF_COMPONENT in component field while creating the application.

  

Going further if we look into the interface we can see there are few methods which are present there along with their signature but of course without implementation, because it’s actually the interface and these methods are supposed to be implemented in the WD component where this interface will be re-implemented. Below the methods which are present in this interface.

Because we have implemented this interface in our WD component, if we go in our component and see the methods available at component level, we can find these methods there. Depends on requirement we need to do coding in appropriate method.

FLUSH:  The basic use of this method is for the data transport. This method is the very first method which comes into picture when user does some FPM framework related action. There can be other buttons also, which user has designed in WD component view. If user does some action on those buttons, this will not be considered under FPM framework and methods triggering will take place as explained in one of my earlier post . Instead if user takes some action say suppose in FPM Toolbar buttons, or in case OIF component has been used and user goes to other tab, these actions would be considered in FPM framework and Flush method will get trigger. 

NEEDS_CONFIRMATION: This is used when some sort of user confirmation is required through a pop up box. Depends on the user action, FPM event loop is either continued or cancelled. 

PROCESS_EVENT: This is used whenever we have to implement some after action of one event. We can always check the parameter MV_EVENT_ID to get the actual event name. This parameter we would be getting inside the actual parameter IO_EVENT. Full path is IO_EVENT-> CL_FPM_EVENT->MV_EVENT_ID. By checking what the triggered event is, we can always code what action needs to be taken now.

PROCESS_BEFORE_OUTPUT: This is used just before the final display of screen. Even  for the first time when we run the application, along with the other hook methods, this method also comes into existence.

AFTER_FAILED_EVENT: This method is called whenever any event could not be completed successfully due to any reason. Accordingly parameter IV_REVERT contains the value.

 

Our next target is to see the actual triggering order in which these methods, along with the other hook methods take place. Below are some scenarios. For the convenience we will only consider the hook methods at the component level.

1.  When application is launched.
            WDDOINIT
            PROCESS_BEFORE_OUTPUT
            WDDOBEFORENAVIGATION
            WDDOPOSTPROCESSING
2.  On some action which is specific to WD component and does not come under FPM event loop.
            < Action handler method of that button>
             WDDOBEFORENAVIGATION
             WDDOPOSTPROCESSING
3.  On some action which comes under FPM event loop like Save, Tab change.
             FLUSH
             NEEDS_CONFIRMATION
             PROCESS_EVENT
             PROCESS_BEFORE_OUTPUT
             WDDOBEFORENAVIGATION
             WDDOPOSTPROCESSING

                    

              Happy Learning :)

Floor Plan Manager: FPM application using OIF

Prerequisite: Basic understating of ABAP Webdynpro component, views, windows.

If you have the basic understanding of ABAP WD and have created few WD applications on your own, I am sure Floor plan manager (FPM) would be in your next hit list. So I’ll start with what is FPM, what it’s use is, what are the different options available under FPM and then at last we will create one application using one of those options.

In simple words FPM is a kind of wrapper we use above our WD application so that the application look uniform in UI and bear a consistency throughout the application.  FPM can be of different types. Below are listed available types.

Object Instance Floorplan (OIF): Standard component is FPM_OIF_COMPONENT

Overview Page Floorplan (OVP): Standard component is FPM_OVP_COMPONENT 
Guided Activity Floorplan (GAF): Standard component is FPM_GAF_COMPONENT

Quick Activity Floorplan (QAF): This is kind of subset of OIF so standard component will be same

Below mentioned are the rough steps which we follow while creating the FPM application.

1. Till creation of WD component our work will remain same. The only difference is at component level, we have to implement the WD component interface named IF_FPM_UI_BUILDING_BLOCK.
2. After that while creating the application we give the respective standard component’s name in component field and corresponding interface view and plug name also.
3.  We create configuration of the WD application, which will lead us to a web page of Webdynpro ABAP Application Configuration. At this point of time it’s very crucial to understand the concept of Application Configuration and Component Configuration. As the name suggests application configuration is meant for WD application and component configuration is meant for WD component. What is the basic difference between these two, we will cover in a later post. As of now we have to create an application configuration for the WD application. We have to give a configuration id for this application configuration. Once we create this configuration id we will see a screen which tells us about the component which we have given while creating the WD application. And now for this component we have to create a component configuration, where we can give the different view of different WD component we would like to have in different tabs. It may sound all clutter up, but have patience. It’s just a matter of doing a practical.

So we will create one WD application with 4 views, 2 windows where each window will host the 2 view out of 4 and we will create plugs so that we can come back and forth with a window’s view. Now we will make a FPM application. For simplicity, we will only have one text displayed in each view.  In Implemented Interface tab we will re-implement the component named IF_FPM_UI_BUILDING_BLOCK.

Create a WD application. As soon as window for application comes, it automatically has the component name for which we are creating the application in component field. We have to remove it and give entries like in screen shot.

Go to the application, right click on it and choose the below path.

 

A web page will get opened like below and it will have the application name. Beside is the field where we have to give the application configuration id. You can see this page is meant for application configuration. If we create component configuration the title of the page will read component configuration instead of application configuration. Give the name for configuration id.

  

 Click on create.

Once you click OK below screen will come. First column will tell us the WD application name. Second column will give us the name of the component which we have given in component field while creating the application. Had we not changed it to FPM_OIF_COMPONENT, it would have come as our component name. The last column is blank which is where we have to put the Component configuration name, and guess what. This component configuration would be for which component. This would not be for our component but for FPM_OIF_COMPONENT. So we will give a name there.

And as soon as we will save it “Go To Component Configuration” button will get active.

A warning is coming. Let it come, we care only about errors :). So click on newly activated button.  IT will take you to the Component configuration screen, and you can clearly see for which component we are creating the configuration. Click on create.

Once you click on OK, below screen will come which will actually be the layout when will test our application. So we have to now design this screen as per our requirement.

  

One main view and inside that one sub view comes by default. Inside that sub view one UIBB will come, which will actually host the windows of the component. We can see that when we click on UIBB, we get fields to gibve the name of the component and the view name. This view here in UIBB is actually the window in WD component. If you give the component name and do F4 in view field, you will get all the windows which are there in WD component.  In right side you have buttons to add many more main views, sub views, UIBBs and all. Main view represents the tab, sub view represents the sub tab, and UIBB represents the window of WD component. We will add one more main view to it (because we have 2 windows in our WD component) and one sub view will come automatically to it.

If you click on main view and sub view, you can see there are options to change the name, index and all. There will also be the delete button to delete that element.

So we will give the component name and view name like below.

 

Click on Save.

Now as we are done with the creation of application and component configuration, we can see two new options for the same would be coming in SE80 in left side panel.

Right click on application configuration and do test. Below screen will get open in browser.

You can navigate to the other views and can come back. Go to the second tab and you will see another view there and can navigate further.

Happy Learning :)