Sunday 13 May 2012

Value Node & Model Node


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.

BOL Entity

Data we enter on the webui  get saved in the database via BOL Entities

To find which component is driving the WebUI Page just press F2 on the view element

from the technical settings you can have the UI component and its corresponding view

  1.  Execute the transaction "BSP_WD_CMPWB"   (BSP WEBDYNPRO COMPONENT WORKBENCH)
  2. Enter the name of the component 
  3. click on display
  4. Identify the view which you have found out by clicking F2 on the UI Element  by expanding the views folder
  5. double click on the View
  6. Expand the Context in the right pane
  7. expand the context nodes
  8. Double Click the context node which u have found by clicking F2 on the UI Element
  9. you will find the context node class with the extension "CNXX
Note
 Controller Class will have an "IMPL " Extension.
 Context class will have an "CTXT" Extension.
Context Node Class will have an " CNXX" Extension.

 The same thing is applicable for controller, window and the view. Just double click on the selected element in the left pane be it either a controller, window or a view the class extensions are same.


The Context Node class contain a collection wrapper class
A collection wrapper class is a container that hold the BOL Entities
A BOL entity is a class instance with underlying structures mapped to the database tables.
These BOL Entities will be of type CL_CRM_BOL_ENTITY

For example consider the Form View which contains the data that is being held by 1 BOL entity which in turn is held by a Collection wrapper

Note
For Table view the data is 1:N, i.e there can be N BOL entities (all with the same structures) corresponding to the each row of the table view and held by the collection wrapper.
To access BOL Entity underlying the view
If  you are in the method of an IMPL Class 
Controller( or ME)-->Context-->Context Node-->Collection Wrapper-->Get_current ( ).

If you are in the method of a Context Node class 

context node-->Collection Wrapper-->Get_Current ( ).

Get_current ( ) gives the BOL Entity underlying the view.

You can also use  get_first ( )  (in the case of a form view) as there is only 1 BOL Entity.

In case of a table view where each and every row of the table view corresponds to 1 BOL Entity you can loop around the collection wrapper and get the BOL Entity of the corresponding row using the index.

Get_next ( ) also gives the next BOL Entity underlying the table view.


Saturday 12 May 2012

Enhancement set


SAP provides a concept to enhance standard UI Components without modifying the standard SAP UI components. all the modifications that are carried by the customer will be stored in the container called Enhancement set

  1. Execute the Transaction SM34.
  2. Open the view cluster BSPWDVC_CMP_EXT.
  3. Go to change mode.
  4. click on " New Entries " Button.
  5. Furnish the details such as Enhancement set (for eg: say ZESET) and maintain the description for the same.
  6. click on "SAVE".
Note:
You can create multiple enhancement sets but only one enhancement set is used by the Webclient UI Framework at runtime.

After Creation of Enhancement set you have to assign your enhancement set to the current client where you are working on enhancing the UI Component.

Assigning the enhancement set to the client
  1. Execute the transaction SM30
  2. Enter BSPWDV_EHSET_ASG
  3. click on "Maintain"
  4. enter assignment no sat for example 221
  5. enter your enhancement set i.e ZESET
  6. SAVE
Note

BSPWDV_EHSET_ASG is a maintainance View to maintain the data of table BSPWD_EHSET_ASGN




Middleware

Middleware is used to exchange data between the CRM Server, mobile clients, connected R/3Server or any legacy (non-sap) systems.

Its main functionalities are
  • Data Queuing & Transporting.
  • Replication & realignment.
  • Data exchange and synchronization (Mapping).
  • Middleware is an integral part of CRM Server
  • It provides seamless backend integration and groupware integration.
  • CRM Server connects to other servers like BW, APO and ERP back-end through the CRM Middleware.
  • Mobile clients can be connected to the CRM Server via communication Station.
Middleware Architecture




Online & Consolidated Database

CRM is separated into two Logical Databases.

  • CDB ------Consolidated Database, It servers the Mobile Applications
  • Online Databse------It servers all other Applications.

Business Adapter Objetcs

Adapters are responsible for converting the data of different formats between the components in an CRM Environment

Filtering can be done either in a source system , target system or both the systems, However in order to reduce the data flow in R/3 the filtering should be done in source system.

Filter settings are stored in Tables "SMOFFILFLD" in CRM SYSTEM AND "CRMFILLTAB"  IN R/3 system

Data Exchange Between different Servers

Between R/3 and CRM


  • A Plug is installed in R/3 end which is equivalent of R/3 adapter on  CRM Server side


Between Legacy Systems and CRM

  •  The Data exchange takes place using External Interface (XIF) adapters.


Between Mobile Clients and CRM

  • Mobile Clients are connected to CRM Server via Communication Station

Wednesday 9 May 2012

BAPIMTCS

Bapi Middleware Transport Communication Structure:

  • It is responsible for exchange of data between CRM Middleware and R/3 Backend Server.
  • In the R/3 Server an object specific Function Module is used to extract the data.
  • The name of the object specific extractor can be found in R/3 Table CRMSUBTAB.

Tuesday 8 May 2012

Web User Interface

WebUI Architecture

Architectutre of SAP CRM Webclient UI application is built up of 3 different layers

Business engine and business layer are responsible for linking CRM business functionalities within the CRM Webclient UI and presentation layer represents the main development environment for webclient ui where single screens of webclient ui are developed.


The business server pages (BSP's) represent the presentation layer of the CRM Webclient. They are used to generate the HTML Page of the CRM Webclient running in the users Browser

The business Logic of CRM business objects and processes are not controlled by the BSP's but by the business layer and the business engine.

Business objetcs of a CRM Webclient session like Business Partner, Product, Transactions etc are hold in the business object layer



The MVC application located in the presentation layer is a non SAP Programming Model. It is a general description of  how to develop a software with a clear separation of business logic and data model. Here we shall discuss three distinct parts of a software with their own responsibilities. We distinguish between Model, View and Controller of an application.

Within the application there is a strict separation of reading /changing/showing the data and reacting to the user inputs.


The Model is a kind of Black box entity which contains all the necessary methods to get access to the business data and functions

In case of webclient UI the model corresponds to SAP CRM's business layer and business engine. All available business objects can be found here.

The View's responsibility is to display the data coming from the model and to offer an interface to the end user for working on the data

The Controller acts as a intermediate element between View and the Model. It receives and processes user requests to call certain business functionalities with in the model and invokes data output in the view


For example when a user clicks on a button to get the more detailed data to be shown , The controller processes the button Click and fetches the data from the Model and puts it on to the view for display












Friday 4 May 2012

Interfaces & Casting

Interfaces extend the scope of a class by adding their own components to its public section. This allows users to address different classes via a universal point of contact. Interfaces along with Inheritance provide one of the pillars of polymorphism, since  they allow a single method within an interface to behave differently in different classes.

Interface components do not have to be assigned individually to a Visibility section, Since they automatically belong to the public section of the class in which the interface is Implemented.

Interfaces do not have Implementation
Interfaces do not have Instances.

Interface References

Reference variables allow you to access object. Instead of creating reference variables with reference to a class you can also define them with reference to an interface. This kind of reference variable can contain references to objects of classes that implement the corresponding Interface.

Addressing Objects Using Interface References

To create an object of the class say C1, You must first have declared a reference variable say CREF.
(i.e. Data : CREF type ref to C1).)
Suppose if the class 'C1' implements an interface 'I1'.
Interface Reference here is IREF.
(data : IREF type ref to I1).

Then the following assignment is possible between CREF & IREF.

IREF = CREF.

Assignment using interface references- Casting

Like class references, you can assign interface references to different reference variables( be it a class reference or interface reference)

When you use the MOVE statement or the assignment operator (=) to assign the reference variables, the system must be able to recognize  the syntax check whether an assignment is possible.

Suppose we have a class reference CREF and Interface reference IREF, IREF1 & IREF2

The following assignments with interface references can be checked statically

Case1
Both interfaces(iref1 and iref2) must refer to the same Interface(iref) or the interface IREF1 must contain the interface IREF2as a component. The following assignment is possible

IREF1 = IREF2.


Case2
The class of the class reference CREF must implement the interface of the interface reference IREF

IREF = CREF.


Case3
The class of CREF must be the predefined empty class OBJECT.

CREF = IREF.

In all other cases you would have to work with the statement  Move....?To  or the Casting Operator (?=).

The casting operator replaces the assignment operator (=) in the MOVE....?TO statement .
When you use the casting operator there is no Static type check. Instead the system checks @ Runtime whether the object reference in the source variable points to an object to which the object reference in the target variable can also point. If the assignment is possible the system makes it, otherwise the catchable runtime error  MOVE_CAST_ERROR occurs.
You must always use casting for assigning an interface reference to a class reference if CREF does not  refer to the predefined empty class OBJECT

CREF ?= IREF.

For Casting to be successful, the object to which IREF points, must be an object of the same class as the type of the class variable CREF.
(i.e Data : iref type ref to i1,
Here 'i1' is the interface being implemented by class 'c1'.
Data cref type ref to c1.)
Here IREF & CREF points to the object of the same class ''c1".
Hence the above Casting is Successful. :-)