Calls to DO_INIT_CONTEXT method in views

Perhaps the cleanup is a nice place for data loss handling and may be that is why it is
not avoided, no matter how we try to exit the screen? This data loss handling is one of
the things "exit" has to worry about and "entry" doesn't. Going by the standard
components, the DO_VIEW_INIT_ON_ACTIVATION is used for registering the
handlers and the DO_CLEANUP_CONTEXT for deregistering the handlers as these
two methods will be called anyways.
The DO_INIT_CONTEXT() is called after the WD_CREATE_CONTEXT() which in turn calls
CONNECT_NODES() on context level. Thus I thought it might be a good idea to register my
event handlers in DO_INIT_CONTEXT() and unregister them in DO_CLEANUP_CONTEXT(). The
later method is called shortly before the CONNECT_NODES() on context level is called to
deregister the event handlers in there.
Modify DO_REQUEST method You now need to modify the DO_REQUEST code so that it calls
the event handling and controls which page to display based on the new page
variable/attribute. The event handling is called using the 'dispatch_input( )' command.
At output, DO_REQUEST carries out the following tasks:
i. DO_REQUEST determines whether data must be fetched from the model or from
the global attributes.
ii. DO_REQUEST fetches the table with the object keys from the top-level controller.
iii.

DO_REQUEST requests a view.

iv.

DO_REQUEST sets the correct attributes for the view.

v.

DO_REQUEST calls the view.

DO_INIT_CONTEXT This method is called once when a custom controller is instantiated or, for view
controllers, each time the view becomes visible to initialize the view controller context according to the
application's needs. This method is called by WD_CREATE_CONTEXT after all the framework
initialization is done. You should redefine it in your controller implementation class.
DO_CLEANUP_CONTEXT This method is called to destroy the context of a controller. For view
controllers, this happens each time the view becomes invisible. It is called by WD_DESTROY before the
framework destroys the controller's context to allow a controller to cleanup its content internally.It should
be redefined in the implementation class.
DO_PREPARE_OUTPUT: this view displayed every time the view is displayed.
DO_FINISH_INPUT : once u press enter in ur View, u can have validations in this method. This is usually
used at the end of all the data input on the screen..
DO_VALIDATE_INPUT : when ever u enter anything on the screen, this would trigger and validations
gets triggered here.

Functions where overwriting is required

DO_REQUEST is the central method in a controller class.

You must overwrite this method.

In DO_REQUEST you specify the request processing, that is, this method is called for every request. This method
does the main work; in particular it should branch to the correct view.
DO_REQUEST can be used in two different areas:
If it is the top-level controller of a component, then this method handles both input and output processing.
If it is a sub-controller of a component, then this method only handles output processing.

Functions where overwriting is recommended

You should overwrite these methods in order to determine input processing.

Method

Description

DO_HANDLE_DATA Reacts to user input.

Processes data input for this component.
DO_HANDLE_EVENT Reacts to user input.
Processes events if the component contains them.
Exactly one view controller is called to handle the event, which contains an event such
as a save button, for example.
DO_FINISH_INPUT

Ends the input processing.

Functions where overwriting is possible

You can overwrite these methods in order to determine input processing.

Method

Description

DO_INIT

This method is called once at the start and is used for initialization.
This method behaves like a constructor method.

DO_INITATTRIBUTES This method is called with every request and is used to initialize the attributes. The
parameters are read from the request. In this method, you can also execute
initializations that are required for each request.
You can also use this method to set additional attributes. This method is not absolutely
necessary, since you can use DO_REQUEST to solve everything that you can

(theoretically) handle here.

Service functions
You can call these methods:

Method

Description

CREATE_VIEW

Creates or fetches a view instance

Use either the name of the view, or the object navigation.

A view must always belong to the same BSP application as its controller.
CALL_VIEW

Calls the request handler of the view instance.

CREATE_CONTROLLER

Creates or fetches a controller instance

CALL_CONTROLLER

Calls the request handler (method DO-REQUEST) of the controller

instance.

GET_ATTRIBUTE

Returns the specified page attributes.

Generic method for reading an attribute value.

GET_LIFETIME

Returns the lifetime of this page (only for the top-level controller)

GET_PAGE_URL

Returns the URL of the page or the current controller

SET_ATTRIBUTE

Sets the specified page attributes.

Generic method for setting an attribute value.

SET_LIFETIME

Changes the lifetime of this page (only for the top-level controller)

TO_STRING

Creates a formatted string

WRITE

Writes a formatted string in the output

GET_OUT

Fetches the current output writer

SET_MIME_TYPE

Changes the MIME type of the page or the content type of the header field

INSTANTIATE_PARAMETER

Instantiates the parameter from the request using the request data

SET_CACHING

Changes the caching values

There are two types of caching:
Browser cache
Server cache
See also Caching BSPs.

You can only use limited caching here.

Note that the server cache is not user-specific.
If you change the page, you should reset the cache that may be set.
DISPATCH_INPUT

Dispatches the input processing (only for the top-level controller).

For each input, DISPATCH_INPUT calls the correct methods in the
correct sequence.
This method fetches data from the request.

This method does not have any attributes.

GET_ID

Calculates the ID from the specified ID and the component ID

SET_MODEL

Creates and registers a model instance

CREATE_MODEL

Creates and registers a model instance

GET_CONTROLLER

Fetches a sub-controller

CONTROLLER_SET_ACTIVE

Sets a controller to active/inactive.

This is relevant with input processing, since you can use it to hide a
controller.
See also Lifetime

DELETE_MODEL

Deletes a model instance

FILL_MODEL_DATA

Fills the model data

DELETE_CONTROLLER

Deletes a sub-controller

GET_MODEL

Fetches a model instance

IS_TOPLEVEL

Is this controller a top (main) controller (0: no, 1: yes)?

IS_NAVIGATION_REQUESTED Has a controller requested a navigation (0: no, 1: yes)?

Framework functions
These methods are provided as part of the framework and are only included here for the sake of completeness.They
are not usually relevant for application development.

Method

Description

IF_BSP_DISPATCHER~REGISTER

Registers a sub-components

IF_BSP_CONTROLLER~FINISH_INPUT_PROCESSING

Processes or dispatches: end of input processing.

IF_BSP_CONTROLLER~FILL_VALUES

Processes or dispatches: handling values

IF_BSP_CONTROLLER~HANDLE_EVENT

Processes or dispatches: Handle event

GET_FIELD_COMPONENT

Finds components for a field name

GET_FIELD_MODEL

Finds model for a field name

Creation and Deletion of View ControllersMethods

WD_VIEW_INITIALIZE
This method is called to initialize a view on the framework side.Do not redefine this
method.
Use method, DO_REPLACE_INITIAL_VIEW, to adapt the view area content to your
needs.Do not call this method yourself.
BIND_VIEW
Binds a view to a view area of a view set.Do not redefine or call this method yourself.
DO_REPLACE_INITIAL_VIEW
You can redefine this method in the implementation class toOverride the view that is
displayed as default in a view area.The default is taken from the runtime repository and
can be replaced dynamically by implementing thismethod. This is useful for a
customizing-based initial view or if the initial view is dependent on the
contextcontent.NOTE: The replacing view has to be defined as content for the same
view area of the same view set.
Initialization and Cleanup of Contexts
Methods
WD_CREATE_CONTEXT

This method is called once when a custom controller is instantiated or, for view
controllers, each time theview becomes visible.The purpose is to create and initialize
thecontext from a framework perspective.Do not redefine that method,But use
DO_INIT_CONTEXT instead, which is made exactly for that purpose.If you already
redefined the method, as the DO_INIT_CONTEXT is relatively new, you do not have
tochange it. However, if you have the time, it would be nice to change it.
DO_INIT_CONTEXT
This method is called once when a custom controller is instantiated or, for view
controllers, each time theview becomes visible to initialize the view controller context
according to the application's needs.This method is called by WD_CREATE_CONTEXT
after all the framework initialization is done.You should redefine it in your controller
implementation class.
WD_DESTROY
This method is called to destroy the context of a controller. For view controllers, this
happens each timethe view becomes invisible. It is used within the framework and
cannot be redefined. It is also called whenthe controller instance is deleted.
DO_CLEANUP_CONTEXT
This method is called to destroy the context of a controller. For view controllers, this
happens each timethe view becomes invisible. It is called by WD_DESTROY before the
framework destroys the controller'scontext to allow controller to clean up its content
internally. It should be redefined in the implementationclass.
WD_DESTROY_CONTEXT
This method is called to destroy the context of a controller. For view controllers, this
happens each timethe view becomes invisible. It is used within the framework and
cannot be redefined. It is called byWD_DESTROY after DO_CLEANUP_CONTEXT
External List Management in SAP CRM
his is on CRM 5.2 You can only use web IC to create the Mapping formation. Dont use win
clinet for this. SAPs intention is to move every one to the Web Client(WEB-IC).
ELM (External list management) is used to load the external data from outside system in to
the CRM system.
ELM is used to load the new customer information (create new BP) or update the existing
customer information (update the BP).
When we load the data from the excel or text (.CSV file or .txt file) the customer data will
be created as a prospect(or any other role that you want).
For loading the data using ELM we need to do the following steps.

Create mapping

Use the created mapping in the external list

You can create and maintain external lists in SAP CRM by acquiring specific data from external providers
and using this data to gain new business partners. The data from external providers could include
information on:
Business partner addresses
Marketing attributes of business partners
Business transactions-related information, such as activities and leads
Survey details
External List Management involves procuring external data, defining mapping formats, checking and
preparing the data, updating existing data, creating business partners, using these business partners in
marketing campaigns, and analyzing (reporting) the methods used.
CRMV_EVENT - what is it?
What is callback?
After processing each part of CRM document, eg. Partners, Customer fields, Organizational data, etc. specific events
are executed in SAP CRM. After these events special function modules are executed. These are called "callbacks".
These callbacks are function modules that end with "_EC" in its name. It means they have special interface that is
needed when module is to be used as callback.
Callbacks are executed by SAP CRM if they are connected in transaction CRMV_EVENT to certain events. And
whether attributes set there, which work as filter, are the same as in processed activity by user.
Each callback is configured in the same way:
- it is connected to transaction category (eg. Service process)
- its time and priority of execution is set,
- it is connected to object and event (Object means part of document that is being "touched", it could be for example
"Partner" or "Orderadm_h". Event could be "Save" - while saving, "After_change", "After_create", etc.)
- it may have attributes set (eg. when processing Partner it could be partner function type),
- it could be executed for headers or/and items of documents.
What it is used for?
Callbacks are used mainly for processing documents. For example in standard they are used to copy organizational
data from previous document when creating new follow-up document.
How to check which callbacks are executed?
in CRMV_EVENT it is best to filter by specific transaction category and object. Eg. Service Process and STATUS.
Please remember that there could be more Transaction categories used in a particular process, like Service Process,
and also generic one so CRM Bus. Transactions.
check also many transactions for tracing / checking (like CRM*EVENT*, eg CRMD_EVENT_TRACE,
CRMD_EVENT_CHECK).
How to define own?
Create function module with proper interface (look at *_EC function modules) and assign in configuration (SPRO ->
CRM -> Transactions -> Basic Settings -> Edit Event Handler Table).

Dynamic Navigation & static navigation

Static navigation is through plugs. We will define outbound, inbound plugs and then we will create a navigation link.
This is how we do the static navigation.
In dynamic navigation there is no need of creating any plugs and navigation link. Within the event handler itself we
can make use of interface if_crm_ui_navigation_service methodnavigate_dynamicaly for the purpose of navigation.