2 2 3 High Level Solution Design v14

TTM 4.0Siebel XSAT 2.2.3

High Level Solution Design

Version 1.4

©2012 Xerox Corporation. All rights reserved. Xerox and the sphere of connectivity design and all product names mentioned in this publication are trademarks of Xerox Corporation in the United States and/or other counties.

Copyright protection claimed includes all forms and matters of copyrightable material and information now allowed by statutory judicial law or hereinafter granted, including without limitation, material generated from the software programs displayed on the screen such as icons, screen displays, or looks.

Other company trademarks are also acknowledged.

Printed in the United States of America.

Changes are periodically made to this document. Changes, technical inaccuracies, and typographic errors will be corrected in subsequent editions.

Revision History

Date Version Description Author

09/02/2013 1.0 Initial Draft Wipro Team

09/02/2013 1.1 Modified the HLD Document based on the Initial Review.

Wipro Team.

09/12/2013 1.2 Modified the HLD Document based on the ARB meeting inputs

Kameswar, Rose, Dave Lewis.

09/13/2013 1.3 Modified the HLD Document base on the internal review

Kameswar, Owens Becky

09/27/2013 1.4 Modified the HLD Document base on the internal review to add information about cancel transaction.

Wipro team

i Xerox Internal Use Only

Table of Contents

1. Revision History.........................................................................................1

2. Purpose.....................................................................................................2

3. Solution Design.........................................................................................2

4. High Level Solution Design.......................................................................3

Call Close View.............................................................................3

Status Updates to NSP...............................………………….........5

Log Error From Barrister.................….. …………………………..10

XSM Incident Id Changes.…. …………………………………………11

5. Approval & Signatures……………. ……………………………………………12

ii Xerox Internal Use Only

Siebel XSAT 2.2.3 Solution Design

2. Purpose

The purpose of this document is to present Wipro’s high level design for XSAT Siebel Release 2.2.3.

3. Solution Design

Following requirements have been addressed in this document:

1. Enable XSAT user to inspect the call close data in Siebel2. Enable to send the Status Updates to NSPs that service FWSS assets.3. Enable to capture error from NSP if the transaction fails.4. Send XSM Source Id to NSP’s.5. Send Call Close data to NSPs that service FWSS assets.

Below are the corresponding RFCs:

1. 642421 - (631877 - Action) XSAT R2.2.3 - Call close view.2. 674788 – XSAT R2.2.3 - XSM Incident Number to Barrister.3. 678959 – XSAT R2.2.3 - Log Error into the SR history when there is an error

in Notification transaction in the web service to NSP’s.4. 678949 – XSAT R2.2.3 - Status Updates to NSP’s.

Integration Details:Mechanism: Web ServicesNumber of interface to be modified: 2Integration Partners: Antenna, Siebel, Prism, Barrister

Siebel UI Changes:

Number of Views: 1 (new)Number of applets: 2 (new)Layout: Discussed in the following section

Workflow Modified: 2Workflow Policy Modified:1

Architecture and Design: Discussed in the following section.

3 Xerox Internal Use Only

4. High Level Solution Design

4.1 Call Close View

Layout (Mock-up):

Design Considerations:1. Capability in Siebel UI for user to inspect the call close data.2. SR has a 1:1 relationship with CX_CALL_DOC_X and 1: M relationship with

CX_CALL_DOC_XM.

Assumptions:1. All fields in this view are read-only for all the responsibilities that have the access to SR

view.2. Purpose of the Call Close View - analyzing the Call Close data for the call.3. In case of Canadian Remote solve, we are expected to populate the data if we get the

data for the call.Questions:

1. Any change to the field/tab captions that you would like to suggest? 2. Some of the columns in the CX_CALL_DOC_XM are used to store multiple kind of

information depending on the Type. The below document shows which columns are updated for each type. Hence how do we name these columns in UI?



4.2 Status Updates to NSP

Current Design:

Status Updates from Device



Proposed Design:

Design Considerations: (Below Prism is being used as an example of an NSP that is using SP’s to take calls).

1. Call is created and Assigned to the Default Prism Id.2. Auto Notifications will be sent to Prism in the 3rd party route as webservice today.


3. Prism system uses Prism App (webservice) to accept the call, status in Siebel is accepted.

4. When Prism SP does an Accept now from A3 Client, XSAT will check the following : Employee details are available in Siebel (existing) Check if the employee is Active in RG (existing) If Assigned Engineer on the SR is not same as the Antenna Engineer from the

accept now and the Accept now flag on the SR is not Y, a new method will be called to do the following:

Check the Dispatch Type of the RG is Webservice

Reject the Call in Siebel and send a Reject Push to antenna.(existing)

Set the SR Status in Siebel to Accepted

Change the Assigned Engineer to Antenna Engineer from accept now.

Update SR History.(existing)

Send an Update service request push to antenna.(existing)

Send a transaction to Prism based on the following condition:

1. If the source of the Accept Now (Antenna) does not match with the service provider (XRX_XSAT_PRISM) on the RG of the SR then status updates will be routed to the RG’s service provider (PRISM System) on the SR through Siebel.



Notes: Outbound Transaction to prism will happen only after the successful updates in Siebel. In case of

any unsuccessful transaction we have to capture the error message in the SR History. As per the existing process email will be sent to production support.

Else existing process will be done.

5. Prism SP does status updates and closes the call using A3 client/Device. All updates and call close data will be sent to prism from Siebel via a web service.

6. In case of a Remote Solve(US), following actions will be taken,i. Call will be cancelled in XSAT.

ii. Call will be cancelled in FWSS.

iii. Send call cancel update to Prism.

7. If XSAT receives a Call Cancel from FWSS (through EIPC); independent of the status of the call, following actions will be taken,

i. Call will be cancelled in XSAT.

ii. Call is then removed from the A3 Client.

iii. Send call cancel update to Prism.

8. Following changes will be done in Customer Wants for Xerox calls assigned to NSP

If a call cancel comes (CW = 03) in for a SR with status ‘Accepted’ and Assigned Engineer = Integration Login (e.g. PHNXINT_PRSM). Then we do the following,

Set the status to ‘Cancelled’ in Siebel.


Send call Cancel to Prism.

Send a transaction to Antenna which will cancel the call in FWSS

If a call cancel comes in for a SR with status ‘Accepted’ and Assigned Engineer as NSP Engineer. Then we do the following,

Send an update to Prism with SP Note.

Prism will inform Prism SP to do Remote Solve.

Prism SP uses A3 client to do a Remote Solve.

This in turn sets the status to ‘Cancelled’ in Siebel.

Send the transaction to Antenna to cancel the call in FWSS.

Trigger Points:1. Device/ A3 Client.2. EIPC.3. Customer Wants.

Assumptions:1. Prism RGs will have a Dispatch Type = Web Service.2. There will be Multiple RG’s with the same Dispatch type and Dispatch

Value for Prism.3. Send to Click will be NO for all these RG’s.



4. Prism SP’s will use only A3 client/Device to do any status updates and call close. (Except for the initial ‘Accepted’ received from the Prism web service based off of the Notification sent to them.)

5. Prism will not send a systematic ‘Rejected’ status to XSAT.6. Status updates done manually through Prism System (due to out of sync

scenarios) will not be sent to XSAT.7. There is no logic to send the data to Click.8. The Scenario’s Covered in Step 4 of the design consideration

Prism SP does an Accept now from A3 client on an SR which has been assigned to Default Prism Sp. Updates and call close data are also sent to prism

Xerox SP does an Accept now from A3 client on an SR which has been assigned to Default Prism Sp. Updates and call close data are also sent to prism for the Xerox sp.(As the RG of the SR is Prism)

Prism SP does an Accept now from A3 Client on an SR which has been assigned to another Prism Sp. Updates and Call close data are also sent to Prism

Xerox SP does an Accept now from A3 Client on an SR which has been assigned to another Prism Sp. Updates and Call close data are also sent to Prism.

If a Prism SP does accept now on a Xerox call then it’s going to be a business process to handle the call. Existing functionality will leave the call in open status because the employee details will not be available in click. This call will be monitored as per existing SSS process to resolve the open calls.

9. On sending status update push transaction to Antenna on Reject. The Gateway does an undispatch in FWSS and will remove the call from the Device.(existing)

10. On Sending a Status update push transaction to Antenna on Accepted. The Gateway does a dispatch in FWSS and send to device. (existing)

11. No Extra validations are necessary before sending status updates to Prism.

12. Visibility issue with respect to other RG’s in the A3 client is not part of scope.

13. All A3 client function like Unlisted Call creation, broadcasting of messages is out of scope for changes.

14. Integration framework performance monitoring can be used to check performance of transactions.

15. Prism SP’s need to be active in the RG so they can be assigned on the SR. This needs to be taken care by ASM team.


Issue:1. Call Queue in A3 Client will handle only 50 calls. Resource groups must be

defined to ensure no more than 50 calls for the Call queue. From a business process perspective how will the SP search through more than 50 calls to find their call?

4.3 Log Error from NSP:

Design Considerations:

1. Whenever there is error from NSP when sending the notifications and Updates through the gateway. We need to capture the error and write the error into SR history.

2. On getting the error update set the Siebel Error Queue Flag to ‘Y’ on the SR.

3. On successful update of the transaction to NSP the Siebel Error Queue Flag is set to ‘N’ on the SR.

Current Design:1. In workflow Whenever XSAT tries to connect to destination NSP system

and is not able to connect then retries to connect based on retry mechanism which includes number of retries and wait time, If fails

2. Then it updates the Performance Log and sends mail to indicated group.3. Further it logs the error in Communication Interface table and Siebel

Error table.4. End of the Workflow

Proposed Design:1. Whenever XSAT tries to connect to destination NSP system and is not

able to connect even after retry.2. Then it updates the Performance Log and sends mail to indicated group.3. Further it logs the error in Communication Interface table and Siebel

Error table.4. Gets the Error from the response from the third party and updates SR

History with the relevant error message and sets the Siebel Error Queue Flag to ‘Y’.

5. End of the Workflow.



Trigger Points:Response to the Web Service transaction sent to Barrister via Gateway.

Assumptions:

1. Error messages cannot be edited.

2. Error Transaction will be captured during the error and SP can still continue the call.

3. The Sample Error message would be as follows:

Unable to send message to + Service Provider of the RG || Error Message captured in the Web service method.

4.4 XSM Incident Id Changes:

Design Considerations:1. Need to Send XSM Source Id field in the notifications to Barrister.

2. Need to Send a value in SR Parent Id in case of continuation calls else it will be blank.

3. Need to Send a blank vlaues for the the following tags ATTRIB_06 to ATTRIB_10, RESTORE_METRIC and RESTORE_TARGET.

4. WSDL Change needs to be done and New WSDL needs to be sent to Barrister.

Trigger Points:Whenever a call is created from XSM.

Assumptions:


1. The Length of the Source System Id field is marked as 50. The Length in Barrister has the value of 30 for the Source System Id field.

2. Additional 9 Columns have been created for future use.

3. XSM has agreed for the new WSDL changes and will be ready by mid-October release.

4. No Validations are done on the XSM Source Id Field.

5. Approval Signatures

Note: Email approvals are allowed in lieu of signatures. Use voting buttons and cut and paste the response tab below. When the approvals have been added, save the document in your project repository. Include the words "Approved/Baselined Version Date" in the Comments field when you check the file in.

Reference your project’s approval matrix to determine the required approvers and reviewers.

Role Name Signature Date


2 2 3 High Level Solution Design v14

Documents

Transcript of 2 2 3 High Level Solution Design v14