Electronic Bonding Architecture Document

Transcription

1 Electronic Bonding with ILEC Electronic Bonding Architecture Document v

2 Revision History Date Revision Author Comment Number 09/12/ Covad Architecture Initial Draft 09/19/ Covad Architecture Add more details 09/25/ Covad Architecture More Details for OSS/J Implementation 09/30/ Covad Architecture Address the MTTR issue 10/03/ Covad Architecture Changes according to design review 10/29/ Covad Architecture More Details on the schema design section 11/13/ Covad Architecture Changes on local entity bean description 12/10/ Covad Architecture 1. Change message acknowledge mode 2. For ILEC trouble ticket creation, creates a record in TT_ILECINFO with Covad related information before sends message v

3 Table of Contents 1INTRODUCTION...5 2INDUSTRY STANDARDS T1M1 STANDARD OSS/J OSS/J VS T1M1 STANDARD...7 3THE EXISITING COVAD TROUBLE TICKET SYSTEM...9 4THE NEW COVAD TROUBLE TICKET SYSTEM DEPLOYMENT VIEW: THE BIG PICTURE NOTES ON THE DEPLOYMENT VIEW DESIGN RATIONALE EMPHASIS ON COVAD MTTR OVERVIEW OF NEW EJB COMPONENTS OVERVIEW OF JMS QUEUE/TOPIC COMPONENTS OVERVIEW OF THE TIMER SERVICE OVERVIEW OF ILEC TROUBLE TICKET GATEWAY SECURITY SCALABILITY PERFORMANCE MANAGEABILITY TRANSACTION DATA MODEL THREE MAIN TABLES SUPPORTING TABLES OSS/J IMPLEMENTATION THE JVTTROUBLETICKETSESSION INTERFACE EXTENDING OSS/J: THE QUERYTROUBLETICKETHISTORYVALUE INTERFACE THE XMLSERIALIZER INTERFACE THE TROUBLETICKETKEY INTERFACE OTHER SUPPORTING INTERFACES THE REQUIRED FIELD PROPERTY FILE OSS/J ATTRIBUTES TO DATABASE FIELD/TABLE MAPPING JVTTROUBLETICKETSESSIONBEAN IMPLEMENTATION XVTREPLYMDB IMPLEMENTATION JVTEVENTMDB IMPLEMENTATION TROUBLETICKETTIMERSERVICE IMPLEMENTATION Configuration File for the Timer Service The Procedures for the Timer Service v

4 7ILEC TROUBLE TICKET GATEWAY IMPLEMENTATION STANDARD T1M1 TO OSS/J MAPPING ILEC SPECIFIC PROPERTY ILEC SPECIFIC MAPPING FILE ILEC SPECIFIC COMMUNICATION PROPERTY CONSUME MESSAGES FROM COVAD TROUBLE TICKET SYSTEM RECEIVE RESPONSES FROM ILEC TROUBLE TICKET SYSTEM RECEIVE EVENT NOTIFICATIONS FROM ILEC TROUBLE TICKET SYSTEM USE CASE REALIZATION CREATE A TROUBLE TICKET Technician s Interactions with TT-Application Sequence Diagram What Happens behind the Scene QUERY A TROUBLE TICKET STATUS/INFORMATION Technician s Interaction with TT-Application Sequence Diagram CANCEL A TROUBLE TICKET Technician s Interaction with TT-Application Sequence Diagram What Happens behind the Scene VIEW A TROUBLE TICKET HISTORY Technician s Interaction with TT-Application Sequence Diagram ESCALATE A TROUBLE TICKET Technician s Interactions with TT-Application Sequence Diagram What Happens behind the Scene MODIFY A TROUBLE TICKET Technician s Interaction with TT-Application Sequence Diagram What Happens behind the Scene VERIFY REPAIR COMPLETION/CLOSE A TROUBLE TICKET Technician s Interaction with TT-Application Sequence Diagram What Happens behind the Scene IMPACTS ON EXISTING SYSTEM v

5 1 INTRODUCTION This architecture document addresses the issues regarding electronically bonding Covad with 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 system is taken down for maintenance, no action towards ILEC trouble ticket system is possible. This design addresses all these problems. Reference Document 1. Use case document: Electronic bonding use case document: by Alex Leong 2. T1M1 Standards: 3. OSS/J Specification: v

6 2 INDUSTRY STANDARDS 2.1 T1M1 Standard The Standard Committee T1-Telecommunications has a series of standards that specify interface requirements between Operation Systems across jurisdictional boundaries. One of the standards is regarding trouble administration. This trouble administration standard defines trouble administration functions between two TMNs (Telecommunication Management Network), trouble ticket attributes, and object 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 definitions are described using ASN.1. The object classes are defined in GDMO (Guidelines for the Definition of Managed Objects). For more information, please refer the standard documents. v

7 2.2 OSS/J OSS/J stands for OSS through Java Initiative, an initiative started by a working group of industry leaders including Sun Microsystems, BEA, IBM Business Consulting Services, MetaSolv, Nokia, Motorola, Nortel, NEC, etc to define and implement an open standard set of APIs using Java technology for Operations Support Systems (OSS) and Business Support Systems (BSS). OSS/J covers many OSS areas including: trouble ticket, customer management, order management, 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 for XML event, JVTEventTopic for Java Event Object. The OSS/J trouble ticket API is finalized in February, For more information regarding OSS/J, go to: OSS/J vs T1M1 Standard There has been a slow acceptance of the use T1M1 standards as an implementation technology 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 OO programming languages. The object-oriented information models defined by CMIP, GDMO, and ASN.1 do not map easily into object-oriented programming languages 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 by manager, what attributes are provided by agent. OSS/J trouble ticket API specification does not address this issue at all. 2. Although it captures the most important part of T1M1, there are some mandatory information missing from OSS/J specification, like the following two attributes: a. TroubleReportFormatObjectPtr b. TroubleReportStatusWindow These two attributes are required for the trouble administration communication with ILECs. 3. It does not address history/log issue. v

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

9 3 THE EXISITING COVAD TROUBLE TICKET SYSTEM TT-Application (GUI) Covad Trouble Ticket System TT-Application (GUI) t3 TT-System t3 CFI CFI t3/glue TT-WFM JDBC OSSO : Database TT TT-CFI FMS t3/glue FMS Current Covad trouble ticket system allows its users to create, view, update, and track trouble ticket within Covad systems. When a trouble ticket involves ILECs, manual process is needed to resolve issues with ILECs. v

10 4 THE NEW COVAD TROUBLE TICKET SYSTEM 4.1 Deployment View: the Big Picture CFI CFI t3/glue TT-CFI Covad Trouble Ticket System TT-WFM t3/glue TT-System FMS FMS JVTTroubleTicketSessionBean ILEC Trouble Ticket TroubleTicketTimerService TroubleTicketLocalEntityBean TT-Application (GUI) TT-Application (GUI) t3 t3/glue SbcXVTReplyMDB SbcJVTEventMDB VerizonJVTEventMDB VerizonXVTReplyMDB JMS SbcXVTMessageQueue Weblogic JMS Server VerizonXVTMessageQueue OSSO : Database SbcXVTMessageReplyQueue VerizonXVTMessageReplyQueue TT ILEC_TT SbcJVTEventTopic VerizonJVTEventTopic ILEC_TT_MSG Firewall JMS JMS SBC Trouble Ticket Gateway Verizon Trouble Ticket Gateway MessageReceiver MessageSender MessagePublisher MessageReceiver MessagePublisher MessageSender Ossj2SbcConverter Sbc2OssjConverter Ossj2VerizonConverter Verizon2OssjConverter Monfox.MOHandle Monfox.MOHandle CMIP CMIP SBC Trouble Ticket System SBC Verizon Trouble Ticket System Verizon v

11 4.2 Notes on the Deployment View The ILEC Trouble Ticket component contains one session bean, two message driven beans, and several local entity beans (only the trouble ticket local entity bean shown in the deployment view). When we use Weblogic Application server, the Weblogic JMS server is part of the Application server. So these beans and the queues, one topic will be running in one JVM. Although different nodes are shown for different gateway for ILECs, these gateways can run on the same machine. 4.3 Design Rationale The current design is based on the following rationales. 1. OSS/J, instead of T1M1 standard, is the right technology to go with. Since ILECs are using T1M1 standards, we will use both OSS/J and T1M1 standard, but T1M1 is used behind OSS/J. 2. We will not fully implement OSS/J specification. We only implement the part necessary for this project. 3. To avoid tightly coupled with ILEC trouble ticket system, we introduce a JMS server in the middle. This JMS server also shields Covad trouble ticket system from the ILEC trouble ticket maintenance schedule. 4. To achieve isolation for ILEC (such as changes for one ILEC should not affect communication with other ILEC), each gateway runs on its on JVM, i.e. different gateways run on different JVMs. The other benefits are that gateway is more scalable and robust. 5. Only TAC can create ILEC trouble ticket through TT GUI. 4.4 Emphasis on Covad MTTR Currently Covad creates total around 320 trouble tickets for all ILECs per day, one JMS server with two queues and one topic should be able to handle this load. To minimize Covad MTTR, 1. We introduce one message queue, one message reply queue, and one event topic for each master ILEC (like SBC, Verizon, etc., not for baby ILEC like AmeriTech). This not only increases the processing speed, but prevents messages designated for the ILEC, which is not on line, from blocking messages designated for other ILECs. 2. The trouble ticket creation request message will be have higher priority than other request 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 be enough. Based on the following reasons, we decide separate the message reply queue and event topic for different ILECs. v

12 1. To maintain the event order, we need to set the message driven bean instance pool size to 1. Event order sometimes is important, considering two update messages/events, we want the database updates in right order. 2. Because the pool size is 1, we cannot take advantage of instance pool. The MDBs could be the trouble ticket processing bottleneck. 4.5 Overview of New EJB Components 1. Session Bean JVTTroubleTicketSessionBean: The bean implements all the business functions defined in JVTTroubleTicketSession interface of OSS/J trouble 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 all messages (XML messages) from XVTMessageReplyQueue. Messages are either the 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 all messages (Java Object messages) from JVTEventTopic. Messages are those notification 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 the data model section. CMP together with cmr fields should be used for these entity beans. v

13 4.6 Overview of JMS Queue/Topic Components In the JMS server, we will have one message queue per ILEC, and one message reply queue, one topic for all ILECs. 1. XVTMessageQueue: this queue is for all XML request messages to ILEC trouble ticket System. 2. XVTMessageReplyQueue: this queue is for XML response/exception messages from ILEC trouble ticket system. 3. JVTEventTopic: this is for Java notification message from ILEC trouble ticket system. 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, like createtroubleticketbyvaluerequest. 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 following properties: 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 Service The 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 to XVTMessageQueue to query ILEC trouble ticket systems for the latest trouble ticket information. The returned information is used to update the Covad database. By using this timer service, Covad database has almost real time information about ILEC trouble tickets created by Covad. More details in the later section. 4.8 Overview of ILEC Trouble Ticket Gateway The gateway process accomplishes the following: v

14 1. Receive XML messages from XVTMessageQueue. 2. Convert between OSS/J XML message and ILEC required values. 3. Use 3 rd party library to send and receive CMIP data. 4. Generate TroubleTicketKey for successful creation request. 5. Publish XML messages to XVTMessageReplyQueue and Java Event to JVTEventTopic. 6. Receive ILEC event notifications. In the deployment diagram, we use MessageReceiver, MessageSender, MessagePublisher, Ossj2IlecConverter, Ilec2OssjConverter, and MOHandle class to illustrate the steps needed in the gateway. In the actual implementation, you may not have exactly the same classes. The ILEC trouble ticket gateway system is an independent Java process. 4.9 Security There 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 T1M1 standard, using encryption. We only need to configure the 3 rd party product (Monfox), store the encryption key in proper location, Monfox s library will handle the secure handshaking with ILECs Scalability Current design should be more than enough for the current load, and even modest increase of the load. If load increases dramatically, we can scale beans, queues, and topics side by clustering Weblogic server. On the gateway size, we can bring up more instances, and divide the loads among these instances, like one instance only dealing with trouble ticket creation, etc. This can be easily done through JMS s message selector mechanism Performance OSS/J defines queues for XML message, topics for both XML messages and Java object message, but does not define Java message for queues. To confirm with this standard, we need to serialize the Java object into XML message, and later on need to parse this XML message to retrieve data out, which essentially is to deserialize the XML message. Although all these operations are performed in memory, it does have performance penalty. However we do not believe the penalty is high. v

15 If the performance is an issue, we could use Java object message instead of XML message, use a new queue for Java object message to replace the current XML message queue. Current design to use Java object message rather than XML message for the notification is mainly due to performance consideration Manageability The ILEC Trouble Ticket Gateway is implemented as a standalone Java process. There are concerns regarding these gateways: 1. How do we monitor them? 2. These gateways are not built on top on some type of platform. Examples of platforms are: J2EE, CORBA, etc. These are good concerns. But the key functionality of the gateway is to communicate ILEC trouble ticket system through CMIP protocol, which makes the gateway impossible to 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, statistic info, and notification support. 2. Write a simple console as the management application, for example, a simple Web client. By doing this, you can achieve the following. 1. All the gateways are built on JMX s Distributed/Agent/Instrumentation layer framework. 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 MBean implementation, the protocol adapter in the distributed layer is also needed to be implemented although Sun Microsystem does have a reference implementation which provides a HTML adapter. The other way is to use J2EE connector architecture. The new JCA 1.5 defines a new set of system-level contracts between an application server and enterprise information system. They include: lifecycle management contract, work management contract, etc. These new contracts make the resource adapters manageable through application administration console. The current JCA 1.5 is in proposed final draft 2 stage. The implementation 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 JCA approach could be taken for the future enhancements. v

16 4.13 Transaction Whenever a persist JMS message is involved in a transaction, this transaction will almost involves multiple database writes. These writes are across different schemas, but in our case, these schemas reside in the same database. Even with this situation, there are concerns about the transaction being a distributed transaction. Based on the following reasons, we still make JVTTroubleTicketSessionBean and message-driven beans transactional: 1. We don t want to introduce our own mechanism to handle multiple database writes 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 other distributed transactions we have seen in the past. It is not truly distributed as all the database writes occur in the same database (but different schemas). Weblogic server should be able to handle these simple cases. However, for the sessions used in the ILEC trouble ticket Gateway systems, they are nontransactional because the actual communications with ILEC could be time-consuming. We may need some manual processes to resolve some data issues. v

17 5 DATA MODEL We need to store ILEC trouble ticket information in Covad database and keep the activity history around a trouble ticket. Although currently we do model ILEC trouble ticket information in our database, the current one is not good enough. Note: the following table structure does not show the primary key field, nor the audit fields. 5.1 Three Main Tables TT_ILECINFO: this is an existing table. New attributes are added into this table to store ebonding 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_HISTORY should contain the following ebonding attributes: Field Name Type Notes Using Ebonding Flag Varchar2(1) Y/N Troubled Object Identifier Varchar2(40) Can be carrier circuit number or telephone number Trouble Type ID Number Enum Additional Trouble Info Varchar2(512) Standard requires minimum 256 Covad Trouble Ticket Num Number Covad Contact Person ID Number FK ILEC 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 Enum Trouble Status ID Number Enum Trouble Status Time Date Additional Trouble Status Info Varchar2(512) Trouble Found ID Number Enum ILEC Contact Person ID Number FK Cancel Requested By Covad Flag Varchar2(1) Close Out Narrative Varchar2(256) Close Out Verification ID Number Enum Maintain Service Charge Varchar2(1) Covad TT Clearance Person Id Number FK Commitment Time Date Already exists (ILEC_COMMIT_TIME) v

18 Outage Years Number Outage Months Number Outage Days Number Outage Hours Number Outage Minutes Number Outage Seconds Number Commitment Time Requested Date Initiating Mode ID Number Enum Trouble Detection Time Date Perceived Trouble Severity ID Number Enum Preferred Priority ID Number Enum Repeat Report ID Number Enum Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_TT_COVAD_WORKLOG should contain the following fields: Field Name Type Notes Ebond TT Covad Worklog ID Number(10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK to TT_ILECINFO table. Covad Trouble Ticket Num Number ILEC Trouble Ticket Num Varchar2(40) Operation Name Varchar2(30) Operation Attribute Value Varchar2 (2048) Operation Status Varchar2(1) Success/Fail/Queued Operation Error Message Varchar2 (256) Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column 5.2 Supporting Tables EBOND_LOOKUP: this ENUM table stores all the ebonding enum lookup values: Fields Type Notes Type Varchar2(30) PK Ebond Lookup ID Number(10) PK Value Varchar2(50) Status Varchar2(8) ACTIVE/INACTIVE Date Created Date Audit Column Created By Varchar2(30) Audit Column v

19 Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_ILEC_PERSON_REACH: this table stores the ILEC person s contact information. It should contain the following fields: Fields Type Notes Ebond Ilec Person Reach ID Number(10) PK. Oracle Sequence. Varchar2(40) +Name Business Key Name Varchar2(40) +Name Business Key Organization 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 Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_COVAD_SUPPORT_CONTACT: this table stores the COVAD support contact information. It should contain the following fields: Fields Type Notes Ebond Covad Support Contact ID PK. Oracle Sequence. Parent Carrier ID Number(10) FK Covad Support Dist List Varchar2(100) Covad Support Phone Number Varchar2(20) Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_COVAD_PERSON_REACH: this table stores the COVAD person s contact information. It should contain the following fields: Fields Type Notes Ebond Covad Person Reach ID PK. Oracle Sequence. Ebond Covad Support Contact ID Number(10) FK Covad OSS TT Login Varchar2(32) Name Varchar2(40) v

20 Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_TT_AUTHORIZATION: this table stores whether authorization is requested by ILEC and granted by Covad. It should contain the following fields: Fields Type Notes Ebond TT Authorization ID Number(10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK Activity Type id Number(10) enum Covad Authorization Person ID Number FK Authorization Time Date Request State ID Number enum (requested, provided, denied) Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_TT_ESCALATION: this table stores what escalation has happened to one trouble ticket. It should contain the following fields: Fields Type Notes Ebond TT Escalation ID Number(10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK ILEC Escalation Person ID Number FK Escalation Time Date Escalation Level ID Number enum Covad Request Person ID Number FK Request State ID Number enum Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_TT_ACTIVITY_DURATION: this table stores duration for all the activities associated with a trouble ticket. It should contain the following fields. Fields Type Notes Ebond TT Activity Duration ID Number(10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK Activity Type ID Number enum Billable Flag Varchar2(1) Y/N Duration In Years Number v

21 Duration In Months Number Duration In Days Number Duration In Hours Number Duration In Minutes Number Duration In Seconds Number Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column EBOND_TT_ACCESS_HOUR: this table stores the access hours for the troubled object and for the troubled location. It should contain the following fields: Fields Type Notes Ebond TT Access Hour ID Number (10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK Day of Week Number Look up value (Sunday,, Saturday) Begin Hour Number Begin Minute Number Begin Second Number End Hour Number End Minute Number End Second Number Troubled Type ID Number enum (Location or Object) Date Created Date Audit Column Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column Note for a given day of week, you can have a list of begin time and end time. We could break the above table into two for database normalization. EBOND_TT_ACCESS_LOCATION: this table stores the trouble location information. It should contain the following fields. Fields Type Notes Ebond TT Access Loaction ID Number(10) PK. Oracle Sequence. ILEC_INCIDENT_ID Number FK Premise 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 v

22 Created By Varchar2(30) Audit Column Date Modified Date Audit Column Modified By Varchar2(30) Audit Column v

23 6 OSS/J IMPLEMENTATION OSS/J trouble ticket API is just a specification. This specification defines everything in terms of interfaces. We need to have our own implementation. Fortunately we only need to implement part of the OSS/j, and there is a reference implementation available for free download. 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 Interface OSS/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: Best Effect and Atomic Bulk. Precisely, the JVTTroubleTicketSession interface is: v

24 JVTTroubleTicketSession +canceltroubleticketbykey( troubleticketkey : TroubleTicketKey, i : int, s : String ) : void +canceltroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : void +canceltroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String ) : void +canceltroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String ) : void +closetroubleticketbykey( troubleticketkey : TroubleTicketKey, i : int, s : String ) : void +closetroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : void +closetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String ) : void +closetroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String ) : void +createtroubleticketbyvalue( troubleticketvalue : TroubleTicketValue ) : TroubleTicketKey +createtroubleticketsbyvalues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKey[] +escalatetroubleticketbykey( troubleticketkey : TroubleTicketKey, escalationlist : EscalationList ) : void +escalatetroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], escalationlist : EscalationList ) : void +escalatetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, escalationlist : EscalationList ) : void +escalatetroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], escalationlist : EscalationList ) : void +gettroubleticketbykey( troubleticketkey : TroubleTicketKey, as : String[] ) : TroubleTicketValue +gettroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], as : String[] ) : TroubleTicketValue[] +gettroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, as : String[] ) : TroubleTicketValueIterator +gettroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], as : String[] ) : TroubleTicketValueIterator +maketroubleticketvalue( s : String ) : TroubleTicketValue +querytroubletickets( queryvalue : QueryValue, as : String[] ) : TroubleTicketValueIterator +settroubleticketbyvalue( troubleticketvalue : TroubleTicketValue, flag : boolean ) : void +settroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], troubleticketvalue : TroubleTicketValue ) : void +settroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, troubleticketvalue1 : TroubleTicketValue ) : void +settroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], troubleticketvalue : TroubleTicketValue ) : void +settroubleticketsbyvalues( atroubleticketvalue : TroubleTicketValue[], flag : boolean ) : void +trycanceltroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : TroubleTicketKeyResult[] +trycanceltroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator +trycanceltroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator +tryclosetroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], i : int, s : String ) : TroubleTicketKeyResult[] +tryclosetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator +tryclosetroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], i : int, s : String, flag : boolean ) : TroubleTicketKeyResultIterator +trycreatetroubleticketsbyvalues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKeyResult[] +tryescalatetroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], escalationlist : EscalationList ) : TroubleTicketKeyResult[] +tryescalatetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, escalationlist : EscalationList, flag : boolean ) : TroubleTicketKeyResultIterator +tryescalatetroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], escalationlist : EscalationList, flag : boolean ) : TroubleTicketKeyResultIterator +trysettroubleticketsbykeys( atroubleticketkey : TroubleTicketKey[], troubleticketvalue : TroubleTicketValue ) : TroubleTicketKeyResult[] +trysettroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, troubleticketvalue1 : TroubleTicketValue, flag : boolean ) : TroubleTicketKeyResultIterator +trysettroubleticketsbytemplates( atroubleticketvalue : TroubleTicketValue[], troubleticketvalue : TroubleTicketValue, flag : boolean ) : TroubleTicketKeyResultIterator +trysettroubleticketsbyvalues( atroubleticketvalue : TroubleTicketValue[], flag : boolean ) : TroubleTicketKeyResult[] Based on the use case document, we need only to support operations on a single trouble ticket. Here is the list of operations we need to implement. For the rest operations, we can just put empty function body. JVTTroubleTicketSessionBean +canceltroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, statue : int, closeoutnarr : String ) : void +closetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, status : int, closeoutnarr : String ) : void +createtroubleticketbyvalue( troubleticketvalue : TroubleTicketValue ) : TroubleTicketKey +escalatetroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, escalationlist : EscalationList ) : void +gettroubleticketsbytemplate( troubleticketvalue : TroubleTicketValue, attrnames : String[] ) : TroubleTicketValueIterator +querytroubletickets( queryvalue : QueryValue, attrnames : String[] ) : TroubleTicketValueIterator +settroubleticketbyvalue( troubleticketvalue : TroubleTicketValue, resyncrequired : boolean ) : void 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 for single trouble ticket: 1. canceltroubleticketbykey 2. closetroubleticketbykey 3. escalatetroubleticketbykey v

25 4. gettroubleticketbykey The reason is that these ByKey operation s parameters are too restrictive to prevent us to pass necessary information. For example, for the cancel trouble ticket case, the canceltroubleticketbykey does not have place for us to pass the trouble clearance person information, but with canceltroubleticketsbytemplate, we can pass this piece information in troubleticketvalue parameter. We need to make sure that the troubleticketvalue input parameter contains troubleticketkey for canceltroubleticketsbytemplate, closetroubleticketsbytemplate and escalatetroubleticketsbytemplate. So effectively, we still deal with single trouble ticket. 6.2 Extending OSS/J: the QueryTroubleTicketHistoryValue Interface OSS/J defines a base interface QueryValue for generic attribute accessor. OSS/J also defines QueryAllOpenTroubleTicketsValue, QueryByEscalationValue sub-interfaces. None of the existing interfaces can satisfy the need to query the history value for a trouble ticket. We define QueryTroubleTicketHistoryValue interface for this purpose. QueryValue QueryTroubleTicketHistoryValue +getcovadtroubleticketnumber() : int +gettroubleticketkey() : TroubleTicketKey +setcovadtroubleticketnumber( int ) : void +settroubleticketkey( troubleticketkey : TroubleTicketKey ) : void We will only support this interface in the querytroubletickets operation. 6.3 The XmlSerializer Interface This interface marshals and un-marshals a Java object to and from XML. XmlSerializer +fromxml(element : org.w3c.dom.element) : Object +toxml( object : Object, elementname : String ) : String This interface is relevant to us because we need to generate XML message from a trouble ticket value (Java object), and also the other way around. Both marshalling and unmarshalling should be done in conform to the XML schema defined by OSS/J. v

26 6.4 The TroubleTicketKey Interface ManagedEntityKey +getapplicationcontext() : ApplicationContext +getapplicationdn() : String +getprimarykey() : Object... TroubleTicketKey +gettroubleticketprimarykey() : String +settroubleticketprimarykey( s : String ) : void 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 of the application JNDI naming context. The application context is used to locate the application components in charge of the managed entity. Both application DN and application context are only interested to the calling application (like the TT-Application GUI). 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 two can be set to null. 6.5 Other Supporting Interfaces There are many other interfaces we need to implement. Here are some examples. TroubleTicketValue +getaccountowner() : PersonReach +getactivitydurationlist() : ActivityDurationList +getadditionaltroubleinfolist() : String[] +makealarmvaluelist() : AlarmValueList +makeauthorization() : Authorization +makecustomerroleassignment() : CustomerRoleAssignment +makeescalation() : Escalation +setcloseoutverification( i : int ) : void +setcommitmenttime( date : Date ) : void +setcommitmenttimerequested( date : Date ) : void... v

27 TroubleTicketValueIterator +getnexttroubletickets( i : int ) : TroubleTicketValue[] Escalation +clone() : Object +getescalationperson() : PersonReach +getescalationtime() : Date +getlevel() : int +getrequestperson() : PersonReach +getrequeststate() : int +setescalationperson( personreach : PersonReach ) : void +setescalationtime( date : Date ) : void +setlevel( i : int ) : void +setrequestperson( personreach : PersonReach ) : void +setrequeststate( i : int ) : void EscalationList +add( aescalation : Escalation[] ) : void +get() : Escalation[] +make( i : int ) : Escalation[] +remove( aescalation : Escalation[] ) : void +set( aescalation : Escalation[] ) : void 6.6 The Required Field Property File This required.xml file is to specify what attributes are required for a given operation. It takes 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 of the file: <Operation> <Operation_Name>createTroubleTicketByValue</Operation_Name> v

28 <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/J TroubleTicketValue interface. Some of the parameters are composite. We could extend this xml file to the level that what fields in the composite attribute are required. For example, Authorization contains request state, activity type, authorization time, authorization person fields, but only the first two are required. We can express this requirement 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 for AuthorizationList needs to be changed to Composite_Required_Parameter. 6.7 OSS/J Attributes to Database Field/Table Mapping Not every attribute defined in OSS/J are used. Not every attribute defined in OSS/J has one-to-one mapping to database table field. Here is the mapping from OSS/J attribute to database field/table mapping. OSS/J Attribute Database Field/Table Note accountowner Not used activitydurationlist EBOND_TT_ additionaltroubleinfolist afterhoursrepairauthority ACTIVITY_DURATION Additional Trouble Info Not used v

29 authorizationlist cancelrequestedbycustomer clearanceperson closeoutnarr closeoutverification commitmenttime commitmenttimerequested customer customerroleassignmentlist customertroublenum dialog escalationlist initiatingmode lastupdatetime maintservicecharge originator outageduration perceivedtroubleseverity preferredpriority receivedtime relatedalarmlist relatedtroubleticketkeylist repairactivitylist repeatreport restoredtime serviceunavailablebegintime serviceunavailableendtime sproleassignmentlist suspectobjectlist troubledescription troubledetectiontime troublefound troublelocation troublelocationinfolist EBOND_TT_ AUTHORIZATION Cancel Requested By Covad Covad Trouble Clearance Person Id Close Out Narr Close Out Verification Commitment Time Commitment Time Requested Covad Trouble Ticket Num EBOND_TT_ ESCALATION Initiating mode Maintenance service charge Outage years/months/days/hours/ minutes/seconds Perceived Trouble Severity Preferred Prority ILEC Received Time Repeat Report Restored Time Additional trouble status info Trouble Detection Time Trouble Found EBOND_TT_ ACCESS_LOCATION Not used Related to Covad Contact Person Id Not used Not used Not used Not used Not used Not used Not used Not used Related to ILEC contact person id Not used Not used v

30 troublenumlist troubledobject troubledobjectaccessfromtime troubledobjectaccesshourslist troubledobjectaccesstotime troublestate troublestatus troublestatustime troublesystemdn troubleticketkey troubletype Trouble Object Identifier EBOND_TT_ ACCESS_HOUR Trouble State Trouble Status Trouble Status Time ILEC Name Trouble Type Not used Not used Not used No corresponding table/field, but is used. Related to ILEC trouble ticket num. 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 hardcoded the Role as Manager. Notes on SPRoleAssignmentList: SPRoleAssignmentList is basically an array of SPRoleAssignment. SPRoleAssignment contains two pieces of information: 1. Contact Person Information 2. Role The contact person information will be mapped to ILEC contact person. We can hardcoded the Role as Agent. 6.8 JVTTroubleTicketSessionBean Implementation As we mentioned in previous section, JVTTroubleTicketSessionBean needs to implement the following functions: 1. createtroubleticketbyvalue: TroubleTicketKey 2. canceltroubleticketsbytemplate 3. closetroubleticketsbytemplate 4. escalatetroubleticketsbytemplate 5. settroubleticketbyvalue v

31 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 a record in TT_IECLINFO table with Covad related information. The following table specifies the mapping from the operations to the XML Message. Operation Name createtroubleticketbyvalue canceltroubleticketsbytemplate closetroubleticketsbytemplate escalatetroubleticketsbytemplate settroubleticketbyvalue XML Message Element createtroubleticketbyvaluerequest canceltroubleticketsbytemplaterequest closetroubleticketsbytemplaterequest escalatetroubleticketsbytemplaterequest settroubleticketbyvaluerequest The return value for createtroubleticketbyvalue is TroubleTicketKey. Since the ILEC trouble ticket number is unknown at this moment, this function should always return null. For the persistence of EBOND_TT_COVAD_WORKLOG, store the actual XML message element (or attribute s name and value pairs) into the Operation Attribute Value field, and set the operation status to Queued. For functions 6-7, we just query our local database. For 7, the Covad trouble ticket number or ILEC trouble ticket number needs to be provided. For 8, only QueryTroubleTicketHistoryValue is required to support. 6.9 XVTReplyMDB Implementation XVTReplyMDB consumes all the messages from XVTMessageReplyQueue. The following 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 v

32 10. settroubleticketbyvalueexception For all these messages, just update the EBOND_TT_COVAD_WORKLOG table according to whether it is a response message or response message based on Covad trouble 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 error message from the exception. In the case of createtroubleticketbyvalueexception, an should be sent to the Covad contact person to notify the trouble ticket creation failed JVTEventMDB Implementation JVTEventMDB subscribes to JVTEventTopic, and consumes all the messages in JVTEventTopic. All the messages are Java object messages. Here is the complete list of Java 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 with database values, if they are same, ignore the event; otherwise create a history record in TT_ILECINFO_HISTORY table, and update TT_ILECINFO table. 3. For creation event, update the record in TT_ILECINFO table TroubleTicketTimerService Implementation This timer service is not customer facing service, but a background one. Its purpose is to query ILEC s database constantly on some pre-configured time interval to get the latest trouble ticket information. Theoretically T1M1 standard requires ILEC send Covad the following 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 v

33 But event notification is not queued at ILEC side, it is only sent once. If it is lost, there is no way to get the same notification again. In real world, there are many reasons that notification 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 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 should include all the common attributes which could be supplied or updated by ILEC. The Join Integration Agreement specifies this information The Procedures for the Timer Service The implementation of this timer service can use the weblogic proprietary interfaces like T3StartupDef 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 the following criteria. a. The state is open b. The commitment time has passed or the trouble ticket has not been updated for a pre-configured time period. 2. If there are trouble tickets returned from step 1, browse XVTMessageQueue to find all the query messages already in the message queue. 3. For each trouble ticket returned from step 1, based on the following message properties 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 the XVTMessageQueue, ignore it. Otherwise, construct a gettroubleticketbykeyrequest message with pre-defined attribute set and send it to the XVTMessageQueue. When the request gets into the XVTMessageQueue, it queries the ILEC system, and wait for return. When return comes, it updates our local database. The work after the message gets into the queue will be carried out by the ILEC gateway system, JVTEventMDB message-driven bean. v

34 With this timer service, all information in Covad database are synchronized with ILEC database regularly, so subsequent queries can just read Covad database, and have almost up to date information. v

35 7 ILEC TROUBLE TICKET GATEWAY IMPLEMENTATION The ILEC Trouble Ticket Gateway interacts with both Covad trouble ticket system and ILEC trouble ticket system. The interactions with Covad trouble ticket system are through JMS for the message consuming and producing. The interactions with ILEC trouble ticket system 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 Mapping OSS/J defines 49 attributes, while T1M1 defines 95 attributes for trouble ticket. Here is the mapping between the fields defined by these two standards. Not all attributes defined by 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 activityduration alarmrecordptrlist additionaltroubleinfolist closeoutnarr receivedtime repairactivitylist restoredtime troubleclearanceperson troublefound troublelocation troublereportnumberlist ManagedObjectInstance troubletype troublereportstate troublereportstatus troublereportstatustime afterhrsrepairauth authorizationlist cancelrequestbymanager closeoutverification commitmenttime commitmenttimerequest custtroubleticknum Dialog escalationlist initiatingmode lastupdatetime maintservicecharge outageduration perceivedtroubleseverity OSS/J activitydurationlist relatedalarmlist additionaltroubleinfolist closeoutnarr receivedtime repairactivitylist restoredtime clearanceperson troublefound troublelocation troublenumlist troubledobject troubletype troublestate troublestatus troublestatustime afterhoursrepairauthority authorizationlist cancelrequestedbycustomer closeoutverification commitmenttime commitmenttimerequested customertroublenum dialog escalationlist initiatingmode lastupdatetime maintservicecharge outageduration perceivedtroubleseverity v

36 preferredpriority repeatreport suspectobjectlist troubledetectiontime managedobjectacessfromtime managedobjectaccesshours managedobjectaccesstotime preferredpriority repeatreport suspectobjectlist troubledetectiontime troubledobjectaccessfromtime troubledobjectaccesshourslist troubledobjectaccesstotime This mapping should be used in two ways. It tells where to find value for CMIP attributes when we construct a CMIP message, it also indicates where to find value when constructing OSS/J objects from CMIP messages. 7.2 ILEC Specific Property Here 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 File T1M1 Standard defines the sets of values for trouble status, trouble found, trouble type and trouble state, but ILEC may have its own set of values (SBC is an example). We can only store values for these fields according to the standard. When we receive messages from ILEC systems, these values will be ILEC proprietary values. We need to map them to the standard values before pass them to the queue or topic. The mapping can be obtained from the Joint Integration Agreement document with ILECs. 7.4 ILEC Specific Communication Property The communication piece with ILEC is implemented through 3 rd party product: Monfox s Dynamic TMN. There are two properties files used by the Dynamic TMN. 1. The naming service property file: this file specifies the protocol initiation parameters, which includes the pointer to the actual protocol property file, the selectors for the presentation layer, session layer, and application layer of the OSI protocol 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. v

37 7.5 Consume Messages from Covad Trouble Ticket System Gateway 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 that all the attribute values can be easily retrieved, and then construct the CMIP message, and use Monfox s MOHandle to send out the message. 7.6 Receive Responses from ILEC Trouble Ticket System Gateway needs to have one sender for XVTMessageReplyQueue, one subscriber for JVTEventTopic. The following is the complete list of what it will receive and how to deal with it. Request Response Action v

38 createtroubleticket ByValueRequest CreateConfirmation PerformException ValueException 1. Construct createtroubleticketbyvaluerespons e XML message. Using the return value of TroubleReportID as the primary key for the troubleticketkey to return. 2. Construct TroubleTicketCreateEvent. 3. Send createtroubleticketbyvaluerespons e message to XVTMessageReplyQueue 4. Publish the TroubleTicketCreateEvent to JVTEvnetTopic From the error code, determine if it is a system error. If it is an application error, do the same as ValueException, otherwise, just log the exception, and throw the exception This is application error. Do the following: 1. Construct createtroubleticketbyvalueexceptio n XML message. 2. Log the exception. 3. Send the constructed message to XVTMessageReplyQueue v

39 canceltroubletickets ByTemplateRequest closetroubletickets ByTemplateRequest SetConfirmation PerformException ValueException SetConfirmation PerformException ValueException 1. Construct canceltroubleticketsbytemplateres ponse XML message. 2. Construct TroubleTicketCancellationEvent. 3. Send canceltroubleticketsbytemplateres ponse to XVTMessageReplyQueue 4. Publish TroubleTicketCancellationEvent to JVTEventTopic From the error code, determine if it is a system error. If it is an application error, do the same as ValueException, otherwise, just log the exception and throw the exception This is application error. Do the following: 1. Construct canceltroubleticketsbytemplateexc eption XML message. 2. Log the exception. 3. Send the constructed message to XVTMessageReplyQueue 1. Construct closetroubleticketsbytemplateresp onse XML message. 2. Construct TroubleTicketCloseOutEvent. 3. Send the constructed message to XVTMessageReplyQueue 4. Publish TroubleTicketCloseOutEvent to JVTEventTopic. From the error code, determine if it is a system error. If it is an application error, do the same as ValueException, otherwise, just log the exception, and throw the exception This is application error. Do the following: 1. Construct closetroubleticketsbytemplateexce ption XML message. 2. Log the exception 3. Send the constructed message to XVTMessageReplyQueue v

40 escalatetroubletickets ByTemplateRequest SetConfirmation PerformException ValueException 1. Construct escalatetroubleticketsbytemplatere sponse XML message. 2. Construct troubleticketattributevaluechangee vent. 3. Send escalatetroubleticketsbytemplatere sonse to XVTMessageReplyQueue 4. Publish troubleticketattributevaluechangee vent to JVTEventTopic. From the error code, determine if it is a system error. If it is an application error, do the same as ValueException, otherwise, just log the exception and throw the exception This is application error. Do the following: 1. Construct escalatetroubleticketsbytemplateex ception XML message. 2. Log the exception 3. Send the constructed message to XVTMessageReplyQueue v

41 settroubleticket ByValueRequest gettroubleticket ByKeyRequest SetConfirmation PerformException ValueException GetConfirmation PerformException ValueException 1. Construct settroubleticketbyvalueresponse XML message. 2. Construct troubleticketattributevaluechangee vent. 3. Send settroubleticketbyvalueresponse message to XVTMessageReplyQueue 4. Publish troubleticketattributevaluechangee vent to JVTEventTopic. From the error code, determine if it is a system error. If it is an application error, do the same as ValueException, otherwise, just log the exception and throw the exception This is application error. Do the following: 1. Construct settroubleticketsbytemplateexcepti on XML message. 2. Log the exception 3. Send the constructed message to XVTMessageReplyQueue 1. Construct gettroubleticketbykeyresponse XML message. 2. Send the constructed message to XVTMessageReplyQueue Just log the exception. Just log the exception 7.7 Receive Event Notifications from ILEC Trouble Ticket System We need to create a new publisher for publishing events to JVTEventTopic. Monfox s Dynamic TMN reports event notification as MOHandleEvent. Based on this event 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 Event object, and publish to JVTEventTopic. a. TroubleTicketAttributeValueChangeEvent v

42 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. v

43 8 USE CASE REALIZATION With all the preparation we had, the use case realization is simple. 8.1 Create a Trouble Ticket 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 for processing Sequence Diagram The following sequence diagram illustrates the technician s interaction with TT- Application. v

44 : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: createtroubleticketbyvalue( troubleticketvalue ) 4: input parameter validation 5: xmlserialize.toxml( troubleticketvalue ) 7: return null 6: send createtroubleticketbyvaluerequest 8: return What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket creation. v

45 XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onmessage( createtroubleticketbyvaluerequest ) 2: xmlserializer.fromxml( createtroubleticketbyvaluerequest ) 3: setstage 4: CreateConfirmation = performcreate(): send CMIP message 5: send( createtroubleticketbyvalueresponse ) 6: publish( troubleticketcreateevent ) 7: onmessage( createtroubleticketbyvalueresponse ) 8: onmessage( troubleticketcreateevent ) 9: persist data 10: persist data 8.2 Query a Trouble Ticket Status/Information Technician s Interaction with TT-Application 1. Technician enters either Covad trouble ticket number or ILEC trouble ticket number for querying a trouble ticket information. 2. Technician submits the request. 3. Information regarding this trouble ticket is presented to the Technician Sequence Diagram The following sequence diagram illustrates the interaction: v

46 : Technician TT-APP (GUI) JVTTroubleTicketSessionBean Database 1: search trouble ticket 2: gettroubleticketsbytemplate( troubleticketvalue, attrnames ) 3: retrieve data 5: display data 4: return data 8.3 Cancel a Trouble Ticket Technician s Interaction with TT-Application 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. 3. Technician is informed that the request has been forwarded to ILEC for processing Sequence Diagram The following sequence diagram illustrates technician s interaction with TT-Application. v

47 : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket cancellation 2: send request 3: canceltroubleticketsbytemplate( troubleticketvalue,... ) 4: xmlserialize.toxml( troubleticketvalue ) 5: send canceltroubleticketsbytemplaterequest What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket cancellation. v

48 XVTMessageQueue ILEC Troble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onmessage( canceltroubleticketsbytemplaterequest ) 2: xmlserializer.fromxml( canceltroubleticketsbytemplaterequest ) 3: setstage 4: setconfirmation = performset(): send CMIP message 5: send ( canceltroubleticketsbytemplateresponse ) 6: publish ( troubleticketcancellationevent ) 7: onmessage( canceltroubleticketsbytemplateresponse ) 8: onmessage( troubleticketcancellationevent ) 9: persist data 10: persist data 8.4 View a Trouble Ticket History Technician s Interaction with TT-Application 1. Technician enters ILCE trouble ticket number for viewing a trouble ticket history. 2. Technician submits the request. 3. TT-Application displays the history Sequence Diagram The following sequence diagram illustrates the successful execution scenario: v

49 : Technician TT-APP (GUI) JVTTroubleTicketSessionBean Database 1: view trouble ticket history based on ILEC trouble ticket number 2: querytroubletickets( QueryTroubleTicketHistoryValue, attrnames ) 3: retrieve data 4: return 5: return 8.5 Escalate a Trouble Ticket 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. 3. Technician is informed that the request has been forwarded to ILEC for processing Sequence Diagram The following sequence diagram illustrates the interaction. v

50 : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare escalation info 2: send request 3: escalatetroubleticketsbytemplate( troubleticketvalue, escalationlist ) 4: xmlserialize.toxml( troubleticketvalue, escalationlist ) 5: send escalationtroubleticketsbytemplaterequest 6: return 7: return What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket escalation. v

51 XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onmessage( escalatetroubleticketsbytemplaterequest ) 2: xmlserializer.fromxml( escalatetroubleticketsbytemplaterequest ) 3: setstage 4: setconfirmation=performset(): send CMIP message 5: send ( escalatetroubleticketsbytemplateresponse ) 6: publish ( troubleticketattributevaluechangeevent ) 7: onmessage( escalatetroubleticketsbytemplateresponse ) 8: onmessage( troubleticketattributevaluechangeevent ) 9: persist data 10: persist data 8.6 Modify a Trouble Ticket Technician s Interaction with TT-Application 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. v

52 3. Technician is informed that the change request has been forwarded to ILEC for processing Sequence Diagram The following sequence diagram illustrates the interaction. : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: settroubleticketbyvalue( troubleticketvalue ) 4: xmlserialize.toxml( troubleticketvalue ) 5: send settroubleticketbyvaluerequest 6: return 7: return What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket modification. v

53 XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onmessage( settroubleticketbyvaluerequest ) 2: xmlserializer.fromxml( settroubleticketbyvaluerequest ) 3: setstage 4: SetConfirmation = performset() : send CMIP message 5: send settroubleticketbyvalueresponse 6: publish TroubleTicketAttributeValueChangeEvent 7: onmessage( settroubleticketbyvalueresponse ) 8: onmessage( TroubleTicketAttributeValueChangeEvent ) 9: persist data 10: persist data 8.7 Verify Repair Completion/Close a Trouble Ticket This use case only applies after an ILEC has repaired the trouble and changes the trouble report status attribute value to clearedawaitingcustverification Technician s Interaction with TT-Application 1. Technician reviews the Trouble Found field, and close out narrative field provided by 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 out verification to verified, otherwise set the close out verification to denied. 4. Technician submits the request. 5. Technician is informed that the request has been forwarded to ILEC for processing. v

54 8.7.2 Sequence Diagram The following sequence diagram illustrates the close a trouble ticket scenario. : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: closetroubleticketsbytemplate( troubleticketvalue, status, closeoutnarr ) 4: xmlserialize.toxml( troubleticketvalue ) 5: send closetroubleticketsbytemplaterequest 6: return 7: return What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket close out. v

55 XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onmessage( closetroubleticketsbytemplaterequest ) 2: xmlserializer.fromxml( closetroubleticketsbytemplaterequest ) 3: setstage 4: SetConfirmation = performset() : send CMIP message 5: send closetroubleticketsbytemplateresponse 6: publish TroubleTicketCloseOutEvent 7: onmessage( settroubleticketsbytemplateresponse ) 8: onmessage( TroubleTicketCloseOutEvent ) 9: persist data 10: persist data v

56 9 IMPACTS ON EXISTING SYSTEM Impacts occur in two places: 1. TT-Application (GUI): we need to add screens for ILEC trouble ticket interactions. 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 to check ILEC trouble ticket state stored in the TT_ILECINFO table. If the state is closed, the corresponding Covad trouble ticket may need to change its state/status too. v