LDAP Directory Services versus the SAP Interfaces File

The LDAP driver implements directory services for use with an LDAP server.

LDAP directories provide:

Interfaces File

Directory Services

Platform-specific

Platform-independent

Specific to each SAP installation

Centralized and hierarchical

Contains separate master and query entries

One entry for each server that is accessed by both clients and servers

Cannot store metadata about the server

Stores metadata about the server

LDAP directory services support more attributes than the SAP interfaces file. These attributes can include server version, server status, and so on.

Note: LDAP is supported only with reentrant libraries. When you are connecting to a server using LDAP directory services, you must use isql_r, instead of isql.
SAP LDAP Directory Definitions

Attribute Name

Value Type

Description

ditbase

interfaces file or libtcl.cfg

DIT base for object tree. If the libtcl.cfg file is specified, the interfaces file is ignored. You can use ct_con_prop() to override the libtcl.cfg file for a specified connection.

dn

Character string

Distinguished name. Must be a unique name that identifies the object.

sybaseVersion

Integer

Server version number.

sybaseServername

Character string

Server name.

sybaseService

Character string

Service type: SAP ASE, or SAP SQL Server.

sybaseStatus

Integer

Status: 1 = Active, 2 = Stopped, 3 = Failed, 4 = Unknown.

sybaseAddress

String

Each server address includes:

  • Protocol: TCP, NAMEPIPE, SPX DECNET (entry is case-sensitive).

  • Address: any valid address for the protocol type.

    dscp splits this attribute into Transport type and Transport address.

sybaseSecurity (optional)

String

Security OID (object ID).

sybaseRetryCount

Integer

This attribute is mapped to CS_RETRY_COUNT, which specifies the number of times that ct_connect retries the sequence of network addresses associated with a server name.

sybaseRetryDelay

Integer

This attribute is mapped to CS_LOOP_DELAY, which specifies the delay, in seconds, that ct_connect waits before retrying the entire sequence of addresses.

sybaseHAservername (optional)

String

A secondary server for failover protection.

The traditional interfaces file with TCP connection and a failover machine looks like:

master tcp ether huey 5000
query tcp ether huey 5000
hafailover secondary
An example of an LDAP entry with TCP and a failover machine looks like:
dn: sybaseServername=foobar, dc=sybase,dc=com
objectClass: sybaseServer
sybaseVersion: 1500
sybaseServername: foobar
sybaseService: ASE
sybaseStatus: 4
sybaseAddress: TCP#1#foobar 5000
sybaseRetryCount: 12
sybaseRetryDelay: 30
sybaseHAServernam: secondary

All entries in the LDAP directory service are called entities. Each entity has a distinguished name (DN) and is stored in a hierarchical tree structure based on its DN. This tree is call the directory information tree (DIT). Client applications use a DIT base to specify where entities are stored.

In the example above, the entry describes an SAP ASE named “foobar” listening on a TCP connection with a port number of 5000. This entity also specifies a retry count of 12 (times) and a retry delay of 30 (seconds). Once a client has found an address where a server responds, the login dialog between the client and the server begins.

You can find a complete list of the SAP LDAP directory schema in %SYBASE%\%SYBASE_OCS%\ini. In the same directory, there is also a file called sybase-schema.conf, which contains the same schema, but uses a Netscape-specific syntax.

Since LDAP supports multiple entries for each attribute, each address attribute must contain the address of a single server, including protocol, access type, and address.

For example, this is an LDAP entry for an Windows server listening on two addresses, with different connection protocols:

sybaseAddress = TCP#1#TOEJAM 4444
sybaseAddress = NAMEPIPE#1#\pipe\sybase\query
Note: Each entry in the address field is separated by the # character.

You can edit these entries with dsedit.

To ensure cross-platform compatibility for all SAP products, the protocol and address attribute fields should be in a platform- and product-independent format.