FPM CHIP Integration

CHIPs (Collaborative Human Interface Part) are created using the Web Dynpro ABAP Page Builder framework. A CHIP is an encapsulated, stateful piece of software used to provide functions in collaboration with other CHIPs in a Page Builder page or side panel. Single FPM GUIBBs can be displayed inside a CHIP.

In principle, an FPM floorplan component can be used as a CHIP; the wrapper component FPM_CHIP implements the CHIP interface, and the OVP component directly implements it. However, this is not recommended since a full floorplan UI is usually too large to be displayed inside a CHIP. However, there is a need for displaying single GUIBBs inside a CHIP, for example, a Form UIBB. For this purpose, FPM offers a single UIBB floorplan, the UIBB CHIP Wrapper Component, FPM_UCW_COMPONENT.

For more information on CHIPs, search for Creating Mashups with the Page Builder in the SAP Help Portal.

Structure of the UIBB CHIP Wrapper Component

The UCW displays only a single UIBB, without an Identification Region (IDR) or a page header.

However, it is permitted to assign nested (composite) UIBBs to the UCW (for example, a Composite UIBB, a Tabbed UIBB, or a Search UIBB (which can embed a Results List UIBB). The configuration is rather simple, and must be maintained with the WD ABAP default configuration editor.

Multi-Instantiability

As there may be several FPM-based CHIPs on a page, it must be possible to run multiple FPM instances in parallel. In this case, the FPM factory to access the central FPM instance (reference to IF_FPM) can no longer be used.

To achieve multi-instantiability, FPM offers the interface IF_FPM_MULTI_INSTANTIABLE, both on WD ABAP and ABAP OO level. The interfaces have a method FPM_INITIALIZE which passes the local FPM instance. With the other method, FPM_IS_MULTI_INSTANTIABLE, an FPM object can declare itself as being multi-instantiable with a Boolean return value. An FPM object that returns a TRUE value commits itself to obey the following rules:

Only the local FPM instance (IF_FPM) passed in FPM_INITIALIZE must be accessed. CL_FPM_FACTORY=>GET_INSTANCE must not be accessed except for a simple determination between runtime and design time.
The methods of CL_FPM_SERVICE_MANAGER are always called with the local FPM instance.
Method CL_FPM_UIBB_API_FACTORY is always called with the local FPM instance
Instances of CL_FPM_LPD_PROVIDER are always created with the local FPM instance.
The application logic itself must compatibly run with parallel FPM instances. (Example: If FPM application objects use the same singleton pattern to access shared transactional data, they should not declare themselves as being multi-instantiable.)

An entire FPM instance is multi-instantiable as long as all its instantiated FPM application-specific objects (that is, application controllers, freestyle UIBBs, GUIBB feeder classes, wire model connector classes and wire model transaction handlers) declare themselves as being multi-instantiable too. GUIBBs are multi-instantiable if, and only if, their feeder classes are multi-instantiable too. If there is more than one non multi-instantiable FPM instance in one roll area, the FPM runtime raises a short dump.

To avoid conflicts due to multi-instantiation, it is recommended that new developments ensure multi-instantiation of FPM objects by implementing IF_FPM_MULTI_INSTANTIABLE, accessing solely the FPM instance passed in method FPM_INITIALIZE, and returning a TRUE value in FPM_IS_MULTI_INSTANTIABLE. In particular, it is strongly recommended that UIBBs and feeder classes developed for usage in the UCW be multi-instantiable.

Communication between FPM CHIPs

UIBBs and GUIBB feeder classes can optionally implement the WD interfaces IF_FPM_CHIP, and IF_FPM_CHIP_FEEDER respectively. Using the Web Dynpro CHIP API passed in method FPM_CHIP_DO_INIT and CHIP_ INIT, it is possible to add dynamic inports. Inport events are communicated in the UCW through the FPM event FPM_HANDLE_CHIP_INPORT, and the CHIP port event object is attached as the event parameter with the key FPM_CHIP_PORT_EVENT.

Note

CHIP inport event-handling is processed after the Web Dynpro before-navigation phase, that is, the latest phase where FPM can execute its dynamic navigation. As a consequence, it is not possible to invalidate the navigation in the event loop triggered by FPM_HANDLE_CHIP_INPORT. For example, it is not possible to trigger the invalidation of dynamic UIBBs, or to exchange UIBBs or tab-strips by the configuration controller of a Tabbed UIBB.

Tagging in FPM GUIBBs

UIBBs can be a tagging source, no matter whether they are embedded in a CHIP or whether they are part of the canvas application. For Web Dynpro components, this can be done by the standard Web Dynpro context tagging. Since GUIBB feeder classes do not have access to the Web Dynpro context, the tagging can be defined in the field descriptions provided in the feeder interface method GET_DEFINITION. Here a tag can be assigned to any field through the field description component TAG_NAME. If the feeder class has assigned a tag to a field, the tagging needs to be activated in the GUIBB configuration. This is done through an activation checkbox (Tag is Active) in the field’s attributes in the Attributes panel in the FPM configuration editor, FLUID.