TTM 4.

Siebel 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

Xerox Internal Use Only

Table of Contents
1.
2.
3.
4.

Revision History.......................................................................................1
Purpose....................................................................................................2
Solution Design........................................................................................2
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 & Signatures12

Xerox Internal Use Only

2. Purpose
The purpose of this document is to present Wipros high level design for XSAT Siebel
Release 2.2.3.

3. Solution Design
Following requirements have been addressed in this document:
1.
2.
3.
4.
5.

Enable XSAT user to inspect the call close data in Siebel

Enable to send the Status Updates to NSPs that service FWSS assets.
Enable to capture error from NSP if the transaction fails.
Send XSM Source Id to NSPs.
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 NSPs.
4. 678949 XSAT R2.2.3 - Status Updates to NSPs.
Integration Details:
Mechanism: Web Services
Number of interface to be modified: 2
Integration 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: 2
Workflow Policy Modified:1
Architecture and Design: Discussed in the following section.

4. High Level Solution Design

4.1

Call Close View

Layout (Mock-up):

Call Close Siebel View

Data Mapping and SR Detail Tab Layout Requirements 11-04-13.xlsx

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 SPs 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
RGs 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 RGs with the same Dispatch type
and Dispatch Value for Prism.
3. Send to Click will be NO for all these RGs.
4. Prism SPs 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 Scenarios 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
its 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 RGs 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 SPs 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 projects approval matrix to determine the required approvers and
reviewers.

Role

Name

Signature

Date