Saturday, 12 May 2012

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. :-)