The Trouble Ticketing API as an essential deliverable of this Prosspero Solution Package has been used successfully in different TT integration scenarios at service providers around the globe. Vodafone D2 of Germany is front-runner in applying this solution pack and, therefore, the following use cases are based on real operational experiences from Vodafone.

Use Cases

High level description of the use cases:

Main scenario (a.k.a. basic Trouble Ticket life cycle):

• A customer of the TT System creates a Trouble Ticket and has therefore the role of a Creator. The Trouble Ticket creation request is forwarded to the TT system with an OSS/J client, which means that the client interacts with the TT System via OSS/J Trouble Ticketing API (CREATE TT use case).
• A Service Provider (role: editor) is responsible for solving the problem described by the ticket. The editor stores his solution of the problem in the TT system by using the UPDATE TT use case. After problem resolution the ticket is set to the cleared state.
• Customer will be informed of Trouble Ticket Changes via notification events and gets information about trouble tickets (GET TT use case).
• The customer is responsible for trouble ticket closure (CLOSE TT use case).

Main Requirements and Conditions

Beside full support for the use cases (see previous chapter) and other business specific requirements, the solution has to fulfill at least the following generic set of requirements for the TT integration scenario:

• Use Cases
  • The Server API needs to support all OSS/J TT API Calls.

• Standardization
  • It must be possible to connect further OSS/J TT clients to the OSS/J certified TT Integration solution (server) without any changes (beside configuration), neither to the server nor to the client. [Plug and Play]
  • It must be possible to develop the OSS/J client interface by just using the Prosspero criteria for TT integration solutions as the information base.

• Extensibility
  • The integration solution may not change the standard based TT data model (JSR 144 and 91). If it is necessary to extend the data model, then it must follow the specification rules (JSR 91 and 144).
  • Beside that, it must be possible to extend the data model as mentioned above (either extended by client or server), without any major influence on the functionality of the end to end scenario and without any inconsistency to the standard.
  • If a client or server knows about the extension, it can use it
  • If client or server doesn’t know about extension, it can still use the non-extended parts of the solution without any restriction or errors.

• Portability
  • The solution has to ensure, that there are no dependency on vendors that provide basic standard infrastructure (i.e. J2EE container services). It must be possible to use the solution in different environments without re-development of the solution (just by reconfiguration and redeployment) Therefore, all J2EE-based implementations of components of the Prosspero TT integration solution must pass the Java Application Verification Kit (AVK) for the Enterprise (see http://java.sun.com/j2ee/avk/index.html) in order to guarantee portability

• System performance / Scalability
  • Scaling the system shall be a matter of configuring the integration solution deployment environment as necessary rather than rebuilding or re-customizing the OSS applications (Trouble Ticketing) themselves every time the load requirements or use cases changed.

• Reliability
  • The solution has to perform at a constant level as the stresses on the solution change
  • Messages have to be delivered once and only once.
  • No messages will be lost.
  • Integration must be stable and accessible at any time.
  • The Client system needs a response whether the ticket has been created. In any other case an error message should occur.