MMSC R30-00 UPower ProcLayer Interface Description CC20 v02

uPower CC2.
0_00
Process Layer Interface Description
Document Version: 1.0

Document Status: FINAL
Document Release Date: April 2007
Copyright 2007 by LogicaCMG Wireless Networks
All rights reserved. This document is protected by copyright law and may not be reprinted, reproduced, or utilised in whole or in part by any
electronic, mechanical, or other means without the prior written consent of LogicaCMG Wireless Networks.
The information in this document is provided on an as is basis and is subject to change without further notice and cannot be construed as a
commitment by LogicaCMG Wireless Networks Wireless Networks. Although every precaution has been taken in the preparation of this
document, LogicaCMG Wireless Networks Wireless Networks assumes no responsibility or liability for any errors or omissions whatsoever, that
may appear in this document. Neither is any liability assumed for damages resulting from the use of the information contained herein.
The products mentioned in this document are identified by the names, trademarks, service marks and logos of their respective companies or
organisations and may not be used in any advertising or publicity or in any other way whatsoever without the prior written consent of those
companies or organisations.
Table of Contents
Preface ...................................................................................................................... ix
1 Introduction......................................................................................................... 1
1.1 What is uPower?.................................................................................................................... 1
1.2 What process layer interface provides?................................................................................. 1
1.3 Data Flow Across the Interface.............................................................................................. 1
2 Process Layer Interface Description................................................................. 3

2.1 Introduction ............................................................................................................................ 3
2.2 Feature XML .......................................................................................................................... 3
2.2.1 Feature XML DTD .................................................................................................. 4
2.2.2 Example of Feature XML........................................................................................ 7
2.2.3 Super and Sub Features ........................................................................................ 8
2.3 Request XML ....................................................................................................................... 10
2.3.1 Request XML DTD ............................................................................................... 10
2.3.2 Examples of Request XMLs ................................................................................. 15
2.3.2.1 LOGIN Request................................................................................ 15
2.3.2.2 SETBASERECORD Request........................................................... 15
2.3.2.3 ADDENTRIES (Add common subscriber) Request ......................... 15
2.3.2.4 UPLOADFILE Request .................................................................... 16
2.3.2.5 RENAMEENTRIES (move subscriber) Request.............................. 16
2.3.2.6 COPYENTRIES request .................................................................. 16
2.3.2.7 DIFFENTRIES request..................................................................... 17
2.4 Response XML .................................................................................................................... 17
2.4.1 Response XML DTD............................................................................................. 17
2.4.2 Examples of Response XML ................................................................................ 21
2.4.2.1 LOGIN Response ............................................................................. 21
2.4.2.2 Response for Add Common subscriber request .............................. 27
2.4.2.3 DIFFENTRIES Response ................................................................ 28
2.5 Process Layer Support for Search Requests ...................................................................... 29
2.5.1 Request XML Element <SEARCHENTRY> ......................................................... 29
2.5.2 Element <SHOWATTRIBUTE>............................................................................ 30
2.5.3 Generic vs Standard Queries ............................................................................... 30
2.5.4 SEARCHENTRY Request Examples ................................................................... 33
2.5.4.1 Search using searchfilter and searchbase....................................... 33
2.5.4.2 Use of <SHOWATTRIBUTE> .......................................................... 34
2.5.4.3 Search using specialfilter ................................................................. 34
2007 LogicaCMG Wireless Networks Table of Contents iii

2.5.4.4 Search using standard queries or token filter without arguments.... 36
2.5.4.5 Search using standard queries or token filter with arguments......... 36
2.6 Grouped Request................................................................................................................. 38
2.6.1 The grouped request layout ................................................................................. 39
2.6.2 Superfeatures and subfeatures ............................................................................ 39
2.7 Mapping between External and Internal LDAP attribute names.......................................... 43
2.8 Password Encryption ........................................................................................................... 43
2.9 Mail Quota in Request/Response ........................................................................................ 44
2.10 URL Encoding...................................................................................................................... 44
3 Transport Layer Specifications ....................................................................... 45

3.1 Introduction .......................................................................................................................... 45
3.2 Transport Layer Functions ................................................................................................... 45
3.2.1 Initiate Connection................................................................................................ 45
3.2.2 Send Request....................................................................................................... 45
3.2.3 Get Response Header.......................................................................................... 46
3.2.4 Get Response Body ............................................................................................. 46
3.2.5 Close Connection ................................................................................................. 47
3.3 Sequence for calling transport layer API ............................................................................. 47
Appendix A. Examples of Important Features/Requests ............................... 49

A.1 Add UM COS ....................................................................................................................... 49
A.2 Add Common Subscriber..................................................................................................... 61
A.3 Add Subscriber uOne Service ............................................................................................. 63
A.4 Add Subscriber uNotify Service ........................................................................................... 68
A.5 Delete Subscriber uOne Service ......................................................................................... 70
A.6 Delete Subscriber uNotify Service ....................................................................................... 72
A.7 Delete Common Subscriber................................................................................................. 74
Appendix B. Examples of Request and Response HTPP Messages ............ 77

B.1 Process Layer Request........................................................................................................ 77
B.2 Example of <PARTIAL_COMPLETION_MESSAGE> Process Layer Response ............... 78
B.3 Example of a simple process layer response ...................................................................... 81
Abbreviations .......................................................................................................... 84
Glossary................................................................................................................... 85
References............................................................................................................... 87
iv <Subsystem> Process Layer Interface Description 2007 LogicaCMG Wireless Networks

List of Figures
Figure 1-1: Data Flow Across Interface ................................................................................................... 2
2007 LogicaCMG Wireless Networks List of Figures v

List of Tables
Table P-1: Typographic conventions ....................................................................................................... x
2007 LogicaCMG Wireless Networks List of Tables vii

Preface
Purpose
The purpose of this document is to describe the details of XML based interface provided by
the uPower process layer for the process layer clients to communicate.
Audience
The target audience of this document is system integrators and third party software
developers involved in developing process layer custom client (presentation layer). The
reader of this document is expected to have a good knowledge of:
1. Extensible Markup Language (XML)
2. HyperText Transfer Protocol (HTTP)
3. Features supported by the uPower process layer
Scope
The scope of the document is to provide an introduction to the uPower process layer and to
describe the interface it provides for provisioning needs of LogicaCMG products.
Other related documents are:
1. Supported Features for UM62.1 uPower
Organisation
This document is organised in 4 chapters and an appendix.
The first chapter provides an introduction to uPower architecture. It gives an overview of

data communication among the various layers of uPower system.
The second chapter focuses on the description of the interface provided by the process
layer. It describes in details the various elements (feature, request, response XMLs) of
process layer interface, provides examples of different requests/responses.
The third chapter describes the details on what functionality the transport layer should
provided to facilitate the presentation-process layer communication.
Appendix A provides a detailed discussion of feature and request XMLs for some important
operations.
Appendix B provides examples of over-the-wire HTTP messages between presentation

and the process layers.
2007 LogicaCMG Wireless Networks Preface ix

Typographic conventions
In this document, the typographic conventions listed in Table P-1 are used.
Table P-1: Typographic conventions
Typeface or Symbol Meaning/Used for Example
Courier Refers to a keyboard key, system The directory data contains

command, label, button, filename,
window, or other computer component Click the Close button to
or output.
<courier> Serves as a placeholder for variable Use the file name <entity>.cfg for...
text that the user will replace as
appropriate to its context.
[] Refers the user to external [ETSI 03.38]

documentation listed in the References
section.
italic Emphasises a new word or term of apply a style to the...

significance.
% Denotes a Unix regular-user prompt for % ls

C shell.
# Denotes a Unix super-user prompt for # ls

any shell.
$ Denotes an OpenVMS Digital $ dir

Command Language prompt.
\ (Unix) Denotes line continuation; the % grep searchforthis \

or character should be ignored as the data/*.dat
(OpenVMS) user types the example, and Enter
should only be pressed after the last $ search [.data]*.dat -
line. searchforthis
- Bridges two keystrokes that should be If Ctrl-C does not work, use Ctrl-
pressed simultaneously. Alt-Del.
Denotes a note, a piece of text Note that the system is usually...

alongside the normal text requiring
extra attention.
x <Subsystem> Process Layer Interface Description 2007 LogicaCMG Wireless Networks

1 Introduction
1.1 What is uPower?

uPower is a web based provisioning tool used to provision and manage the subscriber
database and service-related information for LogicaCMG Wireless Networks products. The
uPower architecture consists of primarily 2 layers communicating with each other using
HTTP POST mechanism. The data exchange between these layers is in the form of XML
documents. The primary layers of uPower consist of Presentation layer and the Process
layer with an intermediate Transport layer for communication between the Presentation and
Process layers. The Presentation Layer deals with presenting data on the web screens and
collecting the modified data from the input sources and sending it to the process layer to
save into the databases. The process layer encapsulates the entire business logic. It deals
with data validation, and creating and saving the data to database.
1.2 What process layer interface provides?

The interface between the uPower Presentation and Process Layers consist of
Request/Response documents that allow the retrieval, addition, modification, and
deletion of all data in LDAP and other databases required for the operation of CMG
WDS products UM, WSB and MMSC.
The interface facilitates Login, session maintenance, and Logout of the Subscriber
or Administrator using uPower. This allows the Process Layer to maintain multiple
simultaneous sessions. The interface utilizes an open-standard syntax, allowing
Service Providers or System Integrators to develop their own Presentation Layers
that work with the Process Layer.
The interface allows more than one Presentation Layer communicating with one
process layer.
The interface is based on Features, which are logical groupings of LDAP attributes.
The interface supports both Administrators and Subscribers. Upon Login of an

Administrator or Subscribers, the Process Layer returns a list of the allowed
Features for the User, the LDAP entries describing the User, and a Session ID. This
allows the Process Layer to control the Features that can be administered,
according to whether the uPower user is an Administrator or a Subscriber.
1.3 Data Flow Across the Interface
The user (Administrator or Subscriber) can access the uPower Subscriber administration
system using a Client Browser (say Netscape) by an URL, which actually calls the uPower
Presentation Layer script. The Presentation Layer will perform a preliminary data validation
on the HTML form data. Depending on the screen from which the user is posting the
request, the Presentation Layer will form a Request XML document using the form data and
2007 LogicaCMG Wireless Networks Introduction 1

also some user-specific information. Then it will call the uPower Transport Layer service to
post the Request XML to the uPower Process Layer.
The Request documents are transmitted via HTTP POST operations. Upon receipt of the
POST operation, the Apache web server instantiates the Process Layer script. This instance
of the Process Layer echoes back the corresponding Response(s) over the socket opened
for the POST. In this manner, the socket remains open until the Process Layer has
complete (or aborted) the requested operation(s). Use of the HTTP POST operation allows
the Presentation Layer to be implemented in any manner, ranging from persistent compiled
GUI applications (C++, Visual Basic, etc.) to web scripts (PHP, Tcl, etc.) to automated
provisioning systems for large-scale installations.
The following figure shows various layers in the uPower architecture and their interaction.
Client Workstation
Client Browser application
Web Request to uPower Web Response from

Presentation Layer (HTTP) Presentation Layer
(HTTP)
UNIX Server1
hosting Web
Server1
uPower Presentation Layer CGI Scripts
uPower Transport Layer Script
REQUEST XML sent RESPONSE XML(s) (partial

(HTTP) and complete) received
(HTTP)
UNIX Server2 hosting Web

Server2
uPower Process Layer CGI Scripts
Some other
LDAP (custom) database
IMAP
Figure 1-1: Data Flow Across Interface
2 <Subsystem> Process Layer Interface Description<Document Type> 2007 LogicaCMG Wireless Networks
2 Process Layer Interface Description
2.1 Introduction
Feature, Request and Response XMLs are important elements of process layer interface.
Presentation and process layers communicate with each other through the exchange of
request and response XMLs, where as the feature XML determines the functional scope of
the request. This chapter provides a detailed description of these XMLs with examples of
each.
A custom presentation layer developer should install the standard uPower presentation layer
and run it in debug mode to understand the details of communication between presentation
and process layer.
2.2 Feature XML

Each process layer request corresponds to a particular process layer feature. Feature is a
static XML, which defines the functional characteristics of the operation requested. Process
layer, is bundled with number of standard feature XMLs. Each Feature is specified by as an
XML document name. The name of the file must be <featurename>.xml. Please refer to
reference 1 to check the list of features supported by process layer and details of each
feature.
Definition of a feature includes:
Type of operation: add (add data)/modify (modify existing data)/delete (delete

existing data)
A logical group of attributes from the LDAP Directory Server accessed by the
LogicaCMG applications. The attributes may be stored under various Distinguished
Names. Any one attribute may be included in multiple Feature Definitions. For the
attributes validation rules can be defined, if defined these override the global rules
for this attribute only for this feature.
Queries required to be run for the feature.
Success/Failure message codes.
The feature XML are packaged in source form and reside typically in the
/home2/spmaster/webapps/upower/XmlDocs/Features directory. Presentation layer
developer should check the available features in this directory and also take note of the
required/allowed attributes by each feature.
2007 LogicaCMG Wireless Networks Process Layer Interface Description 3

2.2.1 Feature XML DTD
<!DOCTYPE FEATURE [
<!ELEMENT FEATURE
(OPERATION,RECORD_TYPE*,ATTRIBUTE*,QUERY*,DELETE_RECORD*)>
<!ELEMENT ATTRIBUTE (VALIDATION*)>
<!ELEMENT VALIDATION (CONSTRUCTATTRVAL*)>
<!ELEMENT CONSTRUCTATTRVAL (ATTRVALPART+)>
<!ELEMENT ATTRVALPART (EMPTY)>
<!ELEMENT OPERATION (EMPTY)>
<!ELEMENT ERRMSGS (GENERIC_SUCCESS_MSG, GENERIC_FAILURE_MSG)>
<!ELEMENT GENERIC_SUCCESS_MSG (EMPTY)>
<!ELEMENT GENERIC_FAILURE_MSG (EMPTY)>
<!ELEMENT QUERY (EMPTY)>
<!ELEMENT DELETE_RECORD (DELETE_ATTR+|DELETE_ALL)>
<!ELEMENT DELETE_ATTR (EMPTY)>
<!ELEMENT DELETE_ALL (EMPTY)>
<!ATTLIST FEATURE PRE_PROC CDATA #IMPLIED

POST_PROC CDATA #IMPLIED>
<!ATTLIST ATTRIBUTE name CDATA #IMPLIED
required CDATA #IMPLIED
loguser CDATA #IMPLIED
logprefix CDATA #IMPLIED
servertype CDATA #IMPLIED>
<!ATTLIST VALIDATION validationtype CDATA #IMPLIED
regex CDATA #IMPLIED
length CDATA #IMPLIED
errorcode CDATA #IMPLIED
procname CDATA #IMPLIED
null_value_allowed CDATA #IMPLIED
searchRegex CDATA #IMPLIED
replaceRegex CDATA #IMPLIED
isUniqueRequired CDATA #IMPLIED
uniqueness_scope CDATA #IMPLIED
uniquenessSearchAttr CDATA #IMPLIED
subtreeOrEntryDefiningAttr CDATA #IMPLIED
typeOfVal CDATA #IMPLIED
listDelimiter CDATA #IMPLIED>
<!ATTLIST OPERATION type CDATA #REQUIRED>
<!ATTLIST RECORD_TYPE recordtype CDATA #REQUIRED>
<!ATTLIST GENERIC_SUCCESS_MSG gen_success_msg_code CDATA #REQUIRED>
<!ATTLIST GENERIC_FAILURE_MSG gen_failure_msg_code CDATA #REQUIRED>
<!ATTLIST CONSTRUCTATTRVAL name CDATA #IMPLIED>
<!ATTLIST ATTRVALPART fixedstring CDATA #IMPLIED
attrname CDATA #IMPLIED
valupto CDATA #IMPLIED
valfrom CDATA #IMPLIED
valuptoincl CDATA #IMPLIED
valfromincl CDATA #IMPLIED>
<!ATTLIST QUERY name CDATA #REQUIRED
showattrlist CDATA #IMPLIED>
<!ATTLIST DELETE_RECORD name CDATA #REQUIRED>
<!ATTLIST DELETE_ATTR name CDATA #REQUIRED
rule CDATA #IMPLIED>
]>
Discussion:
It is not necessary to know all the elements in the above DTD to use the interface. Some
information in the feature XML is for the process layer internal use. This discussion includes
information about the feature XML relevant to use the interface.
Element <FEATURE>
Defines the feature.
Element <ATTRIBUTE>
The attribute name generally corresponds to the name of an LDAP attribute. However,
there are two exceptions:
Sometimes the internal attribute name specified in the Feature documents is different than
the physical storage (LDAP) attribute name. The LDAPAttributeList.tab file defines the
mapping. Refer to Chapter 2.7 for details of LDAPAttributeList.tab file.
Some Feature attributes do not correspond to any LDAP attribute, but rather serve as an
input parameter to the Process Layer.
The attribute required specifies if the LDAP attribute specified by name is required
(value=1) to process the Request. If a Request is missing a required attribute, the
Process Layer will reject the Request.
The attributes loguser and logprefix are used by process layer for event logging.
The attribute servertype specifies allows an attribute to be processed according to the

vendor(s) of the backend servers (LDAP & IMAP).
Element <VALIDATION>
The validation element specifies the validation that needs to occur for the specified attribute.
For example, in the feature xml file when the following validation exists
<ATTRIBUTE name=ou required=1>

<VALIDATION isUniqueRequired=1
uniqueness_scope=directory/>
It will be interpreted as the attribute ou will be required to exist in the request for the feature;
attribute ou will also need to be unique among the whole directory structure on the LDAP.
The valid values and the meaning of uniqueness_scope are:
Valid value for Description

uniqueness_scope
directory The scope applies to the whole directory
community The scope applies to the community
entry The scope applies to the entry
subtree The scope applies to the subtree
directorynotsubtree Whole directory but not for the subtree; subtree is
specified by subtreeOrEntryDefiningAttr
directorynotentry Whole directory but not the entry; entry is specified by
subtreeOrEntryDefiningAttr
communitynotsubtree Whole community but not for the subtree; subtree is
specified by subtreeOrEntryDefiningAttr

communitynotentry Whole community but not the entry; entry is specified by
subtreeOrEntryDefiningAttr
The subtreeOrEntryDefiningAttr is name of the attribute; for example

subtreeOrEntryDefiningAttr=uniqueidentifier
Element <QUERY>
The query element specifies the queries required to be run for the feature. The Presentation
Layer should run these queries before administering the Feature. These queries will return
necessary background data for the Feature.
The query attribute name specifies a standard query recognized by the Process Layer.
For example, GETCOSLIST will return a list of the COS.
In addition, the attribute showattrlist can specify a comma-separated list of attributes,

whose values needs to be returned along with the QUERY being executed. For example,
GETCOSLIST query can specify showattrlist=cos, cosname to return the cos and
cosname attribute values for the entire COS returned.
Element <DELETE_RECORD>
Each DELETE_RECORD specifies a data record to be partially or completely deleted when

processing the Feature. The attribute name specifies a record type to be deleted.
Element <DELETE_ATTR>
A sub-element of DELETE_RECORD, each DELETE_ATTR element specifies an individual

attribute to be deleted. The attribute is specified by name. Process layer removes these
attributes from the LDAP record during the delete operation. The attribute rule defines the
rule for deleting the attribute defined by name. The rule is specified as key-value pair based
on allowed list of attributes for the delete feature.
For example:
<DELETE_ATTR name=mailhost rule=deleteuonesubandimap=yes/>
specifies that the attribute mailhost should be deleted only if deleteuonesubandimap is set
to yes in the request. deleteuonesubandimap should be an allowed attribute by the feature.
Element <DELETE_ALL>
Presence of this sub-element of DELETE_RECORD indicates the entire record will be

deleted. With respect to LDAP storage, this typically means an entire entry and any sub-
entries could be deleted.
Feature Information for Process Layer Internal Use:
Element <FEATURE>
The attributes PRE_PROC and POST_PROC specify the names of the process layer
procedures for the feature. These are for process layer internal use.
Element <OPERATION>
The attribute type specifies the type of operation associated with this Feature. The allowed
values are add OR modify OR delete. The operation type must be defined for each
feature.
Element <RECORD_TYPE>
The attribute type specifies a data record type related to this Feature. A record type is
defined according to application logic, not necessarily physical storage.
Element <VALIDATION>
Validation rules can be defined for each element using this sub-element of ATTRIBUTE.
These rules if defined, override all other rules defined in the validation rules xml document
and attribute definition xml documents. Process layer to validate the data in the request
uses the validation rules. A Presentation layer would not typically use this information.
Element <CONSTRUCTATTRVAL> and Element <ATTRVALPART>
These elements define the validation rules and are used internally by the process layer.
Element < ERRMSGS>
The element <ERRMSGS> defines the generic success and failure messages for the
feature. The feature document contains only the error codes for these messages. The text
for the error messages is defined in the error message file. Process layer sends this
code/message text in case of failure along with specific error messages in case of failure.
2.2.2 Example of Feature XML
Following block shows the addsub_one feature XML as an example of the DTD discussed
above:
<!DOCTYPE FEATURE SYSTEM "UPOWER_FEATUREXML_DTD.xml">

<FEATURE PRE_PROC="preAddSubuOne" POST_PROC="postAddSubuOne">
<OPERATION type="add" />
<RECORD_TYPE recordtype="subscriber_main_entry"/>
<RECORD_TYPE recordtype="subscriber_device_entry"/>

<ATTRIBUTE name="uniqueidentifier" required="1" />
<ATTRIBUTE name="umdeviceversion" required="1"/>
<ATTRIBUTE name="mailroutingaddress"
servertype="Mirapoint_2_9,OpenLDAP"/>
<ATTRIBUTE name="facsimiletelephonenumber"/>
<ATTRIBUTE name="secondaryphonenumber"/>
<ATTRIBUTE name="secondarygroupmailbox"/>
<ATTRIBUTE name="mailforwardingaddress"/>
<ATTRIBUTE name="amisamsgboxid"/>
<ATTRIBUTE name="snrenabled"/>
<ATTRIBUTE name="snrpagerenabled"/>
<ATTRIBUTE name="language"/>
<ATTRIBUTE name="passwordsyncenabled"/>
<ATTRIBUTE name="amisasystem"/>
<ATTRIBUTE name="umblocked"/>
<ATTRIBUTE name="umblockedstatusdescr"/>
<ATTRIBUTE name="mailalternateaddress"/>
<ATTRIBUTE name="mailstorelocation"/>
<ATTRIBUTE name="mailquota" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxquota" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxclassofservice" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxmailboxdisabled" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxfailedlogoncount" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxvacationstatus" servertype="DCL"/>

<ATTRIBUTE name="dcmailboxforwardstatus" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxinternaldelete" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxinternalstatstime" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxstatlastupdatetime" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxstattotalsize" servertype="DCL"/>
<ATTRIBUTE name="mailforwardingenabled" servertype="DCL"/>
<ATTRIBUTE name="msghost" required="1"/>
<ATTRIBUTE name="mailhost"/>
<ATTRIBUTE name="coverphonenumber"/>
<ATTRIBUTE name="phonetype"/>
<ATTRIBUTE name="umdevicecapabilities"/>
<ATTRIBUTE name="inhoursstart"/>
<ATTRIBUTE name="inhoursend"/>
<ATTRIBUTE name="inhoursdow"/>
<ATTRIBUTE name="userlevel"/>
<ATTRIBUTE name="admininfo" required="1"/>
<ATTRIBUTE name="activegreetingid"/>
<ATTRIBUTE name="cosid"/>
<ATTRIBUTE name="cosbase"/>
<ATTRIBUTE name="snr"/>
<ATTRIBUTE name="snrnonbushrbusdays"/>
<ATTRIBUTE name="snrnonbusdays"/>
<ATTRIBUTE name="maxsnrnototry"/>
<ATTRIBUTE name="noforfirstname"/>
<ATTRIBUTE name="noforlastname"/>
<ATTRIBUTE name="subscribertimezone"/>
<ATTRIBUTE name="snaphonenumber"/>
<ATTRIBUTE name="aakey"/>
<ATTRIBUTE name="snrringnumber"/>
<ATTRIBUTE name="fastloginenabled"/>
<ATTRIBUTE name="passwordskipenabled"/>
<ATTRIBUTE name="autoplay"/>
<ATTRIBUTE name="autoplayemail"/>
<ATTRIBUTE name="autoplayfax"/>
<ATTRIBUTE name="autoplayvoice"/>
<ATTRIBUTE name="urgentemailplay"/>
<ATTRIBUTE name="urgentmsgplay"/>
<ATTRIBUTE name="urgentfaxplay"/>
<ATTRIBUTE name="urgentvoiceplay"/>
<ATTRIBUTE name="answeringservice"/>
<ATTRIBUTE name="defaultstartupapp"/>
<ATTRIBUTE name="messageplayemail"/>
<ATTRIBUTE name="messageplayvoice"/>
<ATTRIBUTE name="groupmailboxtype"/>
<ATTRIBUTE name="groupmailboxenabled"/>
<ATTRIBUTE name="badlogincount"/>

<QUERY name="GETCOSLIST" showattrlist="cos,cosname"/>
<QUERY name="GETSMPPLIST"/>
<ERRMSGS>
<GENERIC_SUCCESS_MSG gen_success_msg_code="UM_1089"/>
<GENERIC_FAILURE_MSG gen_failure_msg_code="UM_1090"/>
</ERRMSGS>
</FEATURE>
2.2.3 Super and Sub Features
A new process layer request type called grouped request was introduced in C12_00
release. The grouped request semantics are discussed in details in the process layer
request section below. This section introduces the concept of super and sub-features, which
are used in conjunction with the grouped requests. A grouped request can contain multiple
sub-requests. The grouped requests can be used only for features defined for the purpose.
These features are defined as a super feature having a set of sub-features. The primary
group request has a reference to the super feature and the sub-requests contained within
the primary request refer to the sub-features defined in the super feature. In a typical
installation the super-features can be found in the directory:
/home2/spmaster/webapps/upower/XmlDocs/SuperFeatures
and the corresponding sub-features are defined in the directory:
/home2/spmaster/webapps/upower/XmlDocs/SuperFeatures/SubFeatures.
The super and sub feature XML are related by file naming convention as elaborated in the
discussion below.
DTD for Super feature:
<!DOCTYPE FEATURE [
<!ELEMENT FEATURE (OPERATION,ALLOWEDPREFIX+)>
<!ATTLIST FEATURE PRE_PROC CDATA #IMPLIED
POST_PROC CDATA #IMPLIED>
<!ATTLIST OPERATION type CDATA #REQUIRED>
<!ATTLIST ALLOWEDPREFIX featureprefix #REQUIRED>
]>
Discussion:
The super feature allows a new element ALLOWEDPREFIX, the allowed prefix specifies a
sub-feature prefix. A super feature can specify one or more sub feature prefixes. The sub-
feature XML file is identified by the name <prefix>_<superfeaturefilename>. For example a
super feature addcomplete (filename: addcomplete.xml) defines uone as one of the
prefixes, then the sub-feature file corresponding to this prefix is uone_addcomplete.xml.
Example of a super feature XML:
<!DOCTYPE FEATURE SYSTEM "UPOWER_GROUPEDFEATUREXML_DTD.xml">

<FEATURE PRE_PROC="" POST_PROC="">


<ALLOWEDPREFIX featureprefix="common" required="1"/>
<ALLOWEDPREFIX featureprefix="uone"/>
<ALLOWEDPREFIX featureprefix="unotify"/>
</FEATURE>
DTD for a sub-feature

A sub-feature is like any other regular feature discussed earlier. The sub-feature is related to
the super feature by the file naming convention as discussed above.
2.3 Request XML

The presentation layer sends a request to the process layer in the form of a request XML.
The standard presentation layer can be configured to write the request generated for each
operation to the temporary storage
(/home2/spmaster/webapps/upower/PresentationLayer/Temp directory). To do this set the
debug level (AXDebug attribute in the /home2/spmaster/config/upowerPresLayer.ini file) to
4. The login request is written to tempReq.txt file, whereas all the subsequent requests are
written to the <sessionid>tempReq.txt. Presentation layer developer is advised to check the
requests generated by the presentation layer provided for various operations, before
implementing the feature in the custom presentation layer.
2.3.1 Request XML DTD
<?xml version="1.0" ?>

<!DOCTYPE REQUEST[
<!ELEMENT REQUEST ((LOGIN | VALIDATEDATA | VALIDATEENTRY | ADDENTRY
| MODIFYENTRY | DELETEENTRY* | SEARCHENTRY* | LOGOUT | UPLOADFILE |
COPYENTRIES | GROUPEDREQUEST | DIFFENTRIES))>
<!ELEMENT LOGIN EMPTY>
<!ELEMENT VALIDATEDATA (ATTRIBUTE )>
<!ELEMENT VALIDATEENTRY EMPTY>
<!ELEMENT ADDENTRY (ATTRIBUTE)>
<!ELEMENT MODIFYENTRY (ATTRIBUTE )>
<!ELEMENT DELETEENTRY (ATTRIBUTE )>
<!ELEMENT SEARCHENTRY (SHOWATTRIBUTE*)>
<!ELEMENT DIFFENTRIES (ENTRY+)>
<!ELEMENT LOGOUT EMPTY>
<!ELEMENT UPLOADFILE (ATTRIBUTE, BASE64DATA? )>
<!ELEMENT COPYENTRIES EMPTY>
<!ELEMENT BASE64DATA EMPTY>
<!ELEMENT ENTRY EMPTY>
<!ELEMENT SHOWATTRIBUTE EMPTY>
<!ELEMENT ATTRIBUTE (ATTR_NAME )>
<!ELEMENT ATTR_NAME (ATTR_VALUE )>
<!ELEMENT ATTR_VALUE EMPTY>
<!ELEMENT RENAMEENTRIES (ATTRIBUTE )
<!ELEMENT GROUPEDREQUEST (SUBREQUEST+)
<!ELEMENT SUBREQUEST(ATTR_NAME*)>
<!ATTLIST DIFFENTRIES featurename CDATA #IMPLIED>

<!ATTLIST ENTRY id CDATA #IMPLIED>
<!ATTLIST VALIDATEDATA featurename CDATA #IMPLIED>
<!ATTLIST VALIDATEENTRY record_identifier CDATA #IMPLIED
base_record CDATA #IMPLIED
featurename CDATA #IMPLIED>
<!ATTLIST ADDENTRY featurename CDATA #IMPLIED
base_record CDATA #IMPLIED>
<!ATTLIST MODIFYENTRY featurename CDATA #IMPLIED
<!ATTLIST UPLOADFILE featurename CDATA #IMPLIED
<!ATTLIST DELETEENTRY record_identifier CDATA #IMPLIED
<!ATTLIST RENAMEENTRIES featurename CDATA #IMPLIED
record_identifier CDATA #IMPLIED
<!ATTLIST SEARCHENTRY featurename CDATA #IMPLIED
searchfilter CDATA #IMPLIED
searchbase CDATA #IMPLIED
specialfilter CDATA #IMPLIED
record_type CDATA #IMPLIED>
<!ATTLIST COPYENTRIES base_record CDATA #IMPLIED>
<!ATTLIST SHOWATTRIBUTE name CDATA #IMPLIED>
<!ATTLIST LOGOUT userid CDATA #IMPLIED>
<!ATTLIST ATTR_NAME name CDATA #IMPLIED>
<!ATTLIST ATTR_VALUE value CDATA #IMPLIED
value_id CDATA #IMPLIED>
<!ATTLIST REQUEST sessionid CDATA #IMPLIED>
<!ATTLIST LOGIN userid CDATA #IMPLIED
passwd CDATA #IMPLIED
adminlogin CDATA #IMPLIED
accesstype CDATA #IMPLIED
provideServiceList CDATA #IMPLIED>
]>
Discussion
A request can be for:
LOGIN validate login parameters, create new session

VALIDATEDATA validate a given set of data in the context of a particular feature
being administered (like check if a telephone number is unique, etc.)
VALIDATEENTRY Make sure of backend data validity for a LogicaCMG product.
ADDENTRY create new data entry in the database, for example add a new
subscriber
MODIFYENTRY modify existing data in the database, for example modify an
existing subscriber parameters.
DELETEENTRY delete data from database, for example delete a subscriber
record
SEARCHENTRY Search database for a specified search criteria and get data.
UPLOADFILE Upload a binary data file to the backend server.
COPYENTRIES Copy existing data from one location in the database to the other.
DIFFENTRIES diff two entries on the database and show the difference between
two entries.
RENAMEENTRIES Used to rename LDAP entries (move entries from one parent
to other).
SETBASERECORD Set a community of interest (COI) to work with.
LOGOUT end current uPower session.
The featurename is an attribute of many requests. Each uPower request is tied to a

specific feature. Process layer validates the data provided in the request based on the
feature definition. featurename is the name of the feature file (without the .xml extension)
associated with the request.
Also many request elements contain record_identifier and the base_record attributes. The
record identifier is a key value (attribute in the entry) pair, which along with the base_record
uniquely identifies the record. The base_record is usually the name of the Community of

Interest (COI) to which the record belongs. e.g. record_identifier=cos=100,
base_record=ABC_Company.
All the passwords/PINs in various process layer requests should be encrypted. See section
on password encryption for details.
The following paragraphs describe the various elements of request XML in details:
Element <REQUEST>
For all requests other than the LOGIN request, the attribute sessionid should contain a
valid process layer session id. Process layer returns the session id in the response for the
LOGIN request. The process layer rejects the request if session id is missing or is invalid.
Element <LOGIN>
The attribute userid must be the login id (email address for the administrator and email
address/telephone number/uid depending the subscriber/services configuration). The
attribute passwd is the password corresponding to the userid specified. The password value
must be encrypted.
The accesstype attribute specifies the type of access (subscriber or admin). The standard
presentation layer is configured to be invoked from different ports for subscriber and
administrative access. Process layer will prevent subscriber login (login id corresponding to
a subscriber record) if this is set to admin and vice versa. This port information is
configured in the presentation layer configuration file.
The optional parameter adminlogin is used to specify an administrator started subscriber

login, that is, a subscriber login request (subscriber login id and password) but started from
the administrator screen. The process layer allows the subscriber login even for blocked
subscriber if the adminlogin parameter is set. The administrators email address is used for
the value of adminlogin parameter.
The optional parameter provideServiceList, if set to yes, instructs process layer to provide a
list of services (LogicaCMG products) plugins installed on the process layer. Process layer
provides this plugin list in the response. The presentation layer can use this information to
customize the web forms based on available services.
Element <UM6.0_COMPATIBLE_PRESLAYER>
The LOGIN request should contain the <UM6.0_COMPATIBLE_PRESLAYER> element if

the presentation layer can handle the feature read/write permissions. If this element is
present in the request, process layer uses the LDAP based user access tables. These
tables define feature-based permissions for the uPower user in greater details. The user
may have only read or write permission for a feature. The LOGIN response will contain the
allowed feature with type of permission for <UM6.0_COMPATIBLE_PRESLAYER>, else the
response contains only a list of allowed features and all features have write permission.
Process layer does not allow any writes/modify using the read-only features. This element is
made optional only for the sake of backward compatibility. All the new presentation layers
MUST use this element.
Element <LOGOUT>
The only attribute for the LOGOUT request is the userid passed at the time of LOGIN. Upon
receipt of a Logout Request, the Process Layer will delete all information about the current
session. The Process Layer will reject any subsequent Requests using the same sessionid.
Element <VALIDATEDATA>
The VALIDATEDATA request is used for validating the data passed with the request e.g.
checking uniqueness of a telephone number or email address, checking syntax of some
attribute value. The attribute featurename specifies the feature associated with this Request.
The Process Layer must have a definition of this Feature in the <featurename>.xml file
The LDAP Attribute name/value data is passed in the <ATTRIBUTE> sub-element.
Element <VALIDATEENTRY>
The VALIDATEENTRY request validates (checks if all the important attributes are set
properly, also checks other settings vital for proper functioning of the application) the LDAP
entry specified by the two attributes record_identifier and base_record. Currently
VALIDATEENTRY supports only the validatesubscriber feature which validates the
subscriber data for uOne and uNotify products.
Element <ADDENTRY>
base_record and featurename are specified as described above, base_record is the location
(for example COI) where the data is to be added. The new entry data is specified using the
<ATTRIBUTE> element. Each ADDENTRY element contains one ATTRIBUTE element.
Element <MODIFYENTRY>
base_record and featurename are specified as described above, base_record is the location
(for example COI) where the data exists. The data to be modified is specified using the
<ATTRIBUTE> element. Each MODIFYENTRY element contains one ATTRIBUTE element.
Element <SETBASERECORD>
This request is used to set the community to work with in the process layer. All subscriber
related operations are restricted to this community after issuing this request. From uPower
version 6.1 it is mandatory to issue this request after the administrator login. base_record
is the name of the Community of Interest (COI)
Element <COPYENTRIES>
This request is used to copy an entry from one location to other, for example copy COI.
Currently COPYENTRIES support only copy COI operation. base_record is the name of the
parent where the new entry is to be copied, for example ILN where a new COI is to be
created by copying an existing COI. featurename is the name of the feature being
administered. The new COI to be created is specified using the ATTRIBUTE element. Each
COPYENTRIES element contains one ATTRIBUTE element. The COI to copy from is
always the currently selected COI.
Element < UPLOADFILE>
base_record and featurename are specified as described above. This request can be used
to upload binary data as well as to modify existing data. The data to be modified is specified
using the <ATTRIBUTE> element. Each UPLOADFILE element contains one ATTRIBUTE
element. The binary data being uploaded is specified using <BASE64DATA> element.
There should be at the most one BASE64DATA element in a request.
Element <RENAMEENTRIES>
Used to rename LDAP entries (move entries from one parent to other). This can also be
used to change the RDN value of an entry by providing a suitable feature.
base_record: This is the name of the current parent (Community of Interest (COI)) to which
the record belongs.
featurename: Name of Feature being administered.
record_identifer: key value pair, which uniquely identifies the record in the given community.
Element <ATTRIBUTE>

The data to be added or modified is specified using the ATTRIBUTE element. This contains
one or more sub-element <ATTR_NAME>.
Element <ATTR_NAME>
This is a sub-element of <ATTRIBUTE>. The element <ATTRIBUTE> contains one

<ATTR_NAME> sub-element for each attribute in the request. The attribute name
specifies the name of the backend attribute. This contains one or more sub-element
<ATTR_VALUE>.
Element <ATTR_VALUE>
This is a sub-element of <ATTR_NAME>. There could be one or more <ATTR_VALUE>

elements as each attribute can have multiple values. The attribute value specifies a single
value of the attribute. Optional attribute value_id can be defined for each value. Value_id is
a identifier tag for each value. Process layer will return the value_id in response with the
error message in case of validation failure to indicate the wrong data in the request.
Presentation layer can then use this information to correctly point the user to wrong data
entered on the form.
Element <BASE64DATA>
This is used in conjunction with the UPLOADFILE. The file data being uploaded is specified
using this element. The data should be base64 encoded, it should never contain binary
data. The data is specified as parsed character (#PCDATA) data.
Element <DELETEENTRY>
There can be more than one <DELETEENTRY> elements in the request for multiple
deletes. Only limitation being that the process layer supports similar kinds of deletes in one
request. (that is it can be all delete subscriber or delete COS, etc.) The entry to be deleted is
specified using the record_identifier and the base_record attributes.
Element <SHOWATTRIBUTE>
Refer to the section 2.5 on Search Requests for details on this element.
Element <SEARCHENTRY>
Refer to the section 2.5 on Search Requests for details on this element.
Element <ENTRY>
This is used in conjunction with the DIFFENTRIES. See the request example in section
2.3.2.7 and the corresponding response example in section 2.4.2.3.
Element <DIFFENTRIES>
The DIFFENTRIES request is used to get the difference between two subscribers by
specifying the telephone numbers. Only the subscribers main and device entries will be
included in the diff process. See the request example in section 2.3.2.7 and the
corresponding response example in section 2.4.2.3.
Element <GROUPEDREQUEST>
By using GROUPEDREQUEST a sequence of requests (grouped requests) for various

features can be defined in a single process layer request. Refer to section 2.6 for details on
grouped request.
2.3.2 Examples of Request XMLs
In the request XML examples the DTD is omitted, in the actual request a DTD is appended
at the top of the request.
2.3.2.1 LOGIN Request
<REQUEST>
<LOGIN userid="newupoweroot@logicacmg.com" passwd="0l13271S6V00736V"
accesstype=admin provideServiceList =yes/>
<UM6.0_COMPATIBLE_PRESLAYER/>
</REQUEST>
2.3.2.2 SETBASERECORD Request
<REQUEST>
<SETBASERECORD base_record=ABC Company/>
</REQUEST>
2.3.2.3 ADDENTRIES (Add common subscriber) Request

Check Appendix A for more details on these requests.
<REQUEST sessionid="0221021632543c7567866908a">
<ADDENTRY featurename="addsub_common" base_record="CMGUC">
<ATTRIBUTE>
<ATTR_NAME name="blocked">
<ATTR_VALUE value="no"/>
</ATTR_NAME>
<ATTR_NAME name="language">
<ATTR_VALUE value="en"/>
</ATTR_NAME>
<ATTR_NAME name="mobiletype">
<ATTR_VALUE value="NOK"/>
</ATTR_NAME>
<ATTR_NAME name="cn">
<ATTR_VALUE value="test sub5"/>
</ATTR_NAME>
<ATTR_NAME name="mail">
<ATTR_VALUE value="10632345@abc.com"/>
</ATTR_NAME>
<ATTR_NAME name="givenname">
<ATTR_VALUE value="test"/>
</ATTR_NAME>
<ATTR_NAME name="sn">
<ATTR_VALUE value="sub6"/>
</ATTR_NAME>
<ATTR_NAME name="gender">
<ATTR_VALUE value="F"/>
</ATTR_NAME>
<ATTR_NAME name="telephonenumber">
<ATTR_VALUE value="10632345"/>
</ATTR_NAME>
<ATTR_NAME name="uid">
</ATTR_NAME>
<ATTR_NAME name="password">
<ATTR_VALUE value="0L3G0S0C2c2e2J6X"/>
</ATTR_NAME>
<ATTR_NAME name="numericpassword">
<ATTR_VALUE value="3J3d0@3W2E0X761S"/>

</ATTR_NAME>
</ATTRIBUTE>
</ADDENTRY>
</REQUEST>
2.3.2.4 UPLOADFILE Request
<REQUEST sessionid="1010020954483da586a824be5">
<UPLOADFILE featurename=uploadAllCallsGreeting>
<ATTRIBUTE>
<ATTR_NAME name="uniqueidentifier">
<ATTR_VALUE value="0911021625543d7fa6d269124"/>
</ATTR_NAME>
</ATTRIBUTE>
<BASE64DATA>R0lGODlhCgAKAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwK
bK8AQEBAgICAwMDBERERYWFhwcHCIiIikpKVVVVU1NTUJCQjk5Of98gP9QUNYAk8zs
/+/Wxufn1q2pkDMAAGYAAJkAAMwAAAAzADMzAGYzAJkzAMwzAP8zAABmADNmAGZmAJ
lmAMxmAP9mAACZADOZAGaZAJmZAMyZAP+ZAADMADPMAGbMAJnMAMzMAP/MAGb/AJn/
AMz/AAAAMzMAM2YAM5kAM8wAM/8AMwAzMzMzM2YzM5kzM8wzM/8zMwBmMzNmM2ZmM5
lmM8xmM/9mMwCZMzOZM2aZM5mZM8yZM/+ZMwDMMzPMM2bMM5nMM8zMM//MMzP/M2b/
M5n/M8z/M///MwAAZjMAZmYAZpkAZswAZv8AZgAzZjMzZmYzZpkzZswzZv8zZgBmZj
NmZmZmZplmZsxmZgCZZjOZZmaZZpmZZsyZZ</BASE64DATA>
</UPLOADFILE>
</REQUEST>
2.3.2.5 RENAMEENTRIES (move subscriber) Request

The following request will result in subscriber identified by the uniqueidentifier, being moved
from community ABC Company to community XYZ Company. The new_base_record is a
special attribute allowed by the movesubscriber feature to specify the new community.
<REQUEST sessionid="070303143058fc2d95c9274dd">
<RENAMEENTRIES featurename="movesubscriber"
record_identifier="uniqueidentifier=0515030935578c2863f1cf8bb"
base_record="ABC Company">
<ATTRIBUTE>
<ATTR_NAME name="new_base_record">
<ATTR_VALUE value="XYZ Company"
value_id="form=ADMIN_MOVE_SUBSCRIBER&element=new_base_record&valu
e=1" />
</ATTR_NAME>
</ATTRIBUTE>
</RENAMEENTRIES>
</REQUEST>
2.3.2.6 COPYENTRIES request

The following request copies the current COI (selected in uPower session) to XYZ
Company under ILN A_To_Z_Companies. There are certain restrictions on copying
communities. Check the documentation on supported features for more details.
<REQUEST sessionid="0422031121490945e4d6770b7">
<COPYENTRIES featurename="copycoi" base_record="A_To_Z_Companies">
<ATTRIBUTE>
<ATTR_NAME name="ou">
<ATTR_VALUE value="XYZ Company"
value_id="form=ADMIN_COPY_COI&element=ou&value=1" />
</ATTR_NAME>
</ATTRIBUTE>
</COPYENTRIES>
</REQUEST>
2.3.2.7 DIFFENTRIES request

The following request compares the difference between two different subscribers on the
main and device entries. The corresponding response is in section 2.4.2.3.
<REQUEST sessionid="0422031121490945e4d6770b7">
<DIFFENTRIES featurename="diffsubscribers">
<ENTRY id=telephonenumber=8041001000/>
<ENTRY id=telephonenumber=5551001000/>
</DIFFENTRIES>
</REQUEST>
2.4 Response XML

The process layer communicates back the results of request processing through the
response XML. The standard presentation layer can be configured to write the response
received for each operation to the temporary storage
(/home2/spmaster/webapps/upower/PresentationLayer/Temp directory). To do this set the
debug level (AXDebug attribute in the /home2/spmaster/config/upowerPresLayer.ini file) to
4. The login response is written to tempResp.txt file, whereas all the subsequent responses
are written to the <sessionid>tempResp.txt. Presentation layer developer is advised to
check the request-response by using the presentation layer provided, for various operations,
before implementing the feature in the custom presentation layer.
2.4.1 Response XML DTD
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE RESPONSE [
<!ELEMENT RESPONSE (RESULT+, PARTIAL_COMPLETION_MESSAGE*, MESSAGE*,
BACK_END_MSG*)>
<!ELEMENT RESULT EMPTY>
<!ELEMENT PARTIAL_COMPLETION_MESSAGE EMPTY>
<!ELEMENT MESSAGE EMPTY>
<!ELEMENT BACK_END_MSG EMPTY>
<!ELEMENT DATA ((RECORD_ID_LIST* | RECORDS* | ALLOWED_FEATURES* |
AVAILABLE_SERVICES))>
<!ELEMENT RECORD_ID_LIST EMPTY>
<!ELEMENT RECORDS (RECORD*)>
<!ELEMENT RECORD (ATTRIBUTE+)>
<!ELEMENT ATTRIBUTE (ATTR_NAME+)>
<!ELEMENT ATTR_NAME (ATTR_VALUE+)>
<!ELEMENT ENTRY (ATTR_VALUE+)>
<!ELEMENT ATTR_VALUE EMPTY>
<!ELEMENT ALLOWED_FEATURES (FEATURE+)>
<!ELEMENT AVAILABLE_SERVICES (SERVICE+)>
<!ELEMENT SERVICE EMPTY>
<!ELEMENT FEATURE (QUERY*, ACCESSLEVEL+)>
<!ELEMENT QUERY EMPTY>
<!ELEMENT ACCESSLEVEL EMPTY>

<!ATTLIST RESULT returnval CDATA
#REQUIRED>
<!ATTLIST PARTIAL_COMPLETION_MESSAGE ReqProcessInProgress CDATA
#REQUIRED>
<!ATTLIST MESSAGE msgcode CDATA
#REQUIRED
msgtext CDATA
#REQUIRED
value_id CDATA
#REQUIRED>
<!ATTLIST BACK_END_MSG msgtext CDATA
#REQUIRED>
<!ATTLIST RECORD_ID_LIST record_identifier CDATA
#IMPLIED
base_record CDATA
#IMPLIED
record_type CDATA
#IMPLIED>
<!ATTLIST RECORDS entries_count CDATA

#IMPLIED>
<!ATTLIST RECORD record_identifier CDATA
#IMPLIED
base_record CDATA
#IMPLIED
record_type CDATA
#IMPLIED>
<!ATTLIST ATTR_NAME name CDATA
#IMPLIED>
<!ATTLIST ATTR_VALUE value CDATA
#IMPLIED>
<!ATTLIST ENTRY id CDATA
#IMPLIED>
<!ATTLIST FEATURE featurename CDATA
#REQUIRED>
<!ATTLIST QUERY queryname CDATA
#IMPLIED>
<!ATTLIST ACCESSLEVEL permission CDATA
#IMPLIED>
<!ATTLIST SERVICE name CDATA
#REQUIRED>
]>
Discussion
Element <RESPONSE>
The response xml document contains a single <RESPONSE> element.
Element <RESULT>
<RESULT> contain attribute returnval, which indicates the result of the request processing.
A non-zero value of the attribute returnval indicates success and a zero value indicates
failure. The specific message code is returned within <MESSAGE> element
Element <PARTIAL_COMPLETION_MESSAGE>
If the current response is only an intermediate (partial) response from the process layer, the
response will contain <PARTIAL_COMPLETION_MESSAGE> element with attribute
ReqProcessInProgress set to 1. For requests, which take longer processing time (e.g.
deleting many entries in one request) process layer may intermittently send responses to
presentation layer informing it that the request is still being processed. This is a sort of keep-
alive response and the presentation layer should re-adjust its timeout if any, timeout on the
presentation layer to browser (or rendering device), etc. to keep all the connections alive.
Presentation layer may use this response to inform the user of the progress although the
<PARTIAL_COMPLETION_MESSAGE> does not include data quantifying (percentage
complete) the progress of overall request processing. Presentation layer may receive one
or more <PARTIAL_COMPLETION_MESSAGE> responses. The final request completion
response either will not have this element or if present the attribute ReqProcessInProgress
has a value of 0. Also the final response contains the complete response data, hence the
presentation layer need not store/cache data from the
<PARTIAL_COMPLETION_MESSAGE> responses.
Element <MESSAGE>
The attribute msgcode contains the message code, the code can either be the Generic
Success or Generic Failure code that was contained within the feature document, or this can
be a code generated by the process layer. This Message Code is unique across the
solution.
The message table is referenced in order to lookup the message text associated with a
Message Code. The attribute msgtext contains this human-readable message from the
process layer pertaining to the status of the previous Request. This message should be
displayed to the end user. This is the default error message (in English). If other language
specific error messages are required this must be done within a presentation layer making
use of the message code returned in conjunction with translation tables.
The attribute value_id is returned if there is error associated with a particular attribute value
in the request. The value_id is provided (optional) by the presentation for each value in the
request. Process layer returns the same value_id back if there is an error associated with an
attribute value. This provides the presentation layer an easy way to identify the incorrect
value and map it back to the presentation on the input device. The value_id is returned only
if it is available in the request.
Element <BACK_END_MESSAGE>
The element <BACK_END_MESSAGE> contain attribute msgtext which gives the

success/error message from the database backend. Note this message is generated by the
backend and process layer has no control over the text of the message. This message may
not be shown to the end user. This is usually more technically descriptive than the message
in <MESSAGE>. Presentation layer should log this message in the logs. A system
administrator who has some understanding of backend database servers may wish to see
this information. Conversely, this message may be confusing to a subscriber.
Element <DATA>
The element <DATA> contains the data obtained from the database queries, or the data
generated by the process layer for use by presentation layer. The <DATA> element may
have zero or more sub-elements <RECORD_ID_LIST>, <RECORDS>,
<ALLOWED_FEATURES> and <AVAILABLE_SERVICES>.
Element <RECORD_ID_LIST>
The response contains element <RECORD_ID_LIST>, when the presentation layer

requests the process layer for list of records. e.g. requests like GETBASERECORDNAMES,
GETCOSLIST, GETSMPPLIST (refer to section 2.5 for details on these requests), etc. A
single record is identified in each <RECORD_ID_LIST> element. The record is identified
using two attributes record_identifier and the base_record. Process layer also adds the
record_type attribute for each record. The record_identifier contain an attribute-value pair
from the record whereas the base_record gives the location name (community name) in the

database where the record exists. Note for some queries such as GETCOSLIST, if elements
<SHOWATTRIBUTE> are included in the request, specifying the name of the attributes,
then the response will contain both <RECORD_ID_LIST> and <RECORDS> element
(discussed below). The attribute data is returned using the <RECORDS> element.
Element <RECORDS>
The database records are returned using the <RECORDS> element. The <RECORDS>
element contains one or more <RECORD> sub-element. The attribute entries_count of the
element <RECORDS> specifies the total number of records being returned.
Element <RECORD>
Each RECORD element corresponds to an entry returned by a SEARCHENTRY or

MODIFYENTRY Request.
The record is identified by three attributes record_identifier, base_record and

record_type. These attributes are discussed in details in the Request XML Section. Each
<RECORD> element contains one sub-element <ATTRIBUTE>, which is used to list all the
attributes requested for the record.
Element <ATTRIBUTE>
Contains an ATTR_NAME sub-element for each attribute returned by the SEARCHENTRY

or MODIFYENTRY Request.
Element <ATTR_NAME>
This sub-element of ATTRIBUTE is repeated for each attribute in the record. The attribute
name contains the name of the attribute. The element <ATTR_NAME> contains one or
more <ATTR_VALUE> sub-elements.
Element <ENTRY>
This sub-element of ATTR_NAME is repeated for each attribute in the record. The attribute
id contains telephonenumber=<subscribers telephone number>. The element
<ATTR_NAME> contains two <ENTRY> sub-elements.
Element <ATTR_VALUE>
This sub-element of <ATTR_NAME> is repeated for each value of the attribute. The
attribute value contains a single value of the LDAP attribute.
Element <ALLOWED_FEATURES>
A Login Response will contain a list of allowed Features that may be administered by the
current uPower user. This list is specified by FEATURE sub-elements.
Element <FEATURE>
The attribute featurename contains the name of an allowed Feature.
Element <ACCESSLEVEL>
This is sub-element of <FEATURE> element and may be present in the response if LDAP
based access tables are used to determine users access permissions. This element has a
single required attribute permission. The valid values for the attribute permission are read
and write. A value of read indicates that the user can only do searches using this feature.
Element <AVAILABLE_SERVICES>
The login response may contain the <AVAILABLE_SERVICES> element if the LOGIN
request contains parameter provideServiceList with value yes. Process layer informs the
presentation layer about the list LogicaCMG product plugins available on the process layer
server using this element. It contains one or more sub-elements <SERVICE>.
Element <SERVICE>
This is a sub-element of <AVAILABLE_SERVICES>. The attribute name is the name of the

service (LogicaCMG product plugins available on the process layer server) available.
2.4.2 Examples of Response XML
The response to most of the requests (ADD/ MODIFY/ DELETE/ SETBASERECORD/

UPLOADFILE) is simple containing just a success or failure message. Hence only one
example is included for this type of response. The LOGIN response is different containing
more information about the uPower user, the LOGIN response is describer in details in the
following section. The search related request-response are discussed in a separate section.
2.4.2.1 LOGIN Response

This section shows a LOGIN response example, this response XML corresponds to the
LOGIN request in section 2.3.2.1
<RESPONSE>
<RESULT returnval="1" />
<MESSAGE msgcode="uPowerErr002" msgtext="Login Success" />
<DATA>
<RECORDS entries_count="3">
<RECORD record_identifier="Session ID">
<ATTRIBUTE>
<ATTR_NAME name="sessionid" >
<ATTR_VALUE value="1218031046165413987c9a860" />
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
<RECORD record_identifier="BaseRecord List">
<ATTRIBUTE>
<ATTR_NAME name="baserecord" >
<ATTR_VALUE value="d" />
<ATTR_VALUE value="l" />
<ATTR_VALUE value="a" />
<ATTR_VALUE value="r" />
<ATTR_VALUE value="m" />
</ATTR_NAME>
<ATTR_NAME name="countofeach" >
<ATTR_VALUE value="1" />
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
<RECORD record_identifier="cn=upowerRootAdmin"
base_record="uPowerAdminCOI" record_type="uPower_Administrator_Entry">
<ATTRIBUTE>
<ATTR_NAME name="mail" >
<ATTR_VALUE value="newupoweroot@nike.cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="password" >
<ATTR_VALUE value="432u2w3O754X0O4T" />
</ATTR_NAME>

<ATTR_NAME name="description" >
<ATTR_VALUE value="New Type Root Administrator" />
</ATTR_NAME>
<ATTR_NAME name="objectclass" >
<ATTR_VALUE value="lcupoweradministrator" />
</ATTR_NAME>
<ATTR_NAME name="uniqueidentifier" >
<ATTR_VALUE value="9999999999999997" />
</ATTR_NAME>
<ATTR_NAME name="upoweruserleveltable" >
<ATTR_VALUE value="Root uPower Administrator" />
</ATTR_NAME>
<ATTR_NAME name="upoweradminscope" >
<ATTR_VALUE value="cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="cn" >
<ATTR_VALUE value="upowerRootAdmin" />
</ATTR_NAME>
<ATTR_NAME name="xamtevatitle" >
<ATTR_VALUE value="admin" />
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
<ALLOWED_FEATURES>
<FEATURE featurename="addsub_unotify" >
<accesslevel permission='write'/>
</FEATURE>
<FEATURE featurename="addsub_uone" >
</FEATURE>
<FEATURE featurename="addcos_um" >
</FEATURE>
<FEATURE featurename="addsecsub_uone" >
</FEATURE>
<FEATURE featurename="modsub_unotify" >
</FEATURE>
<FEATURE featurename="modsub_uone" >
</FEATURE>
<FEATURE featurename="modsub_sgm" >
</FEATURE>
<FEATURE featurename="delsub_unotify" >
</FEATURE>
<FEATURE featurename="delsub_uone" >
</FEATURE>
<FEATURE featurename="addsub_sgm" >
</FEATURE>
<FEATURE featurename="addcos" >
</FEATURE>
<FEATURE featurename="addsubscriber" >
</FEATURE>
<FEATURE featurename="validatesubscriber" >
</FEATURE>
<FEATURE featurename="viewsuboptions" >
</FEATURE>
<FEATURE featurename="deleteadmin" >
</FEATURE>
<FEATURE featurename="deletesubscriber" >
</FEATURE>
<FEATURE featurename="modifyadmin" >
</FEATURE>
<FEATURE featurename="modifycos" >
</FEATURE>
<FEATURE featurename="modifysubscriber" >
</FEATURE>
<FEATURE featurename="deletesmsinfo" >
</FEATURE>
<FEATURE featurename="addsecsubscriber" >
</FEATURE>
<FEATURE featurename="modifysecsubscriber" >
</FEATURE>
<FEATURE featurename="deletesecsubscriber" >
</FEATURE>
<FEATURE featurename="addsmppcenter" >
</FEATURE>
<FEATURE featurename="modifysmppcenter" >
</FEATURE>
<FEATURE featurename="addamisacenter" >
</FEATURE>
<FEATURE featurename="addexternaluser" >
</FEATURE>
<FEATURE featurename="modifyexternaluser" >
</FEATURE>
<FEATURE featurename="modifyamisacenter" >
</FEATURE>
<FEATURE featurename="deleteamisacenter" >
</FEATURE>
<FEATURE featurename="deletecos" >
</FEATURE>
<FEATURE featurename="deletesmppcenter" >
</FEATURE>
<FEATURE featurename="addsmsinfo" >
</FEATURE>
<FEATURE featurename="deleteexternaluser" >
</FEATURE>
<FEATURE featurename="addadministrator" >

</FEATURE>
<FEATURE featurename="addupoweradministrator" >
</FEATURE>
<FEATURE featurename="addsub_common" >
</FEATURE>
<FEATURE featurename="modsub_common" >
</FEATURE>
<FEATURE featurename="delsub_common" >
</FEATURE>
<FEATURE featurename="adddelegateddomain" >
</FEATURE>
<FEATURE featurename="modifydelegateddomain" >
</FEATURE>
<FEATURE featurename="deletedomain" >
</FEATURE>
<FEATURE featurename="addmailaliasdomain" >
</FEATURE>
<FEATURE featurename="addfaxdomain" >
</FEATURE>
<FEATURE featurename="addcoi" >
</FEATURE>
<FEATURE featurename="modifycoi" >
</FEATURE>
<FEATURE featurename="deleteilncoi" >
</FEATURE>
<FEATURE featurename="addiln" >
</FEATURE>
<FEATURE featurename="modifyiln" >
</FEATURE>
<FEATURE featurename="copycoi" >
</FEATURE>
<FEATURE featurename="movesubscriber" >
</FEATURE>
<FEATURE featurename="logout" >
</FEATURE>
<FEATURE featurename="modifyupoweradministrator" >
</FEATURE>
<FEATURE featurename="deleteupoweradminstrator" >
</FEATURE>
<FEATURE featurename="modifyadminpasswords" >
</FEATURE>
<FEATURE featurename="addcommunity_mmsc" >
</FEATURE>
<FEATURE featurename="addsub_mmsc" >
</FEATURE>
<FEATURE featurename="delhlrlookupentry_mmsc" >
</FEATURE>
<FEATURE featurename="moddevice_mmsc" >
</FEATURE>
<FEATURE featurename="addcos_mmsc" >
</FEATURE>
<FEATURE featurename="addvas_mmsc" >
</FEATURE>
<FEATURE featurename="delsub_mmsc" >
</FEATURE>
<FEATURE featurename="moddomainalias_mmsc" >
</FEATURE>
<FEATURE featurename="adddevice_mmsc" >
</FEATURE>
<FEATURE featurename="delcos_mmsc" >
</FEATURE>
<FEATURE featurename="delvas_mmsc" >
</FEATURE>
<FEATURE featurename="modhlrlookupentry_mmsc" >
</FEATURE>
<FEATURE featurename="adddomainalias_mmsc" >
</FEATURE>
<FEATURE featurename="deldevice_mmsc" >
</FEATURE>
<FEATURE featurename="modcommunity_mmsc" >
</FEATURE>
<FEATURE featurename="modsub_mmsc" >
</FEATURE>
<FEATURE featurename="addhlrlookupentry_mmsc" >
</FEATURE>
<FEATURE featurename="deldomainalias_mmsc" >
</FEATURE>
<FEATURE featurename="modcos_mmsc" >
</FEATURE>
<FEATURE featurename="modifymmsccoi" >
</FEATURE>
</ALLOWED_FEATURES>
<AVAILABLE_SERVICES>
<SERVICE name="COMMON" />
<SERVICE name="UM" />
<SERVICE name="MMSC" />
</AVAILABLE_SERVICES>

</DATA>
</RESPONSE>
As seen above the LOGIN response mainly contains RECORD elements for session id,
base record list and the uPower users data records, ALLOWED_FEATURES and
AVAILABLE_SERVICES.
2.4.2.1.1 <RECORD> in LOGIN response

LOGIN response contains a special <RECORD> element for record_identifier="Session
ID">. This element contains a single <ATTR_NAME> to provide the value of sessionid. The
sessionid is the identifier for the session started by the LOGIN request. All subsequent
requests should contain this sessionid.
LOGIN response also contains another special <RECORD> element for

record_identifier="BaseRecord List". This element contains 2 <ATTR_NAME> for attributes
baserecord and countofeach. The baserecord attribute values list the letters with which
the community names begin and the countofeach specifies how many COIs begin with a
given letter. Thus in the example below (copied from the LOGIN response shown above)
<ATTR_NAME name="baserecord" >

<ATTR_VALUE value="d" />
<ATTR_VALUE value="l" />
<ATTR_VALUE value="a" />
<ATTR_VALUE value="r" />
<ATTR_VALUE value="m" />
</ATTR_NAME>
<ATTR_NAME name="countofeach" >
there is 1 community each starting from letter d, l, a, and r and 3 communities starting
with letter m. Presentation layer can use this data to present the COI selection information.
The other <RECORD> element(s) correspond to the uPower users data.
2.4.2.1.2 <ALLOWED_FEATURES> in LOGIN response

The <ALLOWED_FEATURES> gives a list of features allowed to administer by the uPower
user. The information consists of feature name along with the access permission
(accesslevel). The data is provided in the following format:

</FEATURE>
The accesslevel is provided only if the LOGIN request contains flag

<UM6.0_COMPATIBLE_PRESLAYER>. If the LOGIN request does not contain this flag the
FEATURE information is provided in the following format:
</FEATURE>
2.4.2.1.3 <AVAILABLE_SERVICES> in LOGIN response

The available services information is provided only if the LOGIN request parameter
provideServiceList is set to yes. This is the list of LogicaCMG products plugins installed
on the process layer server. Process layer currently recognizes the following products: UM,
MMSC, WSB, AVS, MMSTORE. UM indicates uOne or uNotify or both.
2.4.2.2 Response for Add Common subscriber request

Here both error and success message responses are shown as examples.
2.4.2.2.1 Response returning error
<RESPONSE>
<MESSAGE msgcode="uPowerErr016"
value_id="form=SUB_COMMON&element=telephonenumber&value=14"
msgtext="Duplicate value:telephonenumber=8047620050" />
</RESPONSE>
Note the value_id in the response. This value_id was supplied to process layer in the
request for the telephone number value. Also note the returnval attribute in the <RESULT>
element. A value of 0 is returned for this attribute indicating failure of requested operation.
2.4.2.2.2 Response returning success
<RESPONSE>
<MESSAGE msgcode="UM_1048" msgtext="The common subscriber data were added
successfully : Telephonenumber=8047620350" />
</RESPONSE>
Note that process layer returns a message code (msgcode) along with the message text
(msgtext). The message text is always in English. In process layer these messages/codes
are defined in XML document. If the presentation layer is implemented in a different
language or if the custom presentation layer wants to display a different text message, the
presentation layer can implement its own message table with a mapping to the message
code. In such case the presentation layer should use the message code provided in the
response to retrieve the message text from its table. LogicaCMG can provide the list of
message codes and corresponding English text of messages in order for the presentation
layer to customize it.
Also note the returnval attribute in the <RESULT> element. A value of 1 is returned for this
attribute indicating success of requested operation.
2.4.2.2.3 Response returning back end error message

Sometimes in case of an error process layer returns a message from backend or backend
libraries. This message is returned in the msgtext attribute of <BACK_END_MSG> XML
element. Since this message is returned by the database backend, process layer has no
control over the text of this message. This message is usually cryptic and hence should not
be displayed to the end user. Custom presentation layer can log this message to the log file
for some one who understands the database operations. Following response block shows
an example of <BACK_END_MSG>.

<RESPONSE>
<MESSAGE msgcode="UM_1049" msgtext="Addition of common subscriber data
failed : Telephonenumber=8047620450" />
<BACK_END_MSG msgtext="Could not connect to LDAP server" />
</RESPONSE>
2.4.2.3 DIFFENTRIES Response

This section shows a DIFFENTRIES response example, this response XML corresponds to
the DIFFENTRIES request in section 2.3.2.7
<RESPONSE>
<MESSAGE msgcode="common_9.3-02_07" msgtext="Diff successful." />
<DATA>
<RECORD record_type="uOne Subscriber Main">
<ATTRIBUTE>
<ENTRY id=telehonenumber=8041001000>
<ATTR_VALUE value="John Smith" />
</ENTRY>
<ATTR_VALUE value="Golden Subscriber" />
</ENTRY>
</ATTR_NAME>
<ATTR_NAME name="sn" >
<ATTR_VALUE value="Smith" />
</ENTRY>
</ENTRY>
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
<RECORD record_type="Subscriber Device">
<ATTRIBUTE>
<ATTR_NAME name="autoplayvoice" >
<ATTR_VALUE value="no" />
</ENTRY>
<ATTR_VALUE value="yes" />
</ENTRY>
</ATTR_NAME>
<ATTR_NAME name="badlogincount" >
</ENTRY>
</ENTRY>
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
</DATA>
</RESPONSE>
2.5 Process Layer Support for Search Requests
Process layer provides a rich set of API to carry out LDAP searches and to retrieve data
selectively. Process layer is packaged with some frequently used pre-defined search filters.
The presentation layer can use these pre-defined filters using their names (also called as
tokens or identifiers). The presentation layer can also specify the search criteria directly.
Presentation layer can request process layer to provide partial (selective) data matching the
search criteria or complete data set.
Please note that the process layer has a configuration to limit the LDAP searches based on
number of entries (size limit) and time required for searching (time limit). By default the size
limit is 100 and the time limit is 20 seconds. These parameters may affect the search results
especially while searching a large database.
2.5.1 Request XML Element <SEARCHENTRY>
All the database searches are specified using the <SEARCHENTRY> requests.
<SEARCHENTRY> may contain sub-element/s <SHOWATTRIBUTE> to limit the data
returned by the search request.
Following are the attributes for SEARCHENTRY:
featurename: Name of feature being administered. This may affect the results of a query
because the Process Layer may use it to determine the related object classes.
searchfilter: An attribute value pair (e.g. telephonenumber=8047621111) or a special pre-

defined string (token filter) with or without attribute-value pair. Some token filters require an
attribute-value pair to be specified, others dont. Token filters are discussed in details later.
searchbase: This is the COI name to which the record to be searched belongs. Though this
is an optional parameter, if provided it makes searches faster by narrowing down the scope
of search.
specialfilter: The syntax of specialfilter is similar to searchfilter. This provides additional

information about the records being searched; process layer uses this parameter to filter out
unwanted records, which do not contain the specified attribute-value pair. This is an optional
parameter.
record-type: Most of the records have a designated name. Process layer returns these
record names in the response xml. If the record_type is specified process layer filters out
unwanted records. For example if search is for AMIS-A centers, just specifying searchfilter
as amisasystem=* will return both AMIS-A centers and AMIS-A users as both entries
contain attribute amisasystem. So we can specify searchfilter as amisasystem=* and record
type= "AMIS-A Center". Following is the list of record_type designated in the process layer:
1. Greeting Administrator
2. Notify Administrator (for backward compatibility)
3. External AMIS-A Subscriber
4. uOne Subscriber Main
5. COS
6. Subscriber Device
7. SMSC Center

8. AMIS-A Center
9. Delegated_Domain
10. Fax_Domain
11. Mail_Alias_Domain
12. COI
13. ORGILN
14. ILN
15. uPower_Administrator_Entry
16. ORG
17. Unknown Type (If process layer can not resolve the record type)
2.5.2 Element <SHOWATTRIBUTE>
SEARCHENTRY element may contain zero or more SHOWATTRIBUTE elements. Each

SHOWATTRIBUTE element has one attribute name which specifies the attribute name to
be returned in the search results. If included in the Request, the Process Layer will only
return the attribute(s) specified by the SHOWATTRIBUTE element(s). Please see Generic
vs Standard queries section for more details on SHOWATTRIBUTE usage.
Note that some searches will search multiple entries for the attribute(s) from the
<SHOWATTRIBUTE> element(s).
2.5.3 Generic vs Standard Queries
The query described by the SEARCHENTRY element may be classified as a Generic or

Standard Query.
A Generic Query uses a standard search filter and search base. A Standard Query is a
predefined search identified by a special identifier string in the search filter.
If a Standard Query identifier is not found in the searchfilter attribute, the Request is
processed as a Generic Query.
The search result returned by a Standard Query may be different from that of a Generic
Query. A Standard Query will always use the SHOWATTRIBUTE (list of attributes whose
values are expected in the result) to return back the result, if SHOWATTRIBUTE is included
in the request. But the Generic Query will act differently (and will not use the
SHOWATTRIBUTE at all), when the LDAP search query comes back with exactly one entry
match. In that case, the search result will contain the whole matching LDAP entry with all the
attribute values. In addition, if this is a subscriber level main entry, it will also contain all the
device entries associated with the subscriber and also the COS entry for the subscriber.
Presentation layer developer is recommended to use the standard queries wherever

possible as against the generic ones. In the standard queries process layer
encapsulates the search logic, which makes it easier to use. Also standard queries
are optimised for performance.
Following are the standard queries (also called token filters, standard searches, etc.)
supported by the uPower process layer:
1. Searchfilter=GETBASERECORDNAMES: This is used to get a list of base
records (Community of Interest names or the names of database locations where
new records can be added). This list specifies the allowed locations for adding
additional Classes of Services, Subscribers, Administrators, etc.
2. Searchfilter=GETCOSLIST: Returns list of all COS in the scope of search.
3. Searchfilter=GETSMPPLIST: Returns list of all SMPP centers in the scope of

search.
4. Searchfilter=GETSMSLIST: Returns all records (Subscriber Device) with device

capability attribute set to SMS..
5. Searchfilter=SEARCHSUBSCRIBERS=<attribute>=<value>: This will search for

all subscriber entries matching the <attribute>=<value> filter. Below each of
these Subscriber Main entries it will search all subordinate entries for only those
attributes specified by the <SHOWATTRIBUTE> elements. The search will also
traverse the COS entry associated with the subscriber to search attributes
specified.
6. Searchfilter=SEARCHCOMMONSUBSCRIBERS=<attribute>=<value>: This
query works same as that of the above SEARCHSUBSCRIBERS query, except
that it will not return any Secondary Group Mailboxes (SGMs) in the search result.
7. Searchfilter=GETSUBATTRS=<attribute>=<value>: Return only the attributes

specified by <SHOWATTRIBUTE> of the Subscriber specified by the filter
<attribute>=<value>. The difference between GETSUBATTRS and
SEARCHSUBSCRIBERS is GETSUBATTRS searches for the attributes specified
only in the Subscriber Main entries. It does not search them in the subordinate
entries or the COS entries.
8. Searchfilter=GETSUBOREXTATTRS=<attribute>=<value>: Return only the

attributes specified by <SHOWATTRIBUTE> of the Subscriber specified by the
filter <attribute>=<value>. This standard query is same as that of
GETSUBATTRS, except that it would look for the filter attribute in the external user
(AMIS-A) entries also.
9. Searchfilter=GETSUBENTRY=<attribute>=<value>: Returns a single Subscriber

Main entry. All attributes in the entry will be included in the Response.
10. Searchfilter=GETSUBENTRIES=<attribute>=<value>: Returns the Subscriber

Main entry and all subordinate entries except Subscriber Device entries
associated with Secondary Multi-Line Subscribers. The COS entry for
corresponding to the subscriber will not be returned.
11. Searchfilter=GETSECSUBENTRIES=<secondaryphonenumber>: Returns the

Subscriber Main, Subscriber Device, entries of the Secondary Multiline
Subscriber specified by phone number = <secondaryphonenumber>.
12. Searchfilter=GETADMINS=<attribute>=<value>: Return the attributes listed in

<SHOWATTRIBUTE> of the entry specified by the filter <attribute>=<value>.
This will search only for the attributes in Greeting Administrator entries.
13. Searchfilter=GETATTRS=<attribute>=<value>: Return the attributes listed in

<SHOWATTRIBUTE> of the entry specified by the filter <attribute>=<value>.
This is a generic token filter. It searches for any entry with matching attribute
specified in the searchfilter. This search will not search through subordinate entries
to find the attributes.

14. Searchfilter=GETALLDISTLISTS=uniqueidentifier=<uniqueidentifier>: Return all
Distribution List entries. Only the attributes specified by <SHOWATTRIBUTE> will
be included in the Response.
15. Searchfilter=GETDISTLIST=<cn>: Return the Distribution List entry specified by

the filter cn=<cn>. Only the attributes specified by <SHOWATTRIBUTE> will be
included in the Response. Searchbase needs to be specified in order to identify
the subscriber. SEARCHBASE=uniqueidentifier=<value>
16. Searchfilter=GETMSGHOST: Must include <SHOWATTRIBUTE

name=serverhostname /> to return the names of all Messaging Servers
available.
17. Searchfilter=GETCOSENTRY=<cos identifier>: Returns the complete cos entry

specified by the cos identifier. The cos identifier could be the value of the cosdn
attribute in the subscriber record or an attribute value pair like cos=100.
18. Searchfilter=GETCOIBASERECORDNAMES: To get a list of all COIs

administrable by the administrator.
19. Searchfilter=GETILNBASERECORDNAMES: To get a list of all ILN

20. Searchfilter=GETORGBASERECORDNAMES: To get a list of all organizations

21. Searchfilter=GETDELEGATEDDOMAINLIST=<ou=coi/ilnname>: Get a list of

delegated domains allowed for a given COI or an ILN.
22. Searchfilter=GETFAXDOMAINLIST=<ou=coi/ilnname>: Get a list of fax domains

allowed for a given COI or an ILN.
23. Searchfilter=GETALIASDOMAINLIST=<ou=coi/ilnname>: Get a list of alias

domains allowed for a given COI or an ILN.
24. Searchfilter=GETSERVICESLIST=<ou=coi/ilnname>: Get a list of services

allowed for a given COI or an ILN.
25. Searchfilter=GETDOMAINS =<key=val>: Get the domain data, based on key-val

pair. The key can be domainname or domaintype. * is permitted for the value to
get all domains. If domainname is specified the value can be full name or partial
name. Partial name should contain as many lower domain components as
possible
26. Searchfilter=GETDOMAINSTYPE=<domaintype>: Get domain data based on

domain type (DELEGATED, FAX, ALIAS)
27. Searchfilter=GETDELEGATEDDOMAIN=<key=val>: Only allowed key is

domainname. Get delegated domain data for a given domain name.
28. Searchfilter=GETCOIS=<key=val>: Get COIs satisfying the specified key-val.

val can contain wildcard. Returns COIs based on returning admins scope.
29. Searchfilter=GETILNS=<key=val>: Similar to GETCOIS.
30. Searchfilter=GETADMINLEVELLIST: Get list of all admin levels. This list is

generated based on the level of requesting admin.
31. Searchfilter=GETADMINSCOPELIST: Get a list of baserecords for the admin

scope. This list is generated based on the level of requesting admin.
32. Searchfilter=GETUPOWERADMINISTRATORS=<key=value>: Search for
uPower administrators matching the criteria. value can contain wildcard.
33. Searchfilter= GETUPOWERADMINISTRATOR=<key=value>: Search for a single

uPower administrator matching the criteria.
2.5.4 SEARCHENTRY Request Examples
This section provides examples to illustrate the use of various search parameters. The
examples contain the request followed by the corresponding response from the process
layer.
2.5.4.1 Search using searchfilter and searchbase

This is the simplest search request; only the searchfilter and the searchbase are specified.
Request:
<REQUEST sessionid="122303153940cfe8d1af029f4">
<SEARCHENTRY
featurename="modifyamisacenter"
searchfilter="amisasystem=1001"
searchbase="Community1"
specialfilter=""
record_type="">
</SEARCHENTRY>
</REQUEST>
Response:
<RESPONSE>
<MESSAGE msgcode="uPowerErr052" msgtext="Search successful." />
<DATA>
<RECORD record_identifier="amisasystem=1001" base_record="Community1"
record_type="AMIS-A Center">
<ATTRIBUTE>
<ATTR_NAME name="objectclass" >
<ATTR_VALUE value="amisasysteminfo" />
</ATTR_NAME>
<ATTR_NAME name="amisasystem" >
</ATTR_NAME>
<ATTR_NAME name="amisasystemtelephonenumber" >
</ATTR_NAME>
<ATTR_NAME name="amisafirstremotetelephonenumber" >
</ATTR_NAME>
<ATTR_NAME name="amisalastremotetelephonenumber" >
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
</DATA>
</RESPONSE>

2.5.4.2 Use of <SHOWATTRIBUTE>
The request in this example is similar to the one above, except that it specifies
<SHOWATTRIBUTE> elements. This results in only attributes amisasystem and
amisasystemtelephonenumber being returned in the response.
Request:
<SEARCHENTRY
featurename="modifyamisacenter"
searchfilter="amisasystem=1001"
searchbase="Community1"
specialfilter=""
record_type="">
<SHOWATTRIBUTE name="amisasystem"/>
<SHOWATTRIBUTE name="amisasystemtelephonenumber"/>
</SEARCHENTRY>
Response:
<RESPONSE>
<DATA>
<RECORD record_identifier="amisasystem=1001" base_record="Community1"
record_type="AMIS-A Center">
<ATTRIBUTE>
</ATTR_NAME>
<ATTR_NAME name="amisasystemtelephonenumber" >
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
</DATA>
</RESPONSE>
2.5.4.3 Search using specialfilter

This request example illustrates the use of specialfilter parameter. Here the search for
external subscribers (AMISA subscribers) is made using filter sn=*. The attribute sn is
defined for both external as well as normal subscribers, hence this filter will return data for
both kinds of subscribers, but external subscribers have an attribute amisamsgboxid which
normal subscribers do not have. Use is made of this fact to filter out normal subscribers. For
this purpose the specialfilter attribute is used as in the following request.
Request:
<SEARCHENTRY
featurename="modifyexternaluser"
searchfilter="sn=*"
searchbase=""
specialfilter="amisamsgboxid=*"
record_type="">
<SHOWATTRIBUTE name="sn"/>
<SHOWATTRIBUTE name="givenname"/>
<SHOWATTRIBUTE name="cn"/>
<SHOWATTRIBUTE name="telephonenumber"/>
<SHOWATTRIBUTE name="mail"/>
<SHOWATTRIBUTE name="amisamsgboxid"/>
<SHOWATTRIBUTE name="amisasystem"/>
</SEARCHENTRY>
</REQUEST>
Response
<RESPONSE>
<DATA>
<RECORD record_identifier="uniqueidentifier=0213031629073e4c0e234653f"
base_record="Community1" record_type="External AMIS-A Subscriber">
<ATTRIBUTE>
<ATTR_VALUE value="Doe" />
</ATTR_NAME>
<ATTR_NAME name="givenname" >
<ATTR_VALUE value="John" />
</ATTR_NAME>
<ATTR_VALUE value="John Doe" />
</ATTR_NAME>
<ATTR_NAME name="telephonenumber" >
</ATTR_NAME>
<ATTR_VALUE value="4087337720@development.cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="amisamsgboxid" >
</ATTR_NAME>
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
<RECORD record_identifier="uniqueidentifier=0220030930053e54e66de19a1"
base_record="Community1" record_type="External AMIS-A Subscriber">
<ATTRIBUTE>
<ATTR_VALUE value="AMISAUSER" />
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>

</ATTR_NAME>
</ATTR_NAME>
<ATTR_NAME name="amisamsgboxid" >
</ATTR_NAME>
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
</DATA>
</RESPONSE>
2.5.4.4 Search using standard queries or token filter without arguments

There are two kinds of standard queries:
1. Standard queries, which do not take any argument.
2. Standard queries with argument.
This section illustrates the use of standard queries of first type. While using standard query
only the name (token) of the query need to be specified in the parameter searchfilter.
Request:
<SEARCHENTRY
featurename="addcos_um"
searchfilter="GETBASERECORDNAMES"
searchbase=""
specialfilter=""
record_type="">
</SEARCHENTRY>
</REQUEST>
Response:
<RESPONSE>
<DATA>
<RECORD_ID_LIST base_record="Community1" />
</DATA>
</RESPONSE>
2.5.4.5 Search using standard queries or token filter with arguments

Some standard queries accept argument with the token name. Following is an example of
such query. The argument (extra filter) is passed in front of the token name.
Request:
<SEARCHENTRY
featurename="modsub_common"
searchfilter="SEARCHCOMMONSUBSCRIBERS=telephonenumber=804762*"
searchbase=""
specialfilter=""
record_type="">
<SHOWATTRIBUTE name="uniqueidentifier"/>
<SHOWATTRIBUTE name="cn"/>
<SHOWATTRIBUTE name="sn"/>
<SHOWATTRIBUTE name="givenname"/>
<SHOWATTRIBUTE name="telephonenumber"/>
<SHOWATTRIBUTE name="mail"/>
<SHOWATTRIBUTE name="blocked"/>
<SHOWATTRIBUTE name="secondaryphonenumber"/>
<SHOWATTRIBUTE name="secondarygroupmailbox"/>
<SHOWATTRIBUTE name="groupmailboxtype"/>
</SEARCHENTRY>
</REQUEST>
Response:
<RESPONSE>
<DATA>
<RECORD record_identifier="uniqueidentifier=0604030832135eb180c9d86ad"
base_record="Community1" record_type="uOne Subscriber Main">
<ATTRIBUTE>
<ATTR_VALUE value="0604030832135eb180c9d86ad" />
</ATTR_NAME>
<ATTR_VALUE value="Bulk user 3167620005" />
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
<ATTR_NAME name="blocked" >
</ATTR_NAME>
<ATTR_NAME name="secondaryphonenumber" >
</ATTR_NAME>
<ATTR_NAME name="secondarygroupmailbox" >
</ATTR_NAME>
<ATTR_NAME name="groupmailboxtype" >
</ATTR_NAME>
</ATTRIBUTE>

</RECORD>
<RECORD record_identifier="uniqueidentifier=060403083221508b8972c2ea9"
base_record="Community1" record_type="uOne Subscriber Main">
<ATTRIBUTE>
<ATTR_VALUE value="060403083221508b8972c2ea9" />
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
<ATTR_NAME name="blocked" >
</ATTR_NAME>
<ATTR_NAME name="secondaryphonenumber" >
</ATTR_NAME>
<ATTR_NAME name="secondarygroupmailbox" >
</ATTR_NAME>
<ATTR_NAME name="groupmailboxtype" >
</ATTR_NAME>
</ATTRIBUTE>
</RECORD>
</RECORDS>
</DATA>
</RESPONSE>
2.6 Grouped Request

A <GROUPEDREQUEST> allows multiple sub-requests to be specified in a single process
layer request. The purpose of grouped request is to enhance provisioning performance by
minimizing the number of backend transactions. The sub-requests specified by a grouped
request should be related that is they should operate on the same data in the database.
A good example of this type of request is the operation of subscriber provisioning. Due to
the modular design approach in uPower, the subscriber provisioning is broken into n+1
(common subscriber provisioning + service provisioning) requests for a subscriber with n
services. Although this type of provisioning has advantages, it is slower since each request
writes data to the same data structure during processing of each request. Grouped request
have been introduced to optimise such requests in the common component version
C1.2_00. Grouped requests are processed together in the process layer resulting in
minimum backend commit operations.
The grouped request can be used only with the super and related sub-features. Refer to
section on Feature XML for details on these features.
2.6.1 The grouped request layout
The grouped request syntax closely follows the existing ADDENTRY element layout.
However, it adds an additional layer of hierarchy. The groupedrequest request XML format
is:
<REQUEST sessionid="??">
<GROUPEDREQUEST featurename="superfeature" base_record="base">
<SUBREQUEST featureprefix="prefx">
<ATTR_NAME name="someattr">
<ATTR_VALUE value="someval" />
<ATTR_VALUE value="someval_too" />
</ATTR_NAME>
<ATTR_NAME etc
</SUBREQUEST>
<SUBREQUEST featureprefix="other_prefix">
<ATTR_NAME name="someotherattr">
<ATTR_VALUE value="someval" />
<ATTR_VALUE value="someval_too" />
</ATTR_NAME>
</SUBREQUEST>
. . . etc . . .
</GROUPEDREQUEST>
GROUPEDREQUEST xml element: This element wraps a set of related requests.
featurename attribute: this attribute specifies what superfeature is being requested. A

superfeature is an XML document that lists allowed or required subfeatures that may be
used in a grouped request.
base_record attribute: this attribute works as it does with the old ADDENTRY elements
base_record attribute. It may be a logical DN name such as My COI 1, or a real dn such
as ou=mycoi,ou=foo_iln,o=bar.com
SUBREQUEST xml element: this element works like the old ADDENTRY element, but
specifies a subfeature rather than a regular feature. The subfeature must be allowed by
the superfeature specified in the GROUPEDREQUEST element.
featureprefix attribute: this attribute specifies the prefix associated with the subrequest.
This is relevant both to proc-level code as well as file naming conventions. For example, if
the superfeature is test1 and the prefix is uone, then the subfeature to be loaded is
named uone_test1.xml.
2.6.2 Superfeatures and subfeatures
In order to maintain the modularity of the existing uPower packages, the grouped request
calls on more than one feature. For example, in an installation containing only common and
wsb, the following feature files would be installed:
~/webapps/upower/XmlDocs/SuperFeatures/addcomplete.xml
~/webapps/upower/XmlDocs/SuperFeatures/SubFeatures/common_addcomplete.xml
~/webapps/upower/XmlDocs/SuperFeatures/SubFeatures/wsb_addcomplete.xml
Correspondingly, the request would look like:
<REQUEST sessionid="??">
<GROUPEDREQUEST featurename="addcomplete" base_record="base">

<SUBREQUEST featureprefix="common">
(attrs here)
</SUBREQUEST>
<SUBREQUEST featureprefix="wsb">
(attrs here)
</SUBREQUEST>
</GROUPEDREQUEST>
</REQUEST>
If a new service plug-in rpm were installed, it would (potentially) add a supported
subfeature for addcomplete.xml. For example, adding the uone_unotify plugin would add
the files:
~/webapps/upower/XmlDocs/SuperFeatures/SubFeatures/uone_addcomplete.xml
~/webapps/upower/XmlDocs/SuperFeatures/SubFeatures/unotify_addcomplete.xml
Superfeatures have a very simple structure. The addcomplete superfeature looks like this:
<FEATURE PRE_PROC="" POST_PROC="">



<ALLOWEDPREFIX featureprefix="common" required="1"/>
<ALLOWEDPREFIX featureprefix="uone"/>
<ALLOWEDPREFIX featureprefix="unotify"/>
<ALLOWEDPREFIX featureprefix="mmsc"/>
<ALLOWEDPREFIX featureprefix="mmstore"/>
<ALLOWEDPREFIX featureprefix="wsb"/>
<ALLOWEDPREFIX featureprefix="smsc"/>
</FEATURE>
In this superfeature, we see that there is no pre or post proc. Each individual subfeature
may also have pre and post procs (subfeatures use the existing Feature xml DTD). Note
that only one subfeature (common) is required. The remainder are optional. Also note that
subfeatures are processed in the order specified by the superfeature, NOT the order they
appear in the request. This allows feature developers to reliably retrieve values that may
have been set by prior features.
Example of Grouped Request XML:
Following is an example of grouped request for adding common subscriber and uOne and
uNotify services. The super feature addcomplete.xml allows the prefixes uone and unotify.
By using this request a complete subscriber (with uOne and uNotify services) is added using
a single request. This single request replaces 3 regular requests required otherwise.
<REQUEST sessionid="">
<GROUPEDREQUEST featurename="addcomplete" base_record="Ryan COI 1">
<SUBREQUEST featureprefix="common">
</ATTR_NAME>
<ATTR_VALUE value="eng" />
</ATTR_NAME>
<ATTR_VALUE value="abc" />
</ATTR_NAME>
<ATTR_VALUE
value="*CHA*6X1S0a273H3i1E752o132T1G1L0S6Y2R2o28630U3j4Y2Z3f183C3l3g1O0N3
A0J" />
</ATTR_NAME>
<ATTR_VALUE
value="*CHA*3Z191R240A0L472u13663Q2m160D1S2c142D5B2Q0I3o3S2f0B737X662X4X0
T2S" />
</ATTR_NAME>
<ATTR_VALUE value="rd4205" />
</ATTR_NAME>
<ATTR_VALUE value="F" />
</ATTR_NAME>
<ATTR_NAME name="locationinfoallowed">
</ATTR_NAME>
<ATTR_NAME name="prepaid">
</ATTR_NAME>
</ATTR_NAME>
<ATTR_VALUE value="rd4205@cmguc.com" />
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</ATTR_NAME>
</SUBREQUEST>
<SUBREQUEST featureprefix="uone">
<ATTR_NAME name="umdeviceversion">
<ATTR_VALUE value="6.1" />
</ATTR_NAME>
<ATTR_NAME name="mailroutingaddress">
<ATTR_VALUE value="rd4205@development.cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="umblocked">
</ATTR_NAME>
<ATTR_NAME name="mailquota">
</ATTR_NAME>
<ATTR_NAME name="mailhost">
<ATTR_VALUE value="iut-mira1.cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="msghost">
<ATTR_VALUE value="iut-mira1.cmguc.com" />
</ATTR_NAME>
<ATTR_NAME name="phonetype">
<ATTR_VALUE value="landline" />
</ATTR_NAME>
<ATTR_NAME name="inhoursstart">
</ATTR_NAME>

<ATTR_NAME name="inhoursend">
</ATTR_NAME>
<ATTR_NAME name="inhoursdow">
</ATTR_NAME>
<ATTR_NAME name="cosid">
<ATTR_VALUE value="cos=ryancos1" />
</ATTR_NAME>
<ATTR_NAME name="cosbase">
<ATTR_VALUE value="Ryan COI 1" />
</ATTR_NAME>
<ATTR_NAME name="subscribertimezone">
<ATTR_VALUE value="US/Eastern" />
</ATTR_NAME>
<ATTR_NAME name="autoplay">
</ATTR_NAME>
<ATTR_NAME name="answeringservice">
<ATTR_VALUE value="LM" />
</ATTR_NAME>
<ATTR_NAME name="messageplayvoice">
<ATTR_VALUE value="both" />
</ATTR_NAME>
<ATTR_NAME name="badlogincount">
</ATTR_NAME>
<ATTR_NAME name="preferreddateformat">
<ATTR_VALUE value="mm/dd/yyyy" />
</ATTR_NAME>
<ATTR_NAME name="preferredtimeformat">
</ATTR_NAME>
<ATTR_NAME name="secondarytimezone">
<ATTR_VALUE value="US/Eastern" />
</ATTR_NAME>
<ATTR_NAME name="notifyhost">
<ATTR_VALUE value="DEFAULT"/>
</ATTR_NAME>
</SUBREQUEST>
<SUBREQUEST featureprefix="unotify">
<ATTR_NAME name="mwienabled">
<ATTR_VALUE value="yes" />
</ATTR_NAME>
<ATTR_NAME name="ummwiswitch">
<ATTR_VALUE value="C5A" />
</ATTR_NAME>
<ATTR_NAME name="mailstorelocation">
<ATTR_VALUE value="internal" />
</ATTR_NAME>
</SUBREQUEST>
</GROUPEDREQUEST>
</REQUEST>
2.7 Mapping between External and Internal LDAP attribute names
Sometimes uPower process layer uses a different name for an attribute than is defined in
the LDAP schema. Also many a times there are attribute-naming restrictions on some LDAP
servers, resulting in different schema attribute names on different servers. To resolve this
uPower always refers the attribute using the same internal name and the mapping between
the internal to external names is provided in the form of a table. This table is typically
provided in file /home2/spmaster/LDAPAttributeList.tab (the name of this file is configurable
in process layer ini file). All uPower features and requests should contain only the internal
names. The names are translation in both directions is automatically handled by process
layer engine. That is when request is submitted with internal names, the names are
translated to external before submitting the request to LDAP server, similarly during a
search request the attribute names are converted from external to internal before providing
the search data back to presentation layer.
The LDAPAttributeList.tab file contains a | delimited list of attribute names. One attribute is
st
specified per line. The 1 column in the list is the name used by LogicaCMG (uOne)
nd
applications. The 2 column indicates the internal name used by uPower. The remaining
columns specify the attribute external name for various backends. The header line specifies
the relation between name of the backend and the column number (columns 3 onwards).
For example the following entry in LDAPAttributeList.tab file indicates that the attribute
umcosid (as defined in the schema for various backends) is called cos by both the uPower
and the applications.
cos|cos|umcosid|umcosid|umcosid|umcosid|umcosid|umcosid|
The attribute data in this file is sorted for access optimisation. It is recommended not to alter
the data in this file, but the presentation layer developer should view this file to understand
the attribute name mapping.
2.8 Password Encryption

All the passwords in all process layer request should be encrypted. Also process layer
provides passwords in encrypted form while returning those in the response. LogicaCMG
can provide the password encryption library to be integrated with the custom presentation
layer. The password encryptions/decryptions should be carried out using the library
provided.
The encryption library is written in C programming language. The encryption technique used
is single DES encryption with ECB feedback mode and NOPADDING. The package
provided consists of library source files and information on how to use the library. Re-
implementation of this library is not recommended since failure to match password
encryption can cause fatal failures across the board. Java clients can use the library
provided using JNI interface.
Some examples of clear text and corresponding cipher text passwords are provided here in
order to verify the encryption technique implemented:
Key: 55695673
cleartext=456789 ciphertext=2x7416293T3X2q09
cleartext=43210 ciphertext=1X1Z2F0Y2p3l1L0d
cleartext=qwerty ciphertext=5f0T0l2d3Y0K2063
cleartext=asdfg ciphertext=0Y2p7Y232N656W03

2.9 Mail Quota in Request/Response
Some request set the subscribers mailquota. All the mailquota values specified by the
presentation layer in all the requests that set the quota should always be in MEGABYTES.
The process layer will convert the values to different units if required by the application. Also
process layer will always provide these values back to the presentation layer in
MEGABYTES.
2.10 URL Encoding

All the process layer requests should be URL encoded before posting.
The encoding converts the encoded data into a string in which all non-alphanumeric
characters except -_. are replaced with a percent (%) sign followed by two hex digits and
spaces encoded as plus (+) signs. It is encoded the same way that the posted data from a
WWW form is encoded, that is the same way as in application/x-www-form-urlencoded
media type. The space characters are replaced by `+', and non-alphanumeric characters
are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII
code of the character. Line breaks, as in multi-line text field values, are represented as CR
LF pairs, i.e. `%0D%0A'.
For more information on application/x-www-form-urlencoded form-encoding refer to W3

website: http://www.w3.org/MarkUp/html-spec/html-spec_8.html
3 Transport Layer Specifications
3.1 Introduction
Transport layer, which resides with the presentation layer, facilitates communication
between presentation and process layers. The presentation layer communicates with the
process layer using HTTP protocol. The transport layer provides functionality for socket-
based communication to post the request and get and parse the process layer response.
The presentation layer needs to know the process layer web servers host name, port and
the script path. The standard presentation layer has this information configured in the
configuration file. The process layer start-up script processuPowerRequest.uone typically
resides in the /home2/spmaster/webapps/upower/ProcessLayer directory. The apache
server provided with the standard presentation layer is configured to define
/home2/spmaster/webapps as DocumentRoot. Hence the process layer path is defined as
/upower/ProcessLayer/processuPowerRequest.uone.
3.2 Transport Layer Functions

Transport layer should typically provide following functionality:
3.2.1 Initiate Connection
The input to this function is host and port information for the process layer web server.
Optionally this parameter may accept timeout period. Typically the timeout period can be set
to 60 seconds. It should open a non-blocking socket connection with the process layer web
server using the information provided. The function should return appropriate return code
and error message if socket open fails, else return a valid socket handle.
3.2.2 Send Request
The function should accept the socket handle, process layer host, port and path information,
and the XML request string. The function does the following:
The XML request string is URL encoded and then prefixed with string xml_data=.
This becomes the body of the HTTP request.
Prepare the HTTP request as shown below (Refer to Appendix B for an example of
process layer HTTP request):
POST <PROCESS_LAYER_SCRIPT_PATH> HTTP/1.1 <EOL>

Host: <HOST_NAME/IP_ADDRESS>: <PORT> <EOL>
Content-type: application/x-www-form-urlencoded <EOL>
Content-length: <REQUEST_XML_DATA_LENGTH><EOL>
Connection: close <EOL>
<EOL>
xml_data=<URL_ENCODED_REQUEST_XML_STRING>
where <EOL> is CRLF (\r\n).
2007 LogicaCMG Wireless Networks Transport Layer Specifications 45

Send the request to the process layer.
Return success or failure depending on length of data passed to process layer.
3.2.3 Get Response Header
This function gets the HTTP Response header sent by the process layer. NOTE that the
HTTP Response header is sent only once (in the first response) but the body may or may
not contain multiple response XMLs.
This function should do the following:
Wait for the HTTP response back from process layer.
Read the HTTP header line by line (all header lines are terminated by CRLF) until
an empty line is received.
Check if the HTTP body is chunked by checking for string transfer-encoding:

chunked in the HTTP header, if found set a flag indicating the response is chunked.
This flag will be used to read the HTTP body differently.
Please see the Appendix B for the sample HTTP Response.
3.2.4 Get Response Body
This function is called after getting the HTTP header from the response. This function will
return one response XML at a time. The caller of this function should parse the response
XML and check if this is a partial response sent by the Process Layer. The partial response
XMLs will contain the element PARTIAL_COMPLETION_MESSAGE with the attribute
ReqProcessInProgress set to value 1. Absence of this element will indicate that it is not a
partial response. If this is a partial response, then discard this response xml and call this
function again to get the next response XML sent by the Process Layer. This process should
continue until the Process Layer sends the final (non-partial) response xml. This function
should do the following:
Initialize the return buffer to empty string.
First, check if the flag is set to indicate the HTTP body is chunked.
If CHUNKED, then do the following:
o Read the first non-empty line in the HTTP body. It will be hexadecimal value
indicating the size of the HTTP body chunk that is available to be read.
o Convert the hexadecimal value to decimal. This is the chunk size. If the
chunk size is 0, then that is the end of HTTP response body. Return the
buffer to the caller.
o Read the HTTP chunk.
o Check if the last non-empty line in the chunk is ENDOFDATA. If true, then
discard that ENDOFDATA line from the chunk. Append the chunk to the
return buffer. Return the buffer to the caller of the function.
o Otherwise, Append the whole chunk to the return buffer.
o Continue to do the above steps again.
If NON-CHUNKED, then do the following:
o Read one HTTP body line.
o If empty line, then go to step 1.
o If the line is ENDOFDATA or <EOF>, return the buffer to the caller.
o Append the line to the return buffer.
o Continue to do the above steps again.
Please see the Appendix for the sample HTTP Response.
3.2.5 Close Connection
This function is called after receiving the complete response XML. This function closes the
socket connection. The parameter passed to this function is socket handle.
3.3 Sequence for calling transport layer API

Following pseudo code shows the sequence in which the transport layer functions are
called:
1. Call function to initiate connection with process layer
2. If no socket handle returned, error, go to 8
3. Call function Get Response Header.
4. Call function Get Response Body
5. Parse response
6. If PARTIAL_COMPLETION_MESSAGE, go to 4
7. Close connection
8. Go Ahead with other processing
2007 LogicaCMG Wireless Networks Transport Layer Specifications 47

Appendix A. Examples of Important
Features/Requests
Following important features/requests are discussed here in more details:
Add UM COS
Add Common Subscriber
Add uOne Service
Add uNotify Service
Delete uOne Service
Delete uNotify Service
Delete Common Subscriber
For each operation mentioned above, the feature XML, the sample request and response
are provided. Also a discussion is provided on the process layer actions on these requests
(like which attributes are default initialised by process layer in case not provided in the
request). Though the feature XML definition requires few mandatory attributes, it is
recommended to mimic the standard presentation layer requests in the custom presentation
layer for the user-application to function normally. The discussion following each request
discussed specifies the attributes, which are default initialised by the process layer, if not
specified in the request. These attributes may be omitted from the request if the default
values are desired.
This appendix refers to LDAP attribute names with their internal names. The request sent to
LDAP will contain the external (LDAP schema) names. For details on the mapping of
names see the LDAPAttributeList.tab file. For example the feature/request XMLs and the
discussion refers to LDAP attribute umcosid (schema name) as cos.
A.1 Add UM COS

The process layer feature for adding UM COS is addcos_um.xml.
Following code block shows the XML file of this feature:

<FEATURE PRE_PROC="cospreproc">
<RECORD_TYPE recordtype="umcos"/>
<ATTRIBUTE name="COS" required="1" loguser="yes" logprefix="cosnumber=">
<VALIDATION isUniqueRequired = "1"
2007 LogicaCMG Wireless Networks Examples of Important Features/Requests 49

uniqueness_scope = "community"
uniquenessSearchAttr = "cos" />
</ATTRIBUTE>
<ATTRIBUTE name="umcosversion" required="1"/>
<ATTRIBUTE name="COSName"/>
<ATTRIBUTE name="IncludeSpokenName"/>
<ATTRIBUTE name="PersDirEntriesMax"/>
<ATTRIBUTE name="DLEntriesMax"/>
<ATTRIBUTE name="DLMax"/>
<ATTRIBUTE name="InHoursStart"/>
<ATTRIBUTE name="InHoursEnd"/>
<ATTRIBUTE name="InHoursDOW"/>
<ATTRIBUTE name="EOMsgWarning"/>
<ATTRIBUTE name="LoginRetriesMax"/>
<ATTRIBUTE name="MsgLenMaxVoice"/>
<ATTRIBUTE name="PasswdLenMax"/>
<ATTRIBUTE name="PasswdLenMin"/>
<ATTRIBUTE name="passwordMaxLength"/>
<ATTRIBUTE name="passwordMinLength"/>
<ATTRIBUTE name="MessageInventory"/>
<ATTRIBUTE name="reinventory"/>
<ATTRIBUTE name="umsavedinventoryplayavailable"/>
<ATTRIBUTE name="faxenabled"/>
<ATTRIBUTE name="umfaxandemailprintenabled"/>
<ATTRIBUTE name="ttsemailenabled"/>
<ATTRIBUTE name="subscriberxfer"/>
<ATTRIBUTE name="callerxfer"/>
<ATTRIBUTE name="callerxfertocoverage"/>
<ATTRIBUTE name="diskspaceremainingwarninglevel"/>
<ATTRIBUTE name="phonenumberexpansionsection"/>
<ATTRIBUTE name="MaxLoginLockout"/>
<ATTRIBUTE name="umlockoutresetduration"/>
<ATTRIBUTE name="SubSearchBase"/>
<ATTRIBUTE name="PhoneNumberDialingSection"/>
<ATTRIBUTE name="phonenumbercalleraccesssection"/>
<ATTRIBUTE name="callerloginnumber"/>
<ATTRIBUTE name="fastloginavailable"/>
<ATTRIBUTE name="passwordskipavailable"/>
<ATTRIBUTE name="outdialturnaroundpsavailable"/>
<ATTRIBUTE name="maxmultiline"/>
<ATTRIBUTE name="multilineallowed"/>
<ATTRIBUTE name="welcomegrt"/>
<ATTRIBUTE name="umbrandingtone"/>
<ATTRIBUTE name="umtuiglobalhelpappuri"/>
<ATTRIBUTE name="MWIAvailable"/>
<ATTRIBUTE name="OutdialNotificationAvailable"/>
<ATTRIBUTE name="PagerAvailable"/>
<ATTRIBUTE name="umpagingmaxresend"/>
<ATTRIBUTE name="umpagingresendinterval"/>
<ATTRIBUTE name="SMSAvailable"/>
<ATTRIBUTE name="AnsweringServiceList"/>
<ATTRIBUTE name="DefaultStartupAppList"/>
<ATTRIBUTE name="passwordsyncavailable"/>
<ATTRIBUTE name="uOneConfigSection"/>
<ATTRIBUTE name="tuitype"/>
<ATTRIBUTE name="groupmailboxallowed"/>
<ATTRIBUTE name="maxsecphone"/>
<ATTRIBUTE name="snrmodedefault"/>
<ATTRIBUTE name="snrmodeselectableby"/>
<ATTRIBUTE name="mboxquotacos"/>
<ATTRIBUTE name="langavail"/>
<ATTRIBUTE name="langdefault"/>
<ATTRIBUTE name="languageselection"/>
<ATTRIBUTE name="umalravailable"/>
<ATTRIBUTE name="pclogintype"/>
<ATTRIBUTE name="faxheaderservicename"/>
<ATTRIBUTE name="emailnotificationavailable"/>
<ATTRIBUTE name="radiusenabled"/>
<ATTRIBUTE name="intermediatefaxmta"/>
<ATTRIBUTE name="outboundfaxsectionname"/>
<ATTRIBUTE name="useptnallowed"/>
<ATTRIBUTE name="mdnallowed"/>
<ATTRIBUTE name="umexternalmailaccountmax"/>
<ATTRIBUTE name="umwapnotificationavailable"/>
<ATTRIBUTE name="ummmsnotificationavailable"/>
<ATTRIBUTE name="ummaxnotperdayallowed"/>
<ATTRIBUTE name="umdirectnotifyavailable"/>
<ATTRIBUTE name="umfirsteventnotifyavailable"/>
<ATTRIBUTE name="umdirectnotifyfallback"/>
<ATTRIBUTE name="umdirectnotifyfallbackinterval"/>
<ATTRIBUTE name="ummaxtriggers"/>
<ATTRIBUTE name="umminperiodicnotifyinterval"/>
<ATTRIBUTE name="umperiodicnotifyfallback"/>
<ATTRIBUTE name="umperiodicnotifyfallbackinterval"/>
<ATTRIBUTE name="umperiodicalignmentactive"/>
<ATTRIBUTE name="ummaxfilters"/>
<ATTRIBUTE name="dcMailboxQuota" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxInboundSizeLimit" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxOutboundSizeLimit" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxMaxFailedLogons" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxPOP3Allowed" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxIMAP4Allowed" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxQuotaWarn" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxAddBlockSize" servertype="DCL"/>
<ATTRIBUTE name="dcMailboxMailboxType" servertype="DCL"/>
<ATTRIBUTE name="umwelcomegrtinterruptible" />
<ATTRIBUTE name="umattendantringnumber" />
<ATTRIBUTE name="umsubscriberreturncall" />
<ATTRIBUTE name="umvoicequota" />
<ATTRIBUTE name="umprepaidbillingenabled" />
<ATTRIBUTE name="umdirsearchpermissionssub" />
<ATTRIBUTE name="umdirsearchpermissionscaller" />
<ATTRIBUTE name="umasrenabled" />
<ATTRIBUTE name="umasrcssenabled" />
<ATTRIBUTE name="umexpmsgaction" />
<ATTRIBUTE name="umvoiceexpdays" />
<ATTRIBUTE name="umvuivideowelcomegrt" />
<ATTRIBUTE name="umvuivideoexpdays" />
<ATTRIBUTE name="umvuivideomailenabled" />
<ATTRIBUTE name="umvuivisualprivacyavailable" />
<ATTRIBUTE name="umvuiincludepictureid" />
<ATTRIBUTE name="umvuivideouploadenabled" />
<ATTRIBUTE name="umvuivideomsglenmax" />
<ATTRIBUTE name="umvuivideoquota" />
<ATTRIBUTE name="umhotlistmaxentries" />
<ATTRIBUTE name="ummmsplayenabled" />
<ATTRIBUTE name="umsmsplayenabled" />
<ATTRIBUTE name="ummmspushmsgavailable" />
<ATTRIBUTE name="ummdnsenabled" />
<ATTRIBUTE name="ummdnsurl" />
<ATTRIBUTE name="umfaxdistlistenabled" />
<ATTRIBUTE name="ummirapointcalnotificationavailable" />
<ATTRIBUTE name="umcallattemptnotifyavailable" />
<QUERY name="GETBASERECORDNAMES"/>
<ERRMSGS>

</ERRMSGS>
</FEATURE>
The above feature definition specifies the allowed and required attributes for the addcos_um
feature. The cos and umcosversion are required attributes without which the request will
be rejected.
Sample Add UM COS request generated by standard presentation layer:
The following request adds UM Class of Service with cos=666 and cosname=cos666.
<REQUEST sessionid="010504102216f0bfc27517233">
<ADDENTRY featurename="addcos_um" base_record="companyABC">
<ATTRIBUTE>
<ATTR_NAME name="cos">
<ATTR_VALUE value="666"
value_id="form=ADMIN_ADD_COS_FORM&element=cos&value=1" />
</ATTR_NAME>
<ATTR_NAME name="umcosversion">
<ATTR_VALUE value="5.2" value_id="form=&element=&value=2"
/>
</ATTR_NAME>
<ATTR_NAME name="cosname">
<ATTR_VALUE value="cos666"
value_id="form=ADMIN_ADD_COS_FORM&element=cosname&value=3" />
</ATTR_NAME>
<ATTR_NAME name="includespokenname">
<ATTR_VALUE value="yes"
value_id="form=ADMIN_ADD_COS_FORM&element=includespokenname&value
=4" />
</ATTR_NAME>
<ATTR_NAME name="dlentriesmax">
value_id="form=ADMIN_ADD_COS_FORM&element=dlentriesmax&value=5"
/>
</ATTR_NAME>
<ATTR_NAME name="dlmax">
value_id="form=ADMIN_ADD_COS_FORM&element=dlmax&value=6" />
</ATTR_NAME>
value_id="form=ADMIN_ADD_COS_FORM&element=inhoursstart&value=7"
/>
</ATTR_NAME>
value_id="form=ADMIN_ADD_COS_FORM&element=inhoursend&value=8" />
</ATTR_NAME>
value_id="form=ADMIN_ADD_COS_FORM&element=inhoursdow&value=9" />
</ATTR_NAME>
<ATTR_NAME name="eomsgwarning">
value_id="form=ADMIN_ADD_COS_FORM&element=eomsgwarning&value=10"
/>
</ATTR_NAME>
<ATTR_NAME name="msglenmaxvoice">
value_id="form=ADMIN_ADD_COS_FORM&element=msglenmaxvoice&value=11
" />
</ATTR_NAME>
<ATTR_NAME name="passwdlenmax">
value_id="form=ADMIN_ADD_COS_FORM&element=passwdlenmax&value=12"
/>
</ATTR_NAME>
<ATTR_NAME name="passwdlenmin">
value_id="form=ADMIN_ADD_COS_FORM&element=passwdlenmin&value=13"
/>
</ATTR_NAME>
<ATTR_NAME name="passwordmaxlength">
value_id="form=ADMIN_ADD_COS_FORM&element=passwordmaxlength&value
=14" />
</ATTR_NAME>
<ATTR_NAME name="passwordminlength">
value_id="form=ADMIN_ADD_COS_FORM&element=passwordminlength&value
=15" />
</ATTR_NAME>
<ATTR_NAME name="maxsnrnototry">
value_id="form=ADMIN_ADD_COS_FORM&element=maxsnrnototry&value=16"
/>
</ATTR_NAME>
<ATTR_NAME name="messageinventory">
value_id="form=ADMIN_ADD_COS_FORM&element=messageinventory&value=
17" />
</ATTR_NAME>
<ATTR_NAME name="reinventory">
<ATTR_VALUE value="no"
value_id="form=ADMIN_ADD_COS_FORM&element=reinventory&value=18"
/>
</ATTR_NAME>
<ATTR_NAME name="umsavedinventoryplayavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umsavedinventoryplayavailab
le&value=19" />
</ATTR_NAME>
<ATTR_NAME name="faxenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=faxenabled&value=20" />
</ATTR_NAME>
<ATTR_NAME name="umfaxandemailprintenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umfaxandemailprintenabled&a
mp;value=21" />
</ATTR_NAME>
<ATTR_NAME name="ttsemailenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=ttsemailenabled&value=2
2" />
</ATTR_NAME>
<ATTR_NAME name="subscriberxfer">
value_id="form=ADMIN_ADD_COS_FORM&element=subscriberxfer&value=23
" />
</ATTR_NAME>
<ATTR_NAME name="callerxfer">

value_id="form=ADMIN_ADD_COS_FORM&element=callerxfer&value=24" />
</ATTR_NAME>
<ATTR_NAME name="callerxfertocoverage">
value_id="form=ADMIN_ADD_COS_FORM&element=callerxfertocoverage&va
lue=25" />
</ATTR_NAME>
<ATTR_NAME name="diskspaceremainingwarninglevel">
<ATTR_VALUE value=".30"
value_id="form=ADMIN_ADD_COS_FORM&element=diskspaceremainingwarningle
vel&value=26" />
</ATTR_NAME>
<ATTR_NAME name="phonenumberexpansionsection">
<ATTR_VALUE value="DialPlan"
value_id="form=ADMIN_ADD_COS_FORM&element=phonenumberexpansionsection
&value=27" /
>
</ATTR_NAME>
<ATTR_NAME name="maxloginlockout">
value_id="form=ADMIN_ADD_COS_FORM&element=maxloginlockout&value=2
8" />
</ATTR_NAME>
<ATTR_NAME name="umlockoutresetduration">
value_id="form=ADMIN_ADD_COS_FORM&element=umlockoutresetduration&
value=29" />
</ATTR_NAME>
<ATTR_NAME name="subsearchbase">
<ATTR_VALUE value="deviut"
value_id="form=ADMIN_ADD_COS_FORM&element=subsearchbase&value=30"
/>
</ATTR_NAME>
<ATTR_NAME name="phonenumberdialingsection">
<ATTR_VALUE value="USDOMESTIC"
value_id="form=ADMIN_ADD_COS_FORM&element=phonenumberdialingsection&a
mp;value=31" /
>
</ATTR_NAME>
<ATTR_NAME name="phonenumbercalleraccesssection">
<ATTR_VALUE value="CALLERACCESS"
value_id="form=ADMIN_ADD_COS_FORM&element=phonenumbercalleraccesssect
ion&valu
e=32" />
</ATTR_NAME> <ATTR_NAME name="callerloginnumber">
<ATTR_VALUE value="ani"
value_id="form=ADMIN_ADD_COS_FORM&element=callerloginnumber&value
=33" />
</ATTR_NAME>
<ATTR_NAME name="fastloginavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=fastloginavailable&valu
e=34" />
</ATTR_NAME>
<ATTR_NAME name="passwordskipavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=passwordskipavailable&v
alue=35" />
</ATTR_NAME>
<ATTR_NAME name="outdialturnaroundpsavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=outdialturnaroundpsavailabl
e&value=36" />
</ATTR_NAME>
<ATTR_NAME name="maxmultiline">
value_id="form=ADMIN_ADD_COS_FORM&element=maxmultiline&value=37"
/>
</ATTR_NAME>
<ATTR_NAME name="multilineallowed">
value_id="form=ADMIN_ADD_COS_FORM&element=multilineallowed&value=
38" />
</ATTR_NAME>
<ATTR_NAME name="welcomegrt">
<ATTR_VALUE value="LOG_WELCOME_UONE"
value_id="form=ADMIN_ADD_COS_FORM&element=welcomegrt&value=39" />
</ATTR_NAME>
<ATTR_NAME name="mwiavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=mwiavailable&value=40"
/>
</ATTR_NAME>
<ATTR_NAME name="outdialnotificationavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=outdialnotificationavailabl
e&value=41" />
</ATTR_NAME>
<ATTR_NAME name="pageravailable">
value_id="form=ADMIN_ADD_COS_FORM&element=pageravailable&value=42
" />
</ATTR_NAME>
<ATTR_NAME name="umpagingmaxresend">
value_id="form=ADMIN_ADD_COS_FORM&element=umpagingmaxresend&value
=43" />
</ATTR_NAME>
<ATTR_NAME name="umpagingresendinterval">
value_id="form=ADMIN_ADD_COS_FORM&element=umpagingresendinterval&
value=44" />
</ATTR_NAME>
<ATTR_NAME name="smsavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=smsavailable&value=45"
/>
</ATTR_NAME>
<ATTR_NAME name="answeringservicelist">
<ATTR_VALUE value="LM"
value_id="form=ADMIN_ADD_COS_FORM&element=answeringservicelist&va
lue=46" />
</ATTR_NAME>
<ATTR_NAME name="defaultstartupapplist">
<ATTR_VALUE value="uone"
value_id="form=ADMIN_ADD_COS_FORM&element=defaultstartupapplist&v
alue=47" />
</ATTR_NAME>
<ATTR_NAME name="passwordsyncavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=passwordsyncavailable&v
alue=48" />
</ATTR_NAME>
<ATTR_NAME name="uoneconfigsection">
<ATTR_VALUE value="Default"
value_id="form=ADMIN_ADD_COS_FORM&element=uoneconfigsection&value
=49" />

</ATTR_NAME>
<ATTR_NAME name="tuitype">
<ATTR_VALUE value="Generic"
value_id="form=ADMIN_ADD_COS_FORM&element=tuitype&value=50" />
</ATTR_NAME>
<ATTR_NAME name="groupmailboxallowed">
value_id="form=ADMIN_ADD_COS_FORM&element=groupmailboxallowed&val
ue=51" />
</ATTR_NAME>
<ATTR_NAME name="maxsecphone">
value_id="form=ADMIN_ADD_COS_FORM&element=maxsecphone&value=52"
/>
</ATTR_NAME>
<ATTR_NAME name="mboxquotacos">
value_id="form=ADMIN_ADD_COS_FORM&element=mboxquotacos&value=53"
/>
</ATTR_NAME>
<ATTR_NAME name="langavail">
<ATTR_VALUE value="eng"
value_id="form=ADMIN_ADD_COS_FORM&element=langavail&value=54" />
</ATTR_NAME>
<ATTR_NAME name="langdefault">
value_id="form=ADMIN_ADD_COS_FORM&element=langdefault&value=55"
/>
</ATTR_NAME>
<ATTR_NAME name="languageselection">
value_id="form=ADMIN_ADD_COS_FORM&element=languageselection&value
=56" />
</ATTR_NAME>
<ATTR_NAME name="umalravailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umalravailable&value=57
" />
</ATTR_NAME>
<ATTR_NAME name="pclogintype">
<ATTR_VALUE value="emailpcpasswd"
value_id="form=ADMIN_ADD_COS_FORM&element=pclogintype&value=58"
/>
</ATTR_NAME>
<ATTR_NAME name="emailnotificationavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=emailnotificationavailable&
amp;value=59" />
</ATTR_NAME>
<ATTR_NAME name="radiusenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=radiusenabled&value=60"
/>
</ATTR_NAME>
<ATTR_NAME name="intermediatefaxmta">
<ATTR_VALUE value="smart-tts.cmguc.com"
value_id="form=ADMIN_ADD_COS_FORM&element=intermediatefaxmta&valu
e=61"
/>
</ATTR_NAME>
<ATTR_NAME name="outboundfaxsectionname">
<ATTR_VALUE value="T37Address"
value_id="form=ADMIN_ADD_COS_FORM&element=outboundfaxsectionname&
value=62" />
</ATTR_NAME>
<ATTR_NAME name="useptnallowed">
value_id="form=ADMIN_ADD_COS_FORM&element=useptnallowed&value=63"
/>
</ATTR_NAME>
<ATTR_NAME name="mdnallowed">
value_id="form=ADMIN_ADD_COS_FORM&element=mdnallowed&value=64" />
</ATTR_NAME>
<ATTR_NAME name="umexternalmailaccountmax">
value_id="form=ADMIN_ADD_COS_FORM&element=umexternalmailaccountmax&am
p;value=65" />
</ATTR_NAME>
<ATTR_NAME name="umwapnotificationavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umwapnotificationavailable&
amp;value=66" />
</ATTR_NAME>
<ATTR_NAME name="ummmsnotificationavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=ummmsnotificationavailable&
amp;value=67" />
</ATTR_NAME>
<ATTR_NAME name="ummaxnotperdayallowed">
value_id="form=ADMIN_ADD_COS_FORM&element=ummaxnotperdayallowed&v
alue=68" />
</ATTR_NAME>
<ATTR_NAME name="umdirectnotifyavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umdirectnotifyavailable&amp
;value=69" />
</ATTR_NAME>
<ATTR_NAME name="umfirsteventnotifyavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umfirsteventnotifyavailable
&value=70" />
</ATTR_NAME>
<ATTR_NAME name="umdirectnotifyfallback">
<ATTR_VALUE value="end"
value_id="form=ADMIN_ADD_COS_FORM&element=umdirectnotifyfallback&
value=71" />
</ATTR_NAME>
<ATTR_NAME name="umdirectnotifyfallbackinterval">
value_id="form=ADMIN_ADD_COS_FORM&element=umdirectnotifyfallbackinter
val&value=72" />
</ATTR_NAME>
<ATTR_NAME name="ummaxtriggers">
value_id="form=ADMIN_ADD_COS_FORM&element=ummaxtriggers&value=73"
/>
</ATTR_NAME>
<ATTR_NAME name="umminperiodicnotifyinterval">
value_id="form=ADMIN_ADD_COS_FORM&element=umminperiodicnotifyinterval
&value=74" />
</ATTR_NAME>
<ATTR_NAME name="umperiodicnotifyfallback">
<ATTR_VALUE value="end"
value_id="form=ADMIN_ADD_COS_FORM&element=umperiodicnotifyfallback&am
p;value=75" />

</ATTR_NAME>
<ATTR_NAME name="umperiodicnotifyfallbackinterval">
value_id="form=ADMIN_ADD_COS_FORM&element=umperiodicnotifyfallbackint
erval&value=76" />
</ATTR_NAME>
<ATTR_NAME name="umperiodicalignmentactive">
value_id="form=ADMIN_ADD_COS_FORM&element=umperiodicalignmentactive&a
mp;value=77" />
</ATTR_NAME>
<ATTR_NAME name="ummaxfilters">
value_id="form=ADMIN_ADD_COS_FORM&element=ummaxfilters&value=78"
/>
</ATTR_NAME>
<ATTR_NAME name="umwelcomegrtinterruptible">
value_id="form=ADMIN_ADD_COS_FORM&element=umwelcomegrtinterruptible&a
mp;value=79" />
</ATTR_NAME>
<ATTR_NAME name="umattendantringnumber">
value_id="form=ADMIN_ADD_COS_FORM&element=umattendantringnumber&v
alue=80" />
</ATTR_NAME>
<ATTR_NAME name="umsubscriberreturncall">
value_id="form=ADMIN_ADD_COS_FORM&element=umsubscriberreturncall&
value=81" />
</ATTR_NAME>
<ATTR_NAME name="umvoicequota">
value_id="form=ADMIN_ADD_COS_FORM&element=umvoicequota&value=82"
/>
</ATTR_NAME>
<ATTR_NAME name="umprepaidbillingenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umprepaidbillingenabled&amp
;value=83" />
</ATTR_NAME>
<ATTR_NAME name="umdirsearchpermissionssub">
<ATTR_VALUE value="coi"
value_id="form=ADMIN_ADD_COS_FORM&element=umdirsearchpermissionssub&a
mp;value=84" />
</ATTR_NAME>
<ATTR_NAME name="umdirsearchpermissionscaller">
<ATTR_VALUE value="coi"
value_id="form=ADMIN_ADD_COS_FORM&element=umdirsearchpermissionscalle
r&value=85" />
</ATTR_NAME>
<ATTR_NAME name="umasrenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umasrenabled&value=86"
/>
</ATTR_NAME>
<ATTR_NAME name="umasrcssenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umasrcssenabled&value=8
7" />
</ATTR_NAME>
<ATTR_NAME name="umexpmsgaction">
<ATTR_VALUE value="none"
value_id="form=ADMIN_ADD_COS_FORM&element=umexpmsgaction&value=88
" />
</ATTR_NAME>
<ATTR_NAME name="umvoiceexpdays">
value_id="form=ADMIN_ADD_COS_FORM&element=umvoiceexpdays&value=89
" />
</ATTR_NAME>
<ATTR_NAME name="umvuivideowelcomegrt">
<ATTR_VALUE value="LOG_VIDEO_WELCOME"
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideowelcomegrt&va
lue=90"
/>
</ATTR_NAME>
<ATTR_NAME name="umvuivideoexpdays">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideoexpdays&value
=91" />
</ATTR_NAME>
<ATTR_NAME name="umvuivideomailenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideomailenabled&v
alue=92" />
</ATTR_NAME>
<ATTR_NAME name="umvuivisualprivacyavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivisualprivacyavailable
&value=93" />
</ATTR_NAME>
<ATTR_NAME name="umvuiincludepictureid">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuiincludepictureid&v
alue=94" />
</ATTR_NAME>
<ATTR_NAME name="umvuivideouploadenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideouploadenabled&amp
;value=95" />
</ATTR_NAME>
<ATTR_NAME name="umvuivideomsglenmax">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideomsglenmax&val
ue=96" />
</ATTR_NAME> <ATTR_NAME name="umvuivideoquota">
value_id="form=ADMIN_ADD_COS_FORM&element=umvuivideoquota&value=9
7" />
</ATTR_NAME>
<ATTR_NAME name="umhotlistmaxentries">
value_id="form=ADMIN_ADD_COS_FORM&element=umhotlistmaxentries&val
ue=98" />
</ATTR_NAME>
<ATTR_NAME name="ummmsplayenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=ummmsplayenabled&value=
99" />
</ATTR_NAME>
<ATTR_NAME name="umsmsplayenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umsmsplayenabled&value=
100" />
</ATTR_NAME>

<ATTR_NAME name="ummmspushmsgavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=ummmspushmsgavailable&v
alue=101" />
</ATTR_NAME>
<ATTR_NAME name="ummdnsenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=ummdnsenabled&value=102
" />
</ATTR_NAME>
<ATTR_NAME name="ummdnsurl">
<ATTR_VALUE value="tui/messaging/dns/vxml/dns_Init.usp"
value_id="form=ADMIN_ADD_COS_FORM&element=ummdnsurl&va
lue=103" />
</ATTR_NAME>
<ATTR_NAME name="umfaxdistlistenabled">
value_id="form=ADMIN_ADD_COS_FORM&element=umfaxdistlistenabled&va
lue=104" />
</ATTR_NAME>
<ATTR_NAME name="ummirapointcalnotificationavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=ummirapointcalnotificationa
vailable&value=105
" />
</ATTR_NAME>
<ATTR_NAME name="umcallattemptnotifyavailable">
value_id="form=ADMIN_ADD_COS_FORM&element=umcallattemptnotifyavailabl
e&value=106" />
</ATTR_NAME>
</ATTRIBUTE>
</ADDENTRY>
</REQUEST>
Process layer actions
The above request adds UM COS LDAP entry with cos=666 inside the container
ou=umcos in the community companyABC..
Make sure the baserecord specified is a valid community.
A uniqueness search is carried out for cos=666 within the community

companyABC.
Process layer validates the request making sure all the required attributes (cos and
umcosversion) are defined in the request and also all other attributes in the request
are allowed by the feature definition.
Check the attribute values for certain attributes, if the values are specified are not
allowed reset the values to defaults.
The mboxquotacos value is stored in bytes (for DCL KB).
Following attributes are default initialized if not provided in the request:

o umsavedinventoryplayavailable no
o umsmsplayenabled no
o ummmsplayenabled no
o fastloginavailable no
o passwordskipavailable no
o outdialturnaroundpsavailable no
o langavail is set to langdefault if not specified
A.2 Add Common Subscriber

The process layer feature for adding common subscriber is addsub_common.xml.

<FEATURE PRE_PROC="preAddSubCommon" POST_PROC="postAddSubCommon">
<RECORD_TYPE recordtype="subscriber_main_entry"/>


<ATTRIBUTE name="blocked" required = "1" />
<ATTRIBUTE name="language" required = "1" />
<ATTRIBUTE name="mobiletype" required = "1" />
<ATTRIBUTE name="numericpassword" />
<ATTRIBUTE name="password" required = "1" />
<ATTRIBUTE name="uid" required = "1" />
<ATTRIBUTE name="gender" />
<ATTRIBUTE name="imsi" />
<ATTRIBUTE name="locationinfoallowed" />
<ATTRIBUTE name="prepaid" />
<ATTRIBUTE name="locked" />

<ATTRIBUTE name="cn" required="1"/>
<ATTRIBUTE name="mail" />
<ATTRIBUTE name="givenname"/>
<ATTRIBUTE name="sn" required="1" />
<ATTRIBUTE name="telephonenumber" loguser="yes"
logprefix="billingnumber="/>
<ATTRIBUTE name="paburi" />


<ATTRIBUTE name="upoweruserleveltable"/>
<QUERY name="GETBASERECORDNAMES"/>
<QUERY name="GETMOBILETYPES" showattrlist="mobiletype" />
<ERRMSGS>
</ERRMSGS>
</FEATURE>
The above feature definition specifies the allowed and required attributes for the
addsub_common feature. The blocked, language, mobiletype, password, uid, cn, and sn are
required attributes without which the request will be rejected.
Sample Add Common Subscriber request generated by standard presentation layer:
The following request adds a common subscriber profile with telephone number
6660001111.
<ADDENTRY featurename="addsub_common" base_record="companyABC">

<ATTRIBUTE>
value_id="form=SUB_COMMON&element=blocked&value=1" />
</ATTR_NAME>
value_id="form=SUB_COMMON&element=language&value=2" />
</ATTR_NAME>
<ATTR_VALUE value="Nokia56"
value_id="form=SUB_COMMON&element=mobiletype&value=3" />
</ATTR_NAME>
<ATTR_VALUE
value="*CHA*6X1S0a273H3i1E752o132T1G1L0S6Y2R2o28630U3j4Y2Z3f183C3l3g1O0N3
A0J" value_id="form=SUB_COMMON&am
p;element=numericpassword&value=4" />
</ATTR_NAME>
<ATTR_VALUE
value="*CHA*3Z191R240A0L472u13663Q2m160D1S2c142D5B2Q0I3o3S2f0B737X662X4X0
T2S" value_id="form=SUB_COMMON&am
p;element=password&value=5" />
</ATTR_NAME>
value_id="form=SUB_COMMON&element=uid&value=6" />
</ATTR_NAME>
<ATTR_VALUE value="M"
value_id="form=SUB_COMMON&element=gender&value=7" />
</ATTR_NAME>
<ATTR_NAME name="locationinfoallowed">
value_id="form=SUB_COMMON&element=locationinfoallowed&value=8" />
</ATTR_NAME>
<ATTR_NAME name="prepaid">
value_id="form=SUB_COMMON&element=prepaid&value=9" />
</ATTR_NAME>
<ATTR_VALUE value="John Doe"
value_id="form=SUB_COMMON&element=cn&value=10" />
</ATTR_NAME>
<ATTR_VALUE value="6660001111@companyabc.com"
value_id="form=SUB_COMMON&element=mail&value=11" />
</ATTR_NAME>
<ATTR_VALUE value="John"
value_id="form=SUB_COMMON&element=givenname&value=12" />
</ATTR_NAME>
<ATTR_VALUE value="Doe"
value_id="form=SUB_COMMON&element=sn&value=13" />
</ATTR_NAME>
value_id="form=SUB_COMMON&element=telephonenumber&value=14" />
</ATTR_NAME>
</ATTRIBUTE>
</ADDENTRY>
</REQUEST>
The above request adds common subscriber entry with telephone

number=6660001111 and uid=6660001111 inside the container ou=subscribers in
the community companyABC.
A uniqueness search is carried out for telephonenumber=6660001111 within the

whole LDAP directory. Attributes telephonenumber, snaphonenumber,
mailalternateaddress in the subscriber main entry and the attribute billingnumber in
the subscriber device entry are searched for this purpose.
A uniqueness search is carried out for uid=6660001111 within the whole LDAP
directory.
A uniqueness search is carried out for mail=6660001111@companyabc.com within

the whole LDAP directory. Note only mail attribute in the subscriber records are
searched.
Process layer validates the request making sure all the required attributes
(blocked, language, mobiletype, password, uid, cn, and sn) are defined in the
request and also all other attributes in the request are allowed by the feature
definition.
Generate an uniqueidentifier for the subscriber record.
Generate paburi attribute value.
A.3 Add Subscriber uOne Service

The process layer feature for adding uOne service is addsub_uone.xml.

<FEATURE PRE_PROC="preAddSubuOne" POST_PROC="postAddSubuOne">
<RECORD_TYPE recordtype="uone_subscriber_entry"/>
<ATTRIBUTE name="facsimiletelephonenumber"/>
<ATTRIBUTE name="secondaryphonenumber"/>
<ATTRIBUTE name="secondarygroupmailbox"/>
<ATTRIBUTE name="amisamsgboxid"/>
<ATTRIBUTE name="snrpagerenabled"/>
<ATTRIBUTE name="language"/>
<ATTRIBUTE name="passwordsyncenabled"/>
<ATTRIBUTE name="amisasystem"/>
<ATTRIBUTE name="umblocked"/>

<ATTRIBUTE name="umblockedstatusdescr"/>
<ATTRIBUTE name="mailalternateaddress"/>
<ATTRIBUTE name="mailstorelocation"/>
<ATTRIBUTE name="mailquota"/>
<ATTRIBUTE name="dcmailboxquota" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxclassofservice" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxmailboxdisabled" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxfailedlogoncount" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxvacationstatus" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxforwardstatus" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxinternaldelete" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxinternalstatstime" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxstatlastupdatetime" servertype="DCL"/>
<ATTRIBUTE name="dcmailboxstattotalsize" servertype="DCL"/>
<ATTRIBUTE name="mailforwardingenabled" servertype="DCL"/>
<ATTRIBUTE name="mailhost">
<VALIDATION
regex="(^automaticselection$|^([^.]+)(\.[^.]+){2,}$)"
errorcode="uPowerErr015" />
</ATTRIBUTE>
<ATTRIBUTE name="msghost" required="1"/>
<ATTRIBUTE name="coverphonenumber"/>
<ATTRIBUTE name="phonetype"/>
<ATTRIBUTE name="umdevicecapabilities"/>
<ATTRIBUTE name="inhoursstart"/>
<ATTRIBUTE name="inhoursend"/>
<ATTRIBUTE name="inhoursdow"/>
<ATTRIBUTE name="userlevel"/>
<ATTRIBUTE name="admininfo"/>
<ATTRIBUTE name="activegreetingid"/>
<ATTRIBUTE name="snr"/>
<ATTRIBUTE name="snrnonbushrbusdays"/>
<ATTRIBUTE name="snrnonbusdays"/>
<ATTRIBUTE name="noforfirstname"/>
<ATTRIBUTE name="noforlastname"/>
<ATTRIBUTE name="subscribertimezone"/>
<ATTRIBUTE name="snaphonenumber"/>
<ATTRIBUTE name="aakey"/>
<ATTRIBUTE name="snrringnumber"/>
<ATTRIBUTE name="fastloginenabled"/>
<ATTRIBUTE name="passwordskipenabled"/>
<ATTRIBUTE name="autoplay"/>
<ATTRIBUTE name="autoplayemail"/>
<ATTRIBUTE name="autoplayfax"/>
<ATTRIBUTE name="autoplayvoice"/>
<ATTRIBUTE name="urgentemailplay"/>
<ATTRIBUTE name="urgentmsgplay"/>
<ATTRIBUTE name="urgentfaxplay"/>
<ATTRIBUTE name="urgentvoiceplay"/>
<ATTRIBUTE name="umurgentmmsplay"/>
<ATTRIBUTE name="umurgentsmsplay"/>
<ATTRIBUTE name="umautoplaymms"/>
<ATTRIBUTE name="umautoplaysms"/>
<ATTRIBUTE name="answeringservice"/>
<ATTRIBUTE name="defaultstartupapp"/>
<ATTRIBUTE name="messageplayemail"/>
<ATTRIBUTE name="messageplayvoice"/>
<ATTRIBUTE name="groupmailboxtype"/>
<ATTRIBUTE name="groupmailboxenabled"/>
<ATTRIBUTE name="badlogincount"/>
<ATTRIBUTE name="umvuivisualprivacyenabled"/>
<ATTRIBUTE name="umvuiactivevideogreetingid"/>
<ATTRIBUTE name="umvuiurgentvideoplay"/>
<ATTRIBUTE name="umvuiautoplayvideo" />
<ATTRIBUTE name="umvuimessageplayvideo"/>
<ATTRIBUTE name="umbtnumber"/>
<ATTRIBUTE name="PreferredDateFormat" />
<ATTRIBUTE name="PreferredTimeFormat" />
<ATTRIBUTE name="secondarytimezone" />

<ERRMSGS>
</ERRMSGS>
</FEATURE>
addsub_uone feature. The uniqueidentifier, umdeviceversion and msghost are required
attributes without which the request will be rejected.
Sample Add uOne service request generated by standard presentation layer:
The following request adds uOne service for subscriber with uniqueidentifier
010504102953ae4642875edef.
<ADDENTRY featurename="addsub_uone" base_record="companyABC">
<ATTRIBUTE>
<ATTR_VALUE value="010504102953ae4642875edef"
value_id="form=SUB_UONE_1&element=uniqueidentifier&value=1" />
</ATTR_NAME>
<ATTR_VALUE value="6.1"
value_id="form=SUB_UONE_2&element=dcmailboxfailedlogoncount&value
=2" />
</ATTR_NAME>
<ATTR_NAME name="mailroutingaddress">
<ATTR_VALUE value="6660001111@deldomain1.companyABC.com"
value_id="form=SUB_UONE_2&element=mailroutingaddress&value=3" />
</ATTR_NAME>
<ATTR_NAME name="umblocked">
value_id="form=SUB_UONE_2&element=umblocked&value=4" />
</ATTR_NAME>
<ATTR_NAME name="mailquota">
value_id="form=SUB_UONE_2&element=mailquota&value=5" />
</ATTR_NAME>
<ATTR_NAME name="mailhost">
<ATTR_VALUE value="automaticselection"
value_id="form=SUB_UONE_2&element=mailhost&value=6" />
</ATTR_NAME>
<ATTR_NAME name="msghost">
<ATTR_VALUE value="smart-mira.cmguc.com"
value_id="form=SUB_UONE_2&element=msghost&value=7" />
</ATTR_NAME>
<ATTR_NAME name="phonetype">

<ATTR_VALUE value="landline"
value_id="form=SUB_UONE_2&element=phonetype&value=8" />
</ATTR_NAME>
value_id="form=SUB_UONE_2&element=inhoursstart&value=9" />
</ATTR_NAME>
value_id="form=SUB_UONE_2&element=inhoursend&value=10" />
</ATTR_NAME>
value_id="form=SUB_UONE_2&element=inhoursdow&value=11" />
</ATTR_NAME>
<ATTR_VALUE value="cos=666"
value_id="form=SUB_UONE_1&element=cosid&value=12" />
</ATTR_NAME>
value_id="form=SUB_UONE_1&element=cosbase&value=13" />
</ATTR_NAME>
<ATTR_NAME name="subscribertimezone">
<ATTR_VALUE value="US/Eastern"
value_id="form=SUB_UONE_2&element=subscribertimezone&value=14" />
</ATTR_NAME>
<ATTR_NAME name="autoplay">
value_id="form=SUB_UONE_2&element=autoplay&value=15" />
</ATTR_NAME>
<ATTR_NAME name="answeringservice">
<ATTR_VALUE value="LM"
value_id="form=SUB_UONE_2&element=answeringservice&value=16" />
</ATTR_NAME>
<ATTR_NAME name="messageplayvoice">
<ATTR_VALUE value="both"
value_id="form=SUB_UONE_2&element=messageplayvoice&value=17" />
</ATTR_NAME>
<ATTR_NAME name="badlogincount">
value_id="form=SUB_UONE_2&element=badlogincount&value=18" />
</ATTR_NAME>
<ATTR_VALUE value="mm/dd/yyyy"
value_id="form=&element=&value=19" />
</ATTR_NAME>
<ATTR_VALUE value="12" value_id="form=&element=&value=20"
/>
</ATTR_NAME>
<ATTR_NAME name="secondarytimezone">
<ATTR_VALUE value="US/Eastern"
value_id="form=SUB_UONE_2&element=secondarytimezone&value=21" />
</ATTR_NAME>
</ATTRIBUTE>
</ADDENTRY>
</REQUEST>
The above modifies the subscriber main entry and adds a new device entry for the
subscriber inside the container ou=subscribers in the community companyABC.
The device entry is child of subscriber main entry.
(uniqueidentifier, umdeviceversion and msghost) are defined in the request and also
all other attributes in the request are allowed by the feature definition.
The attribute mailhost allows a special value automaticselection for Mirapoint

IMAP backends. In this case if mailhost is specified as automaticselection, process
layer automatically picks up a best available mail server.
Process layer creates a greeting administrator automatically if no greeting admin is

available. The subscriber greeting folders are created in the greeting admin IMAP
account.
If mailquota value is specified as 0, it is treated as unlimited.
Following attributes are default initialized if not provided in the request:

o umbtnumber same value as telephonenumber
o For iPlanet only, maildeliveryoption mailbox and forward
o For iPlanet only, mailuserstatus active
o For iPlanet only, inetuserstatus active
o mailstorelocation internal
o blockedstatusdate current timestamp set only if umblocked=yes
o userlevel 0
o umvuivideouserlevel 0
o Set only if COS attribute mdnallowed=yes, mdngettype manual
o Set only if COS attribute mdnallowed=yes, requestmdn no
o admininfo uniqueidentifier=<greeting admins uniqueidentifier>
o fastloginenabled no
o urgentmsgplay yes
o umhotlistmsgplay no
o urgentemailplay yes
o urgentvoiceplay yes
o urgentfaxplay yes
o umurgentmmsplay yes
o umurgentsmsplay yes
o ummessageplaysms both, if COS attribute umsmsplayenabled=yes
o ummessageplaymms both, if COS attribute ummmsplayenabled=yes
o autoplayfax yes
o autoplayvoice yes
o autoplayemail yes
o umautoplaymms yes
o umautoplaysms yes
o Only if video mail is available in COS, umvuiurgentvideoplay yes
o Only if video mail is available in COS, umvuiautoplayvideo yes
o Only if video mail is available in COS, umvuimessageplayvideo both
o passwordsyncenabled no
o passwordskipenabled no
o groupmailboxenabled no

A.4 Add Subscriber uNotify Service
The process layer feature for adding uNotify service is addsub_unotify.xml.

<FEATURE PRE_PROC="preModSubuNotify" POST_PROC="postAddSubuNotify">
<RECORD_TYPE recordtype="unotify_subscriber_entry"/>
<ATTRIBUTE name="billingnumber" required="1" loguser="yes"
logprefix="billingnumber="/>
<ATTRIBUTE name="mailhost">
<VALIDATION
regex="(^automaticselection$|^([^.]+)(\.[^.]+){2,}$)"
errorcode="uPowerErr015" />
</ATTRIBUTE>
<ATTRIBUTE name="msghost"/>
<ATTRIBUTE name="emailnotificationaddress" />
<ATTRIBUTE name="emailnotificationenabled" />
<ATTRIBUTE name="MWIEnabled" />
<ATTRIBUTE name="outdialNotificationEnabled" />
<ATTRIBUTE name="outdialNotificationNumber" />
<ATTRIBUTE name="outdialturnaroundpsenabled" />
<ATTRIBUTE name="SMSEnabled" />
<ATTRIBUTE name="NotifyEmailNormal" />
<ATTRIBUTE name="NotifyEmailUrgent" />
<ATTRIBUTE name="NotifyFaxNormal" />
<ATTRIBUTE name="NotifyFaxUrgent" />
<ATTRIBUTE name="NotifyVoiceNormal" />
<ATTRIBUTE name="NotifyVoiceUrgent" />
<ATTRIBUTE name="PreferredDateFormat" />
<ATTRIBUTE name="PreferredTimeFormat" />
<ATTRIBUTE name="pagerenabled" />
<ATTRIBUTE name="pagertype" />
<ATTRIBUTE name="pageremailaddress" />
<ATTRIBUTE name="pager" />
<ATTRIBUTE name="pagerpin" />
<ATTRIBUTE name="pagingprovider" />
<ATTRIBUTE name="umoutdialpagingcallbacknumber" />
<ATTRIBUTE name="umoutdialpagerrule" />
<ATTRIBUTE name="umNotifyHoursStart" />
<ATTRIBUTE name="umNotifyHoursEnd" />
<ATTRIBUTE name="umNotifyDays" />
<ATTRIBUTE name="umNotifyMMNormal" />
<ATTRIBUTE name="umNotifyMMUrgent" />
<ATTRIBUTE name="umFilters" />
<ATTRIBUTE name="umMaxAttachmentsInNotification" />
<ATTRIBUTE name="umMaxContentFieldLength" />
<ATTRIBUTE name="umMaxFromFieldLength" />
<ATTRIBUTE name="umMaxTotalLength" />
<ATTRIBUTE name="umMaxNotPerDay" />
<ATTRIBUTE name="umMaxSubjectFieldLength" />
<ATTRIBUTE name="umTriggers" />
<ATTRIBUTE name="umWapNotificationEnabled" />
<ATTRIBUTE name="umMMSNotificationEnabled" />
<ATTRIBUTE name="umInHoursDirectEnabled" />
<ATTRIBUTE name="umInHoursPeriodicEnabled" />
<ATTRIBUTE name="umInHoursPeriodicInterval" />
<ATTRIBUTE name="umInHoursPeriodicChannel" />
<ATTRIBUTE name="umInHoursFirstEventEnabled" />
<ATTRIBUTE name="umOutHoursDirectEnabled" />
<ATTRIBUTE name="umOutHoursPeriodicEnabled" />
<ATTRIBUTE name="umOutHoursPeriodicInterval" />
<ATTRIBUTE name="umOutHoursPeriodicChannel" />
<ATTRIBUTE name="umOutHoursFirstEventEnabled" />
<ATTRIBUTE name="umOutDaysDirectEnabled" />
<ATTRIBUTE name="umOutDaysPeriodicEnabled" />
<ATTRIBUTE name="umOutDaysPeriodicInterval" />
<ATTRIBUTE name="umOutDaysPeriodicChannel" />
<ATTRIBUTE name="umOutDaysFirstEventEnabled" />
<ATTRIBUTE name="umInHoursTriggerA" />
<ATTRIBUTE name="umInHoursTriggerB" />
<ATTRIBUTE name="umInHoursTriggerC" />
<ATTRIBUTE name="umOutHoursTriggerA" />
<ATTRIBUTE name="umOutHoursTriggerB" />
<ATTRIBUTE name="umOutHoursTriggerC" />
<ATTRIBUTE name="umOutDaysTriggerA" />
<ATTRIBUTE name="umOutDaysTriggerB" />
<ATTRIBUTE name="umOutDaysTriggerC" />
<ATTRIBUTE name="umMWIswitch" />

<ATTRIBUTE name="gsmdatacodingscheme"/>
<ATTRIBUTE name="notificationexptime"/>
<ATTRIBUTE name="npi"/>
<ATTRIBUTE name="smppcenterid"/>
<ATTRIBUTE name="ton"/>

<ATTRIBUTE name="ummmspushmsgenabled" />

<ATTRIBUTE name="mailstorelocation"/> 

<QUERY name="GETSMPPLIST"/>
<ERRMSGS>
</ERRMSGS>
</FEATURE>
addsub_unotify feature. The uniqueidentifier, umdeviceversion and billingnumber are
required attributes without which the request will be rejected.
Sample Add uNotify service request generated by standard presentation layer:
The following request adds uNotify service for subscriber with uniqueidentifier
010504102953ae4642875edef.
<MODIFYENTRY featurename="addsub_unotify" base_record="companyABC">
<ATTRIBUTE>

<ATTR_VALUE value="010504102953ae4642875edef"
value_id="form=SUB_UNOTIFY_1&element=uniqueidentifier&value=1" /
>
</ATTR_NAME>
<ATTR_NAME name="billingnumber">
value_id="form=SUB_UNOTIFY&element=billingnumber&value=2" />
</ATTR_NAME>
<ATTR_VALUE value="6.1"
value_id="form=SUB_UNOTIFY&element=mailstorelocation&value=3" />
</ATTR_NAME>
<ATTR_NAME name="mwienabled">
value_id="form=SUB_UNOTIFY&element=mwienabled&value=4" />
</ATTR_NAME>
<ATTR_VALUE value="mm/dd/yyyy"
value_id="form=&element=&value=5" />
</ATTR_NAME>
<ATTR_VALUE value="12" value_id="form=&element=&value=6"
/>
</ATTR_NAME>
<ATTR_NAME name="ummwiswitch">
<ATTR_VALUE value="SMART"
value_id="form=SUB_UNOTIFY&element=ummwiswitch&value=7" />
</ATTR_NAME>
<ATTR_VALUE value="cos=666"
value_id="form=SUB_UNOTIFY_1&element=cosid&value=8" />
</ATTR_NAME>
value_id="form=SUB_UNOTIFY_1&element=cosbase&value=9" />
</ATTR_NAME>
</ATTRIBUTE>
</MODIFYENTRY>
</REQUEST>
The above modifies the subscriber main entry inside the container ou=subscribers
in the community companyABC.
(uniqueidentifier, umdeviceversion and billingnumber) are defined in the request and
also all other attributes in the request are allowed by the feature definition.
A.5 Delete Subscriber uOne Service

The process layer feature for deleting uOne service is delsub_uone.xml.

<FEATURE PRE_PROC="preDelSubuOne" POST_PROC="postDelSubuOne">
<OPERATION type="delete" />
<ATTRIBUTE name="billingnumber" required="1"/>
<ATTRIBUTE name="deleteuonesubandimap" />
<DELETE_RECORD name="uone_subscriber_entry"> 
<DELETE_ATTR name="cosdn" otherobjectclasses="umnotifier"/>
<DELETE_ATTR name="mailhost" otherobjectclasses="umnotifier"/>
<DELETE_ATTR name="mailroutingaddress"
otherobjectclasses="umnotifier"/>
</DELETE_RECORD>
<DELETE_RECORD name="subscriber_device_entry">
<DELETE_ALL/>
</DELETE_RECORD>
<ERRMSGS>
</ERRMSGS>
</FEATURE>
The above feature defines the logic of deleting uOne service. The billingnumber is a
required attribute. The feature specifies that the attributes cosdn, mailhost and
mailroutingaddress are deleted from the uone_subscriber_entry (which is same as
subscriber main entry) if the objectclass umnotifier is not set (uNotify not subscribed by the
subscriber). The feature also specifies that all the attributes (delete complete entry) from the
subscribers device entry be deleted while administering this feature.
Sample Delete uOne service request generated by standard presentation layer:
The following request deletes uOne service for subscriber device with billingnumber
6660001111 in community companyABC.
<DELETEENTRY featurename="delsub_uone"
record_identifier="uniqueidentifier=010504102953ae4642875edef"
base_record="companyABC">
<ATTRIBUTE>
<ATTR_NAME name="billingnumber">
</ATTR_NAME>
<ATTR_NAME name="deleteuonesubandimap">
<ATTR_VALUE value="yes"/>
</ATTR_NAME>
</ATTRIBUTE>
</DELETEENTRY>
</REQUEST>
The above deletes the subscriber uOne service for the device with billingnumber
6660001111.

(billingnumber) are defined in the request and also all other attributes in the request
This feature allows a special attribute deleteuonesubandimap. If this attribute is

specified with value yes, the process layer attempts to delete the subscriber IMAP
account. The subscribers IMAP account is deleted only if there is not other service
(uNotify) subscribed to by the subscriber, which uses the IMAP mailbox. The
subscriber looses all the messages in the mailbox if the subscribers IMAP
mailbox/account is deleted.
A.6 Delete Subscriber uNotify Service

The process layer feature for deleting uNotify service is delsub_unotify.xml.

<FEATURE PRE_PROC="preDelSubuNotify" POST_PROC="postDelSubuNotify">
<DELETE_RECORD name="unotify_subscriber_entry">
<DELETE_ATTR name="cosdn" otherobjectclasses="umsubscriber"/>
<DELETE_ATTR name="emailnotificationaddress" />
<DELETE_ATTR name="emailnotificationenabled" />
<DELETE_ATTR name="MWIEnabled" />
<DELETE_ATTR name="outdialNotificationEnabled" />
<DELETE_ATTR name="outdialNotificationNumber" />
<DELETE_ATTR name="outdialturnaroundpsenabled" />
<DELETE_ATTR name="pager" />
<DELETE_ATTR name="pagerenabled" />
<DELETE_ATTR name="SMSEnabled" />
<DELETE_ATTR name="NotifyEmailNormal" />
<DELETE_ATTR name="NotifyEmailUrgent" />
<DELETE_ATTR name="NotifyFaxNormal" />
<DELETE_ATTR name="NotifyFaxUrgent" />
<DELETE_ATTR name="NotifyVoiceNormal" />
<DELETE_ATTR name="NotifyVoiceUrgent" />
<DELETE_ATTR name="PreferredDateFormat" />
<DELETE_ATTR name="PreferredTimeFormat" />
<DELETE_ATTR name="pageremailaddress" />
<DELETE_ATTR name="pagerpin" />
<DELETE_ATTR name="pagertype" />
<DELETE_ATTR name="pagingprovider" />
<DELETE_ATTR name="umNotifyHoursStart" />
<DELETE_ATTR name="umNotifyHoursEnd" />
<DELETE_ATTR name="umNotifyDays" />
<DELETE_ATTR name="umNotifyMMNormal" />
<DELETE_ATTR name="umNotifyMMUrgent" />
<DELETE_ATTR name="umFilters" />
<DELETE_ATTR name="umMaxAttachmentsInNotification" />
<DELETE_ATTR name="umMaxContentFieldLength" />
<DELETE_ATTR name="umMaxFromFieldLength" />
<DELETE_ATTR name="umMaxTotalLength" />
<DELETE_ATTR name="umMaxNotPerDay" />
<DELETE_ATTR name="umMaxSubjectFieldLength" />
<DELETE_ATTR name="umTriggers" />
<DELETE_ATTR name="umWapNotificationEnabled" />
<DELETE_ATTR name="umMMSNotificationEnabled" />
<DELETE_ATTR name="umInHoursDirectEnabled" />
<DELETE_ATTR name="umInHoursPeriodicEnabled" />
<DELETE_ATTR name="umInHoursPeriodicInterval" />
<DELETE_ATTR name="umInHoursPeriodicChannel" />
<DELETE_ATTR name="umOutHoursDirectEnabled" />
<DELETE_ATTR name="umOutHoursPeriodicEnabled" />
<DELETE_ATTR name="umOutHoursPeriodicInterval" />
<DELETE_ATTR name="umOutHoursPeriodicChannel" />
<DELETE_ATTR name="umOutDaysDirectEnabled" />
<DELETE_ATTR name="umOutDaysPeriodicEnabled" />
<DELETE_ATTR name="umOutDaysPeriodicInterval" />
<DELETE_ATTR name="umOutDaysPeriodicChannel" />
<DELETE_ATTR name="umInHoursTriggerA" />
<DELETE_ATTR name="umInHoursTriggerB" />
<DELETE_ATTR name="umInHoursTriggerC" />
<DELETE_ATTR name="umOutHoursTriggerA" />
<DELETE_ATTR name="umOutHoursTriggerB" />
<DELETE_ATTR name="umOutHoursTriggerC" />
<DELETE_ATTR name="umOutDaysTriggerA" />
<DELETE_ATTR name="umOutDaysTriggerB" />
<DELETE_ATTR name="umOutDaysTriggerC" />

<DELETE_ATTR name="gsmdatacodingscheme"/>
<DELETE_ATTR name="notificationexptime"/>
<DELETE_ATTR name="npi"/>
<DELETE_ATTR name="smppcenterid"/>
<DELETE_ATTR name="ton"/>
</DELETE_RECORD>
<ATTRIBUTE name="telephonenumber" required="1"/>
<ERRMSGS>
</ERRMSGS>
</FEATURE>
The above feature XML specifies the logic behind deleting a uNotify service. It specifies the
attributes, which are deleted from the unotify_subscriber_entry (which is same as subscriber
main entry) using the XML element DELETE_ATTR. Note that the attribute cosdn is deleted
only if objectclass does not have a value of umsubscriber (subscriber does not have uOne
service).
Sample Delete uNotify service request generated by standard presentation layer:
The following request deletes uNotify service for subscriber device with uniqueidentifier
010504102953ae4642875edef in community companyABC.
<DELETEENTRY featurename="delsub_unotify"
base_record="companyABC>
<ATTRIBUTE>
</ATTR_NAME>
</ATTRIBUTE>
</DELETEENTRY>
</REQUEST>

The above deletes the subscriber uNotify service for the uniqueidentifier
010504102953ae4642875edef in community companyABC.
(telephonenumber) are defined in the request and also all other attributes in the
request are allowed by the feature definition.
The process layer attempts to delete the subscriber IMAP account while deleting
uNotify service. The subscribers IMAP account is deleted only if there is not other
service (uOne) subscribed to by the subscriber, which uses the IMAP mailbox. The
A.7 Delete Common Subscriber

The process layer feature for adding deleting common subscriber is delsub_unotify.xml.

<FEATURE PRE_PROC="preDelSubCommon" POST_PROC="postDelSubCommon">
<DELETE_RECORD name="subscriber_main_entry">
<DELETE_ALL/>
</DELETE_RECORD>
<ATTRIBUTE name="telephonenumber" />
<ATTRIBUTE name="uniqueidentifier" />
<ATTRIBUTE name="deleteuonesubandimap" />
<ERRMSGS>
</ERRMSGS>
</FEATURE>
The above feature definition specifies the delete common subscriber action. During delete
common subscriber delete all the attributes in the subscriber main entry (meaning the
complete entry is deleted). All the entries below the subscriber main entry are removed and
then the subscriber main entry is removed. Attribute deleteuonesubandimap specifies if the
subscribers IMAP mailbox should be deleted or not.
Sample Delete common subscriber request generated by standard presentation layer:
The following request deletes uOne service for subscriber device with telephonenumber
6660001111 in community companyABC
<DELETEENTRY featurename="delsub_common"
base_record="deviut"
>
<ATTRIBUTE>
</ATTR_NAME>
<ATTR_NAME name="deleteuonesubandimap">
<ATTR_VALUE value="yes"/>
</ATTR_NAME>
<ATTR_VALUE value=""/>
</ATTR_NAME>
</ATTRIBUTE>
</DELETEENTRY>
</REQUEST>
The above deletes the subscribers LDAP data completely. If a Primary Group
Mailbox (PGM) subscriber is deleted using delete common subscriber request, all
the associated Secondary Group Mailbox (SGM) subscribers are also deleted.
(billingnumber) are defined in the request and also all other attributes in the request
This feature allows a special attribute deleteuonesubandimap. If this attribute is

specified with value yes, the process layer attempts to delete the subscriber IMAP
account. The subscribers IMAP account is deleted only if there is not other service
(uNotify) subscribed to by the subscriber, which uses the IMAP mailbox. The

Appendix B. Examples of Request and Response
HTPP Messages
This Appendix provides process layer request and response examples with url-encoded
data and with HTTP headers.
B.1 Process Layer Request

Following code block provides an example of process layer request wrapped in HTTP
headers and with url-encoded body.
POST /upower/ProcessLayer/processuPowerRequest.uone HTTP/1.1

Host: upowerhost.logicacmg.com:280
Content-type: application/x-www-form-urlencoded
Content-length: 3193
Connection: close
xml_data=%3C%3Fxml+version%3D%221.0%22+%3F%3E%0A%3C%21DOCTYPE+REQUEST%5B%
0A++%3C%21ELEMENT+REQUEST+%28%28LOGIN+%7C
+VALIDATEDATA+%7C+VALIDATEENTRY+%7C+ADDENTRY+%7C+MODIFYENTRY+%7C+DELETEEN
TRY%2A+%7C+SEARCHENTRY%2A+%7C+LOGOUT+%7C+
UPLOADFILE+%7C+COPYENTRIES%29%29%3E%0A++++%3C%21ATTLIST++REQUEST+++++++se
ssionid+++++++CDATA+%23IMPLIED%3E%0A++++%
3C%21ATTLIST++LOGIN+++++++++userid++++++++++CDATA+%23IMPLIED%0A++++++++++
+++++++++++++++++++passwd++++++++++CDATA+
%23IMPLIED%0A+++++++++++++++++++++++++++++adminlogin++++++CDATA+%23IMPLIE
D%0A+++++++++++++++++++++++++++++accessty
pe++++++CDATA+%23IMPLIED%0A%09%09%09+++++provideServiceList+CDATA+%23IMPL
IED%3E%0A++++%3C%21ELEMENT+VALIDATEDATA+%
28ATTRIBUTE+%29%3E%0A+++++%3C%21ATTLIST++VALIDATEDATA+featurename+++++CDA
TA+%23IMPLIED%3E%0A%0A++++%3C%21ATTLIST+V
ALIDATEENTRY++record_identifier+CDATA+%23IMPLIED%0A++++++++++++++++++++++
+++++++base_record+++++CDATA+%23IMPLIED%0
A+++++++++++++++++++++++++++++featurename+++++CDATA+%23IMPLIED%3E%0A%0A++
++%3C%21ELEMENT++ADDENTRY+%28ATTRIBUTE+%2
9%3E%0A++++++%3C%21ATTLIST+ADDENTRY+++++featurename+++++CDATA+%23IMPLIED%
0A+++++++++++++++++++++++++++++base_recor
d+++++CDATA+%23IMPLIED%3E%0A%0A++++%3C%21ELEMENT++MODIFYENTRY+%28ATTRIBUT
E+%29%3E%0A++++++%3C%21ATTLIST+MODIFYENTR
Y++featurename+++++CDATA+%23IMPLIED%0A+++++++++++++++++++++++++++++base_r
ecord+++++CDATA+%23IMPLIED%3E%0A++++%0A++
++%3C%21ELEMENT+UPLOADFILE+%28ATTRIBUTE%2C+BASE64DATA%3F+%29%3E%0A++++%3C
%21ATTLIST+UPLOADFILE+++++featurename++++
+CDATA+%23IMPLIED%0A+++++++++++++++++++++++++++++base_record+++++CDATA+%2
3IMPLIED%3E%09%0A%0A++++%3C%21ELEMENT++DE
LETEENTRY+%28ATTRIBUTE+%29%3E%0A++++%3C%21ATTLIST++DELETEENTRY+++record_i
dentifier+CDATA+%23IMPLIED%0A++++++++++++
+++++++++++++++++base_record+++++CDATA+%23IMPLIED%3E%0A%0A++++%3C%21ELEME
NT++RENAMEENTRIES+%28ATTRIBUTE+%29%3E%0A+
+++%3C%21ATTLIST++RENAMEENTRIES+featurename+++++CDATA+%23IMPLIED+%0A+++++
++++++++++++++++++++++++record_identifier
+CDATA+%23IMPLIED%0A+++++++++++++++++++++++++++++base_record+++++CDATA+%2
3IMPLIED%3E%0A%0A++++%3C%21ELEMENT++SEARC
2007 LogicaCMG Wireless Networks Preface 77

HENTRY+%09+%28SHOWATTRIBUTE%2A%29%3E%0A++++%3C%21ATTLIST++SEARCHENTRY+++f
eaturename+++++CDATA+%23IMPLIED%0A%09++++
++++++++%09+++++searchfilter++++CDATA+%23IMPLIED%0A%09%09+++++++++++++sea
rchbase%09+++++CDATA+%23IMPLIED%0A%09%09%
09+++++specialfilter+++CDATA+%23IMPLIED%0A+++++++++++++++++++++++++++++re
cord_type+++++CDATA+%23IMPLIED%3E%0A%0A++
++%3C%21ATTLIST+COPYENTRIES++++base_record+++++CDATA+%23IMPLIED%3E%0A++++
%0A%09%3C%21ATTLIST++SHOWATTRIBUTE+name%0
9%09%09+CDATA+%23IMPLIED%3E%0A%0A++++%3C%21ATTLIST+LOGOUT+%09+++++userid%
09+++++CDATA+%23IMPLIED%3E%0A%0A%0A++++%3
C%21ELEMENT++ATTRIBUTE+%28ATTR_NAME+%29%3E%0A%0A++++++%3C%21ELEMENT++ATTR
_NAME+%28ATTR_VALUE+%29%3E%0A%0A++++++++%
3C%21ATTLIST++ATTR_NAME++name+++++++++++++CDATA+%23IMPLIED%3E%0A%0A++++++
++%3C%21ATTLIST++ATTR_VALUE+value++++++++
++++CDATA+%23IMPLIED%0A%09%09%09++++++value_id+++++++++CDATA+%23IMPLIED%3
E%0A%0A%5D%3E%0A%0A%3CREQUEST%3E%0A%3CLOG
IN+userid%3D%22upoweroot%40development.cmguc.com%22+passwd%3D%22432u2w3O7
54X0O4T%22+AdminLogin%3D%22%22+accesstype
%3D%22admin%22+provideServiceList%3D%22yes%22+%2F%3E%0A%09%3CUM6.0_COMPAT
IBLE_PRESLAYER%2F%3E%0A%3C%2FREQUEST%3E%0
A
The above is a LOGIN request the presentation layer sends to the process layer. Note the
xml_data tag at the beginning of the request body. The request includes the request XML
DTD. The request is url-encoded, note the spaces replaced by + and other characters
replaced by %HH.
B.2 Example of <PARTIAL_COMPLETION_MESSAGE> Process Layer

Response
Following code block provides an example of the <PARTIAL_COMPLETION_MESSAGE>
response as received from the process layer with the HTTP headers.
HTTP/1.1 200 OK
Date: Tue, 06 Jan 2004 18:10:27 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.5
X-Powered-By: PHP/4.0.5
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
7bb

BACK_END_MSG*, DATA*)>
<!ATTLIST RESULT returnval CDATA #REQUIRED>
#REQUIRED>
<!ATTLIST MESSAGE msgcode CDATA #REQUIRED
msgtext CDATA #REQUIRED
value_id CDATA #REQUIRED>
<!ATTLIST BACK_END_MSG msgtext CDATA #REQUIRED>

<!ELEMENT DATA ((RECORD_ID_LIST*|
RECORDS*|ALLOWED_FEATURES*|AVAILABLE_SERVICES))>
<!ATTLIST RECORD_ID_LIST record_identifier CDATA #IMPLIED
<!ATTLIST RECORDS entries_count CDATA #IMPLIED>
<!ATTLIST RECORD record_identifier CDATA #IMPLIED
<!ATTLIST ATTR_VALUE value CDATA #IMPLIED>

<!ELEMENT FEATURE (QUERY*, accesslevel+)>
<!ATTLIST FEATURE featurename CDATA #REQUIRED>
<!ATTLIST QUERY queryname CDATA #IMPLIED>
<!ATTLIST accesslevel permission CDATA #IMPLIED>
#REQUIRED>
]>
<RESPONSE>
<MESSAGE msgcode="UM_1150" msgtext="Delete Subscriber Successful :
 8047620225 JohnDoe225
uniqueidentifier=1117031341240b00d9c2d0368,ou=subscribers,ou=community1,o
=sandbox.com" />
<PARTIAL_COMPLETION_MESSAGE ReqProcessInProgress="1" />
</RESPONSE>
ENDOFDATA
875

#REQUIRED>



#REQUIRED>
]>
<RESPONSE>
 8047620225 JohnDoe225
=sandbox.com" />
 8047620227 JohnDoe227
uniqueidentifier=11190309443889833e73aad3e,ou=subscribers,ou=community1,o
=sandbox.com" />
<PARTIAL_COMPLETION_MESSAGE ReqProcessInProgress="1" />
</RESPONSE>
ENDOFDATA
8ed

#REQUIRED>


#REQUIRED>
]>
<RESPONSE>
 8047620225 JohnDoe225
=sandbox.com" />
 8047620227 JohnDoe227
uniqueidentifier=11190309443889833e73aad3e,ou=subscribers,ou=community1,o
=sandbox.com" />
 8047620060 JohnDoe60
uniqueidentifier=101403163712900e48451e0be,ou=subscribers,ou=community1,o
=sandbox.com" />
</RESPONSE>
Above is an example of process layer response for deletion of 3 subscribers in a single

request. Process layer responds back after deletion of each subscriber. The HTTP message
st
contains a single HTTP header, but the body is divided into 3 response XMLs. After the 1
subscriber (JohnDoe225, uniqueidentifier=1117031341240b00d9c2d0368) deletion was
done process layer sent a response with result of the deletion and the
<PARTIAL_COMPLETION_MESSAGE ReqProcessInProgress="1" /> tag indicating that
nd
this is not a final response. After the 2 subscriber is deleted process layer sends another
st nd
response XML with success messages for 1 and 2 subscribers and with
PARTIAL_COMPLETION_MESSAGE tag. After deletion of the last subscriber, the complete
response XML is sent again. This response is final because it does not contain the
<PARTIAL_COMPLETION_MESSAGE ReqProcessInProgress="1" /> tag. Also since the
final XML contain all the data for the request, the earlier response XMLs should be
discarded. Note the ENDOFDATA tag after each partial completion response. This
indicates the completion of the intermediate response. The above shown is an example of
chunked HTTP message.
B.3 Example of a simple process layer response

Following code block shows an example of regular response from process layer.
HTTP/1.1 200 OK

Date: Tue, 06 Jan 2004 18:01:46 GMT
Server: Apache/1.3.19 (Unix) PHP/4.0.5
X-Powered-By: PHP/4.0.5
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html
9c9

#REQUIRED>


#REQUIRED>
]>
<RESPONSE>
<DATA>
<RECORD_ID_LIST base_record="Community 2" />
<RECORD_ID_LIST base_record="commutniy1_sub_community" />
<RECORD_ID_LIST base_record="community1_sub_community2" />
<RECORD_ID_LIST base_record="coi1" />
<RECORD_ID_LIST base_record="COI2" />
<RECORD_ID_LIST base_record="COI 1 under TOP ILN 1 child-1" />
<RECORD_ID_LIST base_record="Carolcoi1" />
<RECORD_ID_LIST base_record="Carolcoi1Copied" />
<RECORD_ID_LIST base_record="COI 11 under COI 1" />
<RECORD_ID_LIST base_record="COI-ILN11" />
</DATA>
</RESPONSE>

Abbreviations
SMSC Short Message Service Center

WSB WAP Service Broker
MMSC Multimedia Message Service Center
COI Community Of Interest
ILN Intermediate Level Node
Glossary
uPower The web-based provisioning application to administer data for

various LogicaCMG products.
Presentation Layer The uPower component, which provides graphical user
interface to present data on the web-forms and to gather input.
The terms process layer client and presentation layer are used
interchangeably in this document.
Process Layer The uPower layer, which encompasses the business logic of
provisioning. Process layer provides an interface for its clients
to query/update the backend databases.
Feature A logical grouping of attributes from the LDAP Directory
Server accessed by various LogicaCMG products. The
groupings are generally related to the particular functionality of
the product. The attributes may be stored under various
Distinguished Names. Any one attribute may be included in
multiple Feature Definitions. Each Feature is specified by as an
XML document. The name of the file must be
<featurename>.xml.
Transport Layer The portion of uPower that invokes the Process Layer when a
Request is to be processed. It posts the Request to the Process
Layer and waits for the Response. It returns the Response to
the Presentation Layer.
Request An XML document passed from the Presentation Layer to the
Process Layer via the Transportation Layer. It may be a Query,
Add, Modify, Delete, Validate, Login, or Logout request.
Response An XML document passed from the Process Layer to the
Presentation Layer via the Transportation Layer after the
Process Layer has completed processing the Request.
Standard Query A predefined query (LDAP search) recognized by the Process
Layer.
Administrator An uPower user capable of adding other administrators,
subscribers, Classes of Service, etc.
Subscriber An end-user of the LogicaCMG messaging product. May use
uPower to configure personal account preferences.
uPower User The Administrator or Subscriber Logged in to uPower.
2007 LogicaCMG Wireless Networks Glossary 85

References
1. Supported Features for UM62.1 uPower
2007 LogicaCMG Wireless Networks References 87

Version History
Version Status Date Details of Changes Author(s)
1.0 DRAFT 6 Apr 2007 Initial version
Approval
Version Date Approved by Signature
1.0 12/04/2007 Miroslav Vicher

MMSC R30-00 UPower ProcLayer Interface Description CC20 v02

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MMSC R30-00 UPower ProcLayer Interface Description CC20 v02

Încărcat de

Drepturi de autor:

Formate disponibile

uPower CC2.

Document Version: 1.0

2 Process Layer Interface Description................................................................. 3

2007 LogicaCMG Wireless Networks Table of Contents iii

3 Transport Layer Specifications ....................................................................... 45

Appendix A. Examples of Important Features/Requests ............................... 49

Appendix B. Examples of Request and Response HTPP Messages ............ 77

iv <Subsystem> Process Layer Interface Description 2007 LogicaCMG Wireless Networks

Figure 1-1: Data Flow Across Interface ................................................................................................... 2

2007 LogicaCMG Wireless Networks List of Figures v

Table P-1: Typographic conventions ....................................................................................................... x

2007 LogicaCMG Wireless Networks List of Tables vii

1. Extensible Markup Language (XML)

2. HyperText Transfer Protocol (HTTP)

3. Features supported by the uPower process layer

Other related documents are:

1. Supported Features for UM62.1 uPower

The first chapter provides an introduction to uPower architecture. It gives an overview of

Appendix B provides examples of over-the-wire HTTP messages between presentation

2007 LogicaCMG Wireless Networks Preface ix

Table P-1: Typographic conventions

Typeface or Symbol Meaning/Used for Example

Courier Refers to a keyboard key, system The directory data contains

[] Refers the user to external [ETSI 03.38]

italic Emphasises a new word or term of apply a style to the...

% Denotes a Unix regular-user prompt for % ls

# Denotes a Unix super-user prompt for # ls

$ Denotes an OpenVMS Digital $ dir

\ (Unix) Denotes line continuation; the % grep searchforthis \

Denotes a note, a piece of text Note that the system is usually...

x <Subsystem> Process Layer Interface Description 2007 LogicaCMG Wireless Networks

1.1 What is uPower?

1.2 What process layer interface provides?

The interface supports both Administrators and Subscribers. Upon Login of an

1.3 Data Flow Across the Interface

2007 LogicaCMG Wireless Networks Introduction 1

Client Browser application

Web Request to uPower Web Response from

uPower Presentation Layer CGI Scripts

uPower Transport Layer Script

REQUEST XML sent RESPONSE XML(s) (partial

UNIX Server2 hosting Web

uPower Process Layer CGI Scripts

Figure 1-1: Data Flow Across Interface

2.2 Feature XML

Definition of a feature includes:

Type of operation: add (add data)/modify (modify existing data)/delete (delete

Queries required to be run for the feature.

Success/Failure message codes.

2007 LogicaCMG Wireless Networks Process Layer Interface Description 3

<!ATTLIST FEATURE PRE_PROC CDATA #IMPLIED

Defines the feature.

The attribute servertype specifies allows an attribute to be processed according to the

<ATTRIBUTE name=ou required=1>

The valid values and the meaning of uniqueness_scope are:

Valid value for Description

2007 LogicaCMG Wireless Networks Process Layer Interface Description 5

The subtreeOrEntryDefiningAttr is name of the attribute; for example

In addition, the attribute showattrlist can specify a comma-separated list of attributes,

Each DELETE_RECORD specifies a data record to be partially or completely deleted when

A sub-element of DELETE_RECORD, each DELETE_ATTR element specifies an individual

<DELETE_ATTR name=mailhost rule=deleteuonesubandimap=yes/>

Presence of this sub-element of DELETE_RECORD indicates the entire record will be

Feature Information for Process Layer Internal Use: