efficient use of jco connections webdynprojava

SAP Know-How Network Conference

Efficient Use ofJCo Connections inWeb Dynpro Java

Chris Whealy, NetWeaver RIG EMEA, SAP UK

October ’08

Duration 31:51

© SAP 2008 / SAP TechEd 08 / COMP264

1. A Brief History of Remote Function Calls2. The Adaptive RFC Layer3. Web Dynpro and the Adaptive RFC Layer4. Understanding JCo Pools at Runtime5. Designing Applications for Efficient Use of JCo Connections6. JCo Connection Optimization7. Configuring an SAP Gateway Process8. Summary9. Appendix

Agenda


A Brief History of Remote Function Calls 1/5

The R/3 system’s predecessor was the mainframe based product called R/2.R/2 relied heavily on IBM’s transaction processing system known as CICS.IBM developed a communication API that allowed programs on different servers to call eachother. This was known as Common Programming Interface – Communications or CPI-C.

Physical Unit Controller

Logical Unit

Logical Unit

Token RingNetwork

R/2

RemoteSystem

Call to remoteprogram using CPI-C

Response from remoteprogram using CPI-C



As the successor to R/2, R/3 inherited the use of the CPI-C protocol for externalcommunication.Among the many processes making up an R/3 system, there is one processdedicated to handling external communication: the Gateway process.

R/3 System

Enqueue

V1 Update

Gateway

Message

Spool

Dialogue

Batch V2 Update

CPI-C Handler



R/3 System

ABAP RuntimeEnvironment

RFC

Lay

er RFC enabledABAP

FunctionModule

TCP/IP

At first, communication was limited to other SAP systems only, but with thedevelopment of the C RFC library, non-SAP systems could also invoke ABAPfunctionality.External programs have been able to invoke ABAP functionality within an R/3 system usingRemote Function Call (RFC) since version 2.0F (circa 1994).

Non-SAPSystem

Exte

rnal

Pro

gram

C R

FC L

ibra

ry

CP

I-C

Gat

eway

CP

I-C

Written in C



When Java compatibility was required for Remote Function Calls, the JCo layerwas added. This implementation still relied on the C RFC library.

Non-SAPSystem

Exte

rnal

Pro

gram

Written in Java

JCo

Laye

r

C R

FC L

ibra

ry

CP

I-C

R/3 System


RFC

Lay

er RFC enabledABAP

FunctionModule

TCP/IP

Gat

eway

CP

I-C


The latest version of JCo is a complete standalone Java implementation that nolonger depends on a C implementation of RFC.

Non-SAPSystem

Exte

rnal

Pro

gram

JCo

Laye

r

Java

RFC

CP

I-C

R/3 System


RFC

Lay

er RFC enabledABAP

FunctionModule

TCP/IP

Gat

eway

CP

I-C


Delivered assapjco3.jar



Agenda


SAP ASJava

The Adaptive RFC (aRFC) layer was developed both to overcome restrictionsimposed by previous proxy layers and to provide a full implementation of thefunctionality found in the JCo layer.

The Adaptive RFC Layer architecture inNetWeaver 7.0

WDFramework

JavaDictionary

SAP AS ABAP


RFC

Lay

er RFC enabledABAP

FunctionModule

TCP/IP

Gat

eway

CP

I-C

Web

Dyn

pro

Appl

icat

ion

Adap

tive

RFC

Lay

er

JCo

Laye

r

Java

RFC

CP

I-C


Dictionary Based Features Provided by theAdaptive RFC Layer

The Adaptive RFC layer provides dictionary based access to the metadataavailable in the JCo layer.

The aRFC layer makes the following metadata available at runtime such as:

Field labelsColumn headingsTool Tips

Value SetsDictionary Simple Types

If the interface to an ABAP function modules changes after your Web Dynproapplication has been deployed (E.G. a new field is added to a .APPEND structure),the aRFC layer will automatically update the local Java dictionary with the newmetadata.



Agenda


Model Objects in Web Dynpro Java 1/2

Accessing Services in a Backend ABAP SystemWeb Dynpro Applications call services in backend systems using Model Objects.This is true irrespective of whether the backend service is exposed as a:

Web Service

Remote Enabled ABAP Function Module

Enterprise Java Bean

Model Objects are created usingthe Model Wizard in the NetWeaverDeveloper Studio.


Model Objects in Web Dynpro Java 2/2

Accessing Services in a Backend ABAP SystemIn this case we are interested in the Adaptive RFC Model.

The process of creating the model is not the focus of our attention here; instead,we shall look at how logical systems (a.k.a. JCo Destinations) are created.


JCo Destinations in the Web DynproContent Administrator

Why are Two JCo Destination Names Needed?All aRFC model objects need two distinct JCo destination names.

One is used exclusively for obtaining dictionary based metadata from the ABAPsystem about the function module’s interface.

The other is used for actually invoking the function module.

The exact names you choose are not particularly important as long as they:Describe the type of data being obtained (E.G. FlightData or ServiceOrderData etc)

Do not contain the id of the backend SAP system (E.G. PRD or DEV)


JCo Destination Definition 1/7

How to Create a JCo DestinationA JCo destination identifies a physical backend SAP ABAP system without thebusiness application needing to know any specific details about either the identityof the physical system or the credentials needed to log on to it.

Firstly, you should: 1. Define the client

2. Define the pool’s dimensions



To Which J2EE Cluster will this JCo Destination Belong?All JCo destinations should be assigned to a particular J2EE cluster.

The typical situation is that JCo destinations are created for the local server.


JCo Destination Definition 3/7Configuration 1/2

Understanding the Configuration ValuesThe correct JCo Destination configuration values cannot be determined by asystem administrator in isolation from the Web Dynpro developer.The system administrator and the Web Dynpro developer must work together toanswer the following questions before the configuration can be done correctly:

1. How will the Web Dynpro coding make use of this JCo destination?How many models does the Web Dynpro application use?Do these models share the use of this JCo destination?How many applications could a user execute simultaneously?

2. Is it possible/likely that the user will run multiple instances of the same application?

Only when the above factors arecorrectly understood can the JCoDestination be configured efficiently.


JCo Destination Definition 3/7Configuration 2/2

What do the Configuration Values Mean?Maximum Connections : This determines the maximum number of connections

the pool may contain. This is the upper limit.

Maximal Pool Size : How many connections can remain open after theyhave been returned to the pool?

Connection Timeout : For how long will an unused connection remain openafter it has been returned to the pool?

Maximum Waiting Time : For how long will the JCo Pool Manager wait beforedeciding that a connection cannot be opened?



What Type of Connection is Needed?A Web Dynpro model needs two JCo destinations in order to function correctly.One is for obtaining metadata from the backend ABAP dictionary, and the other isfor actually invoking the ABAP function module.

Selecting “Application Data” gives you the option of whether or not to use logon load balancing.

Selecting “Dictionary Meta Data” forces the connection to point to a dedicated server.



Server IdentityDepending on which type of connection you chose on the previous screen, you willnow have to identify the server to which the JCo Destination will connect.

Before a server will appear in the drop down list however, it must have first beendefined as a Technical System in the System Landscape Directory (SLD).

This step is not covered in this material.



Defining User CredentialsTwo methods for user authentication are commonly used.TicketThe SAP Portal creates a single sign-oncookie at logon time. This is passed fromthe client, through the WD Framework to theJCo Layer when the Authentication Methodis set to “Ticket”.

Userid/PasswordA hard coded user id and password can beused. This is only suitable for dictionaryconnections, testing or where no audit trail ofindividual user activity is required.



Summary and FinishThe summary screen shows you all the configuration values.

The JCo destination is only created when you press “Finish”.



Agenda


Web Dynpro Framework

Understanding JCo Pools at Runtime 1/5

1. Opening or closing connections to the backend ABAP system

2. Management of connections into multiple backend ABAP systems

The first time a Web Dynpro application invokes the execute() method of anaRFC model, the Adaptive RFC layer instructs the JCo Layer to create aconnection pool according to the dimensions defined in the JCo Destination.

WD Application aRFC

JCo Layer

Pool

Man

ager

Pool

What is Connection Pooling?The concept of connection pooling means that a business application does notneed to care about:

Model



1. JCo Destination Name2. User Id3. Logon Language4. Authentication Method

How are JCo Pools Named?When the Pool Manager within the JCo Layer creates a new connection pool, itdoes so using the unique name supplied to it by the Adaptive RFC Layer.

A combination of four values is used:

FlightData_whealy_en_useDefinedUser




1. The Web Dynpro application invokes a model object’s execute() method2. If necessary, the JCo Pool Manager creates a new connection pool and opens the first

connection.3. The next available connection from the pool is allocated to the model object.

Important: For the duration of the model’s use of the JCo connection, the PoolManager looses contact with the connection object instance.

WD Application aRFC

JCo Layer

Pool

Man

ager

Pool

Connection Pooling in Action 1/3Here is the sequence of events that take place when an aRFC model is executed.

2

3

Model

1

ConnectionConnection




4. The model object is now able to invoke the required functionality in the ABAP system.5. When the connection is no longer required by the application, it is returned to the pool.6. The connection remains logged on to the backend system until either the next application

request is received, or the connection timeout is reached.7. If no application requests arrive before the timeout is reached, the connection is flagged

for closure.

If a new connection is subsequently required, the Pool will open a new one automatically.

WD Application

SAP ASABAP

aRFC

JCo Layer

Pool

Man

ager

Pool


4

Model

jRFC

.jar

Connection

5

6Connection

7X




8. The “Maximal Pool Size” value determines how many unused connections may remainlogged on to the backend system within the pool at any one time.

WD Application

SAP ASABAP

aRFC

JCo Layer

Pool

Man

ager

Pool


Model

jRFC

.jar

8



Connection



Agenda


How Many ABAP Function Modules Should One Adaptive RFCModel Contain?1. One function module per model?2. All the function modules needed by the current component?3. All the function modules needed by your application?4. As many as possible?

Option 1 is always wrong because it leads tohighly inefficient connection usage.Option 4 is also wrong because the resultingmodel will have very low reusability.Options 2 and 3 are possibly correct, but itdepends entirely on your business scenario.

Adaptive RFC Model

Designing Applications for Efficient Use of JCoConnections 1/2


The number of function modulesthat should be placed inside anAdaptive RFC Model is based onhow that Model will be reused.

In this example, a model object contains theproxy objects for 11 different function modules.

This is perfectly acceptable because all thesefunction modules are related to the samebusiness process (processing ServiceOrders) and therefore form a single unit ofreuse.

1234567891011

Designing Applications for Efficient Use of JCoConnections 2/2



User 1

APP1M1

M2

aRFC Layer

DEST1

DEST2AS ABAP (DEF)

AS ABAP (ABC)

User 1 Roll AreaABAP Session


An Application Should Consume the Minimum Number of JCoConnections at RuntimeIn this example, a user runs a single application that obtains data from two differentbackend ABAP systems. This means we need a JCo destination for each system.Two models are also required (M1 & M2) – this in turn will result in the creation oftwo pools, each with one connection to the respective backend system.

The following examples all demonstrate good design because each application consumesthe minimum number of JCo connections at runtime.

Connection Usage At Runtime 1/3One User Running One Application

DEST1_User1connection



The same user now starts APP2. This obtains data from the same two backendsystems, but this time using models M3 and M4.This results in two more connections being taken from the existing JCo pools,because the combination of values used to build the pool names has not changed.


User 1

APP1M1

M2

aRFC LayerDEST1_User1

connection


AS ABAP (DEF)

AS ABAP (ABC)



APP2M3

M4

connection

connection



Connection Usage At Runtime 2/3One User Running Two Applications


Web Dynpro FrameworkUser 1

APP1M1

M2

aRFC Layer



AS ABAP (DEF)

AS ABAP (ABC)



APP2M3

M4

connection

connection



User 2

APP1M1

M2

APP2M3

M4



connection

connection





Connection Usage At Runtime 3/3Two Users Running Same Two Applications



Agenda



User 1

APP1M1

M2

aRFC Layer

M1_DEST

M2_DEST

AS ABAP (ABC)



This is always wrong!Look at what happens if you create one JCo Destination per model.In this case, Web Dynpro application APP1 uses two models (M1 & M2) to accessthe same backend ABAP system

Two pools will therefore be createdThis in turn, causes the same user to logon twice to the backend ABAP system.This is very inefficient and could possibly lead to ABAP processing errors such as a lockconflict.

– but does so using two different JCo destinations.

and APP1 will use one connection from each.

How NOT to use JCo Connections! 1/2One JCo Destination per Model

M1_DEST_User1connection

M2_DEST_User1connection



User 1

APP1M1

M2


DEST1

DEST1

AS ABAP (ABC)



This is almost correct!Models M1 & M2 have now been altered to share the same JCo Destination.Consequently, only one JCo pool is created.However by default, each model gets its own connection from the pool, so we stillhave the same multiple logon problem in the backend ABAP system!

How NOT to use JCo Connections! 2/2Two Models – One JCo Destination

connection

connection



User 1

APP1M1

M2


DEST1

DEST1

connection

connection

AS ABAP (ABC)



Principle: Consume as few JCo connections as possibleIn this scenario, the BAPI calls found in models M1 & M2 cannot be combined into asingle model due to their having different reuse scenarios.However, model M2 can be told to share the same JCo connection used by modelM1. This is done by calling its setConnectionProvider() method.

Now the Web Dynpro application uses the minimum number of JCo connections, andconsequently, all the ABAP functionality executes in a single ABAP session.This eliminates the possibility of creating an ABAP lock conflict.

By calling m2.setConnectionProvider(m1),model M2 will use the same JCo connection asmodel M1.

How Models Can Share JCo Connections


Each Model Instance Has A Defined ScopeThe scope of a model determines how widely accessible the runtime instance is.There are several scope types:

APPLICATION_SCOPE (Default)COMPONENT_SCOPE (Deprecated)TASK_SCOPE (Stateless behaviour)VM_SCOPE ( Use Only)SERVERSESSION_AT_LEAST_ONE_APP_SCOPE ( Use Only)SERVERSESSION_SCOPE ( Use Only)NO_SCOPE (Not recommended)

Understanding Model Instance Scope 1/4


Application Scope 1/3The default scope type of APPLICATION_SCOPE is correct about 90% of the time.Without the concept of model scope, the problem of multiple logons to the backendABAP system would still occur.

Web Dynpro FrameworkUser 1APP1

M1

aRFC LayerDEST1

DEST1

AS ABAP (ABC)



Root Component

Child1

Child2

M1

Each model instance would get its own connection.This in turn, would lead to multiple logons for the same user in the ABAP system.



connection


Application Scope 2/3Even though the root component and component “Child1” both have independentusages of model M1 at design time, the scope type of APPLICATION_SCOPEensures that only one model instance exists at runtime.

Web Dynpro FrameworkUser 1APP1

M1

aRFC LayerDEST1_User1DEST1

connection

AS ABAP (ABC)


Root Component

Child1

Child2

M1

2. Therefore, only one connectionis allocated from the JCo Pool.

1. A single instance of modelM1 exists at runtime.

3. Consequently, only oneABAP session exists in thebackend system.




Application Scope 3/3If the situation is now scaled up so that two different model instances are used, wecan still use the setConnectionProvider() method to avoid multiple logons tothe backend system.

User 1APP1

M1

DEST1

Root Component

Child1

Child2

M1 aRFC LayerDEST1_User1

connection

M3

M3

connection

AS ABAP (ABC)



By calling m3.setConnectionProvider(m1),model M3 will share the same JCo connection asmodel M1.




Agenda


This will result in the Adaptive RFC Layer throwing an exception which in turn, willappear as an application error in the Web Dynpro Application.Unless you write specific coding to trap this type of error, the end user will see aJava stack trace on their screen!

Is the Gateway Process Configured Correctly?Under high work load situations, it is possible that the number of availableconnections in the Gateway process could become exhausted.



SAP AS ABAP

Enqueue

V1 Update

Gateway

Message

Spool

Dialogue

Batch V2 UpdateUser 1

APP1 M1Kaboom!

Configuring the SAP Gateway Process 1/2

connectionUnable to obtain

connection


Is the Gateway Process Configured Correctly?The number of connections in the Gateway must be configured correctly in order tohandle the maximum number of expected connections (default = 500).Each active connection in the gateway requires approximately 200Kb of memory.


User 1

APP1 M1


connection

SAP AS ABAP

Gateway

Enqueue

V1 Update

Message

Spool

Dialogue

Batch

V2 Update

User 2

APP1 M2

User n

APP1 Mn


DEST1_Usernconnection

Process Memory

Connection (~200Kb)Connection (~200Kb)

Connection (~200Kb)

Connection limit set by the kernelparameter gw/max_conn

Configuring the SAP Gateway Process 2/2



Agenda


JCo Destination Creation and Destruction1. Before a JCo destination can be created for an SAP system, that system must

first exist as a Technical System in your System Landscape Directory (SLD)2. JCo destination names are case sensitive!3. JCo connection pools are created lazily. A JCo pool will not exist until you

call the execute() method of the first RFC module using that pool.4. The Adaptive RFC layer names JCo connection pools by combining:

1. JCo Destination2. User Id3. Logon Language4. Authentication Method

5. JCo connection pools are destroyed either when:1. When the application ends through the user logging off, closing their browser,

issuing a URL to a different website, or allowing the application to time out.2. Coding is written that explicitly releases the pool.

JCo Destination Summary 1/4


JCo Pool Behaviour6. By default, when different models request connections from the same pool,

they will be allocated different connections.7. Within a single application, the setConnectionProvider() method should

be used to ensure that JCo connections are shared by different modelsneeding access to the same backend system.

8. In addition to the number of JCo connections required by the applicationconnections, a pool will be created for the JCo metadata destination.

9. The number of metadata connections required will be optimized according tothe destination and user id.

This optimization is performed across the entire Adaptive RFC layer;therefore, one connection will be shared by all models, in all applications,connecting to the same backend system with the same user id.

For this reason, a JCo destination used for metadata should always use ahard coded ABAP user id of type “System” rather than ticket basedauthentication.




JCo Pool Size Configuration10. There is no single calculation for pool size requirements that will work in all

situations; however, the following approach offers a good starting point.For each Web Dynpro application:

– Calculate the number of JCo pools in use. This is done by deriving the number ofJCo Destination/User Id combinations in use.

– Each model instance will consume its own connection from the pool unless thesetConnectionProvider() method is used.

– This gives the number of connections that will be required by one user running theapplication.

Multiply the number of connections required by a single application instance, by thenumber of expected concurrent users of that application.Repeat this calculation for each available Web Dynpro application. This gives theminimum number of RFC connections your back-end SAP system must provide forWeb Dynpro (in addition to any other Gateway connections that may be required).Check with your Basis Administrator that the Dispatcher RFC parameters(rdisp/rfc_*) and Gateway parameters (gw/*) are configured correctly for theexpected work load.



Monitoring JCo Connections1. At runtime, the SAP Gateway process can be monitored using transaction

SMGW

2. The memory consumption of the gateway process is proportional to thenumber of active RFC connections

3. For high workload environments, the gw/max_conn parameter should beadjusted (default value = 500):

Important!For SAP systems having a kernel version <= 6.40, the parameter gw/max_connhas a hard coded upper limit of 2000. Setting the parameter to a value higher thanthis will have no effect!



Agenda


Understanding Connection Timeouts 1/3

It is important to understand that when a JCo Connection has reached its timeoutlimit, it is only flagged for closure. The actual closure of the connection happenswhen the pool performs its periodic timeout check.

The default timeout check period is 60 seconds

This value can only be changed programmatically.


Configurable throughthe Content Administrator

Configurableprogrammatically


1. When a JCo connection is returned to the pool, as long as it remains unused, will stay openuntil the connection timeout duration is reached.

2. The pooled connection is flagged for closure, but remains open in the backend system.3. The connection is actually closed when the pool makes its periodic timeout check.

JCo Layer

Pool

Man

ager

Pool

AS ABAP (DEF)

User Roll AreaABAP Session

Connection

X

1

2

3

X



If you feel that unused connections are remaining open for too long in your back endsystem, then the following coding will let you alter the timeout check period.

You should only reduce this value if the Gateway process in your ABAP system isrunning close to its connection limit.

// As long as we can see the SLD...if (WDSystemLandscape.pingSLDConnection()) {// Get all the pool names from the pool managerPoolManager poolMan = JCO.getClientPoolManager().singleton();String[] poolNames = poolMan.getPoolNames();

// Choose some particular poolPool thisPool = poolMan.getPool(poolNames[<some_int_val>]);

// Set the Timeout Check Period to 30s (for instance)long timeoutVal = 30000L;thisPool.setTimeoutCheckPeriod(timeoutVal);

}else {// No SLD available, so pack up and go home...

}

Finding the JCo Pool Timeout Check Period


Classroom Based Web Dynpro Training

Introduction to Web Dynpro JavaCourse Code: JA310

Advanced Web Dynpro for Java:Course Code: JA312

SAP Press books on Web Dynpro for Java

Maximising Web Dynpro for JavaBertram Ganz

Jochen GürtlerTimo Lakner

ISBN 1-59229-077-9

Inside Web Dynpro for JavaChris Whealy

ISBN 978-3-89842-092-5

Further Online Web Dynpro Training

Please return to theWeb Dynpro Mind Mapto start the next online

training session

Title Music

“What Goes Around”Robert Walter’s 20th Congresshttp://www.robertwalter.com

Free Download from http://rw2c.thropter.com/index.asp(Registration required)

Credits

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/WDJava/Learning+Map

http://www.robertwalter.com/

http://rw2c.thropter.com/index.asp


Copyright 2008 SAP AGAll Rights Reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changedwithout prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed arethe trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior writtenpermission of SAP AG. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies,developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note thatthis document is subject to change and may be changed by SAP at any time without notice. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant theaccuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express orimplied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitationshall not apply in cases of intent or gross negligence.

The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in thesematerials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durchSAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden.

Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.

SAP, R/3, xApps, xApp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Services sowie diedazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähnten Namen vonProdukten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zuInformationszwecken. Produkte können länderspezifische Unterschiede aufweisen.

Die in dieser Publikation enthaltene Information ist Eigentum der SAP. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Formauch immer, nur mit ausdrücklicher schriftlicher Genehmigung durch SAP AG gestattet. Bei dieser Publikation handelt es sich um eine vorläufige Version, die nicht Ihrem gültigen Lizenzvertragoder anderen Vereinbarungen mit SAP unterliegt. Diese Publikation enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP®-Produkts. SAP entsteht aus dieserPublikation keine Verpflichtung zu einer bestimmten Geschäfts- oder Produktstrategie und/oder bestimmten Entwicklungen. Diese Publikation kann von SAP jederzeit ohne vorherigeAnkündigung geändert werden.

SAP übernimmt keine Haftung für Fehler oder Auslassungen in dieser Publikation. Des Weiteren übernimmt SAP keine Garantie für die Exaktheit oder Vollständigkeit der Informationen, Texte,Grafiken, Links und sonstigen in dieser Publikation enthaltenen Elementen. Diese Publikation wird ohne jegliche Gewähr, weder ausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a.,aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zweck sowie für die Gewährleistung der Nichtverletzung geltenden Rechts.SAP haftet nicht für entstandene Schäden. Dies gilt u. a. und uneingeschränkt für konkrete, besondere und mittelbare Schäden oder Folgeschäden, die aus der Nutzung dieser Materialienentstehen können. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit.

Die gesetzliche Haftung bei Personenschäden oder Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinks zugreifen,unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen über InternetseitenDritter ab.

Alle Rechte vorbehalten.

efficient use of jco connections webdynprojava

Documents