SAP Interface Scenarios:

tukwilagleefulInternet and Web Development

Oct 31, 2013 (3 years and 5 months ago)

67 views

SAP Interface Scenarios:


Scenario

1
:
Some client needs to initiate communication with
a

SAP system
to perform work

(examples: SAP GUI, SAP Java Connector, SAP .Net
Connector).


How it works:

In this scenario, the

client
(SAP GUI or some connector)
can ini
tiate
logon via a call to the message server running on the central instance of
a SAP system. The client
passes the name of a logon group to the message
server,
and the message server redirects the client to a specific instance
of the
SAP
system based on
a load balancing algorithm.


Once
client

has been re
-
routed by the message server

to a specific
application server
, the dispatcher
running

on
that

application server
takes over the handling of communication between
the
SAP

system

and the
client.


Alternati
vely,
these clients (SAP GUI or a connector)

can connect directly
to an application server via that server’s dispatcher (no message server
involvement

and therefore, no load balancing
).


Scenario

2
:

Some
application

provides
information/services to which
a
SAP
system

needs access. This
application

initiates a conversation with SAP
and then waits (listens) for calls
made
from SAP.


How it works:

Via the
SAP’s
RFC SDK,
third
-
party
applications can start listeners which
allow
SA
P applications

to communicate with them. To enable this
communication, the third
-
party application initiates a conversation with
a
SAP
application server
and registers itself with
that server’s

gateway.
Once the registration occurs, the
third
-
party appli
cation

will go into a
listen mode where it waits for a call from
a

SAP application.
Communication between SAP applications and the listeners registered on a
SAP gateway is made possible by the SAP application’s use “TCP/IP RFC
Destinations” which are main
tained via transaction code SM59 in any SAP
WebAS ABAP system.


Because of the three
-
tiered architecture of a SAP system, RFC Destination
definitions are the same on all of the applications servers (instances) of
a particular system. However, the listener
s to which the RFC destinations
point register themselves at the instance gateway layer which is specific
to each application server. This could cause a problem if a SAP
application running on one instance needs to make a call to a listener

that is only

r
egistered on a different instance.
To keep this situation
from
occurring
,
there are two work
-
arounds.


First, if the listening application supports it, a listener with the same
name can be registered with each instance gateway in the SAP system. This
all
ows that listener to be called using the same RFC destination
regardless of which instance the calling SAP application is loaded on.


The second solution is to only register the listener with one gateway and
then to identify that gateway in the definition
of the RFC destination.
By identifying the gateway, the SAP applications know that the listener is
only registered on a particular instance and all calls to that listener
will be routed through th
at

single gateway.


Diagram Next Page




Interface

Scenarios and Failover/High
-
Availability


With the BancTec production ECC landscape, regardless of the root cause,
there are two possible failover situations. The first possibility
involves the loss of any one or more dialog instance
s of the SAP system.
The second possibility is the loss of the central instance.


Dialog instance failure:

In the situation where a dialog instance suddenly fails,
all communication
with
any client currently logged on to that instance
or any listener
curr
ently connected to the gateway will immediately cease
.


With client connectivity, i
f the client
in question
uses the SAP system’s
logon group load balancing, then that client can immediately reinitiate a
logon to the system and will be routed to one of t
he remaining instances

in the requested logon group.
The additional load on the remaining
instances may result in reduced system performance, but the system is
still available and capable of processing transactions.


If a particular
dialog
instance of the

SAP system fails, any client which
connects directly to that instance, rather than using logon group load
balancing, will have to go through some amount of reconfiguration to
redirect the logon to
an

instance that is still available. The amount of
effort

required
to
reestablish the connection after a failure can vary
between minimal, a user adding a new entry to their logon pad, and
extensive, source code using the Java Connector changed to point to a
different server and the requiring a rebuild.


Central

instance failure:

If the central instance of a SAP system fails, depending on the type of
failure, the
SAP
system may or may not remain somewhat usable. In the
case where only the SAP application has failed on the CI but the server
and database remain av
ailable, any dialog instances will remain up and
connected to the database. Read operations will still work, however all
updates to the database will stop and begin to queue up. In these
circumstances, it is more likely that the reason for CI failure wil
l be
determined and, if possible, fixed as quickly as possible and the instance
will be restarted without declaring an emergency and initiating failover.


If the server hosting the central instance and database suffers a
catastrophic failure, where an emer
gency is declared and failover
procedures are initiated, for some amount of time, the SAP system will be
unavailable to all clients. Once failover is complete, and the system is
brought back online, all clients should, once again, be able to log on
regard
less of whether they are using logon load balancing or a direct
connection to an application server.

Note:
While the following description of connectivity after a failover is

not
comprehensive

and
is
overly simplistic, the underlying theory described does

pertain.


In the case of a CI/DB server failure, High
-
Availability methods are used
to bring both the database and the SAP central instance back up on
different hardware (the discussion of filesystem/database recovery is not
in the scope of this document
and is, therefore, not discussed here). In
the diagrams depicting the CI/DB server above, there are two IP addresses
listed for a single ethernet interface. The IP address for hostname
usplsbt088
, could be described as the actual hostname of the physical

server and the IP address for the hostname
ep1aci

could be described as an
alias (neither description is completely accurate, but the proper meaning
is conveyed). The new server, on which the CI and DB will be started
after failover, will have a differen
t actual
IP address
, for example
an IP
address that resolves to the hostname
usplsbt
999
, however the alias IP
address for
ep1aci
, will be added to one of the ethernet adapters on the
server. In this way, all client connection requests to the message serve
r
for the SAP system which resided on a server with the
ep1aci

DNS alias
will be able to be fulfilled after a failover is complete and the CI/DB is
brought up on new HW. Likewise, none of the dialog instances of the
system will require reconfiguration to
connect to the central instance.


Interface scenario 2 and failover:


In the case where SAP communicates with some other system via a gateway
registered process, neither method (all traffic routed through a single
instance or a different listener for each
instance) is particularly
impacted more than the other during a failover. The only caveat to this
statement is that, if a single listener is used, it should register itself
with the central instance of the SAP system because of that instances
increased av
ailability requirement.