Jco 31 Documentation
Jco 31 Documentation
Release 3.1
Copyright
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express
permission of SAP SE. The information contained herein may be changed without prior notice.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other
software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries,
pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5,
OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe
Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered
trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium,
Massachusetts Institute of Technology.
Java is a registered trademark of Oracle Corporation.
JavaScript is a registered trademark of Oracle Corporation.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP SE in Germany and in several other countries all over
the world. All other product and service names mentioned are the trademarks of their respective companies. Data
contained in this document serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP SE and its affiliated
companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP
Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express warranty statements accompanying such products
and services, if any. Nothing herein should be construed as constituting an additional warranty.
Icons in Body Text
Icon Meaning
Caution
Note
Recommendation
Example
Typographic Conventions
File, package and directory names and their paths, names of classes, variables and
Example text
parameters, and names of installation, upgrade and database tools
Document Version
Implementation Notes
• For an IDoc-based communication you can additionally use the IDoc Class Library.
• You can access the SAP JCo and IDoc class library installation files at https://support.sap.com/jco
Note the additional information on the download page of the SAP Service Marketplace. See SAP
note 2786882 or detailed information on supported platforms.
Procedure
The following instructions apply for Windows and Linux operating systems. The instructions for the
installation of SAP JCo on the individual operating systems are included in the corresponding download files.
6
1. Create a directory, for example C:\SAPJCo, and extract the sapjco31P_<pl>.zip file into this directory
and expand the ZIP or tgz that is contained in the archive.
2. Make sure that the file sapjco3.jar (in the SAP JCo main directory) is contained in the class path for
all projects for which you want to use the SAP JCo.
For productive operation, the following files from the archive within sapjco31P_<pl>.zip file are
required:
• sapjco3.jar (Windows and Linux)
• sapjco3.dll (Linux: libsapjco3.so)
SAP highly recommends that you store sapjco3.jar and sapjco3.dll (libsapjco3.so)
in the same directory.
The downloaded .zip file also contains the javadoc directory that contains the Javadoc for SAP JCo as
well as information about the installation, release notes, and the examples. The Javadoc contains an
overview of all SAP JCo classes and interfaces that are allowed to be used by applications, together with a
detailed description of the corresponding objects, methods, parameters, and fields. Start with the file
intro.html (<drive>:\<SAPJCo>\javadoc\ intro.html) and jump to the other topics in the
navigation bar at the top.
Interface Use
JDSR Passport Manager Interface for client connections to an SAP ABAP
ClientPassportManager application server backend. By default, passports are not sent to the ABAP
system.
Provides the properties for a client connection to a remote SAP system. The
default implementation searches <destname>.jcoDestination files in the
DestinationDataProvider
work directory and is thought for an easy start with JCo, but not for productive
usage.
Provides the properties for a client connection to a remote SAP system via a
message server. The default implementation searches
MessageServerDataProvider
<messageservername>. jcoMessageServer files in the work directory
and is thought for an easy start with JCo, but not for productive usage.
7
Interface Use
Can be implemented by a runtime environment that has a multi-tenancy
TenantProvider concept to provide information about the current tenant context. By default,
JCo assumes to run within a single tenant environment.
For all those runtime embedding capabilities, the highlander principle is in place: There can be only one
instance registered with JCo runtime. Hence, deployments should be separated from business application
code.
You should always implement the interface DestinationDataProvider to optimize data security. If you
are using server functionality you should also implement ServerDataProvider. These interfaces support
the secure storage of critical data.
If application scenarios use stateful call sequences that could span multiple threads, you must
implement SessionReferenceProvider and register an instance of it using the Environment
class. This interface connects JCo with session management. As of JCo 3.1, session events are
supported for a better integration.
You can find details and an example implementation in the JCo installation directory: examples/
com/sap/conn/jco/examples/advanced/multithreading
If application scenarios want to isolate runtime objects from each other, you must implement
TenantProvider and register an instance of it using the Environment class. This interface separates
JCo-related data for each tenant.
You can find details and an example implementation in the JCo installation directory: examples/
com/sap/conn/jco/examples/advanced/MultiTenantExample.java.
8
CLIENT PROGRAMMING
The following section provides an overview of the main elements of client programming when using SAP JCo
3.1 as a standalone component (External (non-SAP) Java calls AS ABAP).
More Information
For an overview of all SAP JCo classes, objects, methods, parameters, and fields, see the Javadoc. These
HTML files are available in the javadoc directory of the SAP JCo installation.
By specifying the destination name, the corresponding connection (pool) is set up in the background.
The destinations to be called are managed using a destination manager and provided by
JCoDestinationManager.
The destination manager retrieves the destination properties from DestinationDataProvider.
DestinationDataProvider is an interface that should be implemented depending on the corresponding
environment. It gives access to all destinations in the storage it represents and not only a single destination
instance.
The implementation delivered by the JCo distribution reads the destination configuration from the file system
in the work directory as <destinationName>.jcoDestination. However, this procedure is
recommended only for development and testing. Within a productive environment, an adequate and secure
solution should be applied.
10
Defining Destinations
The first step defines destination names and properties.
For this example, the destination configuration is stored in a file that is called by the program. In
productive solutions you should avoid this for security reasons and implement a custom destination
data provider (see below).
@Override
public boolean supportsEvents()
{
return false;
}
@Override
public void setDestinationDataEventListener(DestinationDataEventListener eventListener)
{
}
}
11
Creating Destinations
In this section you find a programming example for structuring a connection to an AS ABAP using the JCO
destination concept.
Because the connection type (direct or pool connection) is determined by the destination configuration, it is
set implicitly by specifying the destination name. Furthermore, it is not necessary for the application to know,
which DestinationDataProvider is in place, it simply relies on the destination name and assumes that
properties for that destination are available in the storage.
Connection to an AS ABAP
JCoDestination dest = JCoDestinationManager.getDestination(DESTINATION_NAME);
System.out.println("Attributes: " + dest.getAttributes());
Custom destination
JCoCustomDestination cust_dest = dest.createCustomDestination();
UserData usData = cust_dest.getUserLogonData();
usData.setUser("HUGO");
usData.setPassword("HUGO");
try
{
function.execute(dest);
}
catch (AbapException e)
{
System.out.println(e);
}
12
Executing a Stateful Call Sequence
You need a stateful connection to an AS ABAP if you want to execute multiple function calls in the same
session (in the same context).
Therefore, you must declare a stateful connection explicitly.
try
{
JCoContext.begin(dest);
try
{
bapiFunction1.execute(dest);
bapiFunction2.execute(dest);
bapiTransactionCommit.execute(dest);
}
catch (AbapException ex)
{
bapiTransactionRollback.execute(dest);
}
}
catch (JCoException ex)
{
}
finally
{
JCoContext.end(dest);
}
If you want to start an SAP GUI on an external client, your SAP backend system must meet some
requirements. You will find detailed information in SAP note 1258724.
13
To start an SAP GUI from your client program, proceed as follows:
Windows:
Set the property USE_SAPGUI to 1 (visible) or 2 (hidden).
Prerequisite: You have installed the Windows SAP GUI on your system.
Possible values are:
0: no SAPGUI (default)
1: attach a visible SAPGUI.
2: attach a "hidden" SAPGUI, which just receives and ignores the screen output.
Unix:
For Unix systems, a Java SAP GUI is required. In addition, the environment variable SAPGUI needs to be
set.
Set the environment variable via:
setenv SAPGUI <path to SAPGUI start script> (tcsh) or
export SAPGUI=<path to SAPGUI start script> (bash)
You must not add any parameter after the script name.
Start the JCo application from the same shell to propagate the environment variable to the program.
Scalar Parameters
14
4. After execution, the export parameter list can be accessed by getExportParameterList().
5. Like setValue(<name>, <value>) you can call getValue(<name>) in order to retrieve the content
as the Java type that is fitting best to the ABAP type.
6. The method setValue(<index>, <value>) is useful in JCoStructure and JCoTable, as the
position is clear when accessing concrete fields in those cases.
If you know the data type of the respective field, you can also call type-specific get methods (see in
section "Using suitable getter methods").
If a parameter should never be sent or fetched, you can call setActive() in which first the name,
and then the new state is entered (see here).
try
{
function.execute(dest);
}
catch (AbapException e)
{
System.out.println(e);
return;
}
System.out.println("STFC_CONNECTION finished:");
System.out.println(" Echo: " + function.getExportParameterList().getString("ECHOTEXT"));
System.out.println(" Response: " + function.getExportParameterList().getString("RESPTEXT"));
Reading a Table
In the next example the function module BAPI_COMPANYCODE_GETLIST is called and a table of all the
company codes is displayed. This RFM does not contain any import parameters.
...
1. First, the structure RETURN is checked. The content of each field of a structure can be accessed
similarly with getValue() methods. For flat and char-like structures/tables getString() can be called,
which returns all fields of the current row at once.
2. Second, if the returned type fits, the table is accessed with getTableParameterList().
3. Within this list, access the actual table (getTable(<name>)). The interface JCoTable contains all
methods that are available for JCoStructure, together with additional methods for navigation in a table.
A table can have an arbitrary number of rows or can also have no rows at all.
The code snippet below shows navigation with the method setRow(<row>), in which the current row
pointer is moved to every row in the table in turn. The method getNumRows() specifies how many rows
exist in total. Instead of using setRow(<row>), you can also use the method nextRow(), which moves
the row pointer by one as displayed in the lower section of the code snippet.
15
Accessing a Structure and Table
JCoFunction function = dest.getRepository().getFunction("BAPI_COMPANYCODE_GETLIST");
if (function == null)
throw new RuntimeException("BAPI_COMPANYCODE_GETLIST not found in SAP.");
try
{
function.execute(dest);
}
catch (AbapException e)
{
System.out.println(e);
return;
}
Modifying a Table
In many applications it is not enough to be able to access table fields or navigate through a table, you also
often need to add or delete rows. SAP JCo provides methods that enable you to do this. Normally, you add
rows for table parameters that are sent to the AS ABAP (for example, adding items to a customer order).
The following table summarizes the JCoTable methods that are not contained in JCoStructure.
Method Description
int getNumRows() Returns the number of rows.
16
Method Description
void appendRow() Adds one row at the end of the table.
void appendRows(int Adds multiple rows at the end of the table (better performance than calling
num_rows) appendRow() multiple times).
Modifying a Table
In this example we fill a table with 100 rows having all the same company code. The respective set methods
will convert the value of the passed object to the field in the current row.
[...]
codes.appendRows(100);
codes.firstRow();
do
{
codes.setValue("COMP_CODE", "YYYY"); // or setString
}
while (codes.nextRow());
Using Multi-Threading
Most applications run in several threads. JCo classes like repository or destination are synchronized and
may be used from several threads at the same time.
As long as all stateful call sequences are executed within the same thread (i.e. in the same thread the first
call has been performed in), the default SessionReferenceProvider implementation provided by JCo is
sufficient.
However, within an application server this is frequently not the case, and a running session may change the
thread while being processed.
In this case the environment must provide an adequate implementation of SessionReferenceProvider.
This enables the JCo runtime to assign the function module executions in different threads to a unique
session and can thus decide which connection needs to be chosen in order to end up in the correct ABAP
session for all of the stateful function module executions.
In a multi-thread environment, the use of container objects (for example, JCoTable objects) from
different threads must be implemented carefully. Note further, that it is not possible to make multiple
concurrent SAP calls for the very same connection. Hence, if a JCoContext was started within a
session, you cannot execute multiple requests in concurrent threads belonging to this session at the
very time. When trying this a JCoException with group JCO_ERROR_CONCURRENT_CALL will be
thrown in the second thread trying to perform an execution.
17
SAP JCo Repository
The SAP Java Connector must be able to access the metadata of all Remote Function Modules (RFMs) that
are to be used by a Java client. A JCoRepository object is created to do this. The current metadata for the
RFMs is retrieved either dynamically from the AS ABAP at runtime (recommended), from a previously
serialized instance, or hard-coded.
You must only create the JCoRepository object in the case of hard-coded metadata. This step is
automatically executed internally by JCo when retrieving metadata.
Obtaining a Repository
For the JCo Repository, you need the following interfaces:
• JCoRepository: Contains the runtime metadata of the RFMs.
• JCoFunctionTemplate: Contains the metadata for an RFM.
• JCoFunction: Represents an RFM with all its corresponding parameters.
• JCoListMetaData: Defines the metadata for parameter lists of an RFM.
• JCoRecordMetaData: Defines the metadata for structures and tables.
Make sure that the user ID for the Repository has all the required authorizations for accessing the metadata
of the AS ABAP. (See SAP note 460089.)
The user ID used for repository queries is specified on the corresponding destination.
You must lock the metadata before using them to avoid any unintended changes. For repositories
with dynamic lookups the lock happens automatically
18
Getting the JCoRepository from a JCoDestination
JCoRepository mRepository;
mRepository = dest.getRepository();
In addition to the fitting metadata, a function object also contains the current parameters for executing the
RFMs. The relationship between a function template and a function in SAP JCo is like that between a class
and an object in Java. The code displayed above encapsulates the creation of a function object.
SAP recommends that you create a new function object for each individual execution. By doing so
you can ensure that the parameters do not contain any elements from previous calls, which is very
likely undesired.
19
ABAP Type Description Java Java Type Code
Data
Type
utclong Timestamp String JCoMetadata.TYPE_UTCLONG
In most cases, handling of data types does not represent a problem. However, the ABAP data types for date
and time have some special features. ABAP has two different data types for processing date and time
information:
• ABAP data type T is a 6-char string with the format HHMMSS
• ABAP data type D is an 8-char string with the format YYYYMMDD
Both data types are used in RFMs (including BAPIs). When a BAPI uses a time stamp two fields are used,
one of type D and one of type T.
Java, however, only uses one class (Date) to represent both date and time information. In Java, a time
stamp can therefore be displayed in one variable.
SAP JCo automatically performs the conversion between ABAP and Java data types. Fields of the ABAP
data types D and T are represented as Java Date objects, whereby the part of the Date object that is not
used retains its default value. Java developers must distinguish between whether a field contains an ABAP
date value or an ABAP time value.
20
JCo Type Code JCo Access Method
JCoMetadata.TYPE_STRING String getString()
JCoMetadata.TYPE_XSTRING byte[ ] getByteArray()
JCoMetadata.TYPE_DECF16 BigDecimal getBigDecimal()
JCoMetadata.TYPE_DECF34 BigDecimal getBigDecimal()
JCoMetadata.TYPE_INT8 long getLong()
JCoMetadata.TYPE_UTCLONG String getString
It is not required to use exactly the methods mentioned above for a concrete datatype. JCo will try to
convert any value to the Java type and if this is not possible, ConversionException will be
thrown.
As already denoted above using JCoField only makes sense in very special cases. Usually, it is
better to use the data containers and the corresponding set and get methods directly, in particular,
with regards to performance they are superior to JCoField.
21
Deactivating Parameters
function.getExportParameterList().setActive("COMPANYCODE_ADDRESS", false);
Connection check
Using the property jco.destination.pool_check_connection in the DestinationDataProvider,
you can now check the availability of a connection before the actual RFM call. It is possible to recognize
corrupted connections, and avoid exceptions passed to applications if connectivity is working in principle.
The state of this property can be checked with isPooledConnectionChecked() in JCoDestination.
22
You can now create a message server from JCoMessageServerFactory and retrieve its system
information:
public static void main(String[] args)
throws MessageServerQueryException, JCoException
{
MyMessageServerProvider msp = new MyMessageServerProvider();
Environment.registerMessageServerDataProvider(msp);
// get information
for (JCoLogonGroup logonGroup : messageServer.getLogonGroups())
System.out.println(logonGroup.getName());
Environment.unregisterMessageServerDataProvider(msp);
}
@Override
public void setMessageServerDataEventListener(MessageServerDataEventListener eventListener)
{
}
@Override
public boolean supportsEvents()
{
return false;
}
}
23
Exception Handling
For exception handling, you need the following classes:
• JCoException: root class for exceptions.
o If the group JCO_ERROR_SYSTEM_FAILURE is used by the JCoException, then there are multiple
causes possible: It could be an ABAP message (will provide message related info in addition), a short
dump of the work process, or a corer dump. Check in the ABAP system for the reason, the runtime
error monitor (transaction ST22) could be a good entry point. In this case, the connection will be
closed and if a connection was set to stateful, the state will be lost.
o ABAPException: subclass for exceptions thrown by an RFM. The connection remains open and can
still be used.
An AbapException occurs if the ABAP code that you have called with JCo throws a classic
exception. Check in the ABAP code for the reason.
24
Exception Handling – Option 2
public void executeFunction(JCoFunction function, JCoDestination dest)
{
Try
{
function.execute(dest);
}
catch (AbapException ex)
{
// clause 1
if (!ex.getKey().equalsIgnoreCase("RAISE_EXCEPTION"))
{
// ...
}
}
catch (JCoException ex)
{
// clause 2
logSystemFailure(ex.getMessage());
}
catch (JCoRuntimeException ex)
{
// clause 3
}
catch (Exception ex)
{
// clause 4
}
}
More Information
You can find a detailed description of the individual exception classes in JCo Javadoc in the installation
directory javadoc.
25
SERVER PROGRAMMING
The following section explains how you can write your own JCo server program, if you use the standalone
version of the SAP JCo.
A JCo server program implements functions that are called by an ABAP backend. The JCo server program is
registered via one (or more) SAP Gateways and waits for inbound RFC calls.
1. An RFC server program registers itself under a program ID to an SAP gateway (not for a specific SAP
system).
2. If an RFC call is passed on from any SAP system to this SAP gateway with the option “Connection with a
registered program” (with the same program ID), a connection is opened to the corresponding JCo
server program.
3. Once a remote-enabled function module has been executed, the JCo Server waits for further RFC calls
from the same or other SAP systems.
4. If an RFC connection is interrupted or terminated, the JCo server automatically registers itself again on
the same SAP gateway under the same program ID.
Prerequisites
• You are using the standalone version of SAP JCo.
• You have defined a destination with connection type T (TCP/IP connection) in the SAP system via
transaction SM59.
• You have chosen the registration mode (“Registered server program” option under the “Technical
settings” tab) for this destination.
• The gateway information in the destination matches the corresponding parameters used for starting the
registered RFC server program.
www.sap.com/contactsap
The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.
ABAP Program for RFC Inbound Connection
In transaction SE38, create a report with the following coding:
DATA: REQUTEXT LIKE SY-LISEL,
RESPTEXT LIKE SY-LISEL,
ECHOTEXT LIKE SY-LISEL.
IF SY-SUBRC NE 0.
WRITE: / 'Call STFC_CONNECTION SY-SUBRC = ', SY-SUBRC.
WRITE: / RFC_MESS.
ENDIF.
Function Handler
This function prints out some connection information and responds by copying the import text
REQUTEXT to ECHOTEXT and adds a RESPTEXT.
public class StfcConnectionHandler implements JCoServerFunctionHandler
{
@Override
public void handleRequest(JCoServerContext serverCtx, JCoFunction function)
{
System.out.println("call: " + function.getName());
System.out.println("ConnectionId: " + serverCtx.getConnectionID());
System.out.println("gwhost: " + serverCtx.getServer().getGatewayHost());
// [...]
27
Defining Server Properties
The first step defines a server name and properties.
For this example, the server configuration is stored in a file that is called by the program. In practice
you should avoid this for security reasons and implement an individual server data provider (see
below).
@Override
public Properties getServerProperties(String serverName) throws DataProviderException
{
// here the properties need to be fetched from a secure storage
return SomeSecureDatabase.getProperties(serverName);
}
@Override
public boolean supportsEvents()
{
return false;
}
@Override
public void setServerDataEventListener(ServerDataEventListener eventListener)
{
}
}
28
Setting up a JCo Server
server.start();
The DefaultServerHandlerFactory is enough for most of the use cases and should preferred if
possible. In case you need to offer a more sophisticated implementation for your server, it might
become necessary to implement a custom JCoServerFunctionCallHandlerFactory. In this
case, the implementation needs to return the fitting FunctionCallHandler for the concrete
invocation.
29
Exception and Error Listener
public class MyThrowableListener
implements JCoServerErrorListener, JCoServerExceptionListener
{
30
Processing an ABAP Call
The application code that processes an RFC call, should in general trigger only ABAP exceptions and ABAP
messages. All other (runtime) exceptions that are thrown by handleRequest() are reported back to the
SAP system as a SYSTEM_FAILURE.
As mentioned before, the exception and error listeners are not informed about this exception, as it is thrown
by application code in handleRequest().
tRFC/qRFC Calls
For the use of tRFC and qRFC, the following call sequence is triggered:
Processing requires a custom implementation of JCoServerTIDHandler.
31
3. commit(String tid) or rollback(String tid)
Depending on the result of the function invocations, if none of the handleRequest() invocations has
thrown any exceptions, commit is called. Otherwise rollback is called. It is important to ensure atomic
execution of the transactions, i.e. the transaction is done completely or not at all, as well as exactly once
semantics. The application needs to guarantee this behavior, e.g. if TIDs are stored in a DB, a respective
commit or rollback should be performed. Also, if the application code in the function performs such logic,
it needs to commit altogether or rollback all changes made during processing of the function modules that
are contained in the unit.
4. confirmTID(String tid)
At this point, the application is informed that the client knows that the request has ended for the specified
TID. The application can now release all resources associated with this TID.
Under certain circumstances, this call might be received in a different Listener or, if problems arise, may
not be received in the ABAP backend system at all.
bgRFC Calls
For bgRFC, the process is similar. The difference is, that the ID is passed as an instance of
JCoUnitIdentifier instead of a string. Furthermore, the application needs to implement
getFunctionUnitState(unitIdentifier) which returns the current JCoFunctionUnitState and
for that must track the current state of each unit.
32
Server Security
Authentication
With the JCoServerSecurityHandler, you can check permissions of the user who initiated the RFC
request. Besides the authorization also the authentication can be checked now. This can be done after the
JCoServerSecurityHandler is registered on the JCoServer instance with
JCoServer.setSecurityHandler() by implementing the method checkAuthentication().
An example implementation is shown in the following code snippet. Depending on what kind of
authentication data you want to evaluate, you can only check certain types. If authentication fails, a
JCoApplicationAuthenticationException needs to be thrown.
class JCoServerSecurityHandlerImpl implements JCoServerSecurityHandler
{
@Override
public void checkAuthentication(JCoServerContextInfo serverCtxInfo,
JCoServerAuthenticationData... authenticationData)
throws JCoApplicationAuthenticationException
{
JCoServerAuthenticationData data;
for (int i = 0; i < authenticationData.length; i++)
{
data = authenticationData[i];
switch (data.getAuthenticationMode())
{
case SNC:
validateAuthenticationKey(data.getAuthenticationKey());
break;
case SSO:
validateSSOTicket(data.getSSOTicket());
break;
case X509:
validateX509Certificate(data.getX509Certificate());
break;
default:
break;
}
}
}
}
33
• jco.server.system_id – the system ID of the system the message server belongs to
Optionally, you can also define:
• jco.server.group – the logon group defined in ABAP which is identifying a set of application servers
• jco.server.update_interval – the update time how often the list of application servers is fetched
from the message server
The set of properties can also be retrieved from the JCoServer instance with the respective getter methods.
Features
The Java IDoc class library provides the basic functionality for working with IDocs. This includes:
• Procuring and managing the metadata for IDoc types
• Navigation through an IDoc
• Constructing an IDoc
• Sending IDocs via the tRFC port in the ALE interface
• Receiving IDocs via the tRFC port in the ALE interface
An integrated IDoc XML processor enables the direct transformation from IDoc XML to the binary IDoc
format and vice versa.
The IDoc XML processor is not an XML processor for general XML conversion purposes.
Implementation Considerations
The IDoc class library is a separate software component you can downloaded in addition to SAP JCo 3.1
separately from SAP Service Marketplace.
In contrast to former versions, the current IDoc class library 3.1 is based – like SAP JCo 3.1 – on a
destination model for the communication with partner systems.
Further Information
You can find detailed information on the IDoc class library in the Javadocs of the IDoc class library
installation files.
An example for using the IDoc class library for IDoc communication via SAP JCo 3.1 (acting as a client or
server) is included in IDocClientExample.java and IDocServerExample.java.
34