Value Nodes are used for display purpose.

For example if you have an internal table and want to display

that data on UI, you can do it using a Value Node. A Value does not need any BOL reference, just a Data
Dictionary Structure. It can be created in run time.
Modal Nodes have an underlying GENIL reference, database tables and have many features like relations
etc., A BOL entity is a must for a Modal Node Creation. They can be bound to custom controllers or
component controllers for data exchange. They are arranged in a hierarchy which can be viewed using
TCODE GENIL_MODEL_BROWSER.
Model Node - It represents structured data which is connected to DB layer via BOL Node.
Value Node - It represents data which is not connected to any DB layer but is only used for display. The
data is not persistant.
Mostly it is advisable to create a BOL/Genil layer for custom development instead of going through
Value Node. It may take time and may appear to be a complex development, but it will reduce your
Performance issues and will also reduce Flag programming.
Difference between custom and component controller
The main difference between custom and component controller is the role which they play during data
transfer.
a) Custom controller is used for data transfer across two views within a component. For that you need
to bind view context nodes to custom controller either through wizard or manually by adding the code
in CTXT class create_contextnode method:
initial setting for depandant model node
coll_wrapper =
BTADMINH->get_collection_wrapper( ).
TRY.
entity ?= coll_wrapper->get_current( ).
CATCH cx_sy_move_cast_error.
ENDTRY.
IF entity IS BOUND.
BTOpportH->on_new_focus(
focus_bo = entity ).
ENDIF.

b)Component controller is used for data transfer across two views in two different components. For this,
we need to define the component usage first and then bind the context nodes in the method-
WD_USAGE_INITIALIZE of the Component Controller impl class.
WHEN 'ComponentUsageName'.
iv_usage->bind_context_node(
iv_controller_type = cl_bsp_wd_controller=>co_type_custom
iv_target_node_name = 'ContextNodeName' "#EC NOTEXT
iv_node_2_bind = 'ContextNodeName' ). "#EC NOTEXT
Session breakpoints
With session breakpoints you can stop and debug requests that you trigger in the same user session
where you have set the session breakpoints. They are therefore particularly useful for debugging SAP
GUI-based applications.
You set a session breakpoint in the ABAP Editor (SE38) as a line breakpoint, that is, for a particular row
of the source text. For more information, see Managing Breakpoints in the ABAP Editor. In addition to
this, other breakpoint types can be coverted to session breakpoints during a debugging session. For
more information, see Managing Breakpoints in the ABAP Debugger.
A session breakpoint is valid within all main modes (external modes) of the user session where it was
set.
If you end the user session (by logging off the system), then all of the session breakpoints set in this
session are deleted.
Note:
Session breakpoints are therefore no longer available for implicit new logons, for example when
switching the server using transaction SM51.
External breakpoints
External breakpoints (previously known as: User breakpoints) apply to the current user session in the
same way as session breakpoints. In addition to this, they remain valid for future user sessions. This
does not only mean dialog sessions, but also sessions initiated with RFC or HTTP requests.
You can debug applications with external breakpoints, that use the RFC interface or HTTP protocol
(External Debugging). Functions modules, Web services and Web Dynpro applications, and BSP
applications also belong to this.
An external breakpoint can apply to:
A user in the current SAP system
A user in the current application server of the current SAP system
User sessions started by a request that has a specific terminal ID.
You can set external breakpoints:
In the ABAP Editor (SE38) as line breakpoints, that is, for a specific line of the source text. For more
information, see Managing Breakpoints in the ABAP Editor.
in transaction SICF.
Other breakpoint types can be coverted to session breakpoints during a debugging session. For more
information, see Managing Breakpoints in the ABAP Debugger.
External breakpoints are active for two hours. They are then deactivated. If an external breakpoints is
set then all external breakpoints that had previously been set are reactivated.
External breakpoints apply on the calendar day that they are set. They are deleted in the first minute of
the next calendar day (at midnight).