Basics of ABAP Webdynpro: Getting familiar with Webdynpro jargons part 3

Internal/Context mapping: We can define context node at any of the available controller. However as WD component controller works as a global one, context node defined there is accessible in any other controller. We just have to drag and drop those WD component controller context node to the controller we want them to be used. In that case, if we define any value to this node at WD component level, this value will flow to the other controller where it has been used. And also if we make any changes in that context node in controller where it is mapped, that value will flow to WD component level also.

External/Cross component context mapping: In one of the earlier posts we have seen what component usage is all about. Suppose we are using WDC1 into WDC2 through component usage. Now context mapping between a context node, which is in interface controller of WDC1, and a context node of WDC2 will be known as external mapping. In that case context node data from WDC2 will flow to WDC1.

Hook methods: As soon as you create a WD component, many hook methods will be automatically will be available at WD component level, view level, Window Level. In one of my post, I have very elaborately described about the Hook methods and their order of triggering in normal as well as in special scenarios. To know more ClickHere and Here

Singleton Node: We will understand this with one example. Suppose there is one node which will have sales order header related information. Now this node has another sub/child node which is meant for the item level information. In normal scenario if both of these nodes are normal node, if the parent node has 10 header records, child node will have the item level information of all the 10 sales order.

Now in case the child node is defined as singleton node, this child node will only contain item level information for the sales order which is currently selected. This is huge success in improving the overall application performance.

Supply function: While defining the context node we can give the supply function also. This supply function is meant for providing a value to the context node. Supply function will gets triggered if the data of the context node is being used and its value is either initial or invalid. Context node’s value will be invalid if it’s a singleton node and the lead selection of the parent node has changed. In that case supply function will get triggered and will calculate the new value based on the parent node’s data.

Apart from the ABAP Webdynpro terms I covered in last 3 posts, I have already shared many ABAP Webdynpro related posts in my blogs. While you can go through the blog to find more, here are few links of the important posts.

Using checkbox in ALV Webdynpro with Messaging functionality 

Deploy ABAPWebdynpro application in SAP Enterprise portal 

Default leadselection in ALV in ABAP webdynpro

Disable empty rowscoming in Webdynpro ALV

Dump (System_name :is not a valid attribute type) in starting the Webdynpro Application 

Radio button as a cell editor for a column in Table UI element - Part 1 

Radio button as acell editor for a column in Table UI element - Part 2 

Different types ofwindow creation in Webdynpro

Cell Variant: A wayto use multiple editor in a single table column in webdynpro ALV 

Floor Plan Manager:FPM application using OIF

Use ofIF_FPM_UI_BUILDING_BLOCK interface in FPM and triggering sequence of itsmethods 

I’ll continue posting more basic concepts and exercises in my further post. Till then Happy Learning :)

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 :)