This Website provides CLECs the Technical XML specifications necessary to code for AT&T’s ordering, pre-ordering and post-ordering interfaces for local orders. CLEC Developers and Implementers should use the information on this site together with the information contained in the Local Service Ordering Requirements (LSOR), Local Service Pre-Ordering Requirements (LSPOR) and Local Ordering Handbook (LOH) when coding their interfaces. AT&T’s XML documentation closely follows the Ordering and Billing Forum’s (OBF) Unified Ordering Model – Local Service Request (UOM-LSR) Volumes. Developers should be familiar with the guidelines available on the OBF Website.

2. Establishing Access to the ATT LSR XML Gateway return to top

Customers should contact their ATT Account Manager or OSS Support Contact when they are ready to establish access to the LSR XML Gateway. The Account Manager/OSS Support Contact will provide customers with the necessary request forms. The request form will be used by the customer to provide ATT with their IP/URL information that will need to be configured on the ATT side of the connection, as well as request the necessary application ID(s) and Password(s). The form will also provide the ATT connectivity information needed by the customer (IP addresses, Ports, URLs, etc). Once completed the form will be sent to the IS Call Center (ISCC) to establish connectivity. The connectivity set up typically takes approximately 10 business days to complete. Once connectivity has been established the ISCC will forward the form to that application team to create the customer’s user IDs and passwords and configure the customer account. This step typically takes approximately 5 business days. The ISCC will also work with the customer to verify/test connectivity. Once processed, the completed form will be returned to the customer with their Application ID and Password. Customers can request up to 3 IDs and PWs per region (9/12 state), per environment (test/production). The IDs and PWs provided will be passed in the SOAP Header as well as in the LSR Header for both inbound and outbound transactions.

Before going into production, customers will negotiate and perform functional testing in the CLEC Test environment. Once testing has completed, a production date can be negotiated through the OSS Support Manager or the ATT Account Manager.

3. Transactions Supported by the Gateway return to top

The following transactions are supported by the AT&T 21-State LSR XML Gateway. The business rules associated with the transactions can be found in the LSPOR, LSOR and LOH documents.

3.1. Pre-Order return to top

The enclosed matrix (3.1.1 Pre-Order Transaction Matrix) lists the pre-order transactions supported by the 21-State interface. The region supported, as well as the TXTYP/TXACT/TRANS_CLS/TRX_NAME combinations for each transaction have been provided. The corresponding Sample Mapping Document is listed in the table below (3.1.2 Pre-Order Sample Mapping Reference Chart).

3.1.1. Pre-Order Transaction Matrix

Transaction	12	9	TXTYP	TXACT	TRANS_CLS	TRX_NAME	Sample Map
Address Validation	X		A	A			1
Address Validation - Address		X	A	A	A	AVQRY	2
Address Validation - TN		X	A	A	T	AVQTN	2
Manual Address Validation - New	X		A	M			1
Manual Address Validation - Edit	X		A	E			1
Manual Address Validation - View	X		A	R			1
TN Inquiry	X		B	A			3
TN Reservation	X		B	R			3
TN Inquiry – Request/Reserve DID		X	B	R	D	TNAQD	4
TN Inquiry – Request/Reserve MISC		X	B	R	M	TNAQM	4
TN Inquiry – Request/Reserve MLH		X	B	R	H	TNAQH	4
TN Inquiry – Request/Reserve TNs		X	B	R	P	TNAQY	4
TN Selection – Change Previous Res.		X	B	R	S	TNSQY	5
TN Confirmation	X		B	C			6
Cancel TN Reservation	X		B	K			7
Cancel TN Reservation – POTS		X	B	K	P	TNCAN	8
Cancel TN Reservation – DID		X	B	K	D	TNCND	8
Cancel TN Reservation – MLH		X	B	K	H	TNCNH	8
Feature Service – Feature	X		C	A			9
Service Availability		X	C	A		SAV	10
Scheduling Inquiry – Due Date	X		D	A			11
Appointment Availability		X	D	A		AAQRY	12
Due Date Reservation	X		D	R			11
View Reservation (Due Date)	X		D	V			11
Cancel Due Date Reservation	X		D	K			11
Search for RESIDs by REQNUM (Due Date)	X		D	L			11
Estimated Due Date		X	D	R		ESDQY	25
CSI Only	X		E				13
Parsed CSR		X	E			PCSRQ	14
CABS CSR Request		X				CABSQ	15
Unparsed CSR		X				CSRQY	16
Loop Qualification – Actuals	X		H	A			17
Loop Makeup for Spare Facilities		X	H	A	R	LMUSP	18
Loop Makeup for Working Loops		X	H	A	W	LMUWK	18
Loop Qual – Archived Actual/Design	X		H	D			17
Loop Qual – Manual	X		H	M			17
Loop Qual – View Results	X		H	R			17
Loop Reservation by Cable/Pair		X	H	R	F	LPRCP	19
Loop Make Up Reservation Request		X	H	R	Q	LPRSP	19
Loop Qual – Facility Information	X		H	F			17
Loop Qual – Multiple Loop Information	X		H	X			17
IDLC Inquiry	X		H	I			20
Loop Reservation Cancel		X	H	K	C	LPRCN	19
Loop Pre-Qualification	X		J	A			21
CLLI Inquiry	X		K	A			22
Feature Service – PIC/LPIC	X		L	A			23
CSI/Listing	X		M				13
NC/NCI	X		N	A			24
Directory Listings	X		O	A			13
Listing Only	X		T				13
Parsed CSR		X	T			PCSRQ	14
RACF	X		U	A			26
CFA Inquiry	X		V	A			27
CFA Inquiry – VCI/VPI/RECCKT	X		V	B			27
VOIP View of CSR		X	V			PCSRQ	14
Feature Service – Pooled TNs	X		X	A			28
Scheduling Inquiry – Dispatch	X		Z	A			29
Complex Products Inquiry	X		1	A			30,31,32
Complex Products – Change to Service	X		1	B			30,31,32
Complex Products – View Results	X		1	R			30,31,32
Complex Products – Outside Move	X		1	T			30,31,32
Batch Cut Inquiry	X		3	A			33
Batch Cut Reservation	X		3	R			33
Batch Cut – Modify	X		3	E			33
Batch Cut – Bulk Confirmation	X		3	C			33
Batch Cut – Cancel	X		3	K			33
Batch Cut – View Batch Results	X		3	M			33
Impairment Status Inquiry	X		4	A			34
Transport Impairment Status Inquiry	X		5	A			34
CSI Summary	X		9	A			13
Cable ID / Channel Pair Status		X	H	A	E	FAQRY	35

3.1.2. Pre-Order Sample Mapping Reference Chart

Ref #	Inquiry Sample Map	Response Sample Map
1	AddressValidationReq-ATT	AddressValidationResp-ATT
2	AddressValidationReq-ATT-SE	AddressValidationResp-ATT-SE
3	TelNoAssign-ResInquiryReq-ATT	TelNoAssign-ResInquiryResp-ATT
4	TelNoAssign-ResInquiryReq-ATT-SE	TelNoAssign-ResInquiryResp-ATT-SE
5	TelNoAssign-ResConfirmReq-ATT-SE	TelNoAssign-ResConfirmResp-ATT-SE
6	TelNoAssign-ResConfirmReq-ATT	TelNoAssign-ResConfirmResp-ATT
7	TelNoAssign-CancelReq-ATT	TelNoAssign-CancelResp-ATT
8	TelNoAssign-CancelReq-ATT-SE	TelNoAssign-CancelResp-ATT-SE
9	FeatureAvailabilityReq-ATT	FeatureAvailabilityResp-ATT
10	ServiceAvailabilityReq-ATT-SE	ServiceAvailabilityResp-ATT-SE
11	ApptScheduling-DueDateReq-ATT	ApptScheduling-DueDateResp-ATT
12	AppointmentAvailReq-ATT-SE	AppointmentAvailResp-ATT-SE
12	CSIReq-ATT	CSIResp-ATT
14	CSIReq-ATT-SE	CSIResp-ATT-SE
15	CABSCSIReq-ATT-SE	CABSCSIResp-ATT-SE
16	UnparsedCSIReq-ATT-SE	UnparsedCSIResp-ATT-SE
17	LoopQualReq-ATT	LoopQualResp-ATT
18	LoopQualReq-ATT-SE	LoopQualResp-ATT-SE
19	LoopReserveReq-ATT-SE	LoopReserveResp-ATT-SE
20	IDLCReq-ATT	IDLCResp-ATT
21	LoopPre-QualReq-ATT	LoopPre-QualResp-ATT
22	CLLIReq-ATT	CLLIResp-ATT
23	PICLPICReq-ATT	PICLPICResp-ATT
24	NCNCIReq-ATT	NCNCIResp-ATT
25	ESDReq-ATT-SE	ESDResp-ATT-SE
26	ServiceAvailability-RACFReq-ATT	ServiceAvailability-RACFResp-ATT
27	CFAReq-ATT	CFAResp-ATT
28	ServiceAvailability-PooledTNReq-ATT	ServiceAvailability-PooledTNResp-ATT
29	ApptScheduling-DispatchReq-ATT	ApptScheduling-DispatchResp-ATT
30	BRIISDNReq-ATT	BRIISDNResp-ATT
31	CENTREXReq-ATT	CENTREXResp-ATT
32	RPLReq-ATT	RPL-Resp-ATT
33	BatchHotCutReq-ATT	BatchHotCutResp-ATT
34	ImpairmentStatusReq-ATT	ImpairmentStatusResp-ATT
35	CableChanPairStatusReq-ATT-SE	CableChanPairStatusResp-ATT-SE

3.2. Order return to top

The enclosed matrix (3.2.1 Order Request Transaction Matrix) lists the 21-State inbound (CLEC to ATT) forms used for LSR ordering. The region supported as well as the REQTYP and corresponding Sample Mapping document and Schema file.

3.2.1. Order Request Transaction Matrix

REQTYP	Order Type	12	9	Sample Map	Schema
A	Loop Service	X	X	LSForm-ATT(-SE)	LS-Form
B	Loop Service w/Number Portability	X	X	LSNPForm-ATT(-SE)	LSNP-Form
C	Number Portability	X	X	NPForm-ATT(-SE)	NP-Form
E	Resale	X	X	RSForm-ATT(-SE)	RS-Form
F	Port Service	X	X	PSForm-ATT(-SE)	PS-Form
J	Directory Service	X	X	DLForm-ATT(-SE)	DL-Form
K	Resale Private Line	X	X	RPLForm-ATT(-SE)	RPL-Form
M	Loop with Port	X	X	PSForm-ATT(-SE)	PS-Form
P	Centrex Resale	X	X	CRSResaleForm-ATT(-SE)	CRS-Form
R	Digital Trunking Resale	X	X	DTResaleForm-ATT(-SE)	DT-Form
S	Digital Trunking UNE		X	DTUNEForm-ATT(-SE)	DT-Form
T	DID/PBX Resale	X	X	DDPSResaleForm-ATT(-SE)	DDPS-Form
U	DID/PBX UNE	X		DDPSUNEForm-ATT(-SE)	DDPS-Form
V	Centrex UNE	X	X	CRSUNEForm-ATT(-SE)	CRS-Form
W	DID/PBX UNE		X	DDPSUNEForm-ATT(-SE)	DDPS-Form
X	Centrex UNE		X	CRSUNEForm-ATT(-SE)	CRS-Form
Y	ISDN Prime UNE		X	ISUNEForm-ATT(-SE)	IS-Form
Z	ISDN Prime Resale	X	X	ISResaleForm-ATT(-SE)	IS-Form
2	ISDN Prime Port	X	X	ISUNEForm-ATT(-SE)	IS-Form
3	Digital Trunking UNE	X	X	DTUNEForm-ATT(-SE)	DT-Form
All	LSR – All orders	X	X	LSRForm-ATT(-SE)	LSR-Form
	EU – As applicable	X	X	EUForm-ATT(-SE)	EU-Form
	HGI – As applicable	X	X	HGIForm-ATT(-SE)	HGI-Form

The enclosed matrix (3.2.2 Order Response Transaction Matrix) lists the 21-State outbound responses (ATT to CLEC) used for LSR ordering.

3.2.2. Order Response Transaction Matrix

Local Response Name	12	9	Sample Map	Schema	Structure
Firm Order Confirmation (FOC)	X	X	LSROrderResp-FOC-ATT(-SE)	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Reject	X	X	LSROrderResp-Reject-ATT(-SE)	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Jeopardy	X	X	LSROrderResp-Jeopardy-ATT(-SE)	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Service Order Completion (SOC)	X	X	LSROrderResp-SOC-ATT(-SE)	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Billing Completion Notice (BCN)		X	LSROrderResp-BCN-ATT-SE	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Post to Bill (PTB)	X		LSROrderResp-PTB-ATT	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Provider Notification (PN)	X	X	LSROrderResp-PN-ATT(-SE)	PN-Form
Pending Order Status (POS)		X	LSROrderResp-POS-ATT-SE	UOM-LSR-Base	FIRM_ORDER_NOTIFICATION
Firm Order Acknowledgment		X	LSROrderResp-FirmOrderAck-ATT-SE	UOM-LSR-Base	FIRM_ORDER_ACK

3.3. Post Order return to top

The enclosed matrix (3.3.1 Post-Order Transaction Matrix) lists the post-order transactions supported by the 21-State interface. The region supported, as well as the TXTYP/TXACT/TRANS_CLS/TRX_NAME combinations for each transaction have been provided. The corresponding Sample Mapping Document is listed in the table below (3.3.2 Post-Order Sample Mapping Reference Chart).

3.3.1. Post-Order Transaction Matrix

Transaction	12	9	TXTYP	TXACT	TRANS_CLS	TRX_NAME	Sample Map
Order Status Pending – Detail	X		P	D			1
Order Status Pending – Feature Look Up	X		P	F			1
Order Status Pending – List	X		P	L			1
Order Status Posted – Detail	X		Q	D			1
Order Status Posted – Feature Look Up	X		Q	F			1
Order Status Posted – List	X		Q	L			1
PON List		X	Q	A	L		2
Service Order Status		X	Q	A	O		3
Order Status Pending/Posted – Feature	X		R	F			1
Order Status Pending/Posted – List	X		R	L			1
Provisioning Order Status - Detail	X		W	D			4
Provisioning Order Status – List	X		W	L			4
Provisioning Order Status – Bulk Work Load	X		W	W			4

3.3.2. Post-Order Sample Mapping Reference Chart

Ref #	Inquiry Sample Map	Response Sample Map
1	OrderStatusReq-ATT	OrderStatusResp-ATT
2	PONListReq-ATT-SE	PONListResp-ATT-SE
3	ServiceOrderStatusReq-ATT-SE	ServiceOrderStatusResp-ATT-SE
4	ProvisionedOrderStatusReq-ATT	ProvisionedOrderStatusReq-ATT

4. Documentation return to top

The following documentation is available on this Website:

XML schemas – Zipped file containing the Pre-Order, Order and Post-Order schemas for 21-State transactions in .xsd format. The schemas are based on Industry LSR schemas provided by the Ordering and Billing Forum (OBF) – Unified Ordering Model – Local Service Ordering Volume, and modified to accommodate AT&T’s business rules. Industry fields and structures not used by AT&T may still be listed in the schemas since they are based on UOM-LSR schemas. For this reason, Sample Mapping Documents have also been provided to illustrate the specific fields supported by AT&T.

XML Sample Mapping Documents – Sample layout of the XML required to send and receive LSR transactions to/from AT&T. These documents will include all potential fields that can be included on a transaction. Business rules concerning the validity of specific fields on specific transaction types are available in the LSOR/LSPOR or LOH. An “*” following a field or group indicated a repeating structure. Any transaction labeled “–ATT” applies to the 12-State region. Any transaction labeled “–ATT-SE” applies to the 9-State region.

Pre-Order – Sample transaction for each Pre-Order function supported in

AT&T’s 21-State region, broken down by request and response.

Order – Sample transaction for each order requisition type supported in

AT&T’s 21-State region, as well as the order notifications sent back from

AT&T to the customer.

Post-Order – Sample transaction for each post-order function, primarily

order status transactions, supported in AT&T’s 21-State region.

WSDL Files - Valid request and response schema structures are all defined in the appropriate WSDL file. (ATTPreorder.wsdl, ATTOrder.wsdl, ATTPostorder.wsdl) The WSDLs have the service information for both inbound and outbound transactions.

Documentation Update Log – Log of changes to XML documents based on CLEC questions/comments as well as internal reviews. This document will remain on the website until the final XML documentation is in place and normal CMP guidelines are used for documentation updates. This method of communicating changes was agreed to by the CLEC community as the most effective way to communicate changes during the initial documentation phase.

5. Transaction Flows return to top

The communication protocol will be SOAP over https. Transactions will be supported via a direct circuit or the public internet. Requests and responses must be packaged individually (batching of requests is not supported). There are no size limitations on individual transactions, other than those defined by the business rules in the LSOR, LSPOR or LOH. While the number of files per minute or hour is dependent upon CLEC volumes, it is AT&T’s expectation that the CLEC workload will be reasonably distributed throughout the available hours. In general, a CLEC should send no more than 20% of their normal daily volume in any one hour, and no more than 30% of that hourly volume should be sent in any 10-minute period.

LSRXMLInfrastucture

5.1. Pre-Order return to top

Pre-Order transactions are synchronous transactions that do not require an acknowledgment (“OK” message) as used on the order side.

5.2. Order return to top

Order transactions are asynchronous transactions that require a synchronous acknowledgment for each transmission as defined in the Order WSDL file. ATT will wait 10 seconds for the synchronous acknowledgement from the customer before timing out and will provide acknowledgements within the same timeframe for transactions received from the customer.

Order response transactions will be pushed from ATT to the customer. If the synchronous acknowledgement is not received by ATT, the response will be queued up on the ATT Server, and the push will be retried at regularly scheduled intervals until successful.

5.3. Post-Order return to top

12-State Post-Order transactions (Order Status and Provisioning Order Status) are synchronous transactions that do not require an acknowledgment as used on the order side.

9-State Post-Order transactions (Service Order Status and PON List) are synchronous transactions that do not require an acknowledgment as used on the order side.

6. High level interface design return to top

6.1. Dependencies

To receive the successful responses, all customers need to register their services with ATT.

To support multiple LSOR versions, customers may either create a single generic service which supports any LSOR responses irrespective of LSOR release (see sample below), or support multiple services that are version specific (see WSDL section of the website).

<wsdl:types>

<xsd:schema targetNamespace="http://lsr.att.com/order"

xmlns:tns="http://lsr.att.com/order"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:import schemaLocation="../schema/CommonHeaderV3.xsd" namespace="http://cio.att.com/commonheader/v3" />

<xsd:complexType name="genericOrderResp">

<xsd:sequence>

<xsd:any namespace="##any" processContents="skip" />

</xsd:sequence>

</xsd:complexType>

<xsd:element name="ATT_LSR_ORD_RESP" type="tns:genericOrderResp"/>

<xsd:element name="OK">

<xsd:complexType>

<xsd:sequence />

</xsd:complexType>

</xsd:element>

</xsd:schema>

</wsdl:types>

<wsdl:message name="WSException">

<wsdl:part name="WSException" element="ch:WSException" />

</wsdl:message>

<wsdl:message name="orderResponse">

<wsdl:part name="request" element="order:ATT_LSR_ORD_RESP" />

</wsdl:message>

<wsdl:message name="orderOk">

<wsdl:part name="response" element="order:OK" />

</wsdl:message>

<wsdl:portType name="ATT_ORDER_GENPortType">

<wsdl:operation name="submit">

<wsdl:input message="tns:orderResponse" />

<wsdl:output message="tns:orderOk" />

<wsdl:fault name="WSException" message="tns:WSException" />

</wsdl:operation>

</wsdl:portType>

Customers should utilize standard https port 443

6.2. Requirements for Implementing XML return to top

The requirements for implementing XML includes any Web Server which supports the following standards:

· SOAP Version 1.1

· WSDL Version 1.1

· SOAP with Attachments API for Java (SAAJ) Version higher

· Web Services Security v1.0 (WS-Security 2004)

The information for all the above standards are available at World Wide Web Consortium website www.w3.org

7. Security Access and Setup Considerations return to top

All communication between client and the XML Gateway will be SOAP over HTTPS. SSL encrypted communication is required. Customers are required to provide their own digital certificate. Supported ciphersuites are:

RSA_WITH_RC4_128_MD5
RSA_WITH_RC4_128_SHA
RSA_WITH_DES_CBC_SHA
RSA_WITH_3DES_EDE_CBC_SHA

ATT currently supports the following certificate authorities (CURRENTLY ATT ONLY ACCEPTS SHA1RSA ALGORITHM):

· AddTrust

· ComodoSecurityServices

· Entrust

· Equifax

· GTE

· GoDaddy

· NetworkSolutions

· Thawte

· UTN

· Verisign

All clients will be issued an application Id and an application password. These two pieces of information will be used in the SOAP header of every message to identify and authenticate the sender. IDs and PWs will be provided by AT&T, and will be sent back to the customer on order notifications. Peer/Entity authentication will be handled via mutual authentication at the SSL handshake, as well as through the use of The application ID and Password/CC authentication (Web Services Security v1.0 (WS-Security 2004)).

8. SOAP header return to top

Inbound (CLEC to ATT)

The ATT 21-state LSR XML Gateway utilizes an out-of-band SOAP header definition (not specifically stated in the WSDL). The Gateway will expect a UserNameToken style SOAP header using the docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd specification. The Username value will be the client’s application id and the Password will be the client’s password.

An example of the expected SOAP header: This sample SOAP message is just one possible sample of valid SOAP message

<SOAP-ENV:Envelope xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

<m3:Security xmlns:m3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<m3:UsernameToken xsi:type="m3:UsernameTokenType">

<m3:Username>theUserName</m3:Username>

<m3:Password xsi:type="m3:PasswordString" Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">thePassword</m3:Password>

</m3:UsernameToken>

</m3:Security>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Outbound (ATT to CLEC)

The ATT 21-state LSR XML Gateway utilizes an out-of-band SOAP header definition (not specifically stated in the WSDL). The Gateway will expect a UserNameToken style SOAP header using the docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd specification. The ATT Username value and the Password will Provided to the customer.

An example of the expected SOAP header: This sample SOAP message is just one possible sample of valid SOAP message

<SOAP-ENV:Envelope xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Header>

<m3:Security xmlns:m3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">

<m3:UsernameToken xsi:type="m3:UsernameTokenType">

<m3:Username>theUserName</m3:Username>

<m3:Password xsi:type="m3:PasswordString" Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">thePassword</m3:Password>

</m3:UsernameToken>

</m3:Security>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

9. Exception processing return to top

The wsdl’s define a specific WSException type that is used as a fault exception. SOAP faults will contain the WSException information in the detail tag. The ErrorCode and Message will contain information in regards to the problem that occurred. There is one exception to this exception, if sending an unsupported type to a service then the service responds with an Iona specific FaultException in the detail. The definition of the FaultException will be provided for accurate parsing of the message………

An example of the soap fault returned if a CSI_REQ is sent to the ADD_VAL service

<?xml version="1.0" encoding="utf-8"?>

<SOAP-ENV:Envelope xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:m1="http://schemas.iona.com/faults" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body>

<SOAP-ENV:Fault>

<faultcode>SOAP-ENV:Client</faultcode>

<faultstring>Message name "http://att.com/obf/tML/UOM:CSI_REQ " is not valid for this service.</faultstring>

<m1:FaultException xsi:type="m1:FaultException">

<m1:category>MARSHAL_ERROR</m1:category>

<m1:namespace_uri>http://schemas.xmlsoap.org/soap/envelope/</m1:namespace_uri>

<m1:code>Client</m1:code>

<m1:detail></m1:detail>

<m1:source>CLIENT</m1:source>

<m1:completion_status>NO</m1:completion_status>

<m1:description>Message name "http://att.com/obf/tML/UOM:CSI_REQ " is not valid for this service.</m1:description>

<m1:server_id></m1:server_id>

</m1:FaultException>

</detail>

</SOAP-ENV:Fault>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Enclosed is a list of exceptions returned by the XML Gateway:

9.1. Gateway Error Codes/Messages return to top

Situation	Error Code	Message
Failed authentication – invalid application id or password	10001	Failed Authentication. CLEC_APPL_ID and CLEC_APPL_PASSWORD combination invalid
Failed authentication - Client sent unsupported CC or CCNA for the CLEC_APPL_ID	10002	Invalid CC/CCNA for this CLEC_APPL_ID
Failed validation – invalid XML	10003	Invalid XML. <specific problem with the message>
Failed validation – missing or invalid STATE	10004	Invalid XML. Unsupported STATE.
Gateway processing failure – i.e. MQ PUT failures	10006	Host System Unable to Process Transaction
Required order form missing	10007	XXX form is required with REQTYP/ACT [X/X] combination in REGION XX (where XXX = the missing required form)
Prohibited form was sent	10008	XXX form is prohibited with REQTYP/ACT [X/X] combination in REGION XX (where XXX = the prohibited form that is present)
Invalid REQTYP/ACT combination	10009	Invalid REQTYP/ACT combination

10. Connectivity return to top

Connectivity information, including IP/Port information and urls will be communicated to the customer when they request access to the LSR XML Gateway. For security reasons, that information will not be posted on this website.

11. Business Rule Considerations return to top

Other than the exceptions listed above, the only business rules enforced by the XML Gateway schemas would be on maximum field length. Certain fields in the Header (HDR) of each XML transaction may be required even if the field pages in the LOH or the LSOR/LSPOR don’t indicate that they are required. The STATE field is one example of a required HDR field. Please see the Documentation of the HDR fields (below) for more information regarding these fields. Data passed in the XML schema is not case sensitive. If the data in any field is required to be in upper or lower case, it will be defined in the applicable field pages in the LOH or the LSOR/LSPOR. In most cases within the XML documentation, spaces in field names have been replaced with an underscore, and special characters such as the virgule “/” have been removed. In cases where a field name in the XML documentation does not match what is in the business rule documentation (LSOR/LSPOR/LOH), the field name as defined by the business rules will be presented in parenthesis following the XML field name on the Sample Mapping Documents. For example:

<CFA>string</CFA> (CFA (DS1))

<FEATURE_GRP>*

<FA>s</FA> (TGFA)

<FEATURE>string</FEATURE> (TG FEATURE)

<FEATURE_DETAIL>string</FEATURE_DETAIL> (TG FEATURE DETAIL)

</FEATURE_GRP>

12. Header (HDR) Information return to top

The Header (HDR) sections defined below apply to all transactions. While they accommodate both inbound and outbound transactions in all AT&T regions, not all fields will be used on all transactions. Please refer to the LOH/LSOR/LSPOR for usage rules. The Headers consist of fields documented in the ordering and pre-ordering business rule documents, as well as XML specific fields. Those XML specific fields have been identified in red below, and the data characteristics and valid values are also provided.

Order Header

<HDR>

<MESSAGE_ID>string</MESSAGE_ID>

<CCNA>str</CCNA>

<MSG_TIMESTAMP>2002-10-10T12:00:00-05:00</MSG_TIMESTAMP>

<PON>string</PON>

<EC_VER>str</EC_VER>

<ATN>string</ATN>

<LSR_NO>string</LSR_NO>

<STATE>st</STATE>

<TEST_PROD_INDICATOR>s</TEST_PROD_INDICATOR>

<MESSAGE_TEXT>string</MESSAGE_TEXT>

<CLEC_APPL_ID>string</CLEC_APPL_ID>

<CLEC_APPL_PASSWORD>string</CLEC_APPL_PASSWORD>

<DTSENT>string</DTSENT>

<ORD>string</ORD>

<STATUS_CODE>string</STATUS_CODE>

<STATUS_MSG>string</STATUS_MSG>

<REMARKS>string</REMARKS>

<TRAN_ACK_TYPE>string</TRAN_ACK_TYPE>

<TRANS_SET PURPOSE_CODE>st</TRANS_SET PURPOSE_CODE>

</HDR>

	Inbound	Outbound	Characters	Valid Values
MESSAGE_ID	X	X	32	Free form customer input
CCNA	X	X	3	CCNA is required by XML on Order transactions for customer verification purposes
MSG_TIMESTAMP	X	X	26	xs:date Time (2002-10-10T12:00:00-05:00)
STATE	X	X	2	2 character state code in which the order is being processed (AR, CA, CT, IL, IN, KS, MI, MO, NV, OH, OK, TX, WI, AL, FL, GA, KY, LA, MS, NC, SC, TN)
TEST_PROD_INDICATOR (9-state only)	X	X	1	T-Test P-Production
MESSAGE_TEXT	X	X	264	Free form customer input
CLEC_APPL_ID	X	X	32	Assigned by ATT
CLEC_APPL_PASSWORD	X	X	16	Assigned by ATT

Pre-Order Header

<HDR>

<MESSAGE_ID>string</MESSAGE_ID>

<MSG_TIMESTAMP>2002-10-10T12:00:00-05:00</MSG_TIMESTAMP>

<TXNUM>string</TXNUM>

<STATE>st</STATE>

<DTSENT>string</DTSENT>

<CLEC_APPL_ID>string</CLEC_APPL_ID>

<CLEC_APPL_PASSWORD>string</CLEC_APPL_PASSWORD>

<TRANS_CLS>s</TRANS_CLS>

<TRX_NAME>string</TRX_NAME>

<TEST_PROD_INDICATOR>s</TEST_PROD_INDICATOR>

</HDR>

	Inbound	Outbound	Characters	Valid Values
MESSAGE_ID	X	X	32	Free form customer input
MSG_TIMESTAMP	X	X	26	xs:date Time (2002-10-10T12:00:00-05:00)
STATE	X	X	2	2 character state code in which the transaction is being processed (AR, CA, CT, IL, IN, KS, MI, MO, NV, OH, OK, TX, WI, AL, FL, GA, KY, LA, MS, NC, SC, TN) Note - On a 9-State Unparsed CSR Request, STATE values must be populated with AL, AT, KY, LA, MS, NC, NF, OS, SC, SE, SF or TN when CSR ECCKT is populated, otherwise use values AL, FL, GA, KY, LA, MS, NC, SC or TN
CLEC_APPL_ID	X		32	Assigned by ATT
CLEC_APPL_PASSWORD	X		16	Assigned by ATT
TEST_PROD_INDICATOR (9-state only)	X	X	1	T-Test P-Production

Post-Order Header

<HDR>

<MESSAGE_ID>string</MESSAGE_ID>

<MSG_TIMESTAMP>2002-10-10T12:00:00-05:00</MSG_TIMESTAMP>

<TXNUM>string</TXNUM>

<DTSENT>string</DTSENT>

<CLEC_APPL_ID>string</CLEC_APPL_ID>

<CLEC_APPL_PASSWORD>string</CLEC_APPL_PASSWORD>

<TRANS_CLS>s</TRANS_CLS>

<TRX_NAME>string</TRX_NAME>

<TEST_PROD_INDICATOR>s</TEST_PROD_INDICATOR>

</HDR>

	Inbound	Outbound	Characters	Valid Values
MESSAGE_ID	X	X	32	Free form customer input
MSG_TIMESTAMP	X	X	26	xs:date Time (2002-10-10T12:00:00-05:00)
CLEC_APPL_ID	X	X	32	Assigned by ATT
CLEC_APPL_PASSWORD	X	X	16	Assigned by ATT
TEST_PROD_INDICATOR (9-state only)	X	X	1	T-Test P-Production

13. Hours of Availability return to top

The LSR xML Gateway will be available as documented on the OSS Hours of Operation spreadsheet available on the CLEC On-Line Website (https://clec.att.com/clec). These hours will match the current availability hours of the 12-State EDI and CORBA interfaces. If customers will be down during ATT’s hours of availability, they can notify their OSS Manager or the IS Call Center to contact the XML Application team to make special arrangements for receiving queued up responses from ATT.

14. Contacts return to top

Questions about the documentation provided on this website should be referred to The ATT Change Management Mailbox - attcmp@att.com

Technical issues with the gateway or connectivity should be referred to the IS Call Center (ISCC) – (314) 235-7225 or iscall@att.com

All other inquiries should be addressed to your ATT Account Manager or OSS Support Person.