Cisco SCMS SM LEGs User Guide, Release 3.5.5
About the SOAP LEG
Downloads: This chapterpdf (PDF - 378.0KB) The complete bookPDF (PDF - 2.33MB) | Feedback

About the SOAP LEG

Table Of Contents

About the SOAP LEG

Introduction

Information About the SOAP LEG

SOAP Integration Overview

Query Interface

Secure Requests

Implementing Query Interface at the Server

Common Topologies


About the SOAP LEG


Revised: July 28, 2009, OL-15752-05

Introduction

This module describes the SOAP LEG software module.

Information About the SOAP LEG

The Service Control Management Suite (SCMS) Subscriber Manager (SM) SOAP Login Event Generator (LEG) is a software module that can query an external server via the Simple Object Access Protocol (SOAP) in order to obtain additional information for the subscribers that were logged-in to the SM via various APIs and LEGs. The main purpose of the SOAP LEG is to define the policy of the subscriber based on the input data, the package association configuration, and the query results.

The LEG can query any external server via the SOAP communication protocol if the external server implements an interface defined by the SCMS SM SOAP LEG.

The SCMS SM SOAP LEG supports SOAP 1.1.

The SCMS SM SOAP LEG is an extension of the SM software and runs as part of the SM.

SOAP Integration Overview

Common Topologies

SOAP Integration Overview

The SM activates the SOAP LEG in order to obtain the policy value (or part of the policy value) for the subscribers that are already logged in to the SM.

With the data that the SOAP LEG receives from the SM, it creates a SOAP request, which it issues to the external server in order to retrieve the policy value. After the external server replies, the SOAP LEG determines the policy value according to the input data, the package association configuration, and the query results. It then initiates a subscriber login to the SM. For more information about the package association, see Information about Configuring the Package Association, page 29-3.

Query Interface

Secure Requests

Implementing Query Interface at the Server

Query Interface

The SOAP installation package includes a WSDL file. This WSDL file defines the SOAP LEG query to the external server:

QuerySubscriberOut querySubscriber(QuerySubscriberIn subIn)

The QuerySubsriberIn parameter contains the following data:

subscriberId—Contains the ID of the subscriber

mappings—Contains the Network IDs of the subscriber

keys/values—May contain additional data that the external server may need in order to perform the query

The Web Server responds to the query and SOAP LEG analyzes the results. The output of the Web Server (QuerySubscriberOut) consists of the following elements:

subscriberId—Contains the ID of the subscriber

mappings—Contains the Network IDs of the subscriber

keys/values—May contain additional data that the SOAP LEG may need in order to determine the package value

propertyKeys/propertyValues—May contain subscriber properties; for example, packageId or monitor.

Note that keys and values are used internally by the LEG for the package association procedure and are not passed to the SM when the subscriber is logged in.

Upon receiving a reply from the Web Server, the SOAP LEG adds the query output values to the query input values. Following this, if the SOAP LEG is configured to do so, the LEG uses this data as the input for the package association procedure. See Information about Configuring the Package Association, page 29-3.

Secure Requests

The SOAP LEG is able to issue a secure request to the external server using the UsernameToken profile as defined in the WS-Security specification. Specifically, it attaches username and password to every SOAP request it sends. For further information on configuring the username and password, see Using the SOAP LEG CLU, page 30-1.


Note The SOAP LEG supports only text passwords.


Implementing Query Interface at the Server

Integrating the external server with the SOAP LEG is a two stage process:

1. Compile the provided WSDL file using one of the various tools available. For example, Apache Axis can be used (http://ws.apache.org/axis/). The WSDL file is included in the Cisco WSDL module.

2. Provide the implementation of the querySubscriber function according to the server business logic.

Common Topologies

You can use the SOAP LEG in any SM topology, providing it is possible to supply the LEG with the information it needs in order to perform the query to the policy server and determine the subscriber policy.

The following figures show the most common topologies.

Figure 28-1 shows the topology with the SM API:

Figure 28-1 SOAP Topology with SM API

The SM API performs a login operation to the SM (1). The SM identifies that the SOAP LEG needs be activated, and therefore it does not perform a subscriber login at this stage. The SM core passes the information received from the SM API to the SOAP LEG (2). The SOAP LEG queries the SOAP server and identifies the relevant packageId based on the configuration, input parameters, and the query results (3). The SOAP LEG then performs a login operation to the SM (4).

Figure 28-2 shows the topology with the DHCP Sniffer LEG:

Figure 28-2 SOAP LEG Topology with DHCP Sniffer LEG

The DHCP traffic passes through the SCE (1), which sends a DHCP RDR to the DHCP Sniffer LEG (2). The DHCP Sniffer LEG extracts the relevant information and performs a login operation to the SM (3). The SM identifies that the SOAP LEG needs to be activated, and therefore it does not perform a subscriber login operation at this stage. The SM core passes the information received from the DHCP Sniffer LEG to the SOAP LEG (4). The SOAP LEG queries the SOAP server and identifies the relevant packageId based on all the information received and the query results (5). The SOAP LEG then performs a login operation to the SM (6).

Figure 28-3 shows the topology with the DHCP Lease Query LEG:

Figure 28-3 SOAP LEG Topology with DHCP Lease Query LEG

Unknown traffic passes through the SCE (1), which issues a pull request to the SM (2). The SM issues an anonymous-pull-request to the DHCP Lease Query LEG (3). The DHCP Lease Query LEG then queries the DHCP server (4), after which it performs a login operation to the SM (5). The SM identifies that the SOAP LEG needs to be activated, and therefore it does not perform a subscriber login at this stage. The SM Core passes all of the information received from the DHCP Lease Query LEG to the SOAP LEG (6). The SOAP LEG queries the SOAP server and identifies the relevant packageId based on the information received and the query results (7). The SOAP LEG then performs a login operation to the SM (8).