Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Version 8.0
Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of
its products and services. We would like to encourage you as our customers and users to join
us in working towards a cleaner, safer environment. Please recycle product packaging and
follow the recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental
services we offer, please contact us at Nokia Siemens Networks for any additional information.
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2013. All rights reserved
Id:0900d80580a28e73
A50016-E4103-D851-2-7618
Table of Contents
This document has 33 pages.
Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2
2.1
2.2
2.3
2.3.1
2.3.2
.......
.......
.......
.......
.......
.......
..............
..............
..............
..............
..............
..............
10
10
10
11
12
12
3
3.1
3.1.1
3.2
.......
.......
.......
.......
......
......
......
......
........
........
........
........
14
14
16
16
4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.2
4.2.1
4.2.2
4.2.3
4.3
4.3.1
4.3.2
4.4
4.5
4.5.1
4.5.2
4.5.3
4.5.3.1
4.5.3.2
4.5.4
18
18
18
18
18
19
19
19
19
20
20
20
20
21
21
21
22
22
22
22
23
5
5.1
5.2
5.3
Backward Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DN Case Trigger Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V7 Trigger Object Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V7 Trigger Attribute Transformation. . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
24
24
25
......
......
......
......
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SOAP Notification Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SOAP Notification Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
A50016-E4103-D851-2-7618
Id:0900d80580a28e73
Alarms . . . . . . . . . . . . . . . . . . .
NDS Alarms . . . . . . . . . . . . . .
NTF Alarms. . . . . . . . . . . . . . .
NTF Performance Counters . .
.......
.......
.......
.......
......
......
......
......
.......
.......
.......
.......
......
......
......
......
. . . . . . 29
. . . . . . 29
. . . . . . 29
. . . . . . 30
Id:0900d80580a28e73
A50016-E4103-D851-2-7618
List of Figures
Figure 1
Figure 2
A50016-E4103-D851-2-7618
Id:0900d80580a28e73
List of Tables
Table 1
Id:0900d80580a28e73
A50016-E4103-D851-2-7618
Change History
Change History
Issue 2 (09/2013)
Updated section SOAP Server Overload
Issue 1 (04/2013)
New Release
A50016-E4103-D851-2-7618
Id:0900d80580a28e35
References
References
[NDS-OMG]
[NTF-GD]
[Trig-DG]
Id:0900d805809bc115
A50016-E4103-D851-2-7618
Introduction
1 Introduction
This document contains or references all the information required by application developers about the external One-NDS SOAP Notification interface, such as SOAP protocol
details (versions, schema, limits), configuration options, alarms related to database
trigger, and SOAP notification delivery. Examples for the configuration options and an
example of a SOAP notification are also included.
SOAP notification is the message generated as a result of trigger condition being satisfied. Trigger is the condition defined in database against the data update.
A50016-E4103-D851-2-7618
Id:0900d805809bc155
Overview
One-NDS system has built in notification mechanism which is used to notify its components about data updates in Network Directory Server (NDS). One-NDS components
involved in SOAP notification besides the NDS are Notification Manager (NTF), Application Receivers, and One-NDS Administrator (ADM). SOAP notifications are delivered
between the components by using SOAP protocol, which is the core protocol in OneNDS used for the notification.
NDS generates a SOAP notification based on the updated data and sends it to the NTF.
NTF component helps routing the SOAP notifications and a reliable delivery to applications. Based on the configuration, NTF routes all the SOAP notifications to the configured application receivers. There are multiple NTF hosts in One-NDS system.
Application receivers (ARs) are the targets for the notifications. ARs use the notifications
and execute an action based on its contents. Each application has its own set of receivers, which receive and process them.
ADM is used for managing and configuration of One-NDS components. It is not involved
directly in the notification flow. It uses LDAP and SOAP protocols for communication
with the components.
2.2
10
Id:0900d805809bc156
A50016-E4103-D851-2-7618
Figure 1
2.3
SOAP Protocol
This section describes the details of the SOAP protocol supported by NTF service when
delivering notifications to the application frontends.
SOAP schema for NDS notifications is described in the section SOAP Notification
Schema and an example of a SOAP notification is explained in the section SOAP Notification Example.
Communication with NTF is based on HTTP v1.1 for transmitting SOAP messages.
Supported SOAP versions and their namespaces are specified in following table.
A50016-E4103-D851-2-7618
Id:0900d805809bc156
11
SOAP
Version
SOAP Version as
Labeled by NDS
v1.1
v1.1
http://schemas.xmlsoap.org/soap/envelope/
v1.2
n/a
http://www.w3.org/2001/06/soap-envelope
n/a
http://www.w3.org/2001/09/soap-envelope
n/a
http://www.w3.org/2001/12/soap-envelope
n/a
http://www.w3.org/2002/06/soap-envelope
v1.2a
http://www.w3.org/2002/12/soap-envelope
v1.2b
http://www.w3.org/2003/05/soap-envelope
NTF maintains a limited number of SOAP connections towards each configured application SOAP server; this limit is configurable.
NTF communicates in synchronous mode on all connections. HTTP pipelining is not
supported, that is, NTF sends the next message on each connection only after receiving
a response to the previously sent message.
NTF expects the Application Receivers SOAP server to respond with the HTTP_OK
(200) status code, if it accepted the message. Delivery attempt fails if the response
bears a different HTTP status code or if it contains a SOAP fault element. Unsuccessfully delivered notifications are subject to redelivery by NTF. The numbers of delivery
attempts are configurable.
NTF controls the rate of notifications sent towards each application receiver. The
maximum number of notifications sent per second is configurable separately for each
SOAP service. If a single application receiver URL is registered in more number of
SOAP services, minimal value of configured rate from all the relevant SOAP services is
applied. Default value is set to 100 messages per second for all the SOAP services.
2.3.1
2.3.2
12
NTF cluster can support up to 150 Application Receivers for each SOAP service.
Id:0900d805809bc156
A50016-E4103-D851-2-7618
A50016-E4103-D851-2-7618
Id:0900d805809bc156
13
The action is generated either by raising an alarm or generating a SOAP message. This
SOAP message may contain complete or filtered details about the update performed
and the data affected and may be presented to the recipient through an appropriately
adapted view.
Database trigger conditions are specified in dsTrigEntry instances (see [Trig-DG]).
Trigger actions are specified in dsTrigAction instances (see [Trig-DG]).
For SOAP triggers, a soapClientService instance specifies the attributes of the
remote SOAP service (see NDS SOAP Client).
Trigger conditions are evaluated on the actual object and attributes updated and not on
the adapted view of the data (including access through variants), which is supplied by
the client. The actions are defined such that the notification is adapted, presenting the
information in a expected manner by the client. This includes grouping together updates
to multiple entries that may be performed by a variant object.
3.1
The same string is used for the particular SOAP service in the NTF Registration data.
The associated NTF Registration data entry is created automatically by ADM during
trigger package activation.
soapUrlList
The URL(s) for the remote SOAP servers.
ADM automatically inserts the list of all NTF URL addresses used for trigger processing
in the system to this attribute during the trigger package activation. This list is also automatically updated when a new NTF host is added to the system. Configuration of the
Application Frontend URL addresses to which the notifications are delivered is done in
the NTF Registration data instead. (see [Trig-DG]).
soapUrlUpdInt
Time interval in seconds, during which the SOAP client checks changes to its configuration data.
soapMaxRate
14
Id:0900d80580a28e39
A50016-E4103-D851-2-7618
The maximum number of SOAP requests that the SOAP client sends to a single service
per second. The permitted range of values is from 0 to 500, with 0 disabling the SOAP
service. It has a relation to the NTF parameter nsNinMaxMessageRate, which limits
the SOAP notifications towards receivers.
ADM sets value of soapMaxRate to 100 during application trigger activation as it is part
of the interface between NDS and NTF. Application developers are not allowed to
modify the value.
soapRespTimeout
The response timeout, in milliseconds for a SOAP request.
ADM sets value of soapRespTimeout to 40000 (40s) during trigger activation as it is
part of the interface between NDS and NTF.
soapSendAttempts
The number of times the SOAP client attempts to send a SOAP requests to each
service. The request is discarded in case of failure. It has a relation to the NTF attribute
nsNinDeliveryAttempts.
Value of soapSendAttempts is changed during trigger activation to ignore the value
defined in trigger package. The defined value is configured in the NTF attribute
nsNinDeliveryAttempts.
soapLoadShare
The method is used to deal with multiple servers. If set to roundRobin, the requests
are sent to each of the servers in turn. If set to broadcast, each request is sent to every
server.
Notifications are sent to NTF in roundRobin mode. For broadcast notifications, ADM
changes the value of this attribute to roundRobin during trigger package activation and
sets the Multicast request delivery policy for the associated SOAP Service in NTF registration data. If this rule is not followed in case of manual definition then BC notification
is sent to each NTF host with the consequence that BC notification is sent from each
NTF (refer to the section Message Dispatch Policy).
soapMep
This must be set to requestOnly for SOAP services notified by the trigger process.
soapConnMode
This may be either synchronous or asynchronous. The normal mode of operation is synchronous and in this mode a SOAP client must wait for an acknowledgement from the
server before sending any further requests. Asynchronous mode means HTTP pipelining, there is no callback endpoint configured.
soapConnsPerPort
The number of simultaneous connections that the SOAP client establishes to each of
the servers identified in soapUrlList. The attribute is part of the interface towards
NTF.
soapVersion
The version of the SOAP protocol is used to communicate with the SOAP servers.
For more information regarding individual attributes, refer to the [NDS-OMG], section
Registering SOAP Services.
A50016-E4103-D851-2-7618
Id:0900d80580a28e39
15
3.1.1
The ExP trigger definition of SOAP client contains the following attributes values (refer
to Table 1). Table 1 lists the required configuration for the selected SOAP client attributes. To use a different value, the project must announce this change and its reason
to One-NDS NTF support and test its project specific configuration.
Attributes
Recommended
Values
soapUrlUpdInt
10
Recommendation
Set value 10
100
soapRespTimeout
40000
soapSendAttempts
soapLoadShare
roundRobin
soapMep
requestOnly
asynchronous
Set value to 1
3.2
Trigger Configuration
This section describes the configuration data, which is used to define triggers and their
associated actions. It outlines the configuration objects involved and provides a detailed
description of their attributes.
16
Triggers are fired, if the trigger configuration data, which is stored on the same DSA as
the object(s) are updated. Therefore, it is easy to maintain the same triggering configuration data on all the DSAs in the system. There is no performance overhead, if there
are no instances of the monitored objectClass on a DSA.
Id:0900d80580a28e39
A50016-E4103-D851-2-7618
Trigger Entry
It represents the set of conditions that must be satisfied before generating the SOAP
notification.
Trigger Object
It consists of a list of actions that are performed after the trigger conditions are satisfied. The actions affect content of the SOAP message.
Trigger View Extension
It affects content of the SOAP message, which modifies object and attribute names
according to the requirement of the application view.
A50016-E4103-D851-2-7618
Id:0900d80580a28e39
17
4.1
4.1.1
Inbound Transport
Load Balancing
Load balancer distributes incoming notification messages across all local NTF service
instances (by default, 2 service instances are deployed on an NTF host). One instance
of Apache HTTP Server with Proxy Balancer module does the job while listening at one
external TCP port for incoming traffic.
4.1.2
Notifications related to multiple SOAP Services may be received at one inbound endpoint. However, only SOAP Services with the same response delivery policy
(Request/Response or Remote Request/Response, see Response Delivery Policy)
may share one endpoint. NDS always sends notifications (Round robin and Multicast as
well) to Common endpoint that is created by default in NTF, no extra configuration is
required. Message identification of all SOAP Services sharing one endpoint must be
unambiguous. For more information on message identification, refer to [NTF-GD].
4.1.3
18
Id:0900d80580a2c195
A50016-E4103-D851-2-7618
the request URL is invalid or it can not forward the request to the selected NTF service
instance.
4.1.4
Request Logging
All HTTP requests received by the NTF service are logged by using Request log. It
serves as a tracking tool and is switched off by default. For more information, refer to
[NTF-GD].
4.2
4.2.1
4.2.2
Multicast (MC)
Message is distributed to a specified list of ARs. Each AR receives all published
messages.
Round Robin (RR)
Messages are distributed in a multiplexed way. According to specified ordered list of
SOAP Servers, messages are sent to the next notification SOAP Server in a circular
way. For more information regarding individual message dispatch policies, refer to
[NTF-GD].
A50016-E4103-D851-2-7618
Request/Response (2R)
Asynchronous mode, in which NTF receives the given message, stores it persistently in its message storage on the file system (for example, queue), and generates
a response to the message sender after the message is persisted. This approach
makes it sure that no NDS notification is lost. The delivery to the AR takes place,
once the response to the message sender is already sent, and no other response
concerning this message follows.This response delivery policy is used for SOAP
notifications sent by NDS.
Id:0900d80580a2c195
19
For more information regarding individual message response delivery policies, refer to
[NTF-GD].
4.2.3
Request Logging
Every SOAP message that NTF fails to deliver to its intended SOAP Server according
to configured Dispatch policy and Redelivery algorithm properties is stored in Dead
Letter Log. For more information, refer to [NTF-GD].
Every SOAP message of a known type, which NTF fails to perform any delivery attempt
is stored in Discarded Letter Log. This may be the case of NTF being in the JMS
Overload situation (for more information, refer to the section NTF Overload) or the case
when no SOAP Servers are registered for the given SOAP service. For more information, refer to [NTF-GD].
NTF provides other logging services:
4.3
4.3.1
Request log
It logs all the messages which are accepted by the NTF service instance. It is
switched off by default, because it has impact on performance.
Failed delivery attempt log
If an attempt to deliver notification to an AR fails for any reason, the reason is written
in the log.
Debug logs, configuration log
If NTF does not work as per expectation, it helps to identify the problem.
4.3.2
Availability
To provide high availability, the NTF uses redundancy and its processes are secured by
Watchdog.
NTF service redundancy is provided by multiple NTF hosts. NTF clients such as NDS
are configured to distribute notifications equally among the NTF hosts (for example, in
a round robin manner). Clients are also expected to use other NTF hosts in case their
primary one is not available.
20
Id:0900d80580a2c195
A50016-E4103-D851-2-7618
Watchdog is a process running on each NTF host that checks condition of the local
Apache load balancer and local NTF service instances and restarts them if they are not
in a healthy state.
Figure 2
4.4
Performance
NTF collects performance data (number of requests received, delivered, failed, and so
on) in the form of counters. Counter values are written to the host-specific LDAP nodes
in PGW-DSA, from where they are read out by agents specific for the OAM solution of
the customer.
For more details on performance monitoring and detailed list of counters, refer to [NTFGD].
4.5
4.5.1
Error Handling
Application Receiver (AR) Response
NTF expects the AR to respond with the HTTP_OK (200) status code if it accepts the
message. Responses bearing different HTTP status code cause the delivery attempt to
fail. Delivery attempt is taken as unsuccessful also if the response contains a SOAP fault
element.
Each unsuccessful attempt to deliver a notification from NTF (either indicated by the AR
or caused by the inability of NTF to deliver the message to the AR) is logged in the failed
delivery attempt log on NTF.
NTF does not distinguish between different reasons of delivery failures, neither client
(NTF) or server (AR) specific HTTP, nor SOAP error responses. Depending on the configured redelivery options, NTF attempts to re-deliver failed messages, see section Reliability.
For more information, refer to [NTF-GD].
A50016-E4103-D851-2-7618
Id:0900d80580a2c195
21
4.5.2
4.5.3
4.5.3.1
Overload Situations
NTF Overload
NTF overload is a situation in which NTF fails to provide the service anymore. The following NTF overload types may arise:
JMS Overload
It is caused by a message queue which is full to accept more messages.
Partition Overload
It is caused when the file system partitions used by the service are used completely
and NTF fails to provide space necessary for storing message data and/or log files.
Inbound Endpoint Overload
It is caused when multiple parallel requests are handled at a time.
In the JMS Overload situation, NTF attempts to accept all incoming messages with
HTTP OK (200) to avoid overload on the DSA side. However, all the newly received
messages are automatically discarded and written in the Discarded Letter Log. In other
overload cases, NTF fails to receive any more messages and it responds with HTTP 503
error code. In such a case, DSA SOAP client must either contact another NTF host or
wait and try again after some time. For more information on NTF error responses, refer
to [NTF-GD].
NTF tries to prevent the overload situations by monitoring the reachability states of every
AR or registration (that is, particular SOAP service with a particular AR association).
In every overload case or if any SOAP Server/registration becomes unreachable, NTF
raises the corresponding alarm. NTF also clears the alarm after the overload/unreachability situation is cleared. For alarm details refer to the section NTF Alarms.
For more details on individual NTF overload situations and mechanisms for their prevention, refer to [NTF-GD].
4.5.3.2
22
Id:0900d80580a2c195
A50016-E4103-D851-2-7618
4.5.4
Fault Management
For situations requiring operator notification, NTF raises alarms. The alarms from the
NTF are received by FM Agent running at the same host forwarding the alarm to its
server for further processing. The type of the agent used depends on the variant of the
OAM solution.
For more information, refer to [NTF-GD].
For the list of NTF alarms, refer to the section NTF Alarms.
A50016-E4103-D851-2-7618
Id:0900d80580a2c195
23
Backward Compatibility
5 Backward Compatibility
NTF provides optional transformations of notification messages to provide backward
compatibility of the notifications generated by One-NDS with certain applications
expecting older format. Transformations are configured on the basis of SOAP service.
The following message transformation options are available:
5.1
After transformation
...
<trig:trigger xmlns:trig=http://www.apertio.com/pgw/trigger
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.apertio.com/pgw/trigger PGW_TS_trigger.xsd">
<trig:object
DN="msisdn=4917391102896,o=hlr,imsi=262016491102896,nss=NSS,uid=262016491102896
,sssd=SSSD,o=DEFAULT,dc=C-NTDB" operation="delete">
<trig:attribute name="isBasic" modification="delete">
<trig:beforeValue>TRUE</trig:beforeValue>
</trig:attribute>
</trig:object>
...
5.2
24
Id:0900d805809bc159
A50016-E4103-D851-2-7618
Backward Compatibility
V7 Trigger Object transformation merges the trigger object elements with the same DN
attribute value to one. The grouped object element uses the operation attribute from the
first object element.
Example
Before transformation
...<trig:trigger ...>
<trig:object DN="uid=X,o=TMD,dc=NAB" operation="add">
<trig:attribute name="nabActivationStatus" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
<trig:attribute name="nabProvisioningStatus" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
</trig:object>
<trig:object DN="uid=X,o=TMD,dc=NAB" operation="add">
<trig:attribute name="cmtOnNet" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
</trig:object>
</trig:trigger>
...
After transformation
...
<trig:trigger ...>
<trig:object DN="uid=X,o=TMD,dc=NAB" operation="add">
<trig:attribute name="nabActivationStatus" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
<trig:attribute name="nabProvisioningStatus" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
<trig:attribute name="cmtOnNet" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
</trig:object>
</trig:trigger>
...
5.3
A50016-E4103-D851-2-7618
Id:0900d805809bc159
25
Backward Compatibility
After transformation:
...
<trig:attribute name="dOptRouting" modification="delete">
<trig:beforeValue>FALSE</trig:beforeValue>
</trig:attribute>
<trig:attribute name="dOptRouting" modification="add">
<trig:afterValue>TRUE</trig:afterValue>
</trig:attribute>
...
26
Id:0900d805809bc159
A50016-E4103-D851-2-7618
Appendix
Appendix
SOAP Notification Schema
<?xml version="1.0" encoding="UTF-8"?>
<!--************************************************************
*File name : NDS_trigger.xsd
*Author : John.Doe@nsn.com
*Date : 24th July 2007
*
*This file contains the XML schema defining the NDS notification*
************************************************************
-->
<xs:schema xmlns="http://www.apertio.com/trigger"
targetNamespace="http://www.apertio.com/trigger"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="trigger">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="object"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="object">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="attribute"/>
</xs:sequence>
<xs:attribute name="objectClass" type="xs:string"/>
<xs:attribute name="DN" type="xs:string"/>
<xs:attribute name="operation" use="required" type="operationType"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="operationType">
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="modify"/>
<xs:enumeration value="delete"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="attribute">
<xs:complexType>
<xs:choice>
<xs:element minOccurs="0" maxOccurs="unbounded"
name="currentValue"type="xs:string"/>
<xs:sequence>
<xs:element minOccurs="0"
maxOccurs="unbounded"name="beforeValue"type="xs:string"/>
<xs:element minOccurs="0" maxOccurs="unbounded"
name="afterValue"type="xs:string"/>
</xs:sequence>
</xs:choice>
<xs:attribute name="name" use="required" type="xs:string"/>
<xs:attribute name="modification" use="required"type="modificationType"/>
</xs:complexType>
</xs:element>
<xs:simpleType name="modificationType">
<xs:restriction base="xs:string">
<xs:enumeration value="add"/>
<xs:enumeration value="replace"/>
<xs:enumeration value="delete"/>
<xs:enumeration value="none"/>
</xs:restriction>
A50016-E4103-D851-2-7618
Id:0900d805809bc114
27
Appendix
</xs:simpleType>
</xs:schema>
28
Id:0900d805809bc114
A50016-E4103-D851-2-7618
Appendix
</env:Body>
</env:Envelope>
Alarms
NDS Alarms
The following is the list of NDS alarms and the alarm numbers related to trigger processing. More details can be found in [NDS-OMG].
For more information regarding NDS alarms, refer to the Alarm Repair Manual (A50016E4103-M580-*-7620).
NTF Alarms
The list of alarms that can be raised by NTF can be found in [NTF-GD].
The following alarms indicate a serious startup error that causes malfunctioning of the
entire NTF service instance. Notifications must be delivered by other NTF service
instances in the cluster:
InvalidConfigurationGlobalPropertyData (02)
InvalidGlobalPropertyFile (4)
InvalidLoggerConfiguration (10)
InvalidInstallation (26)
The probability of alarm 10 and 26 occurrence is low as they are related to the configuration files that are not externally modified.
A50016-E4103-D851-2-7618
Id:0900d805809bc114
29
Appendix
The following alarm indicates that the given NTF service instance is stopped intentionally (by operator or some automatic logic) or automatically in case the NTF service
instance free memory gets low:
ServiceShutdownInvoked (33)
The following alarms indicate an invalid entry in the NTF configuration or registration
data or other problem while reading the configuration. This makes NTF use either
default value (on startup) or old value (on configuration/registration update). Notifications may be delivered in other way than intended or not delivered at all:
InvalidConfigurationLdapData (3)
ConfigurationDataUpdateFailed (6)
InvalidSubscriptionData (7)
SubscriptionDataUpdateFailed (8)
UsingDefaultConfigurationValue (24)
ConfigurationDataLoadFailedAlarm (30)
SubscriptionDataLoadFailedAlarm (31)
The following alarms indicate exhaustion of important system resources, which may
negatively affect acceptance of new notifications or delivery of already accepted ones:
JmsStorageOverload (22)
MaxNumberOfParallelRequestsReached (23)
FileSystemStorageFull (25)
NotificationBufferOverloadAlarm (29)
The following alarms are directly related to problems in the delivery of a particular SOAP
message:
UnknownSoapMessageReceived (20)
InvalidSoapMessageReceived (21)
SoapReceiverUnreachable (28)
RegistrationUnreachable (40)
Other types of alarms indicate problems indirectly related to notification delivery, such
as errors while updating performance counters, logging, and so on.
For more information regarding NTF alarms, refer to the Alarm Repair Manual (A50016E4103-M580-*-7620).
30
Request received
Number of Notification requests received.
Request delivered
Number of delivered Notification requests.
Request stored
Number of Notification requests stored for processing.
Id:0900d805809bc114
A50016-E4103-D851-2-7618
Appendix
Request undeliverable
Number of undeliverable Notification requests.
Request delivery attempt failed
Number of failed attempts to deliver Notification requests.
Request failed
Number of failed authentication attempts of Notification requests.
Invalid request
Number of invalid Notification requests received.
Within the categories, there are also separate counters for Message dispatch policies
and Response delivery policies.
Extra counter categories that are related to the NTF administration:
Admin-AuthenticationFailed
Number of failed authentication attempts of Administration requests.
Admin-InvalidRequest
Number of invalid Administration requests received.
Admin-RequestFailed
Number of Administration requests with errors during their processing.
Admin-RequestProcessed
Number of successfully processed Administration requests.
Admin-RequestReceived
Number of Administration requests received.
A50016-E4103-D851-2-7618
Admin-AuthenticationFailed
Admin-InvalidRequest
Admin-RequestFailed
Admin-RequestProcessed
Admin-RequestReceived
Notification-AuthenticationFailed
Notification-InvalidRequest
Notification-RequestDelivered
Notification-RequestFailed
Notification-RequestReceived
Notification-RequestUndeliverable
MC-2R-Policy-DeliveryAttemptFailed
MC-2R-Policy-RequestDelivered
MC-2R-Policy-RequestFailed
MC-2R-Policy-RequestReceived
MC-2R-Policy-RequestStored
MC-2R-Policy-RequestUndeliverable
RR-2R-Policy-DeliveryAttemptFailed
RR-2R-Policy-RequestDelivered
RR-2R-Policy-RequestFailed
RR-2R-Policy-RequestReceived
RR-2R-Policy-RequestStored
RR-2R-Policy-RequestUndeliverable
RR-3R-Policy-DeliveryAttemptFailed
Id:0900d805809bc114
31
Appendix
RR-3R-Policy-RequestDelivered
RR-3R-Policy-RequestFailed
RR-3R-Policy-RequestReceived
RR-3R-Policy-RequestUndeliverable
For more information on NTF performance counters, refer to User Manual (@Com
variant) (A50016-E4103-Q700-*-7619), User Manual (NetAct/SM variant) (A50016E4103-Q701-*-7619).
32
Id:0900d805809bc114
A50016-E4103-D851-2-7618
One-NDS Administrator
distinguished name
directory server agent
lightweight directory access protocol
LDAP data interchange format
(One) Network Directory Server
network element
notification manager
simple object access protocol
A50016-E4103-D851-2-7618
Id:0900d805809bc113
33