Introduction

The purpose of a wire is to transfer data from one UIBB to another UIBB. It also defines the parent child relationship of all the UIBBs and ensures a PROCESS_BEFORE_OUTPUT sequence according to this hierarchy.
For the GUIBBs the only thing the application has to do is to create the wires in the Floorplan configuration.
With the freestyle UIBBs in addition to the configuration also a small coding is needed.

The wire feeder models are the access point of the UIBBs for setting the own data and for retrieving the parent data.
For each UIBB instance there is one wire feeder model instance.
The models are linked via connectors.
The parent model fills the connector with data on request (pull) and the corresponding child model collects that data.
Some connectors (like the URL connector) do not have a feeder model as data source, but an external data source.
Both, the wire feeder model classes, as well as the connector classes are implemented by the FPM SPI Integration (FSI) and can be used by the application.

Dos and Don'ts

Creating Wires

Wires can be created in the Floorplan configuration.
A wire consists of the following data:

• UIBB Instance key of the child that should be supplied with IDs
• UIBB Instance key of the parent that should be used as data source
• Port information (Port Identifier & Port Type)
• Connector information (class name and parameters)

Port

The port identifier determines which outbound port of the parent UIBB wire model should be used by the wire.
Since a GUIBB always belongs to exactly one node it also has only one port.
Freestyle UIBBs can have multiple context nodes and therefore also multiple ports.
So the corresponding context node names should be used as port names to get a generally understandable port name.

The port type defines the selection of records that will be passed through the wire.
There are the following port types:

• Lead Selection
• Selection
• Collection (entire content of the context/data table)

Connector

There are four standard connectors that can be used:

• /PLMU/CL_FRW_W_CONN_DEFAULT:
  The default connector must be taken to connect from a child UIBB to a parent UIBB.
• /PLMU/CL_FRW_W_CONN_URL:
  The URL class must be taken to pick up the URL data with the GET_INPORT_DATA method of the wire model interface.
• /PLMU/CL_FRW_W_CONN_EMPTY:
  The empty connector can be used, to explicitly express that a certain UIBB does not have any input wire data. It might be needed to overrule the automatic wiring, if it is used.
• /PLMU/CL_FRW_W_CONN_HEADER:
  The header connector reads the header data that is exposed by the application by implementing the interfaces /PLMU/WDI_FRW_MAP_HEADER or /PLMU/IF_FRW_MAP_HEADER, which is also used by the navigation logic of the FSI.

There is also one intertwining connector which can be used between a FSI UIBB and a BOL UIBB:

• /PLMU/CL_FRW_W_CONN_TO_BOL:
  This connector is used to connect a parent FSI UIBB with a child BOL UIBB.

Some of the connectors have specific parameters which are explained in the following part.

Connector Parameter – Filter Mode

Do not filter (Default):
In almost all cases there exists a 1 to 1 or 1 to N cardinality between the records of the parent and the child UIBB – then the default shall not be changed since this would reduce the performance!

Filter duplicates:
If an N to 1 cardinality exists between the records of the parent and the child UIBB (which is only the case in very special scenarios) the duplicate filter needs to be set.
The connector will then filter all duplicates that are passed through the wire without changing the sort order.

Connector Parameter – Mapping Class

Per default the provided structure of the wire target will be filled with the data of the wire source via MOVE-CORRESPONDING.
So this will work as long as the requested fields of the source structure have the same names as the respective fields of the target structure.

For more complex use-cases where the normal MOVE-CORRESPONDING doesn't work, we offer the mapping class /PLMU/CL_FRW_W_MAP_PARAMETERS which uses internally our Parameter Mapping that is also used in various other places where some kind of structure mapping is needed (e.g. navigation).

This means, parameters are extracted out of the source structure and these parameters are then mapped back into the target's structure.
The parameter mapping serves two purposes here:

1. If the names of the fields to be mapped are not identically in the source and target structure, the parameter mapping is able of filling the target structure.
2. If the target has no static structure – means the target can handle various structure formats. E.g. an Access Control UIBB might be capable to handle various object types. Here a mapping by MOVE-CORRESPONDING won't work, because the node ID structure is not static – it depends on the current GOS object type. In such cases, the source's data can be gathered by the child UIBB as parameters. The child UIBB simply uses a table of type /PLMB/T_FRW_PARAMETER_SET during the call to the GET_INPORT_DATA method.

It is recommended to use the Parameter Mapping whenever a mapping is needed during the wiring.
This increases the reusability of the UIBBs drastically.
However it is also possible to use an application specific mapping class that needs to implement the interface /PLMU/IF_FRW_W_MAP, which offers one simple method called MAP_DATA with the following parameters:

Wiring Tabbed Components

To link UIBBs to a tabbed component, the wire plug must be filled in that tabbed component.
This wire plug is the single entry point to a tabbed component. The wiring of the individual tabbed component UIBBs takes place within the tabbed component configuration (not in the Floorplan configuration!). That way, the tabbed component represents an encapsulated object with a defined signature.

Wire Communication

In a GUIBB environment the generic feeder class already handles the getting and setting of the wire data, so that the application developer only needs to define the wires in the configuration to make the wiring work.

When building an own Web Dynpro component i.e. a freestyle UIBB, the application developer not only has to define the wires within the configuration but also has to add some logic to its Web Dynpro component to make the wiring work.
It is mandatory for any freestyle UIBB Web Dynpro component to implement the interface IF_FPM_UIBB_MODEL which will add method GET_MODEL_API to the component controller.
This method needs to return a wire feeder model that can be picked up from the factory class /PLMU/CL_FRW_FACTORY.
An implementation of method GET_MODEL_API could look like the following:

IF wd_this->mo_feeder_model IS INITIAL.
  "Create wire feeder model.
  wd_this->mo_feeder_model = /plmu/cl_frw_factory=>get_wire_model_wd(
    iv_abbid                = 'MY_ABBID'
    io_component_controller = wd_this ).
ENDIF.

"Return wire feeder model.
ro_feeder_model = wd_this->mo_feeder_model.

Inbound

To read data from the wire, the Wire Feeder Model needs to be used.
In the GUIBB environment a basic interface of the wire feeder model (/PLMU/IF_FRW_W_MODEL_BASIC) can be obtained directly within the feeder class using method GET_WIRE_MODEL.
For the freestyle UIBBs a more powerful Wire Feeder Model (/PLMU/IF_FRW_W_MODEL_ACCESS), which includes the basic model, can be created via method GET_WIRE_MODEL_WD of class /PLMU/CL_FRW_FACTORY.
For the inbound communication however only the methods of the basic Wire Feeder Model (/PLMU/IF_FRW_W_MODEL_BASIC) are relevant, which are the following:

GET_INPORT_DATA

This method allows reading data from the wire.

Method signature:

When no port type is specified the one set in the configuration is being used, so this parameter can overrule the configured value, which should only be done in very special cases.
The data type of ET_DATA doesn't need to match the source data structure (which is normally a parent UIBB). The provided table will be filled via MOVE-CORRESPONDING.
So when calling this method it is strongly recommended to only request the key information (node ID) that is needed for reading the own data, as shown in the code-snipped below:

DATA:
  lt_node_id               TYPE           my_node_id_table_type.

TRY.
    "Get node ID for retrieve from the wire.
    mo_wire_feeder_model->get_inport_data(
      IMPORTING et_data = lt_node_id ).
  CATCH /plmu/cx_frw_wire.
    CLEAR lt_node_id.
ENDTRY.

"Retrieve the data.
mo_application_model->retrieve(
  EXPORTING iv_node_name        = 'MY_PARENT_NODE_NAME'
            iv_target_node_name = 'MY_NODE_NAME'
            it_node_id          = lt_node_id ).

GET_PORT_TYPE

This method provides the port type that was set in the configuration.

Method signature:

Outbound

The generic feeder class of the GUIBBs automatically handles the complete outbound wire communication. Also all Web Dynpro context nodes of a freestyle UIBB that are administered by the Application Model are automatically handled when it comes to outbound wire communication.

All other nodes (i.e. outbound ports) of a feestyle UIBB that are not administered by the Application Model need to be supplied with data by the application itself.
Therefore the interface /PLMU/WDI_FRW_W_GET_DATA needs to be added to the Web Dynpro component which will add method GET_OUTPORT_DATA to the component controller.
This method allows setting/changing the wire data at runtime.

Method signature of method GET_OUTPORT_DATA:

To create a data container that is needed for handing over data to the wire, the Wire Feeder Model (/PLMU/IF_FRW_W_MODEL_ACCESS) of the freestyle UIBBs offers the following methods:

CREATE_CONTAINER_EMPTY

This method creates an empty wire container, which can be used to explicitly hand over no data.

Method signature:

CREATE_CONTAINER_ITAB

This method creates a wire container for an internal table.

Method signature:

To support the different port types that the wire offers it is required to supply also a selection and lead-selection when creating the container.

CREATE_CONTAINER_PARAM

This method creates a wire container for a set of parameters.

Method signature:

To support the different port types that the wire offers it is required to supply also a selection and lead-selection when creating the container.

CREATE_CONTAINER_WD

This method creates a wire container for a Web Dynpro Context Node.

Method signature:

Via the filter mode it is possible to define which elements of the node shall be extracted e.g. only the rows which were submitted from the backend.

Wire Access for the Application Specific Controller

Data of UIBBs can be accessed via the wiring service interface /PLMU/IF_FRW_W_SERVICES.
Therefore this interface is passed to the application specific controller (Enhancement Spot /PLMU/ES_FRW_CONSUMER_APPCC) in certain methods where wire access is possible.
It offers the following methods:

Creating Wires Automatically

The FPM SPI Integration (FSI) contains a mechanism that creates wires at runtime. So in a GUIBB environment the applications will not have to deal much with the manual creation of wires.
To activate the automatic creation of wires you need to define an application parameter at your Web Dynpro application (FRW_AUTO_WIRE = X).

The logic for the automatic wiring goes as follows:

Initial Screen:
A UIBB on the initial screen will be linked to an URL connector. That way, it can obtain URL parameters via the GET_INPORT_DATA method of the wire model.
If a form GUIBB is found on the initial screen, this will act as parent (=local root) for other UIBBs of the main Floorplan area.

OIF Tabs:
If a form GUIBB is found on the first tab on the first position, this one will act as parent (=local root) for other UIBBs on other OIF tabs.
All list GUIBBs act as parents for other UIBBs.
Child UIBBs will be linked to the next available parent GUIBB. So if there is a form GUIBB on the initial screen, the first UIBB on the first OIF tab will be linked to that initial screen GUIBB. Freestyle UIBBs will never be considered as parent UIBBs, because they can have more than one outbound port. In that case, the automatic wiring logic cannot determine to which UIBB outbound port a child UIBB should be connected to.

Tabbed Components:
The UIBBs get a parent from outside that is determined by the rules mentioned above.
Each Master UIBB is considered as a parent UIBB (=local root). If there are no Master UIBBs, the first Form GUIBB on the first position on the first tab is taken as a parent (=local root) GUIBB. Inside of a Tabbed Component, the wiring of the tab UIBBs works analog to the OIF tabs.

Deactivating the Automatic Wiring:
To deactivate the automatic wiring in general you can use the import parameter IO_WIRE_SERVICES of method INITIALIZATION of your application specific controller.