1 The Service Request Translator

The Oracle Communications ASAP Service Request Translator (SRT) enables a variety of tasks within a transformation computation, including mapping, data lookup, and message transformation. Mapping tasks allow upstream requests to be decomposed into one or more downstream requests. Data lookup functions can involve retrieving data from external systems (such as databases). Transformation actions can involve presentation formatting. The SRT is triggered by an XML source document and generates an XML target document as its output.

Figure 1-1 Service Request Translator Context

Process Overview

Figure 1-2 illustrates an end-to-end process flow for a service activation in which the SRT provisions a service.

Figure 1-2 SRT Process Flow

1. A customer service representative (CSR) receives a request.

2. The CSR creates a service order and enters it into the customer relationship management (CRM) system. The service order includes information about the subscriber and the selected services.

3. The CRM submits the service order to the Enterprise Application Integration (EAI).

4. Other Operations Support Systems (OSS)/ Business Support Systems (BSS) interact with the EAI to process the order and contribute additional provisioning information to the order. For example, an order may include the following information before it is submitted to ASAP:

   • MSISDN

   • IMSI (SIM details)

   • GSM bearer service details

   • Supplementary services list (CFD, CWT)

   • KI (SIM details)

   • Algorithm (SIM details)

   • Carrier Code

   • Profile

   • OIC

   • Welcome message

5. The SRT receives notification from the upstream EAI bus that a message is available and an order is ready to be processed. The SRT determines that this notification represents a new service order.

6. The message headers are saved in the database and managed by the SRT application logic. The actual Java Message Service (JMS) message (including headers and payload) is saved in the database by Oracle WebLogic Server, by configuring the JMS destination (in this case, a queue) to be saved in the database.

   The system translates the new service order by performing the following actions:

   • ASAP creates a new work order template to handle the service order.

   • A new unique work order ID is generated by the system using either a field on the incoming request or predefined custom logic. For example, if multiple CRM systems are used, it may not be possible to find unique IDs from incoming requests because each CRM system may generate duplicate IDs. This possible duplication of IDs may make it difficult to correlate work order IDs. However, the system can be configured to generate a new unique work order ID based on the Originator work order property (to identify which CRM system submitted the request) and the Service Order ID.

   • The system extracts each generic service from the incoming service order. For each generic service, the system does the following:

     • Executes optional custom logic (such as composing one or more ASAP services based on a combination of input parameters and/or tokens and places any derived ASAP services on the ASAP work order. For example:

       "C_", action, service, technology, softwareLoad
       

     • Determines if there are statically-defined ASAP service mappings, executes any optional spawning logic for each (for example, if a network element identifier was not present on the work order, a certain CSDL may be excluded from the ASAP order), and places the appropriate ASAP services on the ASAP work order.

     • Executes optional custom logic for each statically-defined ASAP service and places any derived ASAP services on the ASAP work order.

   • Using predefined mappings (including optional/required parameter configurations), the system identifies the parameters associated with each ASAP service that has been placed on the order and extracts values from the parameters received on the service order. The ASAP parameters are added to the ASAP work order. Incoming parameters are mapped to outgoing parameters.

   • Using a predefined configuration, the system identifies the default values for parameters whose values are not available on the generic service order. The default values are added to the ASAP work order.

   • Using a predefined configuration, the system executes any custom logic that is defined for any ASAP parameters. For example, network element ID parameters (in this case having no incoming service order value) will have preconfigured logic defined that will be used to retrieve a set of (possibly indexed) network element IDs.

     
     

     Note: If the data required to provision the service is not provided by the original service request application, the SRT can retrieve data from external systems other than the order entry or CRM system. You can use these extensions to access external data from another system such as an inventory system. For example, the extension could retrieve the NE ID of a switch and then update a CSDL parameter.

     
     
     
     

     Note: If the SRT goes down after saving the message context and creating the work order in SARM, it is not necessary to send another CreateOrderByValueRequest. After a message has been received from upstream and the transformed createOrderByValueRequest has been delivered to the Java SRP's queue, that transaction is complete and does not need to be repeated in the event of SRT failure. When the SRT starts again, the next message will be an ASAP event. This event will be picked up by SRT, the appropriate plug-in launched, the context loaded from the database by using the work order ID, and then a transformation of the event to the upstream's format is executed and delivered back upstream.

     
     

7. After successfully receiving the generic service order, generating the ASAP work order, and performing the service translation, the system submits the work order to ASAP and waits for a response.

8. The system receives a response from ASAP indicating that the work order has been successfully submitted.

   
   

   Note: If the SRT goes down while it is processing orderComplete or OrderFailEvent, when the SRT starts back up, it will identify unprocessed messages in the topic and will launch the appropriate plug-in to handle these messages, as though the events had just been delivered.

   
   

9. The system notifies the EAI that the associated generic service order has been successfully submitted to ASAP.

10. Externally (downstream), the ASAP work order is decomposed into atomic actions.

11. The system receives notification from ASAP that the work order has either succeeded or failed.

12. The system retrieves any related information/error messages associated with the work order from ASAP.

13. The system notifies the EAI that the corresponding generic service order has either succeeded or failed and provides the corresponding information/error message.

14. The EAI notifies the CRM of the success or failure of the order.