Amdocs - TOA Integration v9

TOA INTEGRATION
Amdocs - TOA Integration

Overview
For Internal Use Only

Document Information
Release:
Publication Date:
Catalog Number:
Information Security:
Created:
Account/FOP:
Author:
Editor:
Last Edited:
File Name:
Template:
Copyright © 2014 Amdocs. All Rights Reserved. Reproduction or distribution other than for intended
purposes is prohibited, without the prior written consent of Amdocs. The trademarks and service marks of
Amdocs, including the Amdocs mark and logo, Intentional Customer Experience, CES, Clarify, Ensemble,
Enabler, Return on Relationship, Intelecable, Collabrent, XACCT, DST Innovis, Stibo Graphic Software, Qpass,
Cramer, SigValue, JacobsRimell, ChangingWorlds, jNetX, OpenMarket Inc., MX Telecom Inc., MX Telecom Ltd,
Streamezzo, and Bridgewater Systems are the exclusive property of Amdocs, and may not be used without
permission. All other marks are the property of their respective owners.
Table of Contents
Part I Introduction ................................................................................................................ 1
1 Goals and Scope .................................................................................................................. 1

Scope of the Solution ......................................................................................................................... 2
2 Architecture........................................................................................................................... 3
Architecture Component Diagram ...................................................................................................... 4
Amdocs Components ......................................................................................................................... 6
Amdocs WOM.......................................................................................................................... 6
Amdocs SOM........................................................................................................................... 6
Amdocs Ordering (OMS) ......................................................................................................... 6
Amdocs CRM........................................................................................................................... 7
Amdocs Self Service................................................................................................................ 7
TOA ETAdirect Suite .......................................................................................................................... 8
ETAdirect Enterprise Suite Overview....................................................................................... 8
ETAdirect SmartManage™ ...................................................................................................... 8
ETAdirect SmartRouting™ ...................................................................................................... 9
ETAdirect SmartMobility™ ....................................................................................................... 9
ETAdirect SmartCapacity™ ..................................................................................................... 9
ETAdirect Interfaces ................................................................................................................ 9
Additional Components ...................................................................................................................... 9
Address Management .............................................................................................................. 9
Network Inventory .................................................................................................................. 10
Equipment and Materials Inventory ....................................................................................... 10
Billing (Amdocs Invoicing) ...................................................................................................... 10
Amdocs USM ......................................................................................................................... 10
Notification Manager .............................................................................................................. 10
3 End-to-End Scenarios ........................................................................................................ 11

Sale Order Normal Flow................................................................................................................... 12
Amend or Cancel of Sale Order ....................................................................................................... 12
Reschedule ...................................................................................................................................... 12
4 Logical Data Model Mapping............................................................................................. 13

WOM Main Entities .......................................................................................................................... 14
Work Order ............................................................................................................................ 14
Task ....................................................................................................................................... 14
Information Security Level 2 – Sensitive iii

Proprietary and Confidential Information of Amdocs
Amdocs - TOA Integration Overview
Service................................................................................................................................... 15
ETAdirect Main Entities.................................................................................................................... 16
Activity ................................................................................................................................... 16
Equipment ............................................................................................................................. 16
Property ................................................................................................................................. 16
Resource (Provider) Tree ...................................................................................................... 16
Resource ............................................................................................................................... 16
Bucket.................................................................................................................................... 16
Calendar ................................................................................................................................ 16
Route/Queue ......................................................................................................................... 17
Entity Mapping ................................................................................................................................. 17
Part II API High Level Description .................................................................................... 19
5 API General Considerations .............................................................................................. 21

Security ............................................................................................................................................ 22
ETAdirect as the Provider ...................................................................................................... 22
WOM as the Provider ............................................................................................................ 22
ETAdirect Inbound ........................................................................................................................... 22
ETAdirect Outbound ........................................................................................................................ 23
6 Capacity API ........................................................................................................................ 25

‘get_capacity’ Input .......................................................................................................................... 26
Required Activity Fields ......................................................................................................... 27
‘get_capacity’ Response .................................................................................................................. 28
Determining if Time Slot can be used .................................................................................... 29
Special Scenarios ............................................................................................................................ 30
Checking if Rescheduling is required after Amend ................................................................ 30
Force Booking........................................................................................................................ 30
7 Activity APIs ........................................................................................................................ 31

Head Node ....................................................................................................................................... 32
Data Node ........................................................................................................................................ 32
Appointment Structure ........................................................................................................... 33
Linked Appointments ............................................................................................................. 34
Special Scenarios ............................................................................................................................ 35
“Not Ready For Dispatch” ...................................................................................................... 35
Amend – Before Technician Starts ........................................................................................ 35
Amend - Upsell ...................................................................................................................... 35
8 Outbound APIs ................................................................................................................... 37

Technical Implementation ................................................................................................................ 38
iv Information Security Level 2 – Sensitive

Table of Contents
Message Header Implementation .................................................................................................... 38

Message Body Implementation ........................................................................................................ 38
Use Cases ....................................................................................................................................... 39
Status Updates ...................................................................................................................... 39
Complete WO ........................................................................................................................ 39
Activation Request ................................................................................................................. 39
Diagnostic Test ...................................................................................................................... 39
9 Search API ........................................................................................................................... 41

search_activities Input ..................................................................................................................... 42
List of Properties for ETA....................................................................................................... 42
search_activities Response ............................................................................................................. 42
Part III Summary................................................................................................................... 43
10 Additional Considerations................................................................................................. 45
Open Issues ..................................................................................................................................... 46
Assumptions .................................................................................................................................... 46
Known Limitations ............................................................................................................................ 46
Possible Enhancements................................................................................................................... 47
Roadmap Items ................................................................................................................................ 47
Appendix A ETAdirect Configuration ................................................................................... 49

ETAdirect Integration with Inventory system .................................................................................... 50
Implementing Custom Plug In .......................................................................................................... 51
Business Notification to Technician ................................................................................................. 52
Launch in Context from ETAdirect ................................................................................................... 54
Appendix B Attachments ....................................................................................................... 55

ETAdirect SDK ................................................................................................................................. 56
Capacity Interface .................................................................................................................. 56
Inbound Interface ................................................................................................................... 56
Outbound Interface ................................................................................................................ 56
Self-Care Interface (Search) .................................................................................................. 56
Information Security Level 2 – Sensitive v

Part I Introduction
1 Goals and Scope .................................................................................................................. 1
2 Architecture........................................................................................................................... 3
3 End-to-End Scenarios ........................................................................................................ 11
4 Logical Data Model Mapping............................................................................................. 13
Information Security Level 2 – Sensitive 1

1 Goals and Scope
The document describes the suggested integration between Amdocs systems and the
ETAdirect product offered by TOA Technologies.
The document is a baseline for any new joint project involving implementation of the
Amdocs systems and ETAdirect.
It is intended to serve the sales engineers, solution architects and implementers of a
project and is designed to provide a baseline for an initial implementation.

Scope of the Solution

The scope of the solution is focused on multi-play projects in the residential market. It
covers works orders that are both related to sale orders and non-sale orders (for example,
trouble tickets).
The nature of work orders created for these projects is characterized by the following:
 Work orders may be complex and include several tasks, with numerous permutations
of the task set within a work order
 The solution is fully automated
 There is expectation that the content of the work order might be changed during the
life cycle of the work order
 Work orders commonly include appointments with the customer (although the
solution supports work orders without appointments)
 The work orders are short in terms of duration (no longer than a few hours)
 Technicians have automatic integration from their PDAs to BSS and OSS systems
 A single product does not usually require more than a single technician visit (but
might require additional work outside of customer premises)
 Technicians usually have the required equipment and materials in their truck
inventory
Although this is the focus, the solution still covers a large portion of what is required in
other business scenarios (corporate services, network build, etc.).
2 Information Security Level 2 – Sensitive

2 Architecture
The architecture of the solution is based on the inclusion of Amdocs Work Order
Management (WOM), which is the only module of Amdocs system that will interface
with ETAdirect.
The solution considers direct integration (not via ESB) within the Amdocs components
and between Amdocs WOM and ETAdirect.

Architecture Component Diagram

Figure 2.1 Architecture Component Diagram
cmp Architecture
Amdocs BSS
Amdocs Self Amdocs OMS
Amdocs CRM Equipment Update
Serv ice
(Non Sale Order) Fulfillment

Status Update
WO Status Update (KSU)
(Non Sale)
Create/Update/Cancel WO
Quey WO Details
Fuflillment Request
Amdocs OSS
Submit WO (Sale Order)
Query Available Appointments Amdocs WOM Amdocs SOM
WO Status Update
(Sale Order)
Reserve Appointment
Technician Requests
Get Capacity Equipment

/Provisioning/
WO Status Update
Search Activities Test Update
Notification
Create/ Update
/Cancel WO
TOA
ETA Direct

Chapter 2. Architecture
Figure 2.2 WOM to ETAdirect API integration Architecture

Amdocs Components
Amdocs WOM
Work Order Management (WOM) provides an integration and abstraction layer for
managing workforce activities. It manages work orders (WOs) from scheduling to
completion. WOM stores the work order history and includes a user interface for
searching and viewing work order details.
Work Order Manager has several functional components:
 Scheduling – This component provides services for scheduling an appointment and
creating a work order.
 Work Order Management – This component manages the life cycle of a work order
from its creation until its completion.
 Work Order Completion – This component is responsible for all validations and
activities that should be performed when the work order is completed.
 Work Order Queries – This component provides a list of queries initiated from
external systems.
WOM supports all the various types of originating orders: sales orders, non-sales orders,
maintenance orders, and miscellaneous orders.
WOM is a module of Amdocs Service Management, and re-uses the system foundations
for its internal processing.
Amdocs SOM
Service Order Management (SOM) is the Amdocs application that is responsible for
managing the entire fulfillment process, which begins upon completion of the order
capture until the service is fulfilled. It includes decomposition, orchestration and
interaction with numerous systems.
Amdocs Ordering (OMS)

Amdocs Ordering manages the entire life-cycle for orders, including:
 Order capture
 Order dispatch to network fulfillment and other delivery systems
 Order notification to billing and other systems
 Order modification
 Order cancelation
Amdocs Ordering manages orders for new products and orders for changes to existing
products, such as a configuration change, a disconnection, or a suspension. Amdocs
Ordering maintains the state of products during ordering and after order completion.
The Amdocs Ordering user interface, which is integrated with Amdocs CRM, allows
service representatives to negotiate order details with customers. The user interface also
provides facilities for handling errors and exceptions during order delivery.

Amdocs CRM
Amdocs Customer Relationship Management (CRM) provides agent-facing BSS
capabilities covering sales, service, and administration of the customer relationship.
Amdocs CRM is particularly optimized for telesales, teleservice, and blended call
centers, focusing on:
 Customer management, including managing contacts, accounts, and subscribers
 Interaction management, including a unified agent desktop for effectively handling
inbound calls and emails
 Customer Service & Support, including diagnosis of issues and dispatch of each issue
as relevant to case management, part requests and/or field dispatch. This is done
according to Service Level Agreements, Entitlements, and Contracts in place
between the customer and the service provider.
 Sales, including account management, forecasting, territories, and telesales
capabilities
 Billing Care, for managing customer billing information through integration with
Amdocs Billing modules.
Amdocs Self Service

Amdocs Multichannel Self Service provides end customers with access to the service
provider’s business through web portals, tablets, and smart mobile phones. Customers
can perform such tasks as:
 Order products
 Query their bills
 Track their unbilled usage
Amdocs Multichannel Self Service reduces the load on traditional call centers and
provides end customers a consistent experience across multiple channels.
The Amdocs Multichannel Self Service user interface (UI) in version 9 provides an out-
of-box UI on top of the Amdocs User Experience foundation in order to support multiple
device types.

TOA ETAdirect Suite

Please note that not all ETAdirect applications (components) shown in Figure 2.3 are
necessarily included in this integration model.
Figure 2.3 ETAdirect Suite of Applications (Components)
ETAdirect Enterprise Suite Overview

ETAdirect brings together a full suite of integrated field service and appointment
management software tools in one natively Web-based application. It is the only mobile
workforce management (MWM) solution focused on delivering a unified and enhanced
customer experience, using predictive analytics to better plan the work day coupled with
intelligent, automated and predictive customer communications that bring customers into
the appointment information loop and keep them informed. ETAdirect’s unique
performance pattern tracking and recognition algorithms provide a comprehensive, real-
time “time and motion” study of operations, creating a veritable work “fingerprint” for
each and every field resource. This fingerprint improves planning and on-time
performance with a keen focus on tailoring work to each worker’s profile, with the
ultimate goal of keeping customer commitments.
ETAdirect SmartManage™
ETAdirect SmartManage serves as the command center for field operations and the
central hub for viewing and managing real-time information about resources and their
activities across the entire field organization, as they happen. Dashboards, standard
reports and real-time predictive screens and alerts enable users to make the most effective
and timely business management decisions. Integrated alerting and jeopardy management

capabilities empower users to identify and resolve potential issues proactively,

contributing to a positive customer experience.
ETAdirect SmartRouting™
ETAdirect SmartRouting intelligently allocates work to field resources via a rules-based
engine using a genetic algorithm that ensures the right technician arrives in the right place
at the right time, meeting SLAs while minimizing travel time, mileage and other
associated costs. ETAdirect is arguably the fastest and most sophisticated job allocation
and routing optimization engine in the market today.
ETAdirect SmartMobility™
ETAdirect SmartMobility provides a device-agnostic Web-based app for field employees
to access their work orders, manage work-related activities and communicate in real time
with dispatchers and other back-office personnel. ETAdirect’s browser-based mobility
app uses HTML5 protocol to provide 100% accessibility within the browser, regardless
of whether the user is online or offline.
ETAdirect SmartCapacity™
ETAdirect SmartCapacity provides a real-time predictive view into the amount of work
that can be performed by the available scheduled workforce. ETAdirect shows actual
capacity of a given workforce based upon the historical performance of the individuals
working on any given day and capacity controller inputs. This helps to ensure optimal
appointment booking and scheduling, with minimal idle time and virtually no overtime
for appointed work.
ETAdirect Interfaces
The ETAdirect suite includes a comprehensive set of API SDKs to enable rapid and
highly flexible integration with external systems and/or middleware platforms. A highly
sophisticated Notification module, together with internal trigger events, enables complex
scenarios to be configured based upon almost any event or action. These scenarios can
then update ETAdirect or external systems, including email gateways, SMS gateways,
IVRs etc.
Additional Components
Some optional additional components that may participate in the solution are described
below.
Address Management
In most of the implementations there is a single system that masters all installation
addresses. In typical scenarios, WOM queries address management for receiving full
address details that are required for the Work Order creation. This component is a critical
part of the solution.
Address management might also control access points, in which case WOM might need
to use this information or to update it. For example, information indicating whether a
cable is connected to the address.

Network Inventory
Network inventory may or may not be managed in the same system as the address
management. Typical interaction between WOM and the network inventory is for
network-ready technologies like cable for which WOM can query the topology and use it
as part of the parameters it needs to calculate or send it as information to the technician.
Equipment and Materials Inventory

WOM typically handles only serialized equipment and may need to integrate with
equipment inventory to validate equipment installed by technician and to receive
technical details of the equipment. Another potential integration point is to update
equipment location/responsibility between the customer and the technician.
ETAdirect allows for an inventory to be created and associated against a resource such as
the technicians’ inventory pool or the customer installed inventory pool using the
standard inbound interface and provides means by which to manage the inventory using
the standard supplied ETAdirect interfaces. For more details refer to appendix A,
“ETAdirect Configuration”.
Billing (Amdocs Invoicing)

It is common for WOM to create customer charges based upon actions initiated by
technicians. Such integration is already implemented with Amdocs Invoicing.
Amdocs USM
USM is a component that is part of Amdocs Service Management. WOM may potentially
integrate with USM to query information regarding existing services of the customer in
order to send it to a technician.
Notification Manager
Amdocs is now in the process of developing Notification Manager, which may be used in
the roadmap for the integration.
Amdocs needs to provide TOA with more information regarding Amdocs Notification
Manager.

3 End-to-End Scenarios
The chapter describes several end-to-end scenarios that demonstrate the integration. The
scenarios chosen here are for sale orders initiated by OMS. Other scenarios, like trouble
tickets from CRM or Self Service scenarios, result in the same integration points between
Amdocs WOM and ETAdirect, and are simpler in their nature.
Tip: For first time readers it might be advisable to go over the scenarios only after
understanding the different interfaces that are described in the next chapters of the
document.

Sale Order Normal Flow
Sale Order Normal

Flow.xlsx
The flow describes the integration around sale order flow.

It includes several phases:
 Negotiation – in this phase the customer is allotted an appointment slot
 Delivery – this phase starts when the negotiation is completed and includes all the
backend processing and updates
 Execution – this is the phase in which the technician physically executes the work
order
 Completion – this is the point at which the work order is reported as completed and
notification needs to be sent as a result
Amend or Cancel of Sale Order
Amend or Cancel
Sale Order.xlsx
The flow describes a scenario in which the customer calls again after initial negotiation to
either cancel the order or amend it.
Reschedule
Reschedule.xlsx
The flow describes a scenario in which customer want to reschedule a work order without
changing its content.

4 Logical Data Model Mapping
The chapter describes the main entities in both Amdocs and ETAdirect and how they are
being mapped.

WOM Main Entities

Work Order
A work order is the main entity in WOM and represents a single technician visit. Every
work order has an associated life cycle and state machine. The state machine is used for
integration with ETAdirect, as illustrated below.
Figure 4.1 WOM Work Order State Machine
stm Work Order
Exit for
Aborted
Aborted CreatedSubmitted
WO is Cancelled
Work Order Created in WFM with Due Date

Wo is Cancelled WO is Submitted without Reservation [WO without Apointment]
[WO without Apointment]
Created Reserved Submitted Work Order Ready for Dispatch

Open Completed
WO is Created Work Order Created in WFM Submit Request WO is Completed
Start End
WO is Cancelled
WO is Cancelled
WO is Cancelled
Cancel In Progress
Cancel Process Completed
Legend
Cancelled
WOM Status
WOM and WFM Status
Exit for
Cancelled
A work order has a unique ID that is generated by WOM and is exposed to other
components. It holds attributes that represent the work order parameters that are required
for categorizing the work order, for capacity management and work order creation, the
appointment details, the technician assignment, and progress details.
Every Work Order is related to a single address and to a single customer.
Task
A task entity represents a single action that the technician needs to perform as part of a
work order. Every task also has a life cycle that is similar to the life cycle of the work
order (in the ETAdirect Integration), although tasks related to a work order can be in a
different state from the work order (for example, when adding new tasks to an existing
work order).

Chapter 4. Logical Data Model Mapping
A task has a unique ID that is generated by WOM and is exposed to other components.
The main attribute of a task is the task code that represents the exact activity required by
the technician.
Tasks are most commonly derived from one or more source entities that are mastered in
other Amdocs applications. Typical entity sources include:
 Order action in OMS
 Cases in CRM
Service
A service refers to a service provided to the customer by the service provider.
For the purpose of simplification, WOM usually represents the service in a slightly
different way from its representation in SOM and OMS.
A service in WOM has a type. Typical WOM service types include equipment, the
porting of equipment, a telecommunications service, or a non-provisioned service;
however, the entity is not limited to these types only. It also has a catalog code - a unique
ID - which is determined by OMS or SOM and as well as a list of attributes that
characterize it (and usually one attribute serves as the main identifier).
Services exist beyond the work order life cycle. The service entity in a WO represents the
snapshot of the service within the work order.
For a service to be related to a work order it is necessary for it to be part of the sales order
that triggered the work order or that it exists in the address of the work order.
Services are grouped in a hierarchy, so one service can be the child of another service
(for example, a port is always a child of an equipment service).
Each service has an action that represents what is required to be performed on the service
as part of the order (for example, connect it, disconnect it, or keep it unchanged), and a
task can be associated to a service.
A service, as part of the work order, also has a status that represents the activities
performed on the service as part of a work order and state machine.
Note: WOM does not hold any WFM resources (technicians, vehicles, etc.) as part
of the entities it manages.

ETAdirect Main Entities

Activity
An Activity represents any work that can be performed by a Field Operator such as a
Technician or an Engineer. An activity can represent a customer appointment that is
associated to a work order. ETAdirect supports both customer facing and non-customer
facing activities. Activities can be grouped in ETAdirect; for example, ‘Internal’
activities (one-on-one, warehouse activities and lunch) and ‘Customer’ activities (work
orders). One activity may include one action (for example, Install Internet Modem) or
multiple actions (for example, Install Triple Play). Activities include multiple attributes
(for example, customer name, services, and address). Any custom property can be
defined and added as an attribute to an Activity in ETAdirect.
Equipment
The attributes of Equipment, otherwise known as Customer Premise Equipment (CPE) or
Inventory, are typically driven by serial number and can include multiple attributes
(Model, Category, etc.) as well as any custom property as an additional attribute.
ETAdirect allows for Technicians / Engineers to have an inventory of equipment and also
supports the installation of inventory at the job site, removal of equipment from the job
site to the van, and the exchange of two pieces of equipment between the van and the site.
Engineers also typically engage with equipment to activate it or test it. For the purposes
of this integration, ETAdirect will be configured with a trigger to notify Amdocs
management systems when these transactions take place.
Property
A Property, otherwise known as a field comprises any single piece of data (for example,
customer first name).
Resource (Provider) Tree

The Resource (Provider) tree serves as the hierarchy (tree-like structure) of resources.
Resource
Resource is the performer of activities (for example, technician)
Bucket
A Bucket is a branch in the resource tree that can hold resources (including other sub
buckets) and activities. The ETAdirect Routing Engine will only accept non-assigned
activities for assignment optimization from a bucket
Calendar
Calendars define timeslots during which technicians are available for performing
activities.

Chapter 4. Logical Data Model Mapping
Route/Queue
Activities assigned to a technician.
Entity Mapping
Every WOM work order is mapped to an activity entity in ETAdirect.
The tasks of the work order are represented by a property in ETAdirect from the type of
table. The task list is visible to the technician, and the technician can be enforced as part
of the completion workflow in ETAdirect to report whether each task was completed or
not.
The services of the work order representation remains an issue that needs to be addressed.
Since the entity is complex and hierarchical, it is very difficult to represent it in two
dimensional formats such as tables. Therefore, a tree view seems to be the natural
representation, but is only suitable for engineers who work with larger screen devices (for
example, laptops or tablets).
There are several options going forward in order to solve this issue:
1. Use a custom plug-in – refer to “Implementing Custom Plug In” in appendix A
2. Use enumeration filtering – this is a new feature of ETAdirect version 4.5, called
‘Linked Properties’
3. Perform further development either in ETAdirect and/or Amdocs.
Note: One option for future development is the creation of an Amdocs OSS2GO
application that will be launched in context from ETAdirect.

Part II API High Level Description
5 API General Considerations .............................................................................................. 21
6 Capacity API ........................................................................................................................ 25
7 Activity APIs ........................................................................................................................ 31
8 Outbound APIs ................................................................................................................... 37
9 Search API ........................................................................................................................... 41

5 API General Considerations
The chapter describes general considerations for designing the APIs between Amdocs
WOM and ETAdirect.
In general, all APIs use web-services as the means of technology.
Note: The APIs are not described in IDD (Interface Detailed Design) format. The
exact list of fields and their format will be determined as part of the initial
implementation.

Security
ETAdirect as the Provider
The body includes an authentication section used for every transaction, preceding the
data section:
<user>
<now>2013-01-29T15:44:00-05:00</now>
<login>admin</login>
<company>sunrise</company>
<auth_string>09c62466cc53c4bd81728959603</auth_string>
</user>
Where:
 now = ISO 8601 time (for example, 2011-03-21T09:25:02+00:00)
 company = provided by TOA
 login = provided by TOA
 password = provided by TOA
 auth_string = hashing: md5 (now+md5(password))
WOM as the Provider

WOM exposes an API to retrieve a valid ticket. The ticket needs to be sent in the web
service request as part of the header. This is based on Web Services Security (WSS)
standards.
ETAdirect Inbound
The Inbound interface is used to insert or update activity and inventory data to
ETAdirect. It enables full and incremental upload of activities and equipment into
ETAdirect (for example, adding a new activity to ETAdirect; assigning activities to a
specific day for a resource, group of resources or all resources; updating, canceling, re-
assigning, or rescheduling an existing activity and equipment in ETAdirect). Any number
of external systems can call the Inbound API to pass this data from many original source
systems.
Some principles of using the inbound APIs:
 WOM will use only activity-related APIs
 WOM will not utilize the Full Upload option
 WOM will not use the Multiple Commands options

Chapter 5. API General Considerations
 WOM will not send files. Although sending files can be considered a future
enhancement, if necessary this functionality can be satisfied by sending a link to the
document repository
Note: Creation and update of an activity can both be achieved using the
update_activity command type of the inbound_interface_request.
When the inbound method is used, it will attempt to update *ALL* the
settings/properties of the activity to those contained in the message. Thus, care
needs to be taken with this feature so that it does not inadvertently change
properties that should not be changed. For example, if the external_id is contained
in the message of the update_activity, which updates an existing activity, that
activity will be placed back in the bucket, even if it has already been allocated to a
technician.
ETAdirect Outbound
The ETAdirect Outbound interface is used to transfer data from ETAdirect to external
systems. The Outbound interface serves to inform external systems about events, such as
activity re-assignment, completion, cancellation, inventory manipulations, alerts related
to service violations, etc.
The mode of work will be implemented using ‘simple mode’ workflow and not ‘advance
mode’, which is the alternative option. WOM will be able to receive outbound interface
information in batches, store it in an internal table, and process the messages in various
transactions by querying the table.
WOM can either return a final response for the batch (status “Passed” in
send_message_response) or send an acknowledgement (status “In Progress”),
If the status that WOM sent was not final, WOM will need to call the API of
set_message_status to update the final status of the message (“Passed” or “Failed”).
In general, for status updates WOM will immediately respond with final message status,
but for activation requests for which technicians must be notified regarding the status,
WOM will respond with acknowledge before later sending the final status using
send_message_status.
For more details refer to Business Notification to Technician.

6 Capacity API
Capacity has one method that is in use – ‘get_capacity’. This API is used during the
Negotiation phase with the customer to check the availability of capacity and, based on
the response received, to commit a time slot to the customer.
Amdocs WOM as part of its functionality determines the input parameters and
normalizes the output to abstract the method to the other Amdocs client systems.

‘get_capacity’ Input
Following are the main input parameters sent by Amdocs WOM and the way in which
the input parameters are determined.
Table 6.1 ‘get_capacity’ Main Inputs
Heading Heading Heading
date Specific day to search for The input includes multiple
capacity elements that each represent a
specific day to search the
capacity
location Capacity bucket WOM will execute rules
based on Address parameters
to determine this field
calculate_duration Indicator whether to calculate If this field is sent as true,
duration other relevant fields for
calculation should be sent.
In general, it is neither
recommended to calculate the
duration not to take the
duration of the current WO
into account when
determining availability, but
since presenting the estimated
duration to the customer is a
valid business requirement it
might be needed.
calculate_travel_time Indicator whether to calculate It is not recommended to
travel time calculate the travel time. It is
unlikely to be an important
parameter from the
customer’s perspective.
calculate_work_skill Indicator whether to calculate In general WOM will send
the work skill or not this indicator as true, as it is
preferable not to hold logic in
WOM to calculate the skills
explicitly. WOM will send
the relevant activity fields
required for the work skill
calculation.
time_slot Indicate specific time slot for WOM will not send this field,
the search and will perform filtering if
required internally.
work_skill Required work skill WOM will not send this field,
but rather will require the
calculation of the skills.
activity_field Field of activity that is WOM will send the list of
required for the calculation fields required for the
calculation, as described in
the chapter below

Chapter 6. Capacity API
Required Activity Fields

The chapter describes the common implementation of activity fields that are required in
the capacity calculation.
 worktype – this is a field that represents the activity type and is calculated by WOM
based on defined rules
 points – this is a calculated field that may impact the duration. If calculation of
duration is already required as part of Capacity, it will need to have already been sent
there.
In addition there might be other custom properties required to be sent here based on the
implementation, in which case WOM will have the rules for calculating them.
Below is an example of a get_capacity request with one time slot (08:00-10:00) and for
the 18th and 21st of July (in this case):
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:toa:capacity">
<soapenv:Header/>
<soapenv:Body>
<urn:get_capacity>
<user>
<now>2012-07-18T13:37:00-05:00</now>
<login> . . . </login>
<company> . . . </company>
<auth_string> . . . </auth_string>
</user>

<date>2012-07-18</date>
<date>2012-07-21</date>

<location>routing</location>

<calculate_duration>1</calculate_duration>

<calculate_travel_time>1</calculate_travel_time>

<calculate_work_skill>1</calculate_work_skill>

<time_slot>08-10</time_slot>


<work_skill>UPGRADE</work_skill>

<activity_field>
<name>aworktype</name>
<value>33</value>
</activity_field>

<activity_field>
<name>ccity</name>
<value>ALTA</value>
</activity_field>
</urn:get_capacity>
</soapenv:Body>
</soapenv:Envelope>
In this get_capacity request example, the worktype value of 33 corresponds to the ‘Add
Outlets’ activity type as configured in the demo. ETAdirect will use an ID value of 33 to
get the travel stats from the Appointment Duration Keys table. If ETAdirect is unable to
find stats matching value 33, then ETAdirect will provide the default travel duration
value (48 minutes in the case of the demo environment) in the response.
‘get_capacity’ Response
The following table details the main output parameters sent by ETAdirect and the way in
which WOM processes them.
Table 6.2 ‘get_capacity’ Main Outputs
Name Description Comment
activity_duration Predicted duration of the It is returned if the input
activity in minutes requested calculation of the
duration
activity_travel_time Predicted travel time in It is returned if the input
minutes requested calculation of the
travel time
capacity Node that represents a The node is returned several
specific slot times for each skill. The
preferred method of referring
duplicate time slots to
different skills is an open
issue
capacity/date The date of the slot

Chapter 6. Capacity API

capacity/ time_slot A string representing the There is a single field that
capacity represents both the slot code
and the hours. WOM will
need to break this field and to
determine the exact hours
capacity/ work_skill The work skill for this slot The use of this field remains
an open issue
capacity/ quota Total number of minutes WOM will need to include
quota in the bucket for that rules in order to determine if
time slot scheduling is allowed or not
in this time slot.
Determining if Time Slot can be used

ETAdirect can return multiple nodes for a specific time slot, each related to a different
work skill. A time slot can be used for the activity only if all work skills have sufficient
availability.
According to best practice, a ratio or fixed number of minutes should be added to allow
for overbooking/under booking (overbooking is represented by a negative number).
The algorithm will be as follows:
1. Go over all work skills for a specific time slot.
2. For each work skill:
a. Ratio based rule:
If (quota-available+duration)/quota < allowed ratio then work skill is available
b. Fixed minutes based rule:
If (available – duration) >number of minutes then work skill is available
3. If all work skills are available then the time slot can be used
The relevant rule to be used is dependent on the implementation. We can either use a
single rule in the system or the rule may be dependent on other parameters like area,
customer type, work type, etc.
WOM will also store all the work skills in order to allow analyze amended order.
An example of a get_capacity response for the 18th and 21st of July, as stated in the
previous request, is as follows:
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://. . . ">
<SOAP-ENV:Body>
<urn:get_capacity_response xmlns:urn="urn:toa:capacity">
<activity_duration>26</activity_duration>
<activity_travel_time>14</activity_travel_time>
<capacity>
<date>2012-07-18</date>
<quota>12909</quota>
<available>2686</available>
</capacity>

<capacity>
<date>2012-07-21</date>
<quota>12909</quota>
<available>2961</available>
</capacity>
</urn:get_capacity_response>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Special Scenarios
Checking if Rescheduling is required after Amend
If an amend order caused changes to critical parameters for capacity (any activity field
that is send to capacity API), WOM needs to identify if the original time slot can be used
or to force the customer to reschedule if he wants to commit the changes.
The logic to achieve it will be as follows:
1. WOM will call the capacity API with the new parameters.
2. If new work skills were returned in the response, WOM will need to execute the logic
of having availability for each of the new work skill with new duration on the
original time slot. If one of the new work skills is not available in the original time
slot, it means that rescheduling is required.
3. If the original duration increased because of the amend request, WOM will need to
check the availability of the work skills that are part of both the original activity and
the activity configuration. However, for these work skills, WOM needs to check just
the availability of the delta between the original duration and the new duration.
Force Booking
If an authorized CSR asked to perform Force Booking, WOM will not check whether the
time slot is available or not, but will instead return all the time slots. If required, WOM
can still carry out the check and indicate on each time slot whether it is available or not
from a capacity perspective.

7 Activity APIs
The Activity Management interface is a set of low-level functions to provide full control
over activities in ETAdirect. External systems may need to take over the control of
activities in ETAdirect such as starting them, completing them, cancelling them, getting a
route of activities for a resource, creating or deleting links between activities, or defining
resource preferences for activities. This API can also be used to retrieve details for all the
activities that match a set of specified conditions, or essentially perform a search.
The chapter describes the activity APIs invoked by WOM to ETAdirect. Activity (which
is equivalent to Work Order in WOM) is subject to several commands invoked by WOM:
 update_activity – used for creation and update of activity
 cancel_activity – used for cancellation of activity
 search_activity – an alternative to search in self-care API (refer to Search API)
In general, all other commands are not in use by WOM.

Head Node
Each message includes the ‘head’ node. The head node defines the settings that apply to
the entire transaction, and define the transaction flow details.
Table 7.1 Head Node Main Elements
upload_type Define the upload WOM will always use 'incremental'
type
default_appointment_ A fallback WOM will always send empty string
pool resource to whom
an activity will be
assigned
appointment Node representing
appointment
details in the head
appointment/keys Keys of the WOM will use the key 'appt_number'
appointment
appointment/action_if Behavior if WOM will send 'update'
_completed appointment status
is 'started',
'cancelled' by user,
'completed' and
'notdone'
properties_mode How to handle the WOM will send 'update', which means updating
properties the properties and not replacing them
All other parameters that are not mentioned will not be sent by WOM.
Data Node
The data node includes a list of commands. WOM will send a single command.
Table 7.2 Command Node Main Elements
type The command type WOM will use either ‘update_activity’ or
‘cancel_activity’
date The date of the Will be sent only for new activity. If there is no
activity scheduling it will be sent as empty
appointment Structure
representing the
activity
All other fields are not used by WOM.

Chapter 7. Activity APIs
Appointment Structure
Table 7.3 Appointment Structure Main Elements
address Address of
customer
appt_number Work Order ID
action_if_completed Behavior if WOM will send 'update'
appointment status
is 'started',
'cancelled' by user,
'completed' and
'notdone'
cell Customer cell WOM will send the cell contact number in this
phone field
city Customer’s city
coordx Longitude of the
location
coordy Latitude of the
location
customer_number The customer ID
email Customer’s email
language The language of A default value, unless multi-language is
the resource supported, and preferred language will need to be
captured
name Customer name
points Points of work This is calculated field in WOM based on rules
phone Customer’s regular WOM will send the home contact number in this
phone field
reminder_time Reminder time in This field needs to be captured
minutes before
activity
sla_window_start and SLA fields Used mainly for unscheduled Work Orders,
sla_window_end although business requirement can direct rules in
WOM to calculate SLA also for scheduled WOs
state The customer’s
state
time_slot The time_slot code Based on the capacity API
time_zone TZ for the work
order
worktype The worktype of WOM will have rules to calculate the worktype
the WO
zip Zip code of the
address
properties List of additional
properties


links A list of activities this is possible enhancement
linked to current
activity
All other fields are not used by WOM.
Properties to be used
This is a list of common properties to be used in a common implementation:
Table 7.4 Common Properties
Not Ready For Indicator that This is use by WOM to manage pre-requisites of
Dispatch blocks an activity an activity, but still reserve the capacity for it
from being
dispatched
Tasks List of tasks to be This is a table property with a list of tasks
performed by performed by technician
technician
Services List of services of It is still an open issue on how to represent this,
the customer as it is a complex structure
Linked Appointments
ETAdirect supports the concept of Linked Activities to control rules for when one
activity should be scheduled in relation to another activity. There is no limit on the
number of dependency links that can be created as needed, and these links can be set
either through the user GUI and/or through the APIs to allow external systems to control
the links. Examples of the types of link dependencies ETAdirect supports include:
 Start to start
 Finish to start
 Simultaneous
 Related
Certain resource relationships can also be added to further control the allocation of tasks
to resources. Examples of these include “must be given to the same resource” or “Must be
given to a different resource.” So, two activities can be related and must be given to two
different resources, but which resource is still to be determined by the routing process.
Other controls such as same day or next day also add further control over these
relationships.
Time intervals can be set between these relationships to accommodate for complex
relationships between the tasks. For example, Activity 1, typically of 90 minutes duration,
must start between 30-40 minutes before Activity 2, typically 50 minutes in duration, can
begin. Setting a time interval ensures that the engineer for Activity 1 is able to start the
task on his/her own, but will later be accompanied by the engineer for Activity 2 in order
to complete the work. Likewise, the finish to start activity plus time intervals can allow
for things such as drying time or wait time after Activity 1 completes before Activity 2 is
started.

Chapter 7. Activity APIs
Special Scenarios
“Not Ready For Dispatch”
The activity is created first as “Not Ready For Dispatch” and only when pre-requisites are
met and full information is available, another update_activity is sent.
If something is about to change in the activity the flag can be turned on again by
update_activity message
Amend – Before Technician Starts

WOM will send update_activity with new information. WOM cannot change location
parameters, but any other parameter can be changed
Amend - Upsell
WOM will send an update_activity. It is up to technician M&Ps to suspend the activity
before this update becomes possible.

8 Outbound APIs
The chapter describes the Outbound APIs sent from ETAdirect to WOM.
Outbound APIs are used mainly for the following cases:
 Status Updates
 Technician Requests – activation, diagnostic test, etc.

Technical Implementation
The mode of work will be simple workflow using a batch of messages. WOM will store
the messages in a table and process them in a separate transaction.
The flow is as described:
1. ETAdirect sends a "send_message" SOAP to WOM
2. WOM sends in the response final status
3. WOM stores all messages in an internal table and sends response to ETAdirect
4. WOM implements a listener on the table to execute new messages in a different
transaction
Message Header Implementation

The only meaningful field is ‘subject’, which WOM expects to contain the message type
delimited by the WO ID, as this is directing to the correct workflow and indexing.
<subject>Status Update:WO123</subject>
Message Body Implementation

Each message has a body that is fully configurable with a list of fields to be sent.
As a reuse from an existing TOA customer (which is different from TOA SDK), it will be
implemented using characteristics node:
<body>
<characteristics>
<characteristic>
<name>appt_number</name>
<value>XXX1234</value
</characteristic>
<characteristic>
<name>name</name>
<value>Rakesh Ivanov</value
</characteristic>
</characteristics>
</body>
If a field value requires multiple values, an internal delimiter should be implemented (list
of completed tasks)
There is no flexibility to implement more complex structures other than name/value but
there are numerous ways in which to represent and manage the data. ETAdirect will

Chapter 8. Outbound APIs
support any value and any delimiter. Through configuration, ETAdirect supports regular
expression masking, and XSLT transformations, which could potentially allow for the
display of complex structures, but this should be used accordingly given the type of
interface and the conditions of the data. Furthermore complex structures can be
represented using multiple navigable screens.
Use Cases
The use cases are just common examples. Specific implementation, based on the business
requirement, will implement exact messages and fields.
Status Updates
WOM will receive the significant statuses. In some of the cases WOM will need to
receive notification of milestones as reported by technician.
Complete WO
In the completion message, WOM needs to know which tasks were done and which are
still pending.
Activation Request
Activation request should include a logical identifier of the equipment service and the
equipment details (most common only the S/N). It is still an open issue on how responses
are sent if business error exists and technician needs to be notified.
Diagnostic Test
If Diagnostic Test is implemented through Amdocs systems (which is not always the
case) WOM will receive the request. Input typically comprises only a logical identifier of
equipment. For more details refer to “Business Notification to Technician” in appendix
A.

9 Search API
The search API is provided by ETAdirect to search and query details of activities. It is
mainly used by WOM for responding to “Where is my technician?” queries.

search_activities Input
Following are the main input parameters that are sent by Amdocs WOM and the way in
which the input parameters are determined.
Table 9.1 ‘search_activities’ - Main Inputs
search_in The search WOM will set it as 'appt_number'
parameter
search_for The parameter WO ID
value
date_from Start date for Current date
search
date_to End date for search A future date
property_filter Array of properties See below list of properties
to be returned
The remaining input fields will not be populated.
List of Properties for ETA

Other filter properties can be included in the search request in order to determine more
meaningful results.
Table 9.2 List of Properties for ETA
position_in_route Ordered position
customer_number Customer number
Date Scheduled date
Time_slot Time slot allocated
search_activities Response
The response includes a list of activities (only one list due to the uniqueness of WOM
search criteria) and, for each activity, the list of properties with their values as requested
in the property_filter.

Part III Summary
10 Additional Considerations................................................................................................. 45
Appendix A ETAdirect Configuration ................................................................................... 49
Appendix B Attachments ....................................................................................................... 55

10 Additional Considerations
The chapter will represent additional considerations:
 Open Issues
 Assumptions
 Known Limitations
 Possible Enhancements
 Roadmap Items

Open Issues
Table 10.1 Open Issues
ID Description Status
OI-1 Representation of service entity in WOM as part of the Activity in ETAdirect is not Open
finalized
OI-2 The capacity response returns duplicate nodes for the slot, but in different skills. The Closed
logic of how to use it by WOM is still not clear
Issue was resolved and explained in the body of the document
OI-3 Why action_if_completed is part of both head and data? Closed
Header node contains the default value, which ETAdirect will search for, if any of the
batch (1:n) data nodes do not provide a value, since each data node can have separate
‘action-if-completed’ value at the activity level.
If the 'head/appointment/action_if_completed' value of the request contradicts the data

node’s 'command/appointments/appointment/action_if_completed' value, the meaning
defined for the command should take precedence.
OI-4 What is the correct way to send business notification to technician based on technician Closed
request? Outbound notification response with advanced mode or inbound notification.
This is achieved by using set_message_status method in Outbound API
Assumptions
Table 10.2 Assumptions
ID Component Description
AS-1 WOM, ETAdirect There is no automatic identification of Outage affected
Activities
AS-2 WOM There is no automation of creating activities for pick-up of
parts/equipment required by technician to perform his other
activities
AS-3 WOM, ETAdirect Technician will not be presented with upsell options and
will not be able to perform the upsell from the mobile
device
Known Limitations
N/A

Chapter 10. Additional Considerations
Possible Enhancements
Table 10.3 Possible Enhancements
PE-1 WOM Use more than one WO with links between them for
complex projects
Refer to section Linked Appointments
PE-2 WOM, ETAdirect Ability to send link to ETAdirect that would be used for
launch-in-context of another system.
Refer to Launch in Context from ETAdirect
PE-3 WOM Support non-Amdocs clients, like Service Assurance

platform
PE-4 WOM Support Required Inventory in the Activity API, for the
dispatch engine take into account the availability of the
equipment in the technician inventory (this feature is part of
ETAdirect 4.5)
Roadmap Items
Table 10.4 Roadmap Items
RM-1 ETAdirect Improve the capabilities of representing complex properties
and tree views in ETAdirect.
Amdocs to work with TOA Technology Center

RM-2 Amdocs Build integration with Amdocs Notification Manager
This is based on existing capabilities of ETAdirect
Outbound API

Appendix A ETAdirect Configuration
This appendix describes the ETAdirect configuration required to support the integration
and E2E solution.

ETAdirect Integration with Inventory system

The ETAdirect Inbound API supports the ability to move inventory via the
"update_inventory" command, which is a type of command option that can be used as
part of the inbound interface. According to best practice, this option should be used for
bulk inventory move operations since multiple commands can be requested to move
inventory from one resource to another within a single Inbound transaction. An example
of one of those commands where the External ID represents the ID of the resource to
which this piece of equipment is being is as follows:
. . .
<command>
<date>2012-07-20</date>
<type>update_inventory</type>
<external_id>33035</external_id>
<inventories>
<inventory>
<properties>
<property>
<label>invsn</label>
<value>HRSA28726</value>
</property>
</properties>
</inventory>
</inventories>
</command>
The alternative option is to use the "update_inventory" method found within the Activity
/ Mobile-Client API. This is a one-off command (and therefore offers no bulk operation
capability) and it is performed based on the Inventory ID, which is the unique integer
assigned to the equipment by ETAdirect when it was originally entered into the system.
Here is an example of such a request:
<urn:update_inventory>
<user> . . .authentication node . . . </user>
<inventory_id>20992200</inventory_id>
<properties>
<name>resource_id</name>
<value>33015</value>
</properties>
</urn:update_inventory>
ETAdirect supports a 'required_inventories' structure, which is an array of

'required_inventory' structures that define inventories specifically required for the activity
performance. Required inventories will be used to mandate which inventory must be
installed.

Appendix A. ETAdirect Configuration
If an 'update_activity' command contains a 'required_inventories' element, then:
 The existing required inventories of the activity are deleted
 New required inventories are added when specified in the request
 An empty 'required_inventories' element deletes all existing required inventories of

the activity
The following xml structure would be included in the Update_Activity command type of
the inbound interface in order for required inventory to be managed by a technician:
<required_inventories>
<required_inventory>
<type>CONNECTOR</type>
<model>CX1135</model>
<quantity>5</quantity>
</required_inventory>
</required_inventories>
Implementing Custom Plug In

Since most technicians out in the field will use conveniently small handheld devices with
typically smaller screen sizes, it is not recommended to provide the ability to present tree
node structures to technicians.
Node structures that can support complex hierarchies are well suited to desktop
environments but not very practical for mobile touchscreen interfaces, as explained in the
following web reference published by the Department of Computer Sciences, San Jose
State University [http://www.cs.sjsu.edu/~teoh/research/papers/vda10.pdf]:
“…tree visualization is challenging because it is inherently difficult to display coherently
a large number of nodes within a limited screen space. Therefore, interaction and layout
techniques are important in allowing users to explore the tree, and focus of parts of the
tree”
The paper goes on to explore a bolder approach for representing tree structures using
multi-touch gestures. In order to represent more complex structures, such as lists of
hierarchical structures that remain easy to use while providing the ability to navigate,
TOA proposes using multiple screens as a best practice approach that would allow a
technician to easily navigate the service structures.
At the time of writing this document, it is anticipated that the representation of complex
structures to a technician would require a custom plugin, which would behave in a similar
manner to the ETAdirect multiscreen ‘completion plugin’, with which TOA has
experience and which has already been implemented for selected TOA customers.

The ETAdirect completion plugin framework provides a simple process of development

for multi-screen plugins with custom logic. This framework has a native functionality for
updating properties and fields and completing activities. It also supports both the Manage
and Mobility interfaces. The completion plugin supports other languages just as
ETAdirect does.
Amdocs would engage with the TOA Technology Center in order to implement similar
functionality so as to better support Amdocs Services structures.
Business Notification to Technician

Business notification can be provided if a technician needs to receive business
notification in return for a sent request. For example:
 Equipment Validation Failed
 Activation Failed
The best way to achieve this is by using the set_message_status method in the Outbound
API.
‘Hits’ are based on "service request" associated with "manual" trigger in ETAdirect,
which can be updated dynamically by Amdocs CRM or OSS.
In order to present the ‘hit status’, the best practice approach is to use a predefined list
(very brief description only), using an enumeration field with values, such as:
 In progress
 Passed
 Failed
 Unknown
For the best user experience, ETAdirect can be configured in the following manner:
 Create equipment status property string or enumeration.
 Create multi-line format property for equipment status.
 Use inbound to update equipment status property
 Equipment status property can be set as Active or Inactive
 Set the visibility options so that it will be shown on mobile view inventory lists.
 This will present the status of the last known operation to the technician once the tech
clicks inventory item
 Additional xslt transformation can be used to represent such structures as signal
measurement results, frequency, etc.
 Tech is allowed to navigate with additional clicks to different screens and can wait
for response from Amdocs WOM system.
 A detailed description can be included with the business notification, which can be
used in another text field and can be configured as a multi-line formatted property

Appendix A. ETAdirect Configuration
with visible settings on inventory details screen, which the technician can navigate to
read the fuller explanation.
Note: Communication lag could be quite long as messages can be queued for a
wait period of up to several seconds before a response is shown.
By employing a plugin in ETAdirect, ETAdirect can directly call the provisioning
system, in which case the time required to get a response is typically 5-10seconds.
The following table shows screen mockups of the notifications to the Field Engineer
following a hit request.
Step 1 Step 2
Figure 2 - Open the Inventory List Figure 3 - Select Item to Hit

Step 3 Step 4
Figure 5 - Monitor Hit Status

Figure 4 - Hit the Item
Launch in Context from ETAdirect

It is possible to define and configure an action link that can be presented to a technician,
for instance. The link can be either a URL or an action of launching a mobile device
application.
Thus, when the button is clicked / tapped by the user, it will initiate the URL/application
with the concatenated values using one or more custom properties defined in ETAdirect
to launch-in-context the composed URL/application.
For example, the following URL is used as the relative path in the plugin tab under
>company settings>action management:
http://maps.google.com/maps?saddr=&daddr={acoord_y},{acoord_x}&t=m&z=15
In this example “{acoord_x}” and “{acoord_y}” are placeholders for properties defined
in ETAdirect. Any number of custom string, integer and enumeration properties can be
used as placeholder values to compose the final URL string.

Appendix B Attachments
The chapter includes additional file attachments.

ETAdirect SDK
Note: The documentation is referring to ETAdirect 4.4. It might be that the actual
implementation will be done on a different version, in which case the reference to
the relevant SDK will be provided.
Capacity Interface
http://creativity/SpaceDirectory/Sites/WOM%20Generic%20Materials/Shared%20Docu
ments/Workshops/TOA/Materials%20from%20TOA/ETAdirect4.4_Capacity_SDK.pdf
Inbound Interface
ments/Workshops/TOA/Materials%20from%20TOA/ETAdirect4.4_InboundInterface_S
DK.pdf
Outbound Interface
ments/Workshops/TOA/Materials%20from%20TOA/ETAdirect4.4_OutboundInterface_
SDK.pdf
Self-Care Interface (Search)

ments/Workshops/TOA/Materials%20from%20TOA/ETAdirect_4.4_SelfCareInterface_
SDK.pdf

Document Release Information
Edited Doc
Release Editor Comments Sent to Site Approved By
Date Version

Amdocs - TOA Integration v9

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Amdocs - TOA Integration v9

Uploaded by

Copyright:

Available Formats

TOA INTEGRATION

Amdocs - TOA Integration

For Internal Use Only

Part I Introduction ................................................................................................................ 1

1 Goals and Scope .................................................................................................................. 1

3 End-to-End Scenarios ........................................................................................................ 11

4 Logical Data Model Mapping............................................................................................. 13

Information Security Level 2 – Sensitive iii

Part II API High Level Description .................................................................................... 19

5 API General Considerations .............................................................................................. 21

6 Capacity API ........................................................................................................................ 25

7 Activity APIs ........................................................................................................................ 31

8 Outbound APIs ................................................................................................................... 37

iv Information Security Level 2 – Sensitive

Message Header Implementation .................................................................................................... 38

9 Search API ........................................................................................................................... 41

Part III Summary................................................................................................................... 43

Appendix A ETAdirect Configuration ................................................................................... 49

Appendix B Attachments ....................................................................................................... 55

Information Security Level 2 – Sensitive v

3 End-to-End Scenarios ........................................................................................................ 11

4 Logical Data Model Mapping............................................................................................. 13

Information Security Level 2 – Sensitive 1

Information Security Level 2 – Sensitive 1

Scope of the Solution

2 Information Security Level 2 – Sensitive

Information Security Level 2 – Sensitive 3

Architecture Component Diagram

(Non Sale Order) Fulfillment

Get Capacity Equipment

4 Information Security Level 2 – Sensitive

Figure 2.2 WOM to ETAdirect API integration Architecture

Information Security Level 2 – Sensitive 5

Amdocs Ordering (OMS)

6 Information Security Level 2 – Sensitive

Amdocs Self Service

Information Security Level 2 – Sensitive 7

TOA ETAdirect Suite

ETAdirect Enterprise Suite Overview

8 Information Security Level 2 – Sensitive

capabilities empower users to identify and resolve potential issues proactively,

Information Security Level 2 – Sensitive 9

Equipment and Materials Inventory

Billing (Amdocs Invoicing)

10 Information Security Level 2 – Sensitive

Information Security Level 2 – Sensitive 11

Sale Order Normal Flow

Sale Order Normal

The flow describes the integration around sale order flow.

Amend or Cancel of Sale Order

12 Information Security Level 2 – Sensitive

Information Security Level 2 – Sensitive 13

WOM Main Entities

Work Order Created in WFM with Due Date

Created Reserved Submitted Work Order Ready for Dispatch

Cancel Process Completed

14 Information Security Level 2 – Sensitive

Information Security Level 2 – Sensitive 15

ETAdirect Main Entities

Resource (Provider) Tree

16 Information Security Level 2 – Sensitive

Information Security Level 2 – Sensitive 17

6 Capacity API ........................................................................................................................ 25

7 Activity APIs ........................................................................................................................ 31