SAP ECC UM Connector

The following sections provide information about the SAP ECC UM connector.

Most of the connector and its configuration is described in the section about the SAP ECC UM Agent. This section describes how to extend the connector by defining a filter that can also perform BAPI and RFC calls. Customers can use this filter to extend the capability of the SAP ECC UM connector.

It is assumed that the reader is familiar with SAP’s Java Connector (JCo). JCo is SAP’s Java middleware and allows SAP customers and partners to build SAP-enabled components and applications in Java easily.

Overview

The Java-based SAP ECC UM connector runs inside the DirX Identity Connector Integration Framework. It converts SPML requests to the appropriate SAP BAPI USER object interface and converts the results and responses of those interfaces back to SPML results and responses.

Request and Response Handling

This section contains an example of a filter that performs a call to the same ECC server as the connector to check if a user exists. This can be used, for example, to change an add request to a modify request. The example only contains the parts to set up a connection and to perform the existence check, not the part to change the SPML request. You can find the source code of the complete example for JCo version 3.0.x on your DVD under

Additions/SampleConnectorFilter/jco3/java

Example Filter Implementation for JCo Version 3

As noted in the DirX Identity Integration Framework Guide, a filter must implement the interface ConnectorFilter. If the filter needs the configuration of the connector, it must also implement the interface ConnectorFilterConfig.

This section describes the filter implementation for JCo version 3. JCo version 3 has changed in incompatible ways from previous versions. For example, the connection management has completely changed. You now use a JCoDestination, which just identifies a physical destination to a function call.

The filter requires at least a variable to hold the successor, the connector configuration, and the JCo variable for a destination. You can use a helper class in the UM connector to simplify the process of interpreting the connector configuration for the proper connection parameters and to create a JCoDestination. The class is named Configuration. Here are the specifications for these variables:

import com.sap.conn.jco.*;
import siemens.dxm.connector.sapUM.Configuration;
public class TestFilterWithConnectorCfg implements ConnectorFilter, ConnectorFilterConfig  {
    ConnectorFilter successor = null;
    private DxmConnectorConfig connCfg = null;
    private JCoDestination destination;
    private Configuration myConfig;

Before the open() method can be called, the setConnectorConfiguration() method must be called to provide the connector configuration:

public void setConnectorConfiguration(DxmConnectorConfig connectorConfig) {
    connCfg = connectorConfig;
}

In the open() method, the filter gets its own configuration and can set up the Configuration variable.

The Configuration helper class includes the following three methods:

  • A constructor to create and initialize the instance

  • A method to get a JCo destination from the JCo pool

  • A method to release the used pool.

You can use the Configuration instance to get one or more destinations objects for the same connection as the connector will use, including the same user and his credentials. The Configuration class does not support the use of a different user and/or connection. If you need this function, you must implement it on your own.

For more information about JCo pooling, read the JCo documentation.

public void open(DxmFilterConfig config, Context context) throws DxmConnectorException {
    if (connCfg != null) {
        try {
            myConfig = new Configuration(connCfg, "myPool");
            destination = myConfig.getDestinationFromPool();
        } catch (JCoException e) {
            throw new DxmConnectorException("Open Filter " + name +" failed:" , e);
        }
    } else {
    throw new DxmConnectorException(name + ": Connector configuration not set");
    }
}

The close() method releases the pool and calls the close() method of its successor:

public void close() {
    try {
        if (destination != null) {
            myConfig.releasePool();
        }
    } catch(Exception e) {
        System.err.println(…)
    }
    successor.close();
}

The main work is done in the doFilter() method. In this example, only add requests are filtered, and no responses:

public SpmlResponse doFilter(SpmlRequest request) throws DxmConnectorException {
    if (request instanceof AddRequest ) {
        request = doCallECC((AddRequest) request);
    }
    return successor.doFilter(request);
}

The doCallECC() method performs the simple BAPI call BAPI_USER_EXISTENCE_CHECK to check if a user exists. First, it extracts the identifier from the add request:

private SpmlRequest doCallECC(AddRequest request)  throws DxmConnectorException {
    Identifier id  = request.getIdentifier();
    if (id.getType() != null && id.getType().toString().equalsIgnoreCase(IdentifierType.VALUE_2.toString())) {
    IdentifierChoice idchoice = id.getIdentifierChoice();
    String username = idchoice.getId();
    try {

The destination is already set up in the open() method. It uses the destination to get the ECC repository to set up a function. A JCo function has an execute() method which uses a destination parameter:

// get a repository from the destination
JCoRepository repository = destination.getRepository();
// using BAPI if user exists
JCoFunctionTemplate fctExistenceTempl = (JCoFunctionTemplate) repository.getFunctionTemplate("BAPI_USER_EXISTENCE_CHECK");
JCoFunction fctExistence = fctExistenceTempl.getFunction();
// get the import parameter list
JCoParameterList plImp = fctExistence.getImportParameterList();
// set parameter, here the user name
plImp.setValue("USERNAME", username);
// execute BAPI EXISTENCE_CHECK
fctExistence.execute(destination);
// Check return structure
JCoStructure returnSt = fctExistence.getExportParameterList().getStructure("RETURN");

If the returned message type is informational and the message number is 88, the user exists; if it is 124, the user does not exist. Any other type or number is a failure.

For the full example, see the source code on the DVD.

Configuration

To use a filter, you must specify a <port> element. The <port> element combines a list of <filter> elements with one <connector>. It specifies the port to a target system and is required when SPML requests from the controller to a connector must be filtered.

The following snippet shows an example from a configuration file. The filter can have its own parameters (like “myAttribute”):

<port connector="SAP UM Agent" mode="inout">
    <filter className="yourFilterClass" name="filterName">
        <property name="myAttribute" value="myValue" />
    </filter>
    <connector role="connector" className="siemens.dxm.connector.sapUM.sapUMuser" name="SAP UM Agent" version="2.00">
        <connection type="SAP_R3_UM"
                user="theUser"
                password="password"
                server="server-address">
            <property name="logonVariant" value="0" />
            <property name="client" value="nnn" />
            <property name="systemID" value="nn" />
            …
        </connection>
    </connector>
</port>