Ebonding Architecture

March 26, 2018 | Author: ekasantosh | Category: Enterprise Java Beans, Application Programming Interface, Information Technology Management, Software Engineering, Computing
Share
Report this link


Comments



Description

Electronic Bonding with ILECElectronic Bonding Architecture Document v1.1.2 1 Revision History Date 09/12/03 09/19/03 09/25/03 09/30/03 10/03/03 10/29/03 11/13/03 Revision Number 0.5 0.9 0.91 0.92 1.0 1.1 1.1.1 Author Covad Architecture Covad Architecture Covad Architecture Covad Architecture Covad Architecture Covad Architecture Covad Architecture Comment Initial Draft Add more details More Details for OSS/J Implementation Address the MTTR issue Changes according to design review More Details on the schema design section Changes on local entity bean description 1. Change message acknowledge mode 2. For ILEC trouble ticket creation, creates a record in TT_ILECINFO with Covad related information before sends message 12/10/03 1.1.2 Covad Architecture v1.1.2 2 Table of Contents 1INTRODUCTION............................................................................................................5 2INDUSTRY STANDARDS............................................................................................. 6 2.1T1M1 STANDARD........................................................................................................... 6 2.2OSS/J........................................................................................................................... 7 2.3OSS/J VS T1M1 STANDARD............................................................................................7 3THE EXISITING COVAD TROUBLE TICKET SYSTEM.......................................9 4THE NEW COVAD TROUBLE TICKET SYSTEM................................................ 10 4.1DEPLOYMENT VIEW: THE BIG PICTURE............................................................................. 10 4.2NOTES ON THE DEPLOYMENT VIEW.................................................................................. 11 4.3DESIGN RATIONALE........................................................................................................11 4.4EMPHASIS ON COVAD MTTR......................................................................................... 11 4.5OVERVIEW OF NEW EJB COMPONENTS............................................................................ 12 4.6OVERVIEW OF JMS QUEUE/TOPIC COMPONENTS............................................................... 13 4.7OVERVIEW OF THE TIMER SERVICE................................................................................... 13 4.8OVERVIEW OF ILEC TROUBLE TICKET GATEWAY.............................................................. 13 4.9SECURITY......................................................................................................................14 4.10SCALABILITY................................................................................................................14 4.11PERFORMANCE............................................................................................................. 14 4.12MANAGEABILITY.......................................................................................................... 15 4.13TRANSACTION..............................................................................................................16 5DATA MODEL.............................................................................................................. 17 5.1THREE MAIN TABLES..................................................................................................... 17 5.2SUPPORTING TABLES.......................................................................................................18 6OSS/J IMPLEMENTATION........................................................................................23 6.1THE JVTTROUBLETICKETSESSION INTERFACE................................................................... 23 6.2EXTENDING OSS/J: THE QUERYTROUBLETICKETHISTORYVALUE INTERFACE......................... 25 6.3THE XMLSERIALIZER INTERFACE...................................................................................... 25 6.4THE TROUBLETICKETKEY INTERFACE............................................................................... 26 6.5OTHER SUPPORTING INTERFACES...................................................................................... 26 6.6THE REQUIRED FIELD PROPERTY FILE...............................................................................27 6.7OSS/J ATTRIBUTES TO DATABASE FIELD/TABLE MAPPING................................................. 28 6.8JVTTROUBLETICKETSESSIONBEAN IMPLEMENTATION......................................................... 30 6.9XVTREPLYMDB IMPLEMENTATION................................................................................ 31 6.10JVTEVENTMDB IMPLEMENTATION............................................................................... 32 6.11TROUBLETICKETTIMERSERVICE IMPLEMENTATION.............................................................32 6.11.1Configuration File for the Timer Service.........................................................33 6.11.2The Procedures for the Timer Service............................................................. 33 v1.1.2 3 7ILEC TROUBLE TICKET GATEWAY IMPLEMENTATION............................. 35 7.1STANDARD T1M1 TO OSS/J MAPPING........................................................................... 35 7.2ILEC SPECIFIC PROPERTY.............................................................................................. 36 7.3ILEC SPECIFIC MAPPING FILE........................................................................................ 36 7.4ILEC SPECIFIC COMMUNICATION PROPERTY..................................................................... 36 7.5CONSUME MESSAGES FROM COVAD TROUBLE TICKET SYSTEM............................................ 37 7.6RECEIVE RESPONSES FROM ILEC TROUBLE TICKET SYSTEM............................................... 37 7.7RECEIVE EVENT NOTIFICATIONS FROM ILEC TROUBLE TICKET SYSTEM................................41 8USE CASE REALIZATION.........................................................................................43 8.1CREATE A TROUBLE TICKET............................................................................................ 43 8.1.1Technician’s Interactions with TT-Application................................................. 43 8.1.2Sequence Diagram............................................................................................. 43 8.1.3What Happens behind the Scene........................................................................44 8.2QUERY A TROUBLE TICKET STATUS/INFORMATION..............................................................45 8.2.1Technician’s Interaction with TT-Application...................................................45 8.2.2Sequence Diagram............................................................................................. 45 8.3CANCEL A TROUBLE TICKET............................................................................................ 46 8.3.1Technician’s Interaction with TT-Application...................................................46 8.3.2Sequence Diagram............................................................................................. 46 8.3.3What Happens behind the Scene........................................................................47 8.4VIEW A TROUBLE TICKET HISTORY.................................................................................. 48 8.4.1Technician’s Interaction with TT-Application...................................................48 8.4.2Sequence Diagram............................................................................................. 48 8.5ESCALATE A TROUBLE TICKET......................................................................................... 49 8.5.1Technician’s Interactions with TT-Application................................................. 49 8.5.2Sequence Diagram............................................................................................. 49 8.5.3What Happens behind the Scene........................................................................50 8.6MODIFY A TROUBLE TICKET............................................................................................51 8.6.1Technician’s Interaction with TT-Application...................................................51 8.6.2Sequence Diagram............................................................................................. 52 8.6.3What Happens behind the Scene........................................................................52 8.7VERIFY REPAIR COMPLETION/CLOSE A TROUBLE TICKET.....................................................53 8.7.1Technician’s Interaction with TT-Application...................................................53 8.7.2Sequence Diagram............................................................................................. 54 8.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 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: 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 Cancel trouble report There are 95 attributes defined for trouble ticket administration. This trouble administration standard defines trouble administration functions between two TMNs (Telecommunication Management Network). trouble ticket attributes. Attribute value change trouble report format definition 17. v1. Enter trouble report 2. Verify repair completion 13. Enroll trouble report 11. The functions are: 1. De-enroll trouble report format definition 16. Enroll trouble report format definition 15.2 6 . The object classes are defined in GDMO (Guidelines for the Definition of Managed Objects). The attribute definitions are described using ASN. Request trouble report status 3. De-enroll trouble report 12. Review trouble history 6.2 2. For more information.1. Trouble report commitment time update 9. Request trouble report format 4. Trouble report status update 8. Trouble report attribute value change 10. Add trouble information 7. The underlying communication protocol is CMIP/CMISE. Trouble report progress update 18. Modify other trouble report attributes 14.1.1 INDUSTRY STANDARDS T1M1 Standard The Standard Committee T1-Telecommunications has a series of standards that specify interface requirements between Operation Systems across jurisdictional boundaries. and object classes. Trouble history event 5. One of the standards is regarding trouble administration. please refer the standard documents. Nortel. OSS/J covers many OSS areas including: trouble ticket. like the following two attributes: a. TroubleReportStatusWindow These two attributes are required for the trouble administration communication with ILECs. 2002. CMIP and its underlying OSI stack are heavyweight. 3.1 do not map easily into object-oriented programming languages either. T1M1 clearly defines what attributes are required.2. A XVTMessageQueue for XML message. TroubleReportFormatObjectPtr b. 2. 4.org/en/jsr/detail?id=91 2. MetaSolv. The object-oriented information models defined by CMIP. v1. it has its own limitations: 1. It does not address history/log issue. IBM Business Consulting Services. Motorola. 2. It is not defined as rigid as T1M1 is for trouble administration. workforce management. For trouble ticket. there are some mandatory information missing from OSS/J specification. an initiative started by a working group of industry leaders including Sun Microsystems. etc to define and implement an open standard set of APIs using Java technology for Operations Support Systems (OSS) and Business Support Systems (BSS). customer management. OSS/J defines: 1. GDMO. etc. The OSS/J trouble ticket API is finalized in February.1.1 and GDMO bears little relationship to OO programming languages. go to: http://jcp. Trouble Ticket EJB Session Interface: JVTTroubleTicketSession. Java object based events and XML string based events. 3. billing. OSS/J does not have these shortcomings. but on the other hand.3 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. The syntax used by ASN. what attributes are provided by agent. JVTEventTopic for Java Event Object. 3. what attributes are provided by manager. 2. Nokia. NEC.2 7 .2 OSS/J OSS/J stands for OSS through Java Initiative. For more information regarding OSS/J. For example. All the definitions provided by T1M1 standards are very complicated. OSS/J trouble ticket API specification does not address this issue at all. and ASN. and two topics: XVTEventTopic for XML event. BEA. order management. Although it captures the most important part of T1M1. XML based request/response messages. 2 8 .Even with these limitations. v1. it is still the best technology we can have given our Java environment.1. Furthermore these OSS/J limitations can be overcome using other means. 3 THE EXISITING COVAD TROUBLE TICKET SYSTEM Covad Trouble Ticket System t3 t3 TT-System TT-Application (GUI) TT-Application (GUI) OSSO : Database CFI CFI t3/GLUE TT-CFI TT-WFM JDBC TT FMS FMS t3/GLUE Current Covad trouble ticket system allows its users to create. When a trouble ticket involves ILECs.2 9 . manual process is needed to resolve issues with ILECs. v1. update. view.1. and track trouble ticket within Covad systems. 1 THE NEW COVAD TROUBLE TICKET SYSTEM 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 t3 TT-Application (GUI) TT-Application (GUI) t3/Glue SbcXVTReplyMDB SbcJVTEventMDB VerizonJVTEventMDB JMS VerizonXVTReplyMDB SbcXVTMessageQueue Weblogic JMS Server VerizonXVTMessageQueue OSSO : Database TT ILEC_TT SbcXVTMessageReplyQueue VerizonXVTMessageReplyQueue SbcJVTEventTopic VerizonJVTEventTopic ILEC_TT_MSG Firewall JMS JMS SBC Trouble Ticket Gateway Verizon Trouble Ticket Gateway MessageReceiver MessagePublisher MessageSender MessageReceiver MessageSender MessagePublisher Ossj2SbcConverter Sbc2OssjConverter Ossj2VerizonConverter Verizon2OssjConverter Monfox.1.MOHandle CMIP CMIP SBC Trouble Ticket System SBC Verizon Trouble Ticket System Verizon v1.2 10 .4 4.MOHandle Monfox. e.2 11 . 2. So these beans and the queues. 5. 3.1. The other benefits are that gateway is more scalable and robust. The trouble ticket creation request message will be have higher priority than other request messages. two message driven beans. and one event topic for each master ILEC (like SBC. instead of T1M1 standard.4. one JMS server with two queues and one topic should be able to handle this load. not for baby ILEC like AmeriTech). We only implement the part necessary for this project. which is not on line. Although different nodes are shown for different gateway for ILECs. and several local entity beans (only the trouble ticket local entity bean shown in the deployment view). is the right technology to go with. the Weblogic JMS server is part of the Application server. theoretically. To minimize Covad MTTR. Based on the following reasons. 1. 4. We introduce one message queue. 4. we decide separate the message reply queue and event topic for different ILECs.4 Emphasis on Covad MTTR Currently Covad creates total around 320 trouble tickets for all ILECs per day. but T1M1 is used behind OSS/J. one topic will be running in one JVM. etc. This not only increases the processing speed. but prevents messages designated for the ILEC. 1. one message reply queue. one message reply queue and one event topic for all ILECs should be enough. When we use Weblogic Application server. To achieve isolation for ILEC (such as changes for one ILEC should not affect communication with other ILEC). To avoid tightly coupled with ILEC trouble ticket system. from blocking messages designated for other ILECs. these gateways can run on the same machine. Only TAC can create ILEC trouble ticket through TT GUI. each gateway runs on its on JVM. OSS/J. Since ILECs are using T1M1 standards. Although Message-driven beans can have instance pools provided by EJB container. This JMS server also shields Covad trouble ticket system from the ILEC trouble ticket maintenance schedule.3 Design Rationale The current design is based on the following rationales. we introduce a JMS server in the middle.. 2. i. Verizon. different gateways run on different JVMs. we will use both OSS/J and T1M1 standard. 4. v1.2 Notes on the Deployment View The ILEC Trouble Ticket component contains one session bean. We will not fully implement OSS/J specification. TroubleTicketCreateEvent b. TroubleTicketStatusChangeEvent This component will call local entity beans to update database. cancelTroubleTicketsByTemplateException g. we need to set the message driven bean instance pool size to 1. CMP together with cmr fields should be used for these entity beans.1.1. setTroubleTicketByValueResponse d.2 12 . 2. closeTroubleTicketsByTemplateException It will call local entity beans to update database. Because the pool size is 1. They are: a. Messages are those notification events defined by OSS/J. Message-Driven Bean JVTEventMDB: this message-driven bean consumes all messages (Java Object messages) from JVTEventTopic. escalateTroubleTicketsByTemplateResponse h. TroubleTicketAttributeValueChangeEvent d. We have much more to say about this bean in later sections. v1. cancelTroubleTicketsByTemplateResponse f. It is also the single entry point to the new trouble ticket system. we cannot take advantage of instance pool. Event order sometimes is important. TroubleTicketCancellationEvent e. 3. To maintain the event order. Message-Driven Bean XVTReplyMDB: this message-driven bean consumes all messages (XML messages) from XVTMessageReplyQueue. we want the database updates in right order. 2. createTroubleTicketByValueResponse b. TroubleTicketCloseOutEvent c. closeTroubleTicketsByTemplateResponse j. setTroubleTicketByValueException e. 4. createTroubleTicketByValueException c. considering two update messages/events. 4. escalateTroubleTicketsByTemplateException i. They are a. Session Bean JVTTroubleTicketSessionBean: The bean implements all the business functions defined in JVTTroubleTicketSession interface of OSS/J trouble ticket API.5 Overview of New EJB Components 1. Local Entity Beans: we need local entity beans for those tables specified in the data model section. The MDBs could be the trouble ticket processing bottleneck. Messages are either the Response or Exception types of messages defined by OSS/J. 2 13 .4. Covad database has almost real time information about ILEC trouble tickets created by Covad. we also need to define the following property for the event: 3. 1.6 Overview of JMS Queue/Topic Components In the JMS server. it will create a timer. At its startup time. By using this timer service. OSS_APPLICATION_TYPE: we can use “Trouble Ticket” 4. for our application. 3. The returned information is used to update the Covad database.8 Overview of ILEC Trouble Ticket Gateway The gateway process accomplishes the following: v1. 4.1. OSS_MESSAGE_TYPE: REQUEST. OSS_APPLICATION_DN: ILEC name Beside these properties. On pre-configured interval. like createTroubleTicketByValueRequest. More details in the later section. OSS_REQUEST_SENDER_ID: we can use “Covad” 5. RESPONSE. ILEC_TROUBLETICKET_NUMBER All the events published to the topic are mandatory by OSS/J to set the following properties: 1. we will have one message queue per ILEC. 4. and one message reply queue. OSS_MESSAGE_NAME: The name of the operation. OSS_EVENT_TYPE: the fully qualified event name 2. ILEC_TROUBLETICKET_NUMBER Also the JMSDeliveryMode for both messages and events are PERSISTENT. XVTMessageQueue: this queue is for all XML request messages to ILEC trouble ticket System. or EXCEPTION. 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_REPLYTO_DESTINATION_TYPE: use value “QUEUE” Beside these properties.7 Overview of the Timer Service The timer service is a Weblogic startup object. one topic for all ILECs. this timer will keep sending out XML request message to XVTMessageQueue to query ILEC trouble ticket systems for the latest trouble ticket information. 3. 2. 2. XVTMessageReplyQueue: this queue is for XML response/exception messages from ILEC trouble ticket system. OSS_REPLY_SENDER_ID: use ILEC name 6. we need to define one more property: 7. using encryption. you may not have exactly the same classes. There are three security aspects for this system. Convert between OSS/J XML message and ILEC required values. and topics side by clustering Weblogic server.1.9 Security 1. we can scale beans. The security for accessing the session bean. queues. but does not define Java message for queues. and MOHandle class to illustrate the steps needed in the gateway. However we do not believe the penalty is high. Although all these operations are performed in memory.2 14 . This can be easily done through JMS’s message selector mechanism. Publish XML messages to XVTMessageReplyQueue and Java Event to JVTEventTopic. 4. If load increases dramatically. The security for accessing queues and topic 3. we can bring up more instances. 2. To confirm with this standard. In the deployment diagram. and divide the loads among these instances. The security for communicating with ILECs. and later on need to parse this XML message to retrieve data out. which essentially is to deserialize the XML message. 5. it does have performance penalty. The first two will be handled in role based EJB way. The ILEC trouble ticket gateway system is an independent Java process.1. On the gateway size. topics for both XML messages and Java object message. Ilec2OssjConverter. The last one will follow the T1M1 standard. etc. Ossj2IlecConverter.11 Performance OSS/J defines queues for XML message. 6. Receive ILEC event notifications. like one instance only dealing with trouble ticket creation. 4. Generate TroubleTicketKey for successful creation request. v1. Receive XML messages from XVTMessageQueue. 4. 4. In the actual implementation.10 Scalability Current design should be more than enough for the current load. and even modest increase of the load. 3. we use MessageReceiver. we need to serialize the Java object into XML message. MessageSender. Use 3rd party library to send and receive CMIP data. MessagePublisher. store the encryption key in proper location. We only need to configure the 3rd party product (Monfox). Monfox’s library will handle the secure handshaking with ILECs. 2. JMX approach or JCA approach could be taken for the future enhancements. 4.5 is in proposed final draft 2 stage.5 defines a new set of system-level contracts between an application server and enterprise information system. The current JCA 1. you can achieve the following. statistic info. use a new queue for Java object message to replace the current XML message queue.2 15 . Write a simple console as the management application. for example.1. and expose functions like: start. Examples of platforms are: J2EE. How do we monitor them? 2. For the phase 1. we could use Java object message instead of XML message. work management contract. There are ways to address these concerns: One way is to use another Java technology called JMX: 1.If the performance is an issue. 2. These new contracts make the resource adapters manageable through application administration console. etc. Gateway can be monitored. Beside the MBean implementation. They include: lifecycle management contract.12 Manageability The ILEC Trouble Ticket Gateway is implemented as a standalone Java process. a simple Web client. 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. Gateway can be easily plugged into the framework. v1. which makes the gateway impossible to be built on top of the popular platforms like J2EE and CORBA. There are concerns regarding these gateways: 1. These are good concerns. 2. CORBA. The new JCA 1. and notification support. But the key functionality of the gateway is to communicate ILEC trouble ticket system through CMIP protocol. One downside of this approach is more development work needed. stop. 3. By doing this. These gateways are not built on top on some type of platform. the standalone process should be good enough. etc. Wrap each gateway into a MBean. The other way is to use J2EE connector architecture. 1. All the gateways are built on JMX’s Distributed/Agent/Instrumentation layer framework. Current design to use Java object message rather than XML message for the notification is mainly due to performance consideration. The implementation of the resource adapter will be more complicated in this case. 2 16 . we still make JVTTroubleTicketSessionBean and message-driven beans transactional: 1. The scenarios we deal with here are relatively simple comparing with other distributed transactions we have seen in the past. but in our case.1. Even with this situation. 3. these schemas reside in the same database. there are concerns about the transaction being a distributed transaction.4. There are no multiple application server instances involved. It is not truly distributed as all the database writes occur in the same database (but different schemas). Based on the following reasons. However. v1. We don’t want to introduce our own mechanism to handle multiple database writes and enforce data integrity. These writes are across different schemas. they are nontransactional because the actual communications with ILEC could be time-consuming. for the sessions used in the ILEC trouble ticket Gateway systems. Weblogic server should be able to handle these simple cases. We may need some manual processes to resolve some data issues.13 Transaction Whenever a persist JMS message is involved in a transaction. this transaction will almost involves multiple database writes. 2. In addition to the existing attributes. Note: the following table structure does not show the primary key field. including all the activities associated with trouble tickets. TT_ILECINFO_HISTORY: this table stores all information about ILEC trouble tickets.5 DATA MODEL We need to store ILEC trouble ticket information in Covad database and keep the activity history around a trouble ticket. 5. nor the audit fields. Although currently we do model ILEC trouble ticket information in our database. EBOND_TT_COVAD_WORKLOG: this table stores all the actions taken by Covad.1.2 . both TT_ILECINFO and TT_ILECINFO_HISTORY should contain the following eBonding attributes: Field Name Using Ebonding Flag Troubled Object Identifier Trouble Type ID Additional Trouble Info Covad Trouble Ticket Num Covad Contact Person ID ILEC Name ILEC Trouble Ticket Num ILEC Received Time Trouble State ID Trouble Status ID Trouble Status Time Additional Trouble Status Info Trouble Found ID ILEC Contact Person ID Cancel Requested By Covad Flag Close Out Narrative Close Out Verification ID Maintain Service Charge Covad TT Clearance Person Id Commitment Time Type Varchar2(1) Varchar2(40) Notes Y/N Can be carrier circuit number or telephone number Number Enum Varchar2(512) Standard requires minimum 256 Number Number FK Varchar2(30) Already exists (ILEC_NAME) Varchar2(40) Already exists (ILEC_TICKET_NUM) Date Already exists (ILEC_CONTACTED_AT) Number Enum Number Enum Date Varchar2(512) Number Enum Number FK Varchar2(1) Varchar2(256) Number Enum Varchar2(1) Number FK Date Already exists (ILEC_COMMIT_TIME) 17 v1. the current one is not good enough.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. Outage Years Outage Months Outage Days Outage Hours Outage Minutes Outage Seconds Commitment Time Requested Initiating Mode ID Trouble Detection Time Perceived Trouble Severity ID Preferred Priority ID Repeat Report ID Date Created Created By Date Modified Modified By Number Number Number Number Number Number Date Number Date Number Number Number Date Varchar2(30) Date Varchar2(30) Enum Enum Enum Enum Audit Column Audit Column Audit Column Audit Column EBOND_TT_COVAD_WORKLOG should contain the following fields: Field Name Ebond TT Covad Worklog ID ILEC_INCIDENT_ID Covad Trouble Ticket Num ILEC Trouble Ticket Num Operation Name Operation Attribute Value Operation Status Operation Error Message Date Created Created By Date Modified Modified By 5. FK to TT_ILECINFO table.2 18 . Oracle Sequence. Success/Fail/Queued Audit Column Audit Column Audit Column Audit Column EBOND_LOOKUP: this ENUM table stores all the eBonding enum lookup values: Fields Type Ebond Lookup ID Value Status Date Created Created By v1.1.2 Supporting Tables Type Varchar2(30) Number(10) Varchar2(50) Varchar2(8) Date Varchar2(30) Notes PK PK ACTIVE/INACTIVE Audit Column Audit Column Type Number(10) Number Number Varchar2(40) Varchar2(30) Varchar2 (2048) Varchar2(1) Varchar2 (256) Date Varchar2(30) Date Varchar2(30) Notes PK. Oracle Sequence. It should contain the following fields: Fields Ebond Covad Support Contact ID Parent Carrier ID Covad Support Email Dist List Covad Support Phone Number Date Created Created By Date Modified Modified By Type Number(10) Varchar2(100) Varchar2(20) Date Varchar2(30) Date Varchar2(30) Notes PK.1. It should contain the following fields: Fields Ebond Covad Person Reach ID Ebond Covad Support Contact ID Covad OSS TT Login Name v1.Date Modified Modified By Date Varchar2(30) Audit Column Audit Column EBOND_ILEC_PERSON_REACH: this table stores the ILEC person’s contact information. Oracle Sequence. FK Audit Column Audit Column Audit Column Audit Column EBOND_COVAD_PERSON_REACH: this table stores the COVAD person’s contact information. Oracle Sequence. FK 19 . Email+Name – Business Key Email+Name – Business Key Audit Column Audit Column Audit Column Audit Column EBOND_COVAD_SUPPORT_CONTACT: this table stores the COVAD support contact information.2 Type Number(10) Varchar2(32) Varchar2(40) Notes PK. It should contain the following fields: Fields Ebond Ilec Person Reach ID Email Name Organization Name Fax Phone Area Code Phone Prefix Phone Suffix Phone Extension Responsible Street Address City State Zip Date Created Created By Date Modified Modified By Type Number(10) Varchar2(40) Varchar2(40) Varchar2(20) Varchar2(30) Varchar2(3) Varchar2(3) Varchar2(4) Varchar2(5) Varchar2(64) Varchar2(64) Varchar2(30) Varchar2(30) Varchar2(10) Date Varchar2(30) Date Varchar2(30) Notes PK. FK FK enum FK enum Audit Column Audit Column Audit Column Audit Column EBOND_TT_ACTIVITY_DURATION: this table stores duration for all the activities associated with a trouble ticket.1. Oracle Sequence. Oracle Sequence. Oracle Sequence. It should contain the following fields. FK enum FK enum (requested. provided. FK enum Y/N 20 . It should contain the following fields: Fields Ebond TT Escalation ID ILEC_INCIDENT_ID ILEC Escalation Person ID Escalation Time Escalation Level ID Covad Request Person ID Request State ID Date Created Created By Date Modified Modified By Type Number(10) Number Number Date Number Number Number Date Varchar2(30) Date Varchar2(30) Notes PK. It should contain the following fields: Fields Ebond TT Authorization ID ILEC_INCIDENT_ID Activity Type id Covad Authorization Person ID Authorization Time Request State ID Date Created Created By Date Modified Modified By Type Number(10) Number Number(10) Number Date Number Date Varchar2(30) Date Varchar2(30) Notes PK.Date Created Created By Date Modified Modified By Date Varchar2(30) Date Varchar2(30) Audit Column Audit Column Audit Column Audit Column EBOND_TT_AUTHORIZATION: this table stores whether authorization is requested by ILEC and granted by Covad. Fields Ebond TT Activity Duration ID ILEC_INCIDENT_ID Activity Type ID Billable Flag Duration In Years v1. denied) Audit Column Audit Column Audit Column Audit Column EBOND_TT_ESCALATION: this table stores what escalation has happened to one trouble ticket.2 Type Number(10) Number Number Varchar2(1) Number Notes PK. Oracle Sequence.Duration In Months Duration In Days Duration In Hours Duration In Minutes Duration In Seconds Date Created Created By Date Modified Modified By Number Number Number Number Number Date Varchar2(30) Date Varchar2(30) Audit Column Audit Column Audit Column Audit Column EBOND_TT_ACCESS_HOUR: this table stores the access hours for the troubled object and for the troubled location. We could break the above table into two for database normalization. It should contain the following fields: Fields Ebond TT Access Hour ID ILEC_INCIDENT_ID Day of Week Begin Hour Begin Minute Begin Second End Hour End Minute End Second Troubled Type ID Date Created Created By Date Modified Modified By Type Number (10) Number Number Number Number Number Number Number Number Number Date Varchar2(30) Date Varchar2(30) Notes PK. It should contain the following fields. FK Look up value (Sunday. Saturday) enum (Location or Object) Audit Column Audit Column Audit Column Audit Column Note for a given day of week.…. EBOND_TT_ACCESS_LOCATION: this table stores the trouble location information. Fields Ebond TT Access Loaction ID ILEC_INCIDENT_ID Premise Name Premise Street Address Premise City Premise State Premise Zip Location Type Date Created Type Number(10) Number Varchar2(64) Varchar2(64) Varchar2(30) Varchar2(30) Varchar2(10) Varchar2(1) Date Notes PK.2 21 . FK ‘A’ or ‘Z’ Audit Column v1. Oracle Sequence.1. you can have a list of begin time and end time. 2 22 .1.Created By Date Modified Modified By Varchar2(30) Date Varchar2(30) Audit Column Audit Column Audit Column v1. and there is a reference implementation available for free download. Close a single trouble ticket 8. Fortunately we only need to implement part of the OSS/j. We could use this reference implementation as our guideline. This specification defines everything in terms of interfaces.1 The JVTTroubleTicketSession Interface OSS/J defines the following operations in the JVTTroubleTicketSession interface: 1.2 23 .1. Get multiple trouble tickets 3. Set multiple trouble tickets 5. Create multiple trouble tickets 7. Cancel a single trouble ticket 10. OSS/J defines two bulk types: Best Effect and Atomic Bulk. Close multiple trouble tickets 9. Here is a list (not complete) of interfaces we need to implement. 6. We need to have our own implementation.6 OSS/J IMPLEMENTATION OSS/J trouble ticket API is just a specification. the JVTTroubleTicketSession interface is: v1. Escalate multiple trouble tickets For operations involving multiple trouble tickets. Set a single trouble ticket 4. Cancel multiple trouble tickets 11. Get a single trouble ticket 2. Create a single trouble ticket 6. Precisely. Escalate a single trouble ticket 12. statue : int. flag : boolean ) : TroubleTicketKeyResultIterator +trySetTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. attrNames : String[] ) : TroubleTicketValueIterator +setTroubleTicketByValue( troubleTicketValue : TroubleTicketValue. i : int. flag : boolean ) : TroubleTicketKeyResultIterator +tryCloseTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. s : String ) : void +cancelTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. i : int. as : String[] ) : TroubleTicketValue[] +getTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. troubleticketvalue : TroubleTicketValue ) : TroubleTicketKeyResult[] +trySetTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. i : int. escalateTroubleTicketByKey v1. s : String. we need only to support operations on a single trouble ticket. closeTroubleTicketByKey 3. flag : boolean ) : TroubleTicketKeyResultIterator +tryCancelTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. escalationlist : EscalationList ) : void +escalateTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. flag : boolean ) : TroubleTicketKeyResultIterator +tryEscalateTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. closeTroubleTickesByTemplate 3. s : String ) : void +cancelTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. flag : boolean ) : void +tryCancelTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. s : String ) : void +createTroubleTicketByValue( troubleticketvalue : TroubleTicketValue ) : TroubleTicketKey +createTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKey[] +escalateTroubleTicketByKey( troubleticketkey : TroubleTicketKey. attrNames : String[] ) : TroubleTicketValueIterator +queryTroubleTickets( queryValue : QueryValue. i : int.JVTTroubleTicketSession +cancelTroubleTicketByKey( troubleticketkey : TroubleTicketKey. escalationlist : EscalationList ) : void +getTroubleTicketByKey( troubleticketkey : TroubleTicketKey. i : int. flag : boolean ) : TroubleTicketKeyResult[] Based on the use case document. escalationlist : EscalationList ) : void +getTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue.2 24 . troubleticketvalue1 : TroubleTicketValue ) : void +setTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. i : int. as : String[] ) : TroubleTicketValueIterator +getTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. as : String[] ) : TroubleTicketValueIterator +makeTroubleTicketValue( s : String ) : TroubleTicketValue +queryTroubleTickets( queryvalue : QueryValue. i : int. s : String ) : void +cancelTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. closeOutNarr : String ) : void +closeTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue. flag : boolean ) : void +setTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. troubleticketvalue : TroubleTicketValue ) : void +setTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. s : String ) : void +closeTroubleTicketByKey( troubleticketkey : TroubleTicketKey. escalationlist : EscalationList ) : void +escalateTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. s : String ) : void +closeTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. i : int. cancelTroubleTicketsByTemplate 2. closeOutNarr : String ) : void +createTroubleTicketByValue( troubleTicketValue : TroubleTicketValue ) : TroubleTicketKey +escalateTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue. JVTTroubleTicketSessionBean +cancelTroubleTicketsByTemplate( troubleTicketValue : TroubleTicketValue. escalationlist : EscalationList ) : void +escalateTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. as : String[] ) : TroubleTicketValue +getTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. cancelTroubleTicketByKey 2. For the rest operations. s : String ) : TroubleTicketKeyResult[] +tryCancelTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. getTroubleTicketsByTemplate We choose these operations instead of the following operations designated by OSS/J for single trouble ticket: 1. status : int. s : String ) : void +closeTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. flag : boolean ) : TroubleTicketKeyResultIterator +trySetTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[]. flag : boolean ) : TroubleTicketKeyResultIterator +tryCloseTroubleTicketsByTemplates( atroubleticketvalue : TroubleTicketValue[]. i : int. troubleticketvalue : TroubleTicketValue ) : void +setTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[]. i : int. escalateTroubleTicketsByTemplate 4. s : String ) : void +closeTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. i : int. s : String. Here is the list of operations we need to implement. s : String ) : TroubleTicketKeyResult[] +tryCloseTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. troubleticketvalue : TroubleTicketValue. troubleticketvalue1 : TroubleTicketValue. escalationlist : EscalationList ) : TroubleTicketKeyResult[] +tryEscalateTroubleTicketsByTemplate( troubleticketvalue : TroubleTicketValue. as : String[] ) : TroubleTicketValueIterator +setTroubleTicketByValue( troubleticketvalue : TroubleTicketValue. s : String. flag : boolean ) : TroubleTicketKeyResultIterator +tryCreateTroubleTicketsByValues( atroubleticketvalue : TroubleTicketValue[] ) : TroubleTicketKeyResult[] +tryEscalateTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. i : int. s : String. escalationlist : EscalationList. resyncRequired : boolean ) : void Note: The following operations were designated by OSS/J for multiple trouble tickets: 1. i : int. escalationlist : EscalationList. we can just put empty function body.1. flag : boolean ) : TroubleTicketKeyResultIterator +trySetTroubleTicketsByKeys( atroubleticketkey : TroubleTicketKey[]. i : int. for the cancel trouble ticket case. closeTroubleTicketsByTemplate and escalateTroubleTicketsByTemplate.w3c. we can pass this piece information in troubleTicketValue parameter. None of the existing interfaces can satisfy the need to query the history value for a trouble ticket. getTroubleTicketByKey The reason is that these “ByKey” operation’s parameters are too restrictive to prevent us to pass necessary information. We need to make sure that the troubleTicketValue input parameter contains troubleTicketKey for cancelTroubleTicketsByTemplate.4. QueryValue QueryTroubleTicketHistoryValue +getCovadTroubleTicketNumber() : int +getTroubleTicketKey() : TroubleTicketKey +setCovadTroubleTicketNumber( int ) : void +setTroubleTicketKey( troubleTicketKey : TroubleTicketKey ) : void We will only support this interface in the queryTroubleTickets operation. we still deal with single trouble ticket. We define QueryTroubleTicketHistoryValue interface for this purpose. OSS/J also defines QueryAllOpenTroubleTicketsValue.2 Extending OSS/J: the QueryTroubleTicketHistoryValue Interface OSS/J defines a base interface QueryValue for generic attribute accessor. the cancelTroubleTicketByKey does not have place for us to pass the trouble clearance person information.dom. For example. XmlSerializer +fromXml(element : org. 6.3 The XmlSerializer Interface This interface marshals and un-marshals a Java object to and from XML. and also the other way around. Both marshalling and unmarshalling should be done in conform to the XML schema defined by OSS/J. but with cancelTroubleTicketsByTemplate.1.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). QueryByEscalationValue sub-interfaces. v1. So effectively.2 25 . 6. An application DN 3..5 Other Supporting Interfaces There are many other interfaces we need to implement.6.2 26 . we only need to set its primaryKey. The application DN is the DN of the application JNDI naming context. An application context The primary key will be the ILEC trouble ticket number. v1.1. TroubleTicketKey +getTroubleTicketPrimaryKey() : String +setTroubleTicketPrimaryKey( s : String ) : void For a trouble ticket key. A primary key 2. The application context is used to locate the application components in charge of the managed entity. 6. 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 . the other two can be set to null. it basically contains three pieces of information: 1. When we generate a TroubleTicketKey. 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.4 The TroubleTicketKey Interface ManagedEntityKey +getApplicationContext() : ApplicationContext +getApplicationDN() : String +getPrimaryKey() : Object .xml file. Here are some examples... 1.6 The Required Field Property File This required. 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.xml file is to specify what attributes are required for a given operation.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.2 27 . Here is just a potion of the file: <Operation> <Operation_Name>createTroubleTicketByValue</Operation_Name> v1. activity type. Not every attribute defined in OSS/J has one-to-one mapping to database table field. but only the first two are required.<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. Authorization contains request state. Some of the parameters are composite. authorization time. For example.1. authorization person fields.2 28 . the original tag name for AuthorizationList needs to be changed to Composite_Required_Parameter. 6. OSS/J Attribute accountOwner activityDurationList additionalTroubleInfoList afterHoursRepairAuthority Database Field/Table EBOND_TT_ ACTIVITY_DURATION Additional Trouble Info Not used Note Not used v1. The parameter name is conformed to OSS/J TroubleTicketValue interface. 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. Here is the mapping from OSS/J attribute to database field/table mapping.7 OSS/J Attributes to Database Field/Table Mapping Not every attribute defined in OSS/J are used. We could extend this xml file to the level that what fields in the composite attribute are required. 2 29 .authorizationList cancelRequestedByCustomer clearancePerson closeOutNarr closeOutVerification commitmentTime commitmentTimeRequested customer customerRoleAssignmentList customerTroubleNum dialog escalationList initiatingMode lastUpdateTime maintServiceCharge originator outageDuration EBOND_TT_ AUTHORIZATION Cancel Requested By Covad Covad Trouble Clearance Person Id Close Out Narr Close Out Verification Commitment Time Commitment Time Requested Not used Related to Covad Contact Person Id Covad Trouble Ticket Num Not used EBOND_TT_ ESCALATION Initiating mode Not used Maintenance service charge Not used Outage years/months/days/hours/ minutes/seconds Perceived Trouble Severity Preferred Prority ILEC Received Time Not used Not used Not used Repeat Report Restored Time Not used Not used Related to ILEC contact person id Not used Additional trouble status info Trouble Detection Time Trouble Found Not used EBOND_TT_ ACCESS_LOCATION perceivedTroubleSeverity preferredPriority receivedTime relatedAlarmList relatedTroubleTicketKeyList repairActivityList repeatReport restoredTime serviceUnavailableBeginTime serviceUnavailableEndTime spRoleAssignmentList suspectObjectList troubleDescription troubleDetectionTime troubleFound troubleLocation troubleLocationInfoList v1.1. Role The contact person information will be mapped to Covad contact person. Related to ILEC trouble ticket num. escalateTroubleTicketsByTemplate 5. cancelTroubleTicketsByTemplate 3. createTroubleTicketByValue: TroubleTicketKey 2. Contact Person Information 2. Contact Person Information 2. CustomerRoleAssignment basically contains two pieces of information: 1. JVTTroubleTicketSessionBean needs to implement the following functions: 1. but is used. 6. Notes on SPRoleAssignmentList: SPRoleAssignmentList is basically an array of SPRoleAssignment. Trouble Type troubleType Notes on CustomerRoleAssignmentList: CustomerRoleAssignmentList is basically an array of CustomerRoleAssignment.2 30 .8 JVTTroubleTicketSessionBean Implementation As we mentioned in previous section. closeTroubleTicketsByTemplate 4.troubleNumList troubledObject troubledObjectAccessFromTime troubledObjectAccessHoursList troubledObjectAccessToTime troubleState troubleStatus troubleStatusTime troubleSystemDN troubleTicketKey Not used Trouble Object Identifier Not used EBOND_TT_ ACCESS_HOUR Not used Trouble State Trouble Status Trouble Status Time ILEC Name No corresponding table/field. setTroubleTicketByValue v1.1. We can hardcoded the Role as “Agent”. SPRoleAssignment contains two pieces of information: 1. We can hardcoded the Role as “Manager”. Role The contact person information will be mapped to ILEC contact person. The following table specifies the mapping from the operations to the XML Message. it creates a record in TT_IECLINFO table with Covad related information. closeTroubleTicketsByTemplateResponse 6. store the actual XML message element (or attribute’s name and value pairs) into the Operation Attribute Value field. queryTroubleTickets The implementation of Functions 1-5 follows the same steps: 1. Generate XML message using XmlSerializer 2. cancelTroubleTicketsByTemplateException 5. For the persistence of EBOND_TT_COVAD_WORKLOG.6. createTroubleTicketByValueException 3. we just query our local database. For 7. cancelTroubleTicketsByTemplateResponse 4. before it executes the steps above. The following is the complete list of XML messages it needs to handle. Since the ILEC trouble ticket number is unknown at this moment. only QueryTroubleTicketHistoryValue is required to support. For functions 6-7.9 XVTReplyMDB Implementation XVTReplyMDB consumes all the messages from XVTMessageReplyQueue. Operation Name createTroubleTicketByValue cancelTroubleTicketsByTemplate closeTroubleTicketsByTemplate escalateTroubleTicketsByTemplate setTroubleTicketByValue XML Message Element createTroubleTicketByValueRequest cancelTroubleTicketsByTemplateRequest closeTroubleTicketsByTemplateRequest escalateTroubleTicketsByTemplateRequest setTroubleTicketByValueRequest The return value for createTroubleTicketByValue is TroubleTicketKey.2 31 . 1. and set the operation status to “Queued”.1. escalateTroubleTicketsByTemplateResponse 8. the Covad trouble ticket number or ILEC trouble ticket number needs to be provided. setTroubleTicketByValueResponse v1. For 8. createTroubleTicketByValueResponse 2. escalateTroubleTicketsByTemplateException 9. getTroubleTicketsByTemplate 7. Send the XML message to XVTMessageQueue 3. closeTroubleTicketsByTemplateException 7. this function should always return null. Persist information to EBOND_TT_COVAD_WORKLOG table For createTroubleTicketByValue function. 6. 1. Object Deletion Notification 4. 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. Its purpose is to query ILEC’s database constantly on some pre-configured time interval to get the latest trouble ticket information. and consumes all the messages in JVTEventTopic. an email should be sent to the Covad contact person to notify the trouble ticket creation failed. TroubleTicketAttributeValueChangeEvent 2. For creation event.10. 1. compare all the not-null values with database values. 6. and update TT_ILECINFO table. set the operation status to “success” 2. ignore the event. but a background one. and operation error message from the exception.10 JVTEventMDB Implementation JVTEventMDB subscribes to JVTEventTopic. otherwise create a history record in TT_ILECINFO_HISTORY table. update the record in TT_ILECINFO table.1. Attribute Value Change Notification 2. Trouble Report Status/Commitment Time Update Notification 5. TroubleTicketCloseOutEvent 4. set the operation status to “failure”. 3. TroubleTicketCreateEvent The handling of these events is as follows: 1. if they are same. Trouble History Event Notification v1. Object Creation Notification 3. ILEC trouble ticket number (if it is not null) and operation name.2 32 . In the case of createTroubleTicketByValueException. TroubleTicketCancellationEvent 3. All the messages are Java object messages. For response messages. setTroubleTicketByValueException For all these messages.11 TroubleTicketTimerService Implementation This timer service is not customer facing service. 6. For all these events except the creation event. For exception messages. Here is the complete list of Java object messages it needs to handle. Theoretically T1M1 standard requires ILEC send Covad the following notification: 1. Retrieve all the attribute values from the event 2. TroubleTicketStatusChangeEvent 5. The commitment time has passed or the trouble ticket has not been updated for a pre-configured time period. If there are trouble tickets returned from step 1. 3. it updates our local database. v1.2 The Procedures for the Timer Service The implementation of this timer service can use the weblogic proprietary interfaces like T3StartupDef and NotificationListener. like every 4 hours. For each trouble ticket returned from step 1. 2. OSS_MESSAGE_NAME c.1. it is only sent once.11.But event notification is not queued at ILEC side. based on the following message properties to determine if the corresponding message has already in the queue: a. a. In real world. there is no way to get the same notification again. If it is lost. So we cannot rely on these notifications to synchronize with ILEC database information. This service performs the following steps regularly on pre-configured time interval: 1. browse XVTMessageQueue to find all the query messages already in the message queue. 6.1 Configuration File for the Timer Service This configuration file should contain two pieces of information: 1.11. 6. ignore it. The time interval: it determines how often the query messages will be generated. The set of attributes we want to query against ILEC systems. This timer service is the way to synchronize our local database with ILEC database. it queries the ILEC system. ILEC_TROUBLETICKET_NUMBER 4. When return comes. Basically we should include all the common attributes which could be supplied or updated by ILEC. 2. The state is open b. Otherwise.2 33 . construct a getTroubleTicketByKeyRequest message with pre-defined attribute set and send it to the XVTMessageQueue. OSS_MESSAGE_TYPE b. and wait for return. The work after the message gets into the queue will be carried out by the ILEC gateway system. JVTEventMDB message-driven bean. The Join Integration Agreement specifies this information. If a trouble ticket already has its corresponding query message in the XVTMessageQueue. there are many reasons that notification may be lost. Query Covad database to find out all the trouble tickets which satisfy the following criteria. When the request gets into the XVTMessageQueue. so subsequent queries can just read Covad database.1. all information in Covad database are synchronized with ILEC database regularly. and have almost up to date information.2 34 .With this timer service. v1. 2 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 35 . 7. while T1M1 defines 95 attributes for trouble ticket.1. Not all attributes defined by T1M1 will be used here. Not all the attributes have the natural mapping here either. Beside the normal CMIP request/response with ILEC systems. 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 v1. The interactions with ILEC trouble ticket system are through CMIP.7 ILEC TROUBLE TICKET GATEWAY IMPLEMENTATION The ILEC Trouble Ticket Gateway interacts with both Covad trouble ticket system and ILEC trouble ticket system. the gateway will also receive event notifications initiated by ILEC trouble ticket systems.1 Standard T1M1 to OSS/J Mapping OSS/J defines 49 attributes. Here is the mapping between the fields defined by these two standards. The interactions with Covad trouble ticket system are through JMS for the message consuming and producing. 4 ILEC Specific Communication Property The communication piece with ILEC is implemented through 3rd party product: Monfox’s Dynamic TMN. TroubleReportStatusWindow 3. which includes the pointer to the actual protocol property file. 2.1. The protocol property file: this file specifies the CMIP user information. Covad’s service Id under ILEC 7. and application layer of the OSI protocol stack. We need to map them to the standard values before pass them to the queue or topic. 7. but ILEC may have its own set of values (SBC is an example). There are two properties files used by the Dynamic TMN. 7. v1. trouble type and trouble state. trouble found.3 ILEC Specific Mapping File Here is the list of attribute values we need to specify for each ILEC: T1M1 Standard defines the sets of values for trouble status. Covad’s account name under ILEC 5. It tells where to find value for CMIP attributes when we construct a CMIP message. these values will be ILEC proprietary values. TroubleReportFormatObjectPtr 2. 3.2 36 .preferredPriority repeatReport suspectObjectList troubleDetectionTime managedObjectAcessFromTime managedObjectAccessHours managedObjectAccessToTime preferredPriority repeatReport suspectObjectList troubleDetectionTime troubledObjectAccessFromTime troubledObjectAccessHoursList troubledObjectAccessToTime This mapping should be used in two ways. The mapping can be obtained from the Joint Integration Agreement document with ILECs. ILEC networkId 4. and a file pointer to the security key file. the selectors for the presentation layer. session layer. it also indicates where to find value when constructing OSS/J objects from CMIP messages.2 ILEC Specific Property 1. functional unit information. When we receive messages from ILEC systems. The naming service property file: this file specifies the protocol initiation parameters. We can only store values for these fields according to the standard. The security key file. 1. 2 37 . The session to the queue is non-transactional. 7. The acknowledge mode is AUTO_ACKNOWLEDGE Gateway needs to create a message receiver. escalateTroubleTicketsByTemplateRequest 5. and then construct the CMIP message. createTroubleTicketByValueRequest 2. 2. getTroubleTicketByKeyRequest Upon receiving these messages. It will asynchronously receive the XML message from XVTMessageQueue. and use Monfox’s MOHandle to send out the message. we need to de-serialize them into Java objects such that all the attribute values can be easily retrieved. The following is the complete list of what it will receive and how to deal with it.1. closeTroubleTicketsByTemplateRequest 4.7. Request Response Action v1. one subscriber for JVTEventTopic. cancelTroubleTicketsByTemplateRequest 3. 3. This receiver has the following properties: The following is the complete list of message types it needs to handle: 1.5 Consume Messages from Covad Trouble Ticket System 1. setTroubleTicketByValueRequest 6.6 Receive Responses from ILEC Trouble Ticket System Gateway needs to have one sender for XVTMessageReplyQueue. Construct createTroubleTicketByValueExceptio n XML message. Publish the TroubleTicketCreateEvent to JVTEvnetTopic From the error code. Construct createTroubleTicketByValueRespons e XML message.1. and throw the exception This is application error. 2. just log the exception. Send the constructed message to XVTMessageReplyQueue PerformException ValueException v1. Do the following: 1. determine if it is a system error. 3. If it is an application error.createTroubleTicket ByValueRequest CreateConfirmation 1. do the same as ValueException. otherwise. 3.2 38 . Using the return value of TroubleReportID as the primary key for the troubleTicketKey to return. Construct TroubleTicketCreateEvent. Log the exception. 2. Send createTroubleTicketByValueRespons e message to XVTMessageReplyQueue 4. otherwise. Send cancelTroubleTicketsByTemplateRes ponse to XVTMessageReplyQueue 4. do the same as ValueException. From the error code. 2. Publish TroubleTicketCloseOutEvent to JVTEventTopic.cancelTroubleTickets ByTemplateRequest SetConfirmation 1. Construct TroubleTicketCancellationEvent. Do the following: 1. 3. do the same as ValueException. just log the exception and throw the exception This is application error. Construct cancelTroubleTicketsByTemplateRes ponse XML message.1. Construct cancelTroubleTicketsByTemplateExc eption XML message. determine if it is a system error. and throw the exception This is application error. just log the exception. If it is an application error. 2. Send the constructed message to XVTMessageReplyQueue 4. Publish TroubleTicketCancellationEvent to JVTEventTopic From the error code. Construct closeTroubleTicketsByTemplateResp onse XML message. Log the exception 3. 2. Construct TroubleTicketCloseOutEvent. Send the constructed message to XVTMessageReplyQueue 1. 2. Send the constructed message to XVTMessageReplyQueue PerformException ValueException closeTroubleTickets ByTemplateRequest SetConfirmation PerformException ValueException v1. If it is an application error. Do the following: 1. 3. Construct closeTroubleTicketsByTemplateExce ption XML message. Log the exception. otherwise. determine if it is a system error.2 39 . 3. 2. If it is an application error. Publish troubleTicketAttributeValueChangeE vent to JVTEventTopic. Construct escalateTroubleTicketsByTemplateEx ception XML message. determine if it is a system error.1. do the same as ValueException. Construct escalateTroubleTicketsByTemplateRe sponse XML message. 2. Log the exception 3. just log the exception and throw the exception This is application error. 3. otherwise. Do the following: 1. Construct troubleTicketAttributeValueChangeE vent. Send escalateTroubleTicketsByTemplateRe sonse to XVTMessageReplyQueue 4. Send the constructed message to XVTMessageReplyQueue PerformException ValueException v1.escalateTroubleTickets SetConfirmation ByTemplateRequest 1.2 40 . From the error code. 2. Sent confirmation back to ILEC system for the notification. and attribute name and value. 2. do the same as ValueException. determine if it is a system error. If it is an application error.7 Receive Event Notifications from ILEC Trouble Ticket System We need to create a new publisher for publishing events to JVTEventTopic. otherwise. TroubleTicketAttributeValueChangeEvent v1.1. Do the following: 1. just log the exception and throw the exception This is application error. Publish troubleTicketAttributeValueChangeE vent to JVTEventTopic. Two steps need to be performed here: 1. a. Send the constructed message to XVTMessageReplyQueue 1. 2. and all the relevant attribute names and values.2 41 . Construct setTroubleTicketsByTemplateExcepti on XML message. From the error code. Send the constructed message to XVTMessageReplyQueue Just log the exception. Monfox’s Dynamic TMN reports event notification as MOHandleEvent. 2. Just log the exception PerformException ValueException getTroubleTicket ByKeyRequest GetConfirmation PerformException ValueException 7. and publish to JVTEventTopic. 3.setTroubleTicket ByValueRequest SetConfirmation 1. Log the exception 3. Construct setTroubleTicketByValueResponse XML message. construct one of the Event object. Send setTroubleTicketByValueResponse message to XVTMessageReplyQueue 4. we can obtain the event type. Based on this event object. Construct troubleTicketAttributeValueChangeE vent. Construct getTroubleTicketByKeyResponse XML message. Based on the event type. trouble status. v1. TroubleTicketCreateEvent e. Publish the event to JVTEventTopic. trouble state mapping.2 42 . TroubleTicketCancellationEvent d.1. TroubleTicketAttributeValueChangeEvent When we construct these event. trouble found.b. we need to apply the ILEC specific trouble type. TroubleTicketCloseOutEvent c. TroubleTicketStatusChangeEvent f. 3. 1.8 USE CASE REALIZATION With all the preparation we had.2 Sequence Diagram The following sequence diagram illustrates the technician’s interaction with TTApplication. 8. v1.2 43 . Technician submits the trouble ticket creation request using TT-Application.1 Create a Trouble Ticket Technician’s Interactions with TT-Application 1. 8.1. Technician is informed that the request has been forwarded to ILEC for processing.1.1 8. 3. 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. the use case realization is simple. 1.toXml( troubleTicketValue ) 6: send createTroubleTicketByValueRequest 7: return null 8: return 8.2 44 . v1.: Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: createTroubleTicketByValue( troubleTicketValue ) 4: input parameter validation 5: xmlSerialize.3 What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket creation.1. 8.1 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.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 Sequence Diagram The following sequence diagram illustrates the interaction: v1.2 45 .XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onMessage( createTroubleTicketByValueRequest ) 2: xmlSerializer.2 8. 3. Information regarding this trouble ticket is presented to the Technician.1.2.2. Technician submits the request. ILEC Trouble Ticket Number b. 8.: Technician TT-APP (GUI) JVTTroubleTicketSessionBean Database 1: search trouble ticket 2: getTroubleTicketsByTemplate( troubleTicketValue. Technician is informed that the request has been forwarded to ILEC for processing.2 46 .3 8.2 Sequence Diagram The following sequence diagram illustrates technician’s interaction with TT-Application.1. 3. Trouble Clearance Person Information c. The Technician prepares the following information: a. v1.1 Cancel a Trouble Ticket Technician’s Interaction with TT-Application 1. Technician submits the trouble ticket cancellation request using TT-Application. attrNames ) 3: retrieve data 4: return data 5: display data 8.3.3. Close out Narratives 2. : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket cancellation 2: send request 3: cancelTroubleTicketsByTemplate( troubleTicketValue. ) 4: xmlSerialize.2 47 . .3.3 What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket cancellation.. v1.1.toXml( troubleTicketValue ) 5: send cancelTroubleTicketsByTemplateRequest 8.. 2 48 . 2. TT-Application displays the history.1 View a Trouble Ticket History Technician’s Interaction with TT-Application 1. 3.4 8.4. 8.2 Sequence Diagram The following sequence diagram illustrates the successful execution scenario: v1. Technician submits the request.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. Technician enters ILCE trouble ticket number for viewing a trouble ticket history.1.XVTMessageQueue ILEC Troble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onMessage( cancelTroubleTicketsByTemplateRequest ) 2: xmlSerializer.4. 2 Sequence Diagram The following sequence diagram illustrates the interaction.5 8. Request State d. Technician submits the escalation request using TT-Application.1. Escalation Person Id c. 3.2 49 . 8. Technician prepares the following information: a. v1.5. Technician is informed that the request has been forwarded to ILEC for processing.1 Escalate a Trouble Ticket Technician’s Interactions with TT-Application 1. Escalation Level b.5. attrNames ) 3: retrieve data 4: return 5: return 8. Additional Trouble Info for the Escalation Reason 2.: Technician TT-APP (GUI) JVTTroubleTicketSessionBean Database 1: view trouble ticket history based on ILEC trouble ticket number 2: queryTroubleTickets( QueryTroubleTicketHistoryValue. Request Person Id e. 2 50 . v1.: Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare escalation info 2: send request 3: escalateTroubleTicketsByTemplate( troubleTicketValue.1. escalationList ) 4: xmlSerialize.5. escalationList ) 5: send escalationTroubleTicketsByTemplateRequest 6: return 7: return 8.3 What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket escalation.toXml( troubleTicketValue. Perceived Trouble Severity g.2 51 . Covad Contact Person e. Technician enters new values to the following attributes: a. Trouble Object Access Hour Information d.6 8. Trouble Authorization Information c. Technician submits the change.XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onMessage( escalateTroubleTicketsByTemplateRequest ) 2: xmlSerializer. Trouble Location Information b.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. Preferred Priority 2.1.1 Modify a Trouble Ticket Technician’s Interaction with TT-Application 1.6. Commitment Time Requested f. v1. 6.2 52 .2 Sequence Diagram The following sequence diagram illustrates the interaction. Technician is informed that the change request has been forwarded to ILEC for processing. : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: setTroubleTicketByValue( troubleTicketValue ) 4: xmlSerialize. 8.1. v1.6.3.toXml( troubleTicketValue ) 5: send setTroubleTicketByValueRequest 6: return 7: return 8.3 What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket modification. 7. v1.XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onMessage( setTroubleTicketByValueRequest ) 2: xmlSerializer. otherwise set the close out verification to “denied”.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.2 53 .1. If it is fixed.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”. and close out narrative field provided by ILEC. Technician determines if the trouble has been fixed. set the close out verification to “verified”. 2. Technician submits the request. 3. Technician reviews the Trouble Found field. Technician is informed that the request has been forwarded to ILEC for processing. Technician set the Trouble Clearance Person Information. 8. 4.1 Technician’s Interaction with TT-Application 1. 5. status.7.8. closeOutNarr ) 4: xmlSerialize.toXml( troubleTicketValue ) 5: send closeTroubleTicketsByTemplateRequest 6: return 7: return 8.7. v1.1.3 What Happens behind the Scene The following sequence diagram illustrates what happens behind the scene for a successful trouble ticket close out.2 54 . : Technician TT-Application (GUI) JVTTroubleTicketSessionBean XVTMessageQueue 1: prepare trouble ticket value 2: send request 3: closeTroubleTicketsByTemplate( troubleTicketValue.2 Sequence Diagram The following sequence diagram illustrates the close a trouble ticket scenario. 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 v1.1.XVTMessageQueue ILEC Trouble Ticket Gateway ILEC Trouble Ticket System XVTMessageReplyQueue JVTEventTopic XVTReplyMDB JVTEventMDB Database 1: onMessage( closeTroubleTicketsByTemplateRequest ) 2: xmlSerializer.2 55 . Impacts occur in two places: v1. the corresponding Covad trouble ticket may need to change its state/status too. The screens should cover all the use cases.2 56 . 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. TT-Application (GUI): we need to add screens for ILEC trouble ticket interactions. 3. TT-Browser: changes are corresponding to the changes in the TT-Application.9 IMPACTS ON EXISTING SYSTEM 1. If the state is closed. 2.1.
Copyright © 2024 DOKUMEN.SITE Inc.