ebonding architecture

Electronic Bonding with ILEC

Electronic Bonding ArchitectureDocument

v1.1.2 1

Revision History

Date RevisionNumber

Author Comment

09/12/03 0.5 Covad Architecture Initial Draft09/19/03 0.9 Covad Architecture Add more details09/25/03 0.91 Covad Architecture More Details for OSS/J Implementation09/30/03 0.92 Covad Architecture Address the MTTR issue10/03/03 1.0 Covad Architecture Changes according to design review10/29/03 1.1 Covad Architecture More Details on the schema design section11/13/03 1.1.1 Covad Architecture Changes on local entity bean description

12/10/03 1.1.2 Covad Architecture

1. Change message acknowledgemode

2. For ILEC trouble ticket creation,creates a record in TT_ILECINFOwith Covad related informationbefore sends message

v1.1.2 2

Table of Contents

1INTRODUCTION............................................................................................................5

2INDUSTRY STANDARDS............................................................................................. 62.1T1M1 STANDARD........................................................................................................... 62.2OSS/J........................................................................................................................... 72.3OSS/J VS T1M1 STANDARD............................................................................................7

3THE EXISITING COVAD TROUBLE TICKET SYSTEM.......................................9

4THE NEW COVAD TROUBLE TICKET SYSTEM................................................ 104.1DEPLOYMENT VIEW: THE BIG PICTURE............................................................................. 104.2NOTES ON THE DEPLOYMENT VIEW.................................................................................. 114.3DESIGN RATIONALE........................................................................................................114.4EMPHASIS ON COVAD MTTR......................................................................................... 114.5OVERVIEW OF NEW EJB COMPONENTS............................................................................ 124.6OVERVIEW OF JMS QUEUE/TOPIC COMPONENTS............................................................... 134.7OVERVIEW OF THE TIMER SERVICE................................................................................... 134.8OVERVIEW OF ILEC TROUBLE TICKET GATEWAY.............................................................. 134.9SECURITY......................................................................................................................144.10SCALABILITY................................................................................................................144.11PERFORMANCE............................................................................................................. 144.12MANAGEABILITY.......................................................................................................... 154.13TRANSACTION..............................................................................................................16

5DATA MODEL.............................................................................................................. 175.1THREE MAIN TABLES..................................................................................................... 175.2SUPPORTING TABLES.......................................................................................................18

6OSS/J IMPLEMENTATION........................................................................................236.1THE JVTTROUBLETICKETSESSION INTERFACE................................................................... 236.2EXTENDING OSS/J: THE QUERYTROUBLETICKETHISTORYVALUE INTERFACE.........................256.3THE XMLSERIALIZER INTERFACE...................................................................................... 256.4THE TROUBLETICKETKEY INTERFACE............................................................................... 266.5OTHER SUPPORTING INTERFACES...................................................................................... 266.6THE REQUIRED FIELD PROPERTY FILE...............................................................................276.7OSS/J ATTRIBUTES TO DATABASE FIELD/TABLE MAPPING................................................. 286.8JVTTROUBLETICKETSESSIONBEAN IMPLEMENTATION......................................................... 306.9XVTREPLYMDB IMPLEMENTATION................................................................................316.10JVTEVENTMDB IMPLEMENTATION...............................................................................326.11TROUBLETICKETTIMERSERVICE IMPLEMENTATION.............................................................32

6.11.1Configuration File for the Timer Service.........................................................336.11.2The Procedures for the Timer Service............................................................. 33

v1.1.2 3

7ILEC TROUBLE TICKET GATEWAY IMPLEMENTATION............................. 357.1STANDARD T1M1 TO OSS/J MAPPING........................................................................... 357.2ILEC SPECIFIC PROPERTY.............................................................................................. 367.3ILEC SPECIFIC MAPPING FILE........................................................................................ 367.4ILEC SPECIFIC COMMUNICATION PROPERTY..................................................................... 367.5CONSUME MESSAGES FROM COVAD TROUBLE TICKET SYSTEM............................................ 377.6RECEIVE RESPONSES FROM ILEC TROUBLE TICKET SYSTEM............................................... 377.7RECEIVE EVENT NOTIFICATIONS FROM ILEC TROUBLE TICKET SYSTEM................................41

8USE CASE REALIZATION.........................................................................................438.1CREATE A TROUBLE TICKET............................................................................................ 43

8.1.1Technician’s Interactions with TT-Application................................................. 438.1.2Sequence Diagram............................................................................................. 438.1.3What Happens behind the Scene........................................................................44

8.2QUERY A TROUBLE TICKET STATUS/INFORMATION..............................................................458.2.1Technician’s Interaction with TT-Application...................................................458.2.2Sequence Diagram............................................................................................. 45

8.3CANCEL A TROUBLE TICKET............................................................................................ 468.3.1Technician’s Interaction with TT-Application...................................................468.3.2Sequence Diagram............................................................................................. 468.3.3What Happens behind the Scene........................................................................47

8.4VIEW A TROUBLE TICKET HISTORY.................................................................................. 488.4.1Technician’s Interaction with TT-Application...................................................488.4.2Sequence Diagram............................................................................................. 48

8.5ESCALATE A TROUBLE TICKET......................................................................................... 498.5.1Technician’s Interactions with TT-Application................................................. 498.5.2Sequence Diagram............................................................................................. 498.5.3What Happens behind the Scene........................................................................50

8.6MODIFY A TROUBLE TICKET............................................................................................518.6.1Technician’s Interaction with TT-Application...................................................518.6.2Sequence Diagram............................................................................................. 528.6.3What Happens behind the Scene........................................................................52

8.7VERIFY REPAIR COMPLETION/CLOSE A TROUBLE TICKET.....................................................538.7.1Technician’s Interaction with TT-Application...................................................538.7.2Sequence Diagram............................................................................................. 548.7.3What Happens behind the Scene........................................................................54

9IMPACTS ON EXISTING SYSTEM.......................................................................... 56

v1.1.2 4

1 INTRODUCTION

This architecture document addresses the issues regarding electronically bonding Covadwith various ILECs for trouble ticket creation, status query, escalation, cancellation,modification in ILEC trouble ticket systems.

Problems with the existing way to interact with ILECs regarding trouble ticket include:

1. It is a manual process. So it is time-consuming, error prone, and very inefficient.

2. No unified tools or interfaces to work with for different ILECs.

3. Highly depended on ILEC trouble ticket system. When ILEC trouble ticket systemis taken down for maintenance, no action towards ILEC trouble ticket system ispossible.

This design addresses all these problems.

Reference Document1. Use case document: Electronic bonding use case document:

http://docushare/View/Collection-2386 by Alex Leong

2. T1M1 Standards: http://docushare/View/Collection-2528

3. OSS/J Specification: http://jcp.org/en/jsr/detail?id=91

v1.1.2 5

2 INDUSTRY STANDARDS

2.1 T1M1 StandardThe Standard Committee T1-Telecommunications has a series of standards that specifyinterface requirements between Operation Systems across jurisdictional boundaries. Oneof the standards is regarding trouble administration.

This trouble administration standard defines trouble administration functions betweentwo TMNs (Telecommunication Management Network), trouble ticket attributes, andobject classes. The underlying communication protocol is CMIP/CMISE.

The functions are:

1. Enter trouble report

2. Request trouble report status

3. Request trouble report format

4. Trouble history event

5. Review trouble history

6. Add trouble information

7. Trouble report status update

8. Trouble report commitment time update

9. Trouble report attribute value change

10. Enroll trouble report

11. De-enroll trouble report

12. Verify repair completion

13. Modify other trouble report attributes

14. Enroll trouble report format definition

15. De-enroll trouble report format definition

16. Attribute value change trouble report format definition

17. Trouble report progress update

18. Cancel trouble report

There are 95 attributes defined for trouble ticket administration. The attribute definitionsare described using ASN.1.

The object classes are defined in GDMO (Guidelines for the Definition of ManagedObjects).

For more information, please refer the standard documents.

v1.1.2 6

2.2 OSS/JOSS/J stands for OSS through Java Initiative, an initiative started by a working group ofindustry leaders including Sun Microsystems, BEA, IBM Business Consulting Services,MetaSolv, Nokia, Motorola, Nortel, NEC, etc to define and implement an open standardset of APIs using Java technology for Operations Support Systems (OSS) and BusinessSupport Systems (BSS).

OSS/J covers many OSS areas including: trouble ticket, customer management, ordermanagement, workforce management, billing, etc.

For trouble ticket, OSS/J defines:

1. Trouble Ticket EJB Session Interface: JVTTroubleTicketSession.

2. XML based request/response messages.

3. Java object based events and XML string based events.

4. A XVTMessageQueue for XML message, and two topics: XVTEventTopic forXML event, JVTEventTopic for Java Event Object.

The OSS/J trouble ticket API is finalized in February, 2002. For more informationregarding OSS/J, go to: http://jcp.org/en/jsr/detail?id=91

2.3 OSS/J vs T1M1 StandardThere has been a slow acceptance of the use T1M1 standards as an implementationtechnology for managing equipment and networks because of the following reasons:

1. CMIP and its underlying OSI stack are heavyweight.

2. The syntax used by ASN.1 and GDMO bears little relationship to OOprogramming languages. The object-oriented information models defined byCMIP, GDMO, and ASN.1 do not map easily into object-oriented programminglanguages either.

3. All the definitions provided by T1M1 standards are very complicated.

OSS/J does not have these shortcomings, but on the other hand, it has its own limitations:

1. It is not defined as rigid as T1M1 is for trouble administration. For example,T1M1 clearly defines what attributes are required, what attributes are provided bymanager, what attributes are provided by agent. OSS/J trouble ticket APIspecification does not address this issue at all.

2. Although it captures the most important part of T1M1, there are some mandatoryinformation missing from OSS/J specification, like the following two attributes:

a. TroubleReportFormatObjectPtr

b. TroubleReportStatusWindow

These two attributes are required for the trouble administration communicationwith ILECs.

3. It does not address history/log issue.

v1.1.2 7

Even with these limitations, it is still the best technology we can have given our Javaenvironment. Furthermore these OSS/J limitations can be overcome using other means.

v1.1.2 8

3 THE EXISITING COVAD TROUBLE TICKET SYSTEM

Covad Trouble Ticket System

TT-WFM

TT-System

TT-CFI

TT-Application (GUI)

TT-Application (GUI)

OSSO : Database

TT

FMS

FMS

CFI

CFIJDBC

t3

t3/GLUE

t3/GLUE

t3

Current Covad trouble ticket system allows its users to create, view, update, and tracktrouble ticket within Covad systems. When a trouble ticket involves ILECs, manualprocess is needed to resolve issues with ILECs.

v1.1.2 9

4 THE NEW COVAD TROUBLE TICKET SYSTEM

4.1 Deployment View: the Big Picture

Covad Trouble Ticket System

ILEC Trouble TicketJVTTroubleTicketSessionBean TroubleTicketLocalEntityBeanTroubleTicketTimerService

VerizonXVTReplyMDBVerizonJVTEventMDBSbcXVTReplyMDB SbcJVTEventMDB

JMS

Weblogic JMS Server

VerizonXVTMessageReplyQueueSbcXVTMessageReplyQueue

VerizonXVTMessageQueueSbcXVTMessageQueue

VerizonJVTEventTopicSbcJVTEventTopic

TT-SystemTT-WFM

TT-CFI

SBC Trouble Ticket Gateway

Monfox.MOHandle

Ossj2SbcConverter

MessageReceiver

Sbc2OssjConverter

MessagePublisherMessageSender

Verizon Trouble Ticket Gateway

Monfox.MOHandle

Verizon2OssjConverterOssj2VerizonConverter

MessageReceiver MessagePublisher MessageSender

Verizon Trouble Ticket SystemVerizon

SBC Trouble Ticket System

SBC

OSSO : Database

TT-Application (GUI)TT-Application (GUI)

FMS

FMS

CFI

CFI

ILEC_TT_MSG

ILEC_TTTT

JMS

CMIP

Firewall

t3/GLUE

t3/Glue

t3

JMS

t3/GLUE

CMIP

v1.1.2 10

4.2 Notes on the Deployment ViewThe ILEC Trouble Ticket component contains one session bean, two message drivenbeans, and several local entity beans (only the trouble ticket local entity bean shown inthe deployment view). When we use Weblogic Application server, the Weblogic JMSserver is part of the Application server. So these beans and the queues, one topic will berunning in one JVM.

Although different nodes are shown for different gateway for ILECs, these gateways canrun on the same machine.

4.3 Design RationaleThe current design is based on the following rationales.

1. OSS/J, instead of T1M1 standard, is the right technology to go with. Since ILECsare using T1M1 standards, we will use both OSS/J and T1M1 standard, but T1M1is used behind OSS/J.

2. We will not fully implement OSS/J specification. We only implement the partnecessary for this project.

3. To avoid tightly coupled with ILEC trouble ticket system, we introduce a JMSserver in the middle. This JMS server also shields Covad trouble ticket system fromthe ILEC trouble ticket maintenance schedule.

4. To achieve isolation for ILEC (such as changes for one ILEC should not affectcommunication with other ILEC), each gateway runs on its on JVM, i.e. differentgateways run on different JVMs. The other benefits are that gateway is morescalable and robust.

5. Only TAC can create ILEC trouble ticket through TT GUI.

4.4 Emphasis on Covad MTTRCurrently Covad creates total around 320 trouble tickets for all ILECs per day, one JMSserver with two queues and one topic should be able to handle this load. To minimizeCovad MTTR,

1. We introduce one message queue, one message reply queue, and one event topicfor each master ILEC (like SBC, Verizon, etc., not for baby ILEC likeAmeriTech). This not only increases the processing speed, but prevents messagesdesignated for the ILEC, which is not on line, from blocking messages designatedfor other ILECs.

2. The trouble ticket creation request message will be have higher priority than otherrequest messages.

Although Message-driven beans can have instance pools provided by EJB container,theoretically, one message reply queue and one event topic for all ILECs should beenough. Based on the following reasons, we decide separate the message reply queue andevent topic for different ILECs.

v1.1.2 11

1. To maintain the event order, we need to set the message driven bean instance poolsize to 1. Event order sometimes is important, considering two updatemessages/events, we want the database updates in right order.

2. Because the pool size is 1, we cannot take advantage of instance pool. The MDBscould be the trouble ticket processing bottleneck.

4.5 Overview of New EJB Components1. Session Bean JVTTroubleTicketSessionBean: The bean implements all the

business functions defined in JVTTroubleTicketSession interface of OSS/Jtrouble ticket API. It is also the single entry point to the new trouble ticket system.We have much more to say about this bean in later sections.

2. Message-Driven Bean XVTReplyMDB: this message-driven bean consumes allmessages (XML messages) from XVTMessageReplyQueue. Messages are eitherthe Response or Exception types of messages defined by OSS/J. They are:

a. createTroubleTicketByValueResponse

b. createTroubleTicketByValueException

c. setTroubleTicketByValueResponse

d. setTroubleTicketByValueException

e. cancelTroubleTicketsByTemplateResponse

f. cancelTroubleTicketsByTemplateException

g. escalateTroubleTicketsByTemplateResponse

h. escalateTroubleTicketsByTemplateException

i. closeTroubleTicketsByTemplateResponse

j. closeTroubleTicketsByTemplateException

It will call local entity beans to update database.

3. Message-Driven Bean JVTEventMDB: this message-driven bean consumes allmessages (Java Object messages) from JVTEventTopic. Messages are thosenotification events defined by OSS/J. They are

a. TroubleTicketCreateEvent

b. TroubleTicketCloseOutEvent

c. TroubleTicketAttributeValueChangeEvent

d. TroubleTicketCancellationEvent

e. TroubleTicketStatusChangeEvent

This component will call local entity beans to update database.

4. Local Entity Beans: we need local entity beans for those tables specified in thedata model section. CMP together with cmr fields should be used for these entitybeans.

v1.1.2 12

4.6 Overview of JMS Queue/Topic ComponentsIn the JMS server, we will have one message queue per ILEC, and one message replyqueue, one topic for all ILECs.

1. XVTMessageQueue: this queue is for all XML request messages to ILEC troubleticket System.

2. XVTMessageReplyQueue: this queue is for XML response/exception messagesfrom ILEC trouble ticket system.

3. JVTEventTopic: this is for Java notification message from ILEC trouble ticketsystem.

All the messages sent to the queues are mandatory to set the following properties:

1. OSS_MESSAGE_TYPE: REQUEST, RESPONSE, or EXCEPTION.

2. OSS_MESSAGE_NAME: The name of the operation, likecreateTroubleTicketByValueRequest.

3. OSS_APPLICATION_TYPE: we can use “Trouble Ticket”

4. OSS_REQUEST_SENDER_ID: we can use “Covad”

5. OSS_REPLY_SENDER_ID: use ILEC name

6. OSS_REPLYTO_DESTINATION_TYPE: use value “QUEUE”

Beside these properties, for our application, we need to define one more property:

7. ILEC_TROUBLETICKET_NUMBER

All the events published to the topic are mandatory by OSS/J to set the followingproperties:

1. OSS_EVENT_TYPE: the fully qualified event name

2. OSS_APPLICATION_DN: ILEC name

Beside these properties, we also need to define the following property for the event:

3. ILEC_TROUBLETICKET_NUMBER

Also the JMSDeliveryMode for both messages and events are PERSISTENT.

4.7 Overview of the Timer ServiceThe timer service is a Weblogic startup object. At its startup time, it will create a timer.On pre-configured interval, this timer will keep sending out XML request message toXVTMessageQueue to query ILEC trouble ticket systems for the latest trouble ticketinformation. The returned information is used to update the Covad database. By usingthis timer service, Covad database has almost real time information about ILEC troubletickets created by Covad. More details in the later section.

4.8 Overview of ILEC Trouble Ticket GatewayThe gateway process accomplishes the following:

v1.1.2 13

1. Receive XML messages from XVTMessageQueue.

2. Convert between OSS/J XML message and ILEC required values.

3. Use 3rd party library to send and receive CMIP data.

4. Generate TroubleTicketKey for successful creation request.

5. Publish XML messages to XVTMessageReplyQueue and Java Event toJVTEventTopic.

6. Receive ILEC event notifications.

In the deployment diagram, we use MessageReceiver, MessageSender,MessagePublisher, Ossj2IlecConverter, Ilec2OssjConverter, and MOHandle class toillustrate the steps needed in the gateway. In the actual implementation, you may not haveexactly the same classes.

The ILEC trouble ticket gateway system is an independent Java process.

4.9 SecurityThere are three security aspects for this system.

1. The security for accessing the session bean.

2. The security for accessing queues and topic

3. The security for communicating with ILECs.

The first two will be handled in role based EJB way. The last one will follow the T1M1standard, using encryption. We only need to configure the 3rd party product (Monfox),store the encryption key in proper location, Monfox’s library will handle the securehandshaking with ILECs.

4.10 ScalabilityCurrent design should be more than enough for the current load, and even modestincrease of the load.

If load increases dramatically, we can scale beans, queues, and topics side by clusteringWeblogic server. On the gateway size, we can bring up more instances, and divide theloads among these instances, like one instance only dealing with trouble ticket creation,etc. This can be easily done through JMS’s message selector mechanism.

4.11 PerformanceOSS/J defines queues for XML message, topics for both XML messages and Java objectmessage, but does not define Java message for queues. To confirm with this standard, weneed to serialize the Java object into XML message, and later on need to parse this XMLmessage to retrieve data out, which essentially is to deserialize the XML message.Although all these operations are performed in memory, it does have performancepenalty. However we do not believe the penalty is high.

v1.1.2 14

If the performance is an issue, we could use Java object message instead of XMLmessage, use a new queue for Java object message to replace the current XML messagequeue. Current design to use Java object message rather than XML message for thenotification is mainly due to performance consideration.

4.12 ManageabilityThe ILEC Trouble Ticket Gateway is implemented as a standalone Java process. Thereare concerns regarding these gateways:

1. How do we monitor them?

2. These gateways are not built on top on some type of platform. Examples ofplatforms are: J2EE, CORBA, etc.

These are good concerns. But the key functionality of the gateway is to communicateILEC trouble ticket system through CMIP protocol, which makes the gateway impossibleto be built on top of the popular platforms like J2EE and CORBA.

There are ways to address these concerns:

One way is to use another Java technology called JMX:

1. Wrap each gateway into a MBean, and expose functions like: start, stop, statisticinfo, and notification support.

2. Write a simple console as the management application, for example, a simpleWeb client.

By doing this, you can achieve the following.

1. All the gateways are built on JMX’s Distributed/Agent/Instrumentation layerframework.

2. Gateway can be easily plugged into the framework.

3. Gateway can be monitored.

One downside of this approach is more development work needed. Beside the MBeanimplementation, the protocol adapter in the distributed layer is also needed to beimplemented although Sun Microsystem does have a reference implementation whichprovides a HTML adapter.

The other way is to use J2EE connector architecture. The new JCA 1.5 defines a new setof system-level contracts between an application server and enterprise informationsystem. They include: lifecycle management contract, work management contract, etc.These new contracts make the resource adapters manageable through applicationadministration console. The current JCA 1.5 is in proposed final draft 2 stage. Theimplementation of the resource adapter will be more complicated in this case.

For the phase 1, the standalone process should be good enough. JMX approach or JCAapproach could be taken for the future enhancements.

v1.1.2 15

4.13 TransactionWhenever a persist JMS message is involved in a transaction, this transaction will almostinvolves multiple database writes. These writes are across different schemas, but in ourcase, these schemas reside in the same database. Even with this situation, there areconcerns about the transaction being a distributed transaction. Based on the followingreasons, we still make JVTTroubleTicketSessionBean and message-driven beanstransactional:

1. We don’t want to introduce our own mechanism to handle multiple databasewrites and enforce data integrity.

2. There are no multiple application server instances involved.

3. The scenarios we deal with here are relatively simple comparing with otherdistributed transactions we have seen in the past. It is not truly distributed as allthe database writes occur in the same database (but different schemas). Weblogicserver should be able to handle these simple cases.

However, for the sessions used in the ILEC trouble ticket Gateway systems, they are non-transactional because the actual communications with ILEC could be time-consuming.We may need some manual processes to resolve some data issues.

v1.1.2 16

5 DATA MODELWe need to store ILEC trouble ticket information in Covad database and keep the activityhistory around a trouble ticket. Although currently we do model ILEC trouble ticketinformation in our database, the current one is not good enough.

Note: the following table structure does not show the primary key field, nor the auditfields.

5.1 Three Main TablesTT_ILECINFO: this is an existing table. New attributes are added into this table to storeeBonding information about ILEC trouble tickets.

TT_ILECINFO_HISTORY: this table stores all information about ILEC trouble tickets,including all the activities associated with trouble tickets.

EBOND_TT_COVAD_WORKLOG: this table stores all the actions taken by Covad.

In addition to the existing attributes, both TT_ILECINFO and TT_ILECINFO_HISTORYshould contain the following eBonding attributes:

Field Name Type NotesUsing Ebonding Flag Varchar2(1) Y/NTroubled Object Identifier Varchar2(40) Can be carrier circuit number or

telephone numberTrouble Type ID Number EnumAdditional Trouble Info Varchar2(512) Standard requires minimum 256Covad Trouble Ticket Num NumberCovad Contact Person ID Number FKILEC Name Varchar2(30) Already exists (ILEC_NAME)ILEC Trouble Ticket Num Varchar2(40) Already exists

(ILEC_TICKET_NUM)ILEC Received Time Date Already exists

(ILEC_CONTACTED_AT)Trouble State ID Number EnumTrouble Status ID Number EnumTrouble Status Time DateAdditional Trouble Status Info Varchar2(512)Trouble Found ID Number EnumILEC Contact Person ID Number FKCancel Requested By Covad Flag Varchar2(1)Close Out Narrative Varchar2(256)Close Out Verification ID Number EnumMaintain Service Charge Varchar2(1)Covad TT Clearance Person Id Number FKCommitment Time Date Already exists

(ILEC_COMMIT_TIME)

v1.1.2 17

Outage Years NumberOutage Months NumberOutage Days NumberOutage Hours NumberOutage Minutes NumberOutage Seconds NumberCommitment Time Requested DateInitiating Mode ID Number EnumTrouble Detection Time DatePerceived Trouble Severity ID Number EnumPreferred Priority ID Number EnumRepeat Report ID Number EnumDate Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_TT_COVAD_WORKLOG should contain the following fields:

Field Name Type NotesEbond TT Covad Worklog ID Number(10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FK to TT_ILECINFO table.Covad Trouble Ticket Num NumberILEC Trouble Ticket Num Varchar2(40)Operation Name Varchar2(30)Operation Attribute Value Varchar2

(2048)Operation Status Varchar2(1) Success/Fail/QueuedOperation Error Message Varchar2

(256)Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

5.2 Supporting TablesEBOND_LOOKUP: this ENUM table stores all the eBonding enum lookup values:

Fields Type NotesType Varchar2(30) PKEbond Lookup ID Number(10) PKValue Varchar2(50)Status Varchar2(8) ACTIVE/INACTIVEDate Created Date Audit ColumnCreated By Varchar2(30) Audit Column

v1.1.2 18

Date Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_ILEC_PERSON_REACH: this table stores the ILEC person’s contactinformation. It should contain the following fields:

Fields Type NotesEbond Ilec Person Reach ID Number(10) PK. Oracle Sequence.Email Varchar2(40) Email+Name – Business KeyName Varchar2(40) Email+Name – Business KeyOrganization Name Varchar2(20)Fax Varchar2(30)Phone Area Code Varchar2(3)Phone Prefix Varchar2(3)Phone Suffix Varchar2(4)Phone Extension Varchar2(5)Responsible Varchar2(64)Street Address Varchar2(64)City Varchar2(30)State Varchar2(30)Zip Varchar2(10)Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_COVAD_SUPPORT_CONTACT: this table stores the COVAD supportcontact information. It should contain the following fields:

Fields Type NotesEbond Covad Support Contact ID PK. Oracle Sequence.Parent Carrier ID Number(10) FKCovad Support Email Dist List Varchar2(100)Covad Support Phone Number Varchar2(20)Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_COVAD_PERSON_REACH: this table stores the COVAD person’s contactinformation. It should contain the following fields:

Fields Type NotesEbond Covad Person Reach ID PK. Oracle Sequence.Ebond Covad Support Contact ID Number(10) FKCovad OSS TT Login Varchar2(32)Name Varchar2(40)

v1.1.2 19

Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_TT_AUTHORIZATION: this table stores whether authorization is requested byILEC and granted by Covad. It should contain the following fields:

Fields Type NotesEbond TT Authorization ID Number(10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FKActivity Type id Number(10) enumCovad Authorization Person ID Number FKAuthorization Time DateRequest State ID Number enum (requested, provided, denied)Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_TT_ESCALATION: this table stores what escalation has happened to onetrouble ticket. It should contain the following fields:

Fields Type NotesEbond TT Escalation ID Number(10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FKILEC Escalation Person ID Number FKEscalation Time DateEscalation Level ID Number enumCovad Request Person ID Number FKRequest State ID Number enumDate Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_TT_ACTIVITY_DURATION: this table stores duration for all the activitiesassociated with a trouble ticket. It should contain the following fields.

Fields Type NotesEbond TT Activity Duration ID Number(10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FKActivity Type ID Number enumBillable Flag Varchar2(1) Y/NDuration In Years Number

v1.1.2 20

Duration In Months NumberDuration In Days NumberDuration In Hours NumberDuration In Minutes NumberDuration In Seconds NumberDate Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

EBOND_TT_ACCESS_HOUR: this table stores the access hours for the troubled objectand for the troubled location. It should contain the following fields:

Fields Type NotesEbond TT Access Hour ID Number (10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FKDay of Week Number Look up value (Sunday,…,

Saturday)Begin Hour NumberBegin Minute NumberBegin Second NumberEnd Hour NumberEnd Minute NumberEnd Second NumberTroubled Type ID Number enum (Location or Object)Date Created Date Audit ColumnCreated By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

Note for a given day of week, you can have a list of begin time and end time. We couldbreak the above table into two for database normalization.

EBOND_TT_ACCESS_LOCATION: this table stores the trouble location information. Itshould contain the following fields.

Fields Type NotesEbond TT Access Loaction ID Number(10) PK. Oracle Sequence.ILEC_INCIDENT_ID Number FKPremise Name Varchar2(64)Premise Street Address Varchar2(64)Premise City Varchar2(30)Premise State Varchar2(30)Premise Zip Varchar2(10)Location Type Varchar2(1) ‘A’ or ‘Z’Date Created Date Audit Column

v1.1.2 21

Created By Varchar2(30) Audit ColumnDate Modified Date Audit ColumnModified By Varchar2(30) Audit Column

v1.1.2 22

6 OSS/J IMPLEMENTATIONOSS/J trouble ticket API is just a specification. This specification defines everything interms of interfaces. We need to have our own implementation. Fortunately we only needto implement part of the OSS/j, and there is a reference implementation available for freedownload. We could use this reference implementation as our guideline. Here is a list(not complete) of interfaces we need to implement.

6.1 The JVTTroubleTicketSession InterfaceOSS/J defines the following operations in the JVTTroubleTicketSession interface:

1. Get a single trouble ticket

2. Get multiple trouble tickets

3. Set a single trouble ticket

4. Set multiple trouble tickets

5. Create a single trouble ticket

6. Create multiple trouble tickets

7. Close a single trouble ticket

8. Close multiple trouble tickets

9. Cancel a single trouble ticket

10. Cancel multiple trouble tickets

11. Escalate a single trouble ticket

12. Escalate multiple trouble tickets

For operations involving multiple trouble tickets, OSS/J defines two bulk types: BestEffect and Atomic Bulk.

Precisely, the JVTTroubleTicketSession interface is:

v1.1.2 23

+trySetTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], troubleticketvalue : TroubleTicketValue, flag : boolean ) : TroubleTicketKeyResultIterator+trySetTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, troubleticketvalue1 : TroubleTicketValue, flag : boolean ) : TroubleTicketKeyResultIterator

+tryEscalateTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], escalationlist : EscalationList, flag : boolean ) : TroubleTicketKeyResultIterator+tryEscalateTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, escalationlist : EscalationList, flag : boolean ) : TroubleTicketKeyResultIterator

+tryCancelTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator

+tryCloseTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator

+tryCancelTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator

+tryCloseTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator

+trySetTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], troubleticketvalue : TroubleTicketValue ) : TroubleTicketKeyResult[]

+tryEscalateTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], escalationlist : EscalationList ) : TroubleTicketKeyResult[]

+setTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], troubleticketvalue : TroubleTicketValue ) : void+setTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, troubleticketvalue1 : TroubleTicketValue ) : void

+escalateTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], escalationlist : EscalationList ) : void

+trySetTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[], flag : boolean ) : TroubleTicketKeyResult[]

+getTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], as : String[] ) : TroubleTicketValueIterator

+tryCancelTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : TroubleTicketKeyResult[]

+tryCloseTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : TroubleTicketKeyResult[]

+escalateTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, escalationlist : EscalationList ) : void

+getTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, as : String[] ) : TroubleTicketValueIterator

+setTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], troubleticketvalue : TroubleTicketValue ) : void

+escalateTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], escalationlist : EscalationList ) : void

+tryCreateTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKeyResult[]

+escalateTroubleTicketByKey( troubleticketkey : TroubleTicketKey, escalationlist : EscalationList ) : void

+getTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], as : String[] ) : TroubleTicketValue[]

+cancelTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String ) : void

+closeTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String ) : void

+cancelTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String ) : void

+closeTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String ) : void

+createTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKey[]

+getTroubleTicketByKey( troubleticketkey : TroubleTicketKey, as : String[] ) : TroubleTicketValue

+setTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[], flag : boolean ) : void

+cancelTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : void

+createTroubleTicketByValue( troubleticketvalue : TroubleTicketValue ) : TroubleTicketKey

+closeTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : void

+queryTroubleTickets( queryvalue : QueryValue, as : String[] ) : TroubleTicketValueIterator+setTroubleTicketByValue( troubleticketvalue : TroubleTicketValue, flag : boolean ) : void

+cancelTroubleTicketByKey( troubleticketkey : TroubleTicketKey, i : int, s : String ) : void

+closeTroubleTicketByKey( troubleticketkey : TroubleTicketKey, i : int, s : String ) : void

+makeTroubleTicketValue( s : String ) : TroubleTicketValue

JVTTroubleTicketSession

Based on the use case document, we need only to support operations on a single troubleticket. Here is the list of operations we need to implement. For the rest operations, we canjust put empty function body.

+getTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue, attrNames : String[] ) : TroubleTicketValueIterator

+cancelTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue, statue : int, closeOutNarr : String ) : void

+escalateTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue, escalationlist : EscalationList ) : void

+closeTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue, status : int, closeOutNarr : String ) : void

+setTroubleTicketByValue( troubleTicketValue : TroubleTicketValue, resyncRequired : boolean ) : void+queryTroubleTickets( queryValue : QueryValue, attrNames : String[] ) : TroubleTicketValueIterator

+createTroubleTicketByValue( troubleTicketValue : TroubleTicketValue ) : TroubleTicketKey

JVTTroubleTicketSessionBean

Note: The following operations were designated by OSS/J for multiple trouble tickets:

1. cancelTroubleTicketsByTemplate

2. closeTroubleTickesByTemplate

3. escalateTroubleTicketsByTemplate

4. getTroubleTicketsByTemplate

We choose these operations instead of the following operations designated by OSS/J forsingle trouble ticket:

1. cancelTroubleTicketByKey

2. closeTroubleTicketByKey

3. escalateTroubleTicketByKey

v1.1.2 24

4. getTroubleTicketByKey

The reason is that these “ByKey” operation’s parameters are too restrictive to prevent usto pass necessary information. For example, for the cancel trouble ticket case, thecancelTroubleTicketByKey does not have place for us to pass the trouble clearanceperson information, but with cancelTroubleTicketsByTemplate, we can pass this pieceinformation in troubleTicketValue parameter.

We need to make sure that the troubleTicketValue input parameter containstroubleTicketKey for cancelTroubleTicketsByTemplate, closeTroubleTicketsByTemplateand escalateTroubleTicketsByTemplate. So effectively, we still deal with single troubleticket.

6.2 Extending OSS/J: the QueryTroubleTicketHistoryValue InterfaceOSS/J defines a base interface QueryValue for generic attribute accessor. OSS/J alsodefines QueryAllOpenTroubleTicketsValue, QueryByEscalationValue sub-interfaces.

None of the existing interfaces can satisfy the need to query the history value for a troubleticket. We define QueryTroubleTicketHistoryValue interface for this purpose.

+setTroubleTicketKey( troubleTicketKey : TroubleTicketKey ) : void+setCovadTroubleTicketNumber( int ) : void+getTroubleTicketKey() : TroubleTicketKey+getCovadTroubleTicketNumber() : int

QueryTroubleTicketHistoryValue

QueryValue

We will only support this interface in the queryTroubleTickets operation.

6.3 The XmlSerializer InterfaceThis interface marshals and un-marshals a Java object to and from XML.

+toXml( object : Object, elementName : String ) : String+fromXml(element : org.w3c.dom.Element) : Object

XmlSerializer

This interface is relevant to us because we need to generate XML message from a troubleticket value (Java object), and also the other way around. Both marshalling and un-marshalling should be done in conform to the XML schema defined by OSS/J.

v1.1.2 25

6.4 The TroubleTicketKey Interface

+setTroubleTicketPrimaryKey( s : String ) : void+getTroubleTicketPrimaryKey() : String

TroubleTicketKey

+getApplicationContext() : ApplicationContext+getApplicationDN() : String+getPrimaryKey() : Object...

ManagedEntityKey

For a trouble ticket key, it basically contains three pieces of information:

1. A primary key

2. An application DN

3. An application context

The primary key will be the ILEC trouble ticket number. The application DN is the DN ofthe application JNDI naming context. The application context is used to locate theapplication components in charge of the managed entity. Both application DN andapplication context are only interested to the calling application (like the TT-ApplicationGUI). These two pieces of information should be specified in the ejb-jar.xml file.

When we generate a TroubleTicketKey, we only need to set its primaryKey, the other twocan be set to null.

6.5 Other Supporting InterfacesThere are many other interfaces we need to implement. Here are some examples.

+makeCustomerRoleAssignment() : CustomerRoleAssignment

+setCommitmentTimeRequested( date : Date ) : void

+getActivityDurationList() : ActivityDurationList

+setCommitmentTime( date : Date ) : void

+makeAlarmValueList() : AlarmValueList+getAdditionalTroubleInfoList() : String[]

+setCloseOutVerification( i : int ) : void

+makeAuthorization() : Authorization

+getAccountOwner() : PersonReach

+makeEscalation() : Escalation

...

TroubleTicketValue

v1.1.2 26

+getNextTroubleTickets( i : int ) : TroubleTicketValue[]

TroubleTicketValueIterator

+setEscalationPerson( personreach : PersonReach ) : void

+setRequestPerson( personreach : PersonReach ) : void

+setEscalationTime( date : Date ) : void

+getEscalationPerson() : PersonReach

+getRequestPerson() : PersonReach

+setRequestState( i : int ) : void

+getEscalationTime() : Date

+getRequestState() : int

+setLevel( i : int ) : void

+clone() : Object

+getLevel() : int

Escalation

+remove( aescalation : Escalation[] ) : void

+add( aescalation : Escalation[] ) : void

+set( aescalation : Escalation[] ) : void

+make( i : int ) : Escalation[]+get() : Escalation[]

EscalationList

6.6 The Required Field Property FileThis required.xml file is to specify what attributes are required for a given operation. Ittakes the following format:

<Operation_Required_Info>

<Operation>

<Operation_Name>…</Operation_Name>

<Required_Fields>

<Required_Field>…</Required_Field>

…

</Required_Fields>

</Operation>

</Operation_Required_Info>

This xml file will be parsed once when the session bean is created. Here is just a potion ofthe file:

<Operation>

<Operation_Name>createTroubleTicketByValue</Operation_Name>

v1.1.2 27

<Required_Parameters>

<Required_Parameter>TroubledObject</Required_Parameter>

<Required_Parameter>TroubledType</Required_Parameter>

<Required_Parameter>AdditionalTroubleInfoList</Required_Parameter>

<Required_Parameter>TroubleSystemDN</Required_Parameter>

<Required_Parameter>CustomerTroubleNum</Required_Parameter>

<Required_Parameter>AuthorizationList</Required_Parameter>

<Required_Parameter>TroubleLocationInfoList</Required_Parameter>

<Required_Parameter>TroubledObjectAccessHoursList</Required_Parameter>

<Required_Parameter>CustomerRoleAssignmentList</Required_Parameter>

</Required_Parameters>

</Operation>

This file is for basic nullity checking. The parameter name is conformed to OSS/JTroubleTicketValue interface. Some of the parameters are composite. We could extendthis xml file to the level that what fields in the composite attribute are required. Forexample, Authorization contains request state, activity type, authorization time,authorization person fields, but only the first two are required. We can express thisrequirement as follows:

<Composite_Required_Parameter>

<Composite_Parameter_Name>AuthroizationList</Composite_Parameter_Name>

<Required_Parameter>RequestState</Required_Parameter>

<Required_Parameter>ActivityType</Required_Parameter>

</Composite_Required_Parameter>

If we use this composite required parameter tag, the original tag name forAuthorizationList needs to be changed to Composite_Required_Parameter.

6.7 OSS/J Attributes to Database Field/Table MappingNot every attribute defined in OSS/J are used. Not every attribute defined in OSS/J hasone-to-one mapping to database table field. Here is the mapping from OSS/J attribute todatabase field/table mapping.

OSS/J Attribute Database Field/Table NoteaccountOwner Not usedactivityDurationList EBOND_TT_

ACTIVITY_DURATIONadditionalTroubleInfoList Additional Trouble InfoafterHoursRepairAuthority Not used

v1.1.2 28

authorizationList EBOND_TT_

AUTHORIZATIONcancelRequestedByCustomer Cancel Requested By

CovadclearancePerson Covad Trouble Clearance

Person IdcloseOutNarr Close Out NarrcloseOutVerification Close Out VerificationcommitmentTime Commitment TimecommitmentTimeRequested Commitment Time

Requestedcustomer Not usedcustomerRoleAssignmentList Related to Covad Contact

Person IdcustomerTroubleNum Covad Trouble Ticket Numdialog Not usedescalationList EBOND_TT_

ESCALATIONinitiatingMode Initiating modelastUpdateTime Not usedmaintServiceCharge Maintenance service chargeoriginator Not usedoutageDuration Outage

years/months/days/hours/

minutes/secondsperceivedTroubleSeverity Perceived Trouble SeveritypreferredPriority Preferred ProrityreceivedTime ILEC Received TimerelatedAlarmList Not usedrelatedTroubleTicketKeyList Not usedrepairActivityList Not usedrepeatReport Repeat ReportrestoredTime Restored TimeserviceUnavailableBeginTime Not usedserviceUnavailableEndTime Not usedspRoleAssignmentList Related to ILEC contact

person idsuspectObjectList Not usedtroubleDescription Additional trouble status

infotroubleDetectionTime Trouble Detection TimetroubleFound Trouble FoundtroubleLocation Not usedtroubleLocationInfoList EBOND_TT_

ACCESS_LOCATION

v1.1.2 29

troubleNumList Not usedtroubledObject Trouble Object IdentifiertroubledObjectAccessFromTime Not usedtroubledObjectAccessHoursList EBOND_TT_

ACCESS_HOURtroubledObjectAccessToTime Not usedtroubleState Trouble StatetroubleStatus Trouble StatustroubleStatusTime Trouble Status TimetroubleSystemDN ILEC NametroubleTicketKey No corresponding

table/field, but is used.Related to ILEC troubleticket num.

troubleType Trouble Type

Notes on CustomerRoleAssignmentList:

CustomerRoleAssignmentList is basically an array of CustomerRoleAssignment.CustomerRoleAssignment basically contains two pieces of information:

1. Contact Person Information

2. Role

The contact person information will be mapped to Covad contact person. We can hard-coded the Role as “Manager”.

Notes on SPRoleAssignmentList:

SPRoleAssignmentList is basically an array of SPRoleAssignment. SPRoleAssignmentcontains two pieces of information:

1. Contact Person Information

2. Role

The contact person information will be mapped to ILEC contact person. We can hard-coded the Role as “Agent”.

6.8 JVTTroubleTicketSessionBean ImplementationAs we mentioned in previous section, JVTTroubleTicketSessionBean needs to implementthe following functions:

1. createTroubleTicketByValue: TroubleTicketKey

2. cancelTroubleTicketsByTemplate

3. closeTroubleTicketsByTemplate

4. escalateTroubleTicketsByTemplate

5. setTroubleTicketByValue

v1.1.2 30

6. getTroubleTicketsByTemplate

7. queryTroubleTickets

The implementation of Functions 1-5 follows the same steps:

1. Generate XML message using XmlSerializer

2. Send the XML message to XVTMessageQueue

3. Persist information to EBOND_TT_COVAD_WORKLOG table

For createTroubleTicketByValue function, before it executes the steps above, it creates arecord in TT_IECLINFO table with Covad related information.

The following table specifies the mapping from the operations to the XML Message.

Operation Name XML Message ElementcreateTroubleTicketByValue createTroubleTicketByValueRequestcancelTroubleTicketsByTemplate cancelTroubleTicketsByTemplateRequestcloseTroubleTicketsByTemplate closeTroubleTicketsByTemplateRequestescalateTroubleTicketsByTemplate escalateTroubleTicketsByTemplateRequestsetTroubleTicketByValue setTroubleTicketByValueRequest

The return value for createTroubleTicketByValue is TroubleTicketKey. Since the ILECtrouble ticket number is unknown at this moment, this function should always return null.

For the persistence of EBOND_TT_COVAD_WORKLOG, store the actual XMLmessage element (or attribute’s name and value pairs) into the Operation Attribute Valuefield, and set the operation status to “Queued”.

For functions 6-7, we just query our local database. For 7, the Covad trouble ticketnumber or ILEC trouble ticket number needs to be provided. For 8, onlyQueryTroubleTicketHistoryValue is required to support.

6.9 XVTReplyMDB ImplementationXVTReplyMDB consumes all the messages from XVTMessageReplyQueue. Thefollowing is the complete list of XML messages it needs to handle.

1. createTroubleTicketByValueResponse

2. createTroubleTicketByValueException

3. cancelTroubleTicketsByTemplateResponse

4. cancelTroubleTicketsByTemplateException

5. closeTroubleTicketsByTemplateResponse

6. closeTroubleTicketsByTemplateException

7. escalateTroubleTicketsByTemplateResponse

8. escalateTroubleTicketsByTemplateException

9. setTroubleTicketByValueResponse

v1.1.2 31

10. setTroubleTicketByValueException

For all these messages, just update the EBOND_TT_COVAD_WORKLOG tableaccording to whether it is a response message or response message based on Covadtrouble ticket number, ILEC trouble ticket number (if it is not null) and operation name.

1. For response messages, set the operation status to “success”

2. For exception messages, set the operation status to “failure”, and operation errormessage from the exception.

In the case of createTroubleTicketByValueException, an email should be sent to theCovad contact person to notify the trouble ticket creation failed.

6.10 JVTEventMDB ImplementationJVTEventMDB subscribes to JVTEventTopic, and consumes all the messages inJVTEventTopic. All the messages are Java object messages. Here is the complete list ofJava object messages it needs to handle.

1. TroubleTicketAttributeValueChangeEvent

2. TroubleTicketCancellationEvent

3. TroubleTicketCloseOutEvent

4. TroubleTicketStatusChangeEvent

5. TroubleTicketCreateEvent

The handling of these events is as follows:

1. Retrieve all the attribute values from the event

2. For all these events except the creation event, compare all the not-null values withdatabase values, if they are same, ignore the event; otherwise create a historyrecord in TT_ILECINFO_HISTORY table, and update TT_ILECINFO table.

3. For creation event, update the record in TT_ILECINFO table.

6.11 TroubleTicketTimerService ImplementationThis timer service is not customer facing service, but a background one. Its purpose is toquery ILEC’s database constantly on some pre-configured time interval to get the latesttrouble ticket information. Theoretically T1M1 standard requires ILEC send Covad thefollowing notification:

1. Attribute Value Change Notification

2. Object Creation Notification

3. Object Deletion Notification

4. Trouble Report Status/Commitment Time Update Notification

5. Trouble History Event Notification

v1.1.2 32

But event notification is not queued at ILEC side, it is only sent once. If it is lost, there isno way to get the same notification again. In real world, there are many reasons thatnotification may be lost.

So we cannot rely on these notifications to synchronize with ILEC database information.This timer service is the way to synchronize our local database with ILEC database.

6.11.1 Configuration File for the Timer Service

This configuration file should contain two pieces of information:

1. The time interval: it determines how often the query messages will be generated,like every 4 hours.

2. The set of attributes we want to query against ILEC systems. Basically we shouldinclude all the common attributes which could be supplied or updated by ILEC.The Join Integration Agreement specifies this information.

6.11.2 The Procedures for the Timer Service

The implementation of this timer service can use the weblogic proprietary interfaces likeT3StartupDef and NotificationListener.

This service performs the following steps regularly on pre-configured time interval:

1. Query Covad database to find out all the trouble tickets which satisfy thefollowing criteria.

a. The state is open

b. The commitment time has passed or the trouble ticket has not beenupdated for a pre-configured time period.

2. If there are trouble tickets returned from step 1, browse XVTMessageQueue tofind all the query messages already in the message queue.

3. For each trouble ticket returned from step 1, based on the following messageproperties to determine if the corresponding message has already in the queue:

a. OSS_MESSAGE_TYPE

b. OSS_MESSAGE_NAME

c. ILEC_TROUBLETICKET_NUMBER

4. If a trouble ticket already has its corresponding query message in theXVTMessageQueue, ignore it. Otherwise, construct agetTroubleTicketByKeyRequest message with pre-defined attribute set and send itto the XVTMessageQueue.

When the request gets into the XVTMessageQueue, it queries the ILEC system, and waitfor return. When return comes, it updates our local database. The work after the messagegets into the queue will be carried out by the ILEC gateway system, JVTEventMDBmessage-driven bean.

v1.1.2 33

With this timer service, all information in Covad database are synchronized with ILECdatabase regularly, so subsequent queries can just read Covad database, and have almostup to date information.

v1.1.2 34

7 ILEC TROUBLE TICKET GATEWAY IMPLEMENTATIONThe ILEC Trouble Ticket Gateway interacts with both Covad trouble ticket system andILEC trouble ticket system. The interactions with Covad trouble ticket system are throughJMS for the message consuming and producing. The interactions with ILEC trouble ticketsystem are through CMIP. Beside the normal CMIP request/response with ILEC systems,the gateway will also receive event notifications initiated by ILEC trouble ticket systems.

7.1 Standard T1M1 to OSS/J MappingOSS/J defines 49 attributes, while T1M1 defines 95 attributes for trouble ticket. Here isthe mapping between the fields defined by these two standards. Not all attributes definedby T1M1 will be used here. Not all the attributes have the natural mapping here either.We use bold and italic fields to highlight the name difference:

T1M1 OSS/JactivityDuration activityDurationListalarmRecordPtrList relatedAlarmListadditionalTroubleInfoList additionalTroubleInfoListcloseOutNarr closeOutNarrreceivedTime receivedTimerepairActivityList repairActivityListrestoredTime restoredTimetroubleClearancePerson clearancePersontroubleFound troubleFoundtroubleLocation troubleLocationtroubleReportNumberList troubleNumListManagedObjectInstance troubledObjecttroubleType troubleTypetroubleReportState troubleStatetroubleReportStatus troubleStatustroubleReportStatusTime troubleStatusTimeafterHrsRepairAuth afterHoursRepairAuthorityauthorizationList authorizationListcancelRequestByManager cancelRequestedByCustomercloseOutVerification closeOutVerificationcommitmentTime commitmentTimecommitmentTimeRequest commitmentTimeRequestedcustTroubleTickNum customerTroubleNumDialog dialogescalationList escalationListinitiatingMode initiatingModelastUpdateTime lastUpdateTimemaintServiceCharge maintServiceChargeoutageDuration outageDurationperceivedTroubleSeverity perceivedTroubleSeverity

v1.1.2 35

preferredPriority preferredPriorityrepeatReport repeatReportsuspectObjectList suspectObjectListtroubleDetectionTime troubleDetectionTimemanagedObjectAcessFromTime troubledObjectAccessFromTimemanagedObjectAccessHours troubledObjectAccessHoursListmanagedObjectAccessToTime troubledObjectAccessToTime

This mapping should be used in two ways. It tells where to find value for CMIP attributeswhen we construct a CMIP message, it also indicates where to find value whenconstructing OSS/J objects from CMIP messages.

7.2 ILEC Specific PropertyHere is the list of attribute values we need to specify for each ILEC:

1. TroubleReportFormatObjectPtr

2. TroubleReportStatusWindow

3. ILEC networkId

4. Covad’s account name under ILEC

5. Covad’s service Id under ILEC

7.3 ILEC Specific Mapping FileT1M1 Standard defines the sets of values for trouble status, trouble found, trouble typeand trouble state, but ILEC may have its own set of values (SBC is an example). We canonly store values for these fields according to the standard. When we receive messagesfrom ILEC systems, these values will be ILEC proprietary values. We need to map themto the standard values before pass them to the queue or topic.

The mapping can be obtained from the Joint Integration Agreement document withILECs.

7.4 ILEC Specific Communication PropertyThe communication piece with ILEC is implemented through 3rd party product: Monfox’sDynamic TMN. There are two properties files used by the Dynamic TMN.

1. The naming service property file: this file specifies the protocol initiationparameters, which includes the pointer to the actual protocol property file, theselectors for the presentation layer, session layer, and application layer of the OSIprotocol stack.

2. The protocol property file: this file specifies the CMIP user information,functional unit information, and a file pointer to the security key file.

3. The security key file.

v1.1.2 36

7.5 Consume Messages from Covad Trouble Ticket SystemGateway needs to create a message receiver. This receiver has the following properties:

1. It will asynchronously receive the XML message from XVTMessageQueue.

2. The session to the queue is non-transactional.

3. The acknowledge mode is AUTO_ACKNOWLEDGE

The following is the complete list of message types it needs to handle:

1. createTroubleTicketByValueRequest

2. cancelTroubleTicketsByTemplateRequest

3. closeTroubleTicketsByTemplateRequest

4. escalateTroubleTicketsByTemplateRequest

5. setTroubleTicketByValueRequest

6. getTroubleTicketByKeyRequest

Upon receiving these messages, we need to de-serialize them into Java objects such thatall the attribute values can be easily retrieved, and then construct the CMIP message, anduse Monfox’s MOHandle to send out the message.

7.6 Receive Responses from ILEC Trouble Ticket SystemGateway needs to have one sender for XVTMessageReplyQueue, one subscriber forJVTEventTopic. The following is the complete list of what it will receive and how to dealwith it.

Request Response Action

v1.1.2 37

createTroubleTicket

ByValueRequest

CreateConfirmation 1. ConstructcreateTroubleTicketByValueResponse XML message. Using the returnvalue of TroubleReportID as theprimary key for the troubleTicketKeyto return.

2. Construct TroubleTicketCreateEvent.

3. SendcreateTroubleTicketByValueResponse message toXVTMessageReplyQueue

4. Publish theTroubleTicketCreateEvent toJVTEvnetTopic

PerformException From the error code, determine if it is asystem error. If it is an application error, dothe same as ValueException, otherwise, justlog the exception, and throw the exception

ValueException This is application error. Do the following:

1. ConstructcreateTroubleTicketByValueException XML message.

2. Log the exception.

3. Send the constructed message toXVTMessageReplyQueue

v1.1.2 38

cancelTroubleTickets

ByTemplateRequest

SetConfirmation 1. ConstructcancelTroubleTicketsByTemplateResponse XML message.

2. ConstructTroubleTicketCancellationEvent.

3. SendcancelTroubleTicketsByTemplateResponse to XVTMessageReplyQueue

4. PublishTroubleTicketCancellationEvent toJVTEventTopic

PerformException From the error code, determine if it is asystem error. If it is an application error, dothe same as ValueException, otherwise, justlog the exception and throw the exception


1. ConstructcancelTroubleTicketsByTemplateException XML message.

2. Log the exception.


closeTroubleTickets

ByTemplateRequest

SetConfirmation 1. ConstructcloseTroubleTicketsByTemplateResponse XML message.

2. ConstructTroubleTicketCloseOutEvent.


4. Publish TroubleTicketCloseOutEventto JVTEventTopic.

PerformException From the error code, determine if it is asystem error. If it is an application error, dothe same as ValueException, otherwise, justlog the exception, and throw the exception


1. ConstructcloseTroubleTicketsByTemplateException XML message.

2. Log the exception


v1.1.2 39

escalateTroubleTickets

ByTemplateRequest

SetConfirmation 1. ConstructescalateTroubleTicketsByTemplateResponse XML message.

2. ConstructtroubleTicketAttributeValueChangeEvent.

3. SendescalateTroubleTicketsByTemplateResonse to XVTMessageReplyQueue

4. PublishtroubleTicketAttributeValueChangeEvent to JVTEventTopic.



1. ConstructescalateTroubleTicketsByTemplateException XML message.



v1.1.2 40

setTroubleTicket

ByValueRequest

SetConfirmation 1. ConstructsetTroubleTicketByValueResponseXML message.

2. ConstructtroubleTicketAttributeValueChangeEvent.

3. SendsetTroubleTicketByValueResponsemessage to XVTMessageReplyQueue

4. PublishtroubleTicketAttributeValueChangeEvent to JVTEventTopic.



1. ConstructsetTroubleTicketsByTemplateException XML message.



getTroubleTicket

ByKeyRequest

GetConfirmation 1. ConstructgetTroubleTicketByKeyResponseXML message.


PerformException Just log the exception.ValueException Just log the exception

7.7 Receive Event Notifications from ILEC Trouble Ticket SystemWe need to create a new publisher for publishing events to JVTEventTopic.

Monfox’s Dynamic TMN reports event notification as MOHandleEvent. Based on thisevent object, we can obtain the event type, and all the relevant attribute names and values.Two steps need to be performed here:

1. Sent confirmation back to ILEC system for the notification.

2. Based on the event type, and attribute name and value, construct one of the Eventobject, and publish to JVTEventTopic.

a. TroubleTicketAttributeValueChangeEvent

v1.1.2 41

b. TroubleTicketCloseOutEvent

c. TroubleTicketCancellationEvent

d. TroubleTicketCreateEvent

e. TroubleTicketStatusChangeEvent

f. TroubleTicketAttributeValueChangeEvent

When we construct these event, we need to apply the ILEC specific trouble type,trouble status, trouble found, trouble state mapping.

3. Publish the event to JVTEventTopic.

v1.1.2 42

8 USE CASE REALIZATIONWith all the preparation we had, the use case realization is simple.

8.1 Create a Trouble Ticket

8.1.1 Technician’s Interactions with TT-Application

1. Technician interacts with TT-Application prepare the following information:

1) Trouble Object Identifier

2) Trouble Type

3) Additional Trouble Info

4) Covad Trouble Ticket Number

5) Covad Contact Person Information

6) Trouble Location Information

7) Trouble Ticket Authorization Information

8) ILEC Name

9) Trouble Ticket Escalation Information

10) Commitment Time Requested

11) Repeat Report

12) Trouble Detection Time

13) Perceived Trouble Severity

14) Preferred Priority

2. Technician submits the trouble ticket creation request using TT-Application.

3. Technician is informed that the request has been forwarded to ILEC forprocessing.

8.1.2 Sequence Diagram

The following sequence diagram illustrates the technician’s interaction with TT-Application.

v1.1.2 43

JVTTroubleTicketSessionBean XVTMessageQueueTT-Application (GUI): Technician

return null7:

input parameter validation4:

xmlSerialize.toXml( troubleTicketValue )5:

send createTroubleTicketByValueRequest6:

createTroubleTicketByValue( troubleTicketValue )3:

prepare trouble ticket value1:

send request2:

return 8:

8.1.3 What Happens behind the Scene

The following sequence diagram illustrates what happens behind the scene for asuccessful trouble ticket creation.

v1.1.2 44

ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueueXVTMessageQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database

xmlSerializer.fromXml( createTroubleTicketByValueRequest )2:

setStage3:

CreateConfirmation = performCreate(): send CMIP message4:

send( createTroubleTicketByValueResponse )5:

publish( troubleTicketCreateEvent )6:

onMessage( createTroubleTicketByValueResponse )7:

onMessage( createTroubleTicketByValueRequest )1:

onMessage( troubleTicketCreateEvent )8:

persist data9:

persist data10:

8.2 Query a Trouble Ticket Status/Information

8.2.1 Technician’s Interaction with TT-Application

1. Technician enters either Covad trouble ticket number or ILEC trouble ticketnumber for querying a trouble ticket information.

2. Technician submits the request.

3. Information regarding this trouble ticket is presented to the Technician.


The following sequence diagram illustrates the interaction:

v1.1.2 45

JVTTroubleTicketSessionBean: Technician TT-APP (GUI) Database

return data4:

retrieve data3:

search trouble ticket1:

display data5:

getTroubleTicketsByTemplate( troubleTicketValue, attrNames )2:

8.3 Cancel a Trouble Ticket


1. The Technician prepares the following information:

a. ILEC Trouble Ticket Number

b. Trouble Clearance Person Information

c. Close out Narratives

2. Technician submits the trouble ticket cancellation request using TT-Application.



The following sequence diagram illustrates technician’s interaction with TT-Application.

v1.1.2 46


send cancelTroubleTicketsByTemplateRequest5:


cancelTroubleTicketsByTemplate( troubleTicketValue, ... )3:

send request2:

prepare trouble ticket cancellation1:


The following sequence diagram illustrates what happens behind the scene for asuccessful trouble ticket cancellation.

v1.1.2 47

ILEC Trouble Ticket SystemILEC Troble Ticket Gateway XVTMessageReplyQueueXVTMessageQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database

xmlSerializer.fromXml( cancelTroubleTicketsByTemplateRequest )2:

setStage3:

setConfirmation = performSet(): send CMIP message4:

send ( cancelTroubleTicketsByTemplateResponse )5:

publish ( troubleTicketCancellationEvent )6:

onMessage( cancelTroubleTicketsByTemplateResponse )7:

onMessage( troubleTicketCancellationEvent )8:

onMessage( cancelTroubleTicketsByTemplateRequest )1:

persist data9:

persist data10:

8.4 View a Trouble Ticket History


1. Technician enters ILCE trouble ticket number for viewing a trouble ticket history.


3. TT-Application displays the history.


The following sequence diagram illustrates the successful execution scenario:

v1.1.2 48

JVTTroubleTicketSessionBean: Technician TT-APP (GUI) Database

retrieve data3:

view trouble ticket history based on ILEC trouble ticket number1:

return 5:

queryTroubleTickets( QueryTroubleTicketHistoryValue, attrNames )2:

return 4:

8.5 Escalate a Trouble Ticket

8.5.1 Technician’s Interactions with TT-Application

1. Technician prepares the following information:

a. Escalation Level

b. Escalation Person Id

c. Request State

d. Request Person Id

e. Additional Trouble Info for the Escalation Reason

2. Technician submits the escalation request using TT-Application.



The following sequence diagram illustrates the interaction.

v1.1.2 49


return 6:

send escalationTroubleTicketsByTemplateRequest5:

xmlSerialize.toXml( troubleTicketValue, escalationList )4:

escalateTroubleTicketsByTemplate( troubleTicketValue, escalationList )3:

send request2:

return 7:

prepare escalation info1:


The following sequence diagram illustrates what happens behind the scene for asuccessful trouble ticket escalation.

v1.1.2 50


xmlSerializer.fromXml( escalateTroubleTicketsByTemplateRequest )2:

setStage3:

setConfirmation=performSet(): send CMIP message4:

send ( escalateTroubleTicketsByTemplateResponse )5:

publish ( troubleTicketAttributeValueChangeEvent )6:

onMessage( escalateTroubleTicketsByTemplateResponse )7:

onMessage( troubleTicketAttributeValueChangeEvent )8:

onMessage( escalateTroubleTicketsByTemplateRequest )1:

persist data9:

persist data10:

8.6 Modify a Trouble Ticket


1. Technician enters new values to the following attributes:

a. Trouble Location Information

b. Trouble Authorization Information

c. Trouble Object Access Hour Information

d. Covad Contact Person

e. Commitment Time Requested

f. Perceived Trouble Severity

g. Preferred Priority

2. Technician submits the change.

v1.1.2 51

3. Technician is informed that the change request has been forwarded to ILEC forprocessing.


The following sequence diagram illustrates the interaction.


return 6:

send setTroubleTicketByValueRequest5:


setTroubleTicketByValue( troubleTicketValue )3:

send request2:

return 7:



The following sequence diagram illustrates what happens behind the scene for asuccessful trouble ticket modification.

v1.1.2 52


xmlSerializer.fromXml( setTroubleTicketByValueRequest )2:

setStage3:

SetConfirmation = performSet() : send CMIP message4:

send setTroubleTicketByValueResponse5:

publish TroubleTicketAttributeValueChangeEvent6:

onMessage( setTroubleTicketByValueResponse )7:

onMessage( setTroubleTicketByValueRequest )1:

onMessage( TroubleTicketAttributeValueChangeEvent )8:

persist data9:

persist data10:

8.7 Verify Repair Completion/Close a Trouble TicketThis use case only applies after an ILEC has repaired the trouble and changes the troublereport status attribute value to “clearedAwaitingCustVerification”.


1. Technician reviews the Trouble Found field, and close out narrative field providedby ILEC.

2. Technician set the Trouble Clearance Person Information.

3. Technician determines if the trouble has been fixed. If it is fixed, set the close outverification to “verified”, otherwise set the close out verification to “denied”.



v1.1.2 53


The following sequence diagram illustrates the close a trouble ticket scenario.


return 6:

send closeTroubleTicketsByTemplateRequest5:


closeTroubleTicketsByTemplate( troubleTicketValue, status, closeOutNarr )3:

send request2:

return 7:



The following sequence diagram illustrates what happens behind the scene for asuccessful trouble ticket close out.

v1.1.2 54


xmlSerializer.fromXml( closeTroubleTicketsByTemplateRequest )2:

setStage3:

SetConfirmation = performSet() : send CMIP message4:

send closeTroubleTicketsByTemplateResponse5:

publish TroubleTicketCloseOutEvent6:

onMessage( setTroubleTicketsByTemplateResponse )7:

onMessage( closeTroubleTicketsByTemplateRequest )1:

onMessage( TroubleTicketCloseOutEvent )8:

persist data9:

persist data10:

v1.1.2 55

9 IMPACTS ON EXISTING SYSTEMImpacts occur in two places:

1. TT-Application (GUI): we need to add screens for ILEC trouble ticketinteractions. The screens should cover all the use cases.

2. TT-Browser: changes are corresponding to the changes in the TT-Application.

3. The Timer Task used for closing a Covad trouble ticket needs to be modified tocheck ILEC trouble ticket state stored in the TT_ILECINFO table. If the state isclosed, the corresponding Covad trouble ticket may need to change its state/statustoo.

v1.1.2 56

ebonding architecture

Documents