TAW10 - COMMUNICATION AND INTEGRATION TECHNOLOGIES

BUSSINESS PROCESS DISTRIBUTION USING ALE

Application Link Enabling (ALE) enables you to create and operate distributed applications. ALE basically enables the practical operation of a distributed, yet integrated system landscape. ALE links different systems in business terms through secure and consistent data transfer.
You can clearly see from the slide how various business processes in a company are distributed using ALE.

IMPLEMENTING ALE

This slide shows you an example of how the data within the SAP system is synchronized in the business process.
The IDoc format describes the structure of the intermediate documents.
You can transfer data by Remote Function Call (RFC), HTTP, or HTTPS.
Transfer type can be either synchronous transfer or asynchronous transfer.
Synchronous transfer implies that the data is transferred at the time of creation or change. An asynchronous transfer can happen at intervals of your choice.


INTERFACES TECHNOLOGIES USED IN SAP SYSTEMS

SAP systems have interfaces at different communication levels.
Many interface technologies are used by the SAP system:
  Application Link Enabling or ALE

  Business Application Programming Interface or BAPI

  Common Program Interface Communication or CPI-C

  Electronic Data Interchange or EDI

  HyperText Transfer Protocol or HTTP

  Logical Unit Type 6.2 or LU 6.2

  Remote Function Call or RFC

  Object Linking and Embedding or OLE

  Simple Mail Transfer Protocol or SMTP

  Simple Object Access Protocol or SOAP

  Transmission Control Protocol/Internet Protocol or TCP/IP

  Extensible Markup Language or XML


RFC CONNECTION POSSIBILITIES

The Remote Function Call interface is an SAP interface protocol based on CPI-C and TCP/IP. With an RFC, you can call and execute predefined functions either in a remote system or within the same system. You can also call functions in non-SAP systems. During RFC communication between two SAP systems, the calling system uses an RFC definition to access a specific function. ABAP programs use RFCs to access functions in SAP systems.
To start external programs remotely, you need an RFC interface outside the SAP system. As all RFC interfaces are bidirectional, external programs can also use RFCs to access functions in SAP systems.


REMOTE FUNCTION CALL IN DETAIL

To access an RFC module from an SAP system, you need to know the import and export parameters, as defined in the Function Builder. The two systems must have a technical connection. This is called an RFC connection or an RFC destination.
You can create an RFC destination named DEST in the calling system. In ABAP, RFCs can call a function module in another system if you key in the relevant code:
CALL FUNCTION <Name>
DESTINATION <Ziel>
EXPORTING ...
IMPORTING ...
You can name the function to be executed in the target system. Next, reference the name of the target to one of the RFC connections available. Exportingand Importing are the functions used to pass on the parameters to the target function and also to receive the returned parameters.
If you need a bidirectional RFC connection between two systems, you need to set up a similar second RFC connection in the system called.

BOR AND BAPIs

A Business Application Programming Interface (BAPI) is a standardized programming interface. It enables internal and external access to business processes and data in SAP systems. BAPIs are defined in the Business Object Repository (BOR) as methods that facilitate an object-oriented view of business data in an SAP system.

BAPI USES

BAPIs are used in several ways:
  They link business processes across system boundaries, such as when using ALE.

  They integrate various solutions in the framework of the SAP Business Suite.

  They connect an SAP system to the Internet.

  They can be used in conjunction with the SAP Business Workflow.

  They also help to connect to external programs.

SAP R/2 AND R/3

SAP R/2 and SAP R/3 have these common features:
  Real-time processing of business processes

  Use of ABAP as a programming language

  Constantly increasing features (during the maintenance period) by functions newly created by SAP

  Adjustability of mapped processes to company-specific activities

  All information is stored in a central database

The primary difference is host-based system on client-server-based system. The change from SAP R/2 to SAP R/3 basically means a change in the technical infrastructure and in the design of the user interface.


CLIENT-SERVER ARCHITECTURE VERSUS ENTERPRISE SOA

In the usual Client Server Architecture, the system database holds the business process data. The application processes, which run on application servers, are made available through predefined interfaces. Also, different business applications exchange data directly through the database.
In the Enterprise SOA, on the other hand, role-based user interfaces function as central entry points for the employees of the company, who carry out their work using different applications in different systems. New process steps are provided as Enterprise Services. These enable the users to save the data in totally different databases, as well as to integrate the data using general standards.
For example, Client Server Architecture enables a financial transaction to access an HR-related table in which data was updated from an HR transaction earlier.
In contrast, in Enterprise SOA, the financial application would request the HR data through a specific application-to-application (A2A) interface and not simply retrieve the data from the database with an SQL access.

ENTERPRISE SOA VS WEB SERVICES

An Enterprise Service is a complete industry-specific process, which comprises many small individual steps. All the actions together form the Enterprise Service, thus constituting the overall context-oriented business process logic.
In contrast, Web Services are smaller modular applications which run within the framework of Internet technologies and address detail functions within applications or Enterprise Services.

CHARACTERISTICS OF ENTERPRISE SOA

An Enterprise SOA application
  is implemented across systems;

  is created in ABAP or in Java; and

  generally does not have its own database.

New functions are entered outside the existing systems for Enterprise SOA applications.


ENTERPRISE SERCIVES: ADVANTAGES

The availability of Enterprise Services enables the efficient creation of new applications without having to modify the underlying system. It also provides flexibility in the configuration of business processes and simplifies the creation of applications that use the functions of several systems.

SAP NETWEAVER: WEB SERVICES STANDARD

A Web service is a module that can be used flexibly in different applications.
In the SAP NetWeaver Application Server, some basic standards for Web services are implemented, such as
  eXtensible Markup Language (XML);

  Simple Object Access Protocol (SOAP);

  Web Service Description Language (WSDL); and

  Universal Description, Discovery, and Integration (UDDI).


OUTLINE OF A WEB SERVICE SCENARIO

A Web service defined can be called up from an ABAP program or from a Business Server Page.
The steps to create a Web service scenario are quite distinct:
  The Web service provider publishes the service in a publicly accessible UDDI directory. A URL is generated, as are the WSDL files.

  The Web service user creates a proxy object that refers to the URL of the Web service .The Web service user then searches directly for Web services in the UDDI directory.

  The proxy object is written to and integrated into an executable program (for example, in ABAP) and called up there.