SAP Interfacing
Techniques
SAP AG has been coming up with new tools and
techniques to support emerging industry standard EAI technologies from time to
time.
The following are the techniques currently supported
by SAP (as in SAP Version 4.6c) for both batch and real-time interfacing.
Batch Data Communication (BDC)
Batch Input (BI) & Direct Input (DI) programs
Remote Function Call (RFC)
Electronic Data Interchange (EDI)
Application Link Enabling (ALE)
Business Application Programming Interface (BAPI)
SAP Automation Tools
SAP Connectors
Internet Transaction Server (ITS)
Low-level communication techniques.
CPI-C Communication.
Platform specific development libraries for SNA
& TCP/IP communication and a number of third party EAI tools to
integrate SAP and Non-SAP systems with R/3.
5 times faster2 : Based on the benchmark performed by the
author. Result may vary depending on factors like number of Transactions,
Material Views, System load, Release, Database, Operating System, Hardware etc…
RFC is a very powerful tool for interfacing with SAP system
in real time. Most other
interfacing techniques like ALE, EDI, BAPI etc… are inherently based on the RFC
technology.
How they all fit together
Batch Data Communication (BDC)
Batch Data Communication (BDC) is the oldest batch
interfacing technique that SAP provided since the early versions of R/3.
BDC is not a typical integration tool, in the sense that, it can be only be
used for uploading data into R/3 and so it is not bi-directional.
BDC works on the principle of simulating user input
for transactional screen, via an ABAP program. Typically the input
comes in the form of a flat file. The ABAP program reads this file
and formats the input data screen by screen into an internal table
(BDCDATA). The transaction is then started using this internal table
as the input and executed in the background. The following diagram
explains
Since the BDC technique invokes the standard SAP
transaction, which the normal user would invoke interactively, all the input
field validations, translations and flow are intact and behaves in accordance
with the expected process flow (Please note that this is does not hold good in
a few cases, in which the Dialogue module checks whether the Transaction is
being executed interactively or in the BDC Batch mode in order to control the
screen flow. For example getting the confirmation from the end-user).
This flip side of it is performance hit. Since
BDC has to go through all the Transactional screens and validations, most of
the time is spent by the system in loading the DYNPRO (Dialog screens) as
opposed to doing the actual business function.
There are two ways to run BDC programs.
• Using CALL
TRANSACTION
• Using Batch
Input Sessions
In ‘Call Transaction’, the transactions are triggered
at the time of processing itself and so the ABAP program must do the error
handling. It can also be used for real-time interfaces and custom error
handling & logging features.
Whereas in Batch Input Sessions, the ABAP program
creates a session with all the transactional data, and this session can be
viewed, scheduled and processed (using Transaction SM35) at a later time.
The latter technique has a built-in error processing mechanism too.
The BDC Transaction recorder (Transaction SHDB) helps
in recording the user inputs and the screen flow of a transaction and can
generate ABAP code to create BDC sessions. With this facility, the
programmer no longer needs to dig through the attributes to note down the field
names, program names and screen numbers to create a BDC program.
Though BDC is simple enough to develop, it is not very
efficient when compared to other interfacing options like Batch Input (BI),
Direct Input (DI), RFC, BAPI etc…
SAP has been introducing more and more BI / DI
programs & BAPIs in the new releases, in order to provide better
integration at the business object level and at a higher speed.
Batch Input (BI) & Direct
Input (DI) programs
These are
SAP supplied standard ABAP programs for loading master and transaction data
into SAP. Both these types of programs take a flat file as the input and
load the data into the R/3 system.
Batch
Input (BI) programs still use the classical BDC approach but doesn’t require an
ABAP program to be written to format the BDCDATA. The user has to format
the data using predefined structures and store it in a flat file. The BI
program then reads this and invokes the transaction mentioned in the header
record of the file.
Direct
Input (DI) programs work exactly similar to BI programs. But the only
difference is, instead of processing screens they validate fields and directly
load the data into tables using standard function modules. For this
reason, DI programs are much faster (RMDATIND - Material Master DI program
works at least 5 times faster2) than the BDC counterpart and
so ideally suited for loading large volume data.
DI
programs are not available for all application areas. Only a limited
number of DI programs have been supplied by SAP, which are listed below.
SAP supplied Direct Input Programs
Program
|
Description
|
RMDATIND
|
MM: Create
Material master data
|
RFBIBL00
|
FI: Create
Account documents
|
RVAFSS00
|
SD: Invoicing
external transactions
|
RAALTD11
|
AM: Create
Asset Account documents
|
RKEVEXT0
|
CO-PA:
External data transfer to CO
|
The Direct Input sessions can be created, viewed, scheduled,
processed and restarted using Transaction
BMV0 or using Program RBMVSHOW.
Remote
Function Call (RFC)
Remote Function Call (RFC) in SAP R/3 is based on
UNIX’s Remote Procedure Call (RPC). RFC enables the real-time link
between different R/3 instances and can connect SAP to Non-SAP systems.
With Remote Function Call, both inbound (RFCServer)
and outbound (RFCClient) interfaces are possible. SAP also provides a
toolkit called RFC API for non-SAP systems to interact with SAP’s Function
modules remotely.
The following diagram illustrates the RFC calls
between SAP & non-SAP system programs.
RFC communication between systems
SAP
maintains a central repository of interoperable system definitions called
“Destinations” (Transaction SM59). The following types of
connections are possible with RFC Destinations.
• Connection to R/3 system
• Connection to R/2 system
• External program connection via TCP/IP
• External program connection via SNA or
APPC
• RFC via special ABAP/4 drivers
From
release 3.0 onwards, SAP has introduced a new version of RFC called
Transactional RFC (tRFC). tRFC makes sure that the function remote calls
are transactional in nature, that is, safe,
independent of the availability of the RFC server and being called only
once. SAP provides support of both Synchronous and Asynchronous RFC calls.
Electronic Data Interchange (EDI)
Electronic
Data Interchange (EDI) is the industry standard format for exchanging Business
data. SAP uses a neutral format called Intermediate Document (IDoc) for
communicating EDI & ALE messages.
The IDoc
interface contains data structures and processing logic for each of the
business transaction. These are grouped as Message Types. The
external EDI Server is responsible for receiving the EDI messages sent by the trading partners. These
EDI messages are then mapped onto the IDoc structure fields and stored in the
IDoc interface layer by SAP.
EDI/IDoc
supports both inbound and outbound interfaces. The IDocs received through
the EDI Server can be configured to automatically get processed, or can be
stored in the IDoc interface layer for a future manual or scheduled
processing.
The IDoc
interface layer also has a powerful error handling, reporting, monitoring and
reprocessing mechanism built into it (Transaction WEDI). IDoc is
also tightly integrated with the WorkFlow system of SAP for initiating other
business tasks upon receiving/sending EDI messages.
The IDoc
interface can be employed for non-SAP applications to load or extract data from
SAP system. But typically, EDI / IDoc is engaged when SAP system is to be
integrated with any of its business partners (Customers, Suppliers and other
partners) for carrying out standard business transactions (like Create Sales
orders, Sending Purchase orders to Suppliers, etc…).
Application Link Enabling (ALE)
Application
Link Enabling (ALE) is a middleware tool, which is part of SAP’s Business
framework Architecture (BFA). ALE can effectively be used for loosely
coupled Asynchronous communication between SAP systems and
with non-SAP systems. ALE is based on the distributed processing
architecture and hence integrates applications with the local database rather than
centralized one.
ALE
messages are based on the Intermediate Document (IDoc) format, similar to the
EDI counterpart.
Though
ALE can be used to interface with non-SAP systems, usually it is used to
distribute Master & Transactional data between SAP R/3 instances.
The ALE
distribution can be based on,
• Business APIs
• IDoc Message Types
Distribution
based on IDoc Message types (example, MATMAS / MATCOR for Material Master data
& ORDERS / ORDCHG for Customer master etc…) are typically used in 3.x
SAP releases. The order of the day (since release 4.0A) and future is ALE
distribution through BAPIs.
The main
advantage of ALE is that it can work between different releases of R/3 systems.
So, even after a release (version) upgrade, ALE links continue to work as
is. Since ALE is based on the IDoc processing model, error handling
becomes easy.
Business API (BAPI)
Business API (BAPI) is the most important component of
SAP Business Framework. BAPI enables SAP and third party applications to
interact and integrate with each other at the Business Object / Process
level.
Till some time back, SAP was deep into its
not-so-friendly interface and architecture, which it inherited from the IBM
Mainframe based parent system. But now it has come up with truly platform
independent business object interfaces using BAPIs. Business Objects and
BAPIs provide an object-oriented view of SAP’s business functionality (Transaction
BAPI).
BAPI and the SAP Business Framework .
BAPIs are
implemented using remotely callable Function modules. These RFCs are
assigned as a callable method of a Business Object in the
Business Object Repository (BOR). All BAPIs are independent of the screen
and hence can work in the background without user intervention.
BAPI
supports both inbound and outbound processing. Since it follows
object-oriented approach, SAP has positioned itself to support interfacing
through BAPIs in the future.
SAP Automation Tools
SAP
Automation Tools are set of tools, components and class libraries for
developers to integrate non-SAP systems with SAP systems.
There are
two tool sets available for SAP Automation.
• SAP GUI interfaces
• RFC & BAPI interfaces
SAP GUI
interface toolset can be used for developing applications that can interact
with SAP transactions interactively, so that the end-users can access SAP
Screens directly from other applications (like showing SAP screen from a
VisualBasic screen scraper program). These toolsets use the SAPGUI
application server component to connect to SAP R/3.
Using the
second set of tools, SAP lets you access RFCs and BAPIs directly from non-SAP
systems. Using these tools you can
• Connect to R/3 from outside of the SAP
GUI interface environment
• Access SAP business objects and
Business APIs (BAPIs)
• Access R/3 RFC function modules
• Trigger R/3 transactions in batch mode
from outside of R/3
• Provide an alternative GUI interface
to R/3 applications and transactions (Screen scrapers)
• Send or receive inbound or outbound
IDoc documents to or from R/3
The SAP
Assistant toolset contains following components.
• C, C++, Java, VB APIs & Class
files
• Active X controls
• COM / DCOM connectors & server
• Standalone EXE files, etc…
SAP
Automation tools are very powerful developer toolkit, which is ideal for
developing both inbound and outbound real-time interfaces to or from SAP R/3
system.
SAP Connectors
There are
a number of connectors supplied by SAP for integrating R/3 with different
applications and technologies.
• SAP Business Connectors
• SAP Java Connectors
• SAP .NET Connectors
• SAP DCOM Connectors
The Java,
.NET and DCOM connectors are took kits, which are functionally similar, to
enable interoperability between SAP and other software. These toolkits
typically come with middleware APIs to support RFC (synchronous, transactional
& queued), BAPIs, and IDocs. These connectors are ideal for
custom interface development for the in-house integration needs.
SAP
Business Connectors is a step above the technology connectors. Business
Connectors allow integration of local and application over the net, with open
standards (like XML etc…). The BAPI and IDoc interfaces are made
available to partners over the net using secured XML based services. In
addition, Business Connectors enable to expose additional Web Services over the
internet for the business partners to get information deeply buried into your
ERP system.
Internet Transaction Server (ITS)
Internet
Transaction Server (ITS) is the transaction processing system that connects the
web HTTP server and the standard R/3 system. ITS is available since SAP
release 3.1G. All the Internet Application Components (IAC) of SAP will
be transacted through ITS.
Using ITS
& IAC the standard R/3 transactions can be performed through the World
Wide Web.
Some of
the business components that are pre-web-enabled by SAP are,
• HR Employee Self-Service (ESS)
• Components in SAP Retail Store
• SAP B2B Procurement
It is
also possible to web-enable the custom transactions and other
standard transactions using ITS, using the following tools and components
supplied by SAP.
• SAP@Web Studio
• SAP GUI for HTML
• Web RFC
• Web Reporting
• Web Transactions
These
components support generation of dynamic HTMLs, HTMLBusiness,
JavaScript, Common Gateway Interface (CGI), Microsoft Information Server API
(ISAPI), Netscape Server API (NSAPI) and can interact with Java, C++ or VB programs.
Though
the current development environment is not yet a matured one, it will soon be
so in the forthcoming releases of SAP.
CPI-C communication
Common
Programming Interface – Communication (CPI-C) is a direct program-to-program
communication protocol. Those who want to develop simple but proprietary
protocol can use this technique. Remote Function Call (RFC) is a
simplified version of CPI-C, so that the programmer need not worry about the
communication protocols and rather can concentrate on communicating business
information between programs.
CPI-C
allows an ABAP program to set up a connection to one or more external
application programs in order to send data directly to these programs.
CPI-C ABAP Statements
CPI-C Call
in ABAP
|
Explanation
|
COMMUNICATION
INIT
|
Initialize
connection
|
COMMUNICATION
ALLOCATE
|
Set up
connection
|
COMMUNICATION
ACCEPT
|
Accept
connection
|
COMMUNICATION
SEND
|
Send Data
|
COMMUNICATION
RECEIVE
|
Receive data
|
COMMUNICATION
DEALLOCATE
|
Close the
connection
|
In short,
CPI-C is the low-level stuff that hard-core protocol developers will be
interested in. It is not meant for Business-Object-level or
Application-level integration.
EAI Products for SAP R/3
There are
a number of Enterprise Application Integration (EAI) products, which can
integrate SAP R/3 with various other products and applications. These
products claim to work at different levels of integration, viz., technology
integration, application integration, business process integration, system integration
etc…
Most of
the products are generic integration tools that come with SAP specific
adapters. Many of these also come with pre-built Business Object
Templates for integrating SAP’s standard business objects like Sales Orders,
Invoices, and Purchase Orders etc…
Some of
the EAI products that are available in the market are:
• IBM’s ‘Websphere’ (formerly known as
Crossworlds)
• BEA’s ‘Weblogic Integration’
• Seebeyond's ‘e*Gate’
• IT Architects ‘Connect-IT’
• Tibco’s ‘Business Connect’
• Backsoft’s ‘btalk’
• Mercator’s ‘Integration Broker’ and
• SAP AG’s own ‘Business Connector’ and
‘mySAP Exchanges’
For more
details about the products visit the links provided at the end of this
document.
No comments:
Post a Comment