Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02638268 2008-07-24
SERVICE REQUEST EXECUTION ARCHITECTURE FOR
A COMMUNICATIONS SERVICE PROVIDER
INVENTORS:
ADRIANO OTTAVI
STEFANO RENZO GANDINI
BACKGROUND OF THE INVENTION
1. Technical Field.
[001] This disclosure concerns identifying and managing service requests. In
particular, this disclosure concerns handling service requests and their
related
exceptions in a service provider architecture.
2. Background Information.
[002] The communications industry continues to face demands for more
services, and rapid deployment of new services, while the complexity of the
underlying technologies providing the services continues to increase. Service
providers require systems that provide both residential and commercial
consumers
the ability to easily activate and manage requests for services directly and
at lower
prices. Communications service providers recognize the ability of consumers to
choose desired services and take at least basic steps to order the services as
a
critical market differentiator. Consumers assess service providers based on
the
number of available services and the ease of activation and use of the
services by
consumers. Consumers also recognize the cycle-time between initiating a
request
for a service and service activation as a dominant market differentiator.
[003] Provisioning communication services involves many complex and
technical details, and often results in exceptions occurring during the
process of
obtaining customer information and provisioning services. Unfortunately, the
lack of
ready-to-use services available from business support systems (BSS) capable of
supporting standard processes of communication providers creates technical
challenges for service providers. The complexity of new operational support
systems (OSS) deployed in support of new network services also creates
technical
1
CA 02638268 2008-07-24
challenges for service providers desiring to hide the complexity from
consumers.
The continuous desire of providers to differentiate their services from each
other
drives OSS to introduce more sophisticated services and complex technologies,
in
addition to life-cycle maintenance issues. The many technical challenges
facing
service providers include not only improving the experience of consumers in
the
context of activating and using services, but actually carrying through with a
service
request and successfully activating the service. Communication service
providers
use complex systems to track and resolve exceptions arising during the
provisioning
and operation of services. Current self-provisioning systems currently
overwhelm
and confuse consumers, discourage consumers from self-provisioning
communications services, and the use of such self-provisioning capabilities..
Communication service providers currently direct scarce resources to assisting
consumers to provision services at the expense of focusing resources on
developing
and delivering new services.
(004] Communications service providers face many technical challenges to
successfully activating services as well as providing consumers with an
enhanced
ability to self-provision network services- The technical challenges include
providing
robust and dynamic user interfaces, workflow solutions that provide efficient
and
elegant exception handling, and service request orchestration. The already
immense number of process steps, and potential exceptions that may result in
the
course of activating and managing network services increase exponentially with
the
integration of each new network element or service. Unfortunately, current
systems
may require a consumer to respond to an unreasonable number of exceptions in
the
course of activating or deactivating a service, further frustrating the
consumer.
Furthermore, current systems may themselves become the victims of runaway
error
propagation (e-g,, exceptions), leading to overwhelmed system resources,
multitudes
of partially completed provisioning service requests, and time consuming,
expensive,
and technically challenging exception resolution.
[005] A need has long existed for a system and method that efficiently and
effectively accelerates the self-provisioning of services by managing
exceptions,
exception queues, and elegantly orchestrating the processing of service
requests.
2
CA 02638268 2008-07-24
SUMMARY
[006] The service request execution architecture ("architecture") for a
communications service provider decouples the complexity of provisioning
communication services from the consumer experience. The architecture
identifies
and manages related service requests corresponding to exceptions that may
occur
during the course of processing service requests. The architecture efficiently
manages exceptions, exception queues, and elegantly orchestrates the
processing
of related service requests. The architecture accelerates the process of
fulfilling
requests for services by managing exceptions corresponding to requested
services,
and locking and unlocking related services corresponding to an exception, upon
the
occurrence and resolution of an exception. Accordingly, the disclosed service
request execution architecture promotes effectiveness of man-machine
interaction,
particularly promoting acceptance and use of self-service provisioning by
consumers, leading to increased cost-savings on the side of the service
provider.
Particularly, the architecture greatly reduces the technical burden of
managing
exceptions that occur while processing requests for services.
[007] The architecture may process service requests broken into a fine level
of granularity that promotes the efficient implementation, reuse, and
optimization
of not only the service requests, but more complicated services built with the
granular service requests. Examples of the granular services requests are
given
in more detail below. In general, the architecture may include a comprehensive
set of service requests- For example, the service requests may include a
customer
create service request, customer modify general date service request, and
service order provisioning service request. The architecture may receive
service
requests and identify attributes (e.g., customer code, account code,
organization
code, product code, and an order id) of the service requests that define
correlation
codes. The architecture may use the correlation codes to manage exceptions and
related service requests in a coordinated fashion. The architecture may
transform
the service requests to obtain orchestrated service requests that include
corresponding correlation codes. In one implementation, the architecture uses
an
XSLT (eXtensible Stylesheet language transformation) processor to obtain
3
CA 02638268 2012-04-26
54800-21
orchestrated sarvico requests. The archl(octure uses correlation codes to
group and
relate multiple orchestrated sorvico requests.. The architecture may compose
correlation c duw using Varydrrg riaumber s of attributes, and the number of
attributes
rn.sy,, be based on the characteristics of the corresponding service request-
10081 The architecture may initiate processing of a currently orchestrated
service
request by extracting the correlation coda- from the currently orchestrated
service
request, and deierrr-ining whether the extracted corretati;on code matches a
correlation code corresponding to an existing serkrlce request exception
stored in an
exception handler queue. The architecture may attempt to process the currently
orchestrated service request, whore the archtt tore determines that the
exception
handler queue clams not int ude an existing service request exception with a
corresponding chrrelotion code that matches the currently corr. heslrreted
service
request. Thu architecture may process the ,rrtently w be.;Arated service
regucast,
and, in the event an exception does occur, stop the processing =of the
ourruntly
orchestrated seMce request and store a service request exception with a c:artc
latlon
code corresponding to the currently orchestrated service request in the
oxceptlon
queue.
E009) In one implementation, the architecture tilts process initiation of a
currently orchestrated servion, request, where the architecture deiexrnines
that an
existing service request exception exists with a matching correlat oon coda.
the
existing service request exception may represent an exc rpo-tion resulting
from an
attempt to process a previously orchestrated service request. The exception
that ndler
may lock the currently orchestrated service request based on the correlation
code of
the currently orchestrated service request matching the correlation code of
the
service request exception. The architecture may resolve the service request
exception and unlock, tooth the. currently orchestrated service request and
previously
orciieslrate-d service requests currently locked based on the correlation
codes of the
currently orchestrated service request and the previously orchestrated service
requests matching the correlation code of the resolved service request oxo
[tpb n.
4
CA 02638268 2012-04-26
54800-21
According to one aspect of the present invention, there is provided a
computer-implemented method comprising: receiving a service request comprising
service request attributes; identifying correlation attributes in the service
request
attributes; extracting the correlation attributes and forming a correlation
code from the
correlation attributes; adding the correlation code to the service request to
obtain an
orchestrated service request; queuing the orchestrated service request in a
service
request queue; processing the orchestrated service request by: extracting the
correlation code from the orchestrated service request to obtain an extracted
correlation code; comparing the extracted correlation code to a locked
correlation
code associated with a pending service request exception; and when the
extracted
correlation code and the locked correlation code match: searching the service
request queue for matching service requests comprising the extracted
correlation
code in addition to the orchestrated service request; and locking the
orchestrated
service request and the matching service request in the service request queue
so
that they do not execute.
According to another aspect of the present invention, there is provided
a service request processing system comprising: correlation code extractor
means
operable to: receive a service request comprising service request attributes;
identify
correlation attributes in the service request attributes; extract the
correlation attributes
and form a correlation code from the correlation attributes; and add the
correlation
code to the service request to obtain an orchestrated service request; queuing
means
operable to queue the orchestrated service request in a service request queue;
and
orchestrated service processing means operable to: extract the correlation
code from
the orchestrated service request to obtain an extracted correlation code;
compare the
extracted correlation code to a locked correlation code associated with a
pending
service request exception; and when the extracted correlation code and the
locked
correlation code match: search the service request queue for matching service
4a
CA 02638268 2012-04-26
54800-21
requests comprising the extracted correlation code in addition to the
orchestrated
service request; and lock the orchestrated service request and the matching
service
request in the service request queue so that they do not execute.
[010] Other systems, methods, and features of the invention will be, or will
become, apparent to one with skill in the art upon examination of the
following figures
and detailed description. It is intended that all such additional systems,
4b
CA 02638268 2008-07-24
methods, features and advantages be included within this description, be
within the
scope of the invention, and be protected by the following claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[011] The disclosure can be better understood with reference to the following
drawings and description. The components in the figures are not necessarily to
scale, emphasis instead being placed upon illustrating the principles of the
invention.
Moreover, in the figures, like referenced numerals designate corresponding
parts or
elements throughout the different views.
[012] Figure 1 illustrates the service request execution architecture
("architecture").
[013] Figure 2 shows a dataflow diagram that illustrates events that may occur
to initiate the exception handler to manage an exception.
[014] Figure 3 illustrates the EAI/ESI3 system.
[015] Figure 4 shows the processing flow the architecture may take to process
a
service request.
[016] Figure 5 shows examples of entities the architecture may use to
provision
and manage services.
[017) Figure 6 shows additional examples of entities the architecture may use
to
provision and manage services.
[018] Figure 7 illustrates the construction of correlation codes,
[019] Figure 8 shows a hierarchy of coarse grain service requests.
[020] Figure 9 shows the matching and locking processes for the architecture.
DETAILED DESCRIPTION
[021) The architecture may uniquely define operational events (e.g., actions)
that the architecture maps to business services (e.g., service requests
directed to a
service). The architecture may use business services to exchange information
between systems involved in the delivery and management of services. In one
implementation, the architecture implements a data model schema that defines
entities used to create, read, update and delete service requests. Entities
may
CA 02638268 2008-07-24
represent discrete objects within the architecture used to offer consumers
services
and manage the delivery of services to customers. As examples, the
architecture
may include entities such as a billing account entity, customer entity, and
organization entity. Entities may include attributes that uniquely identify
service
requests and define correlation codes. The architecture may use correlation
codes
to identify and manage related service requests in an orchestrated manner. For
example, the architecture may use correlation codes to implement exception
handling functionality.
[022] Although specific components of the architecture will be described,
methods, systems, and articles of manufacture consistent with the architecture
may
include additional or different components. For example, a processor may be
implemented as a microprocessor, microcontroller, application specific
integrated
circuit (ASIC), discrete logic, or a combination of other type of circuits or
logic.
Similarly, memories may be DRAM, SRAM, Flash or any other type of memory.
Logic that implements the processing and programs described below may be
stored
(e.g., as computer executable instructions) on a computer readable medium such
as
an optical or magnetic disk or other memory. Alternatively or additionally,
the logic
may be realized in an electromagnetic or optical signal that may be
transmitted
between entities- An example of such a signal is a physical layer Ethernet
signal
bearing TCP/IP packets that include program source code or executable
programs.
Flags, data, databases, tables, and other data structures may be separately
stored
and managed, may be incorporated into a single memory or database, may be
distributed, or may be logically and physically organized in many different
ways.
Programs may be parts of a single program, separate programs, or distributed
across several memories and processors. Furthermore, the programs, or any
portion of the programs, may instead be implemented in hardware.
[023] Figure 1 illustrates the service request execution architecture
("architecture") 100. The architecture 100 may include an enterprise
application
integration and enterprise service bus (EAIIESB) 102, a CCare (Customer Care)
system 104, a customer portal 106 system, a billing system 108, an integrated
order
management system (tOM) 110, a unify directory (UD) system 112, a provisioning
system 114, an enterprise resource planning (ERP) system 116, and a balance
6
CA 02638268 2008-07-24
system 118 (e.g., account management system). The service providers 120
communicate with customers 122, consumers 124 (e.g., potential customers),
distribution partners 126 and other entities through a network 128 (e.g., the
Internet).
[024] The EAI/ESB system 102 may mediate between the systems included in
the architecture 100 and in communication with the architecture 100. The
EAI/ESB
system 102 may permit applications to execute cohesively to carry out a number
of
logical cross-functional business processes. The EAI/ESB system 102 may
provide
messaging services so that different applications can communicate together
using
service requests (e.g., business service requests).
[0251 Table 1 shows a list of business services the architecture 100 may use
to
deliver and manage provisioned services. The architecture 100 uniquely defines
operational events (e.g., actions) that the architecture 100 maps to business
services. The architecture 100 uses business services to exchange information
such
as data included in entities forwarded in service requests, between systems
involved
in the delivery and management of services (e.g., the EAI/ESB system 102, the
CCare system 104, the customer portal 106 system, the billing system 108, lOM
system 110, and UD system 112, the provisioning system 114, and the ERP system
116).
Table I - Business Services
Account Invoice Inquiry
Activation
Adjustment Post-Paid Account
Bank Account Check
Create Alerts
Create Billing Account
Create Customer
Create Service Account
Create Post-Paid Order
Create Pre-Paid Order
7
CA 02638268 2008-07-24
Create Service Request
Create User
Credit Balance Inquiry
Modify Billing Account
Modify Customer Data
Modify Service Request
Modify User
Number Portability Request
Refill
Request SIM Card Replacement
Retrieve Billing Account Data
Retrieve Customer Data
Retrieve Installed Assets
Retrieve Orders
Retrieve Product Configuration
Retrieve Product List
Retrieve Product Price
Retrieve Service Accounts
Retrieve Service Request
Retrieve User Data
Send e-Mail message
Send SMS message
Service Item for Provisioning Response
Service Order for Provisioning
Service Order for Provisioning Response
Synchronize Account Billing Profile
Synchronize Account Bill to Address
Synchronize Account Bill to Person
Synchronize Account General Data
Synchronize Account Payment Data
Synchronize Account
B
CA 02638268 2008-07-24
Synchronize Asset Component
Synchronize Customer
Synchronize Customer Fiscal Address
Synchronize Customer General Data
Task Execute
Task Execute Response
Traffic Usage Inquiry
Validate Credit Card Data
Validate Customer Address
Validate Customer Data
Validate DSL availability
[026] Table 2 shows a list of objects that may represent logical entities that
include attributes that further define and uniquely identify the business
services. The
business services may be uniquely defined by the combination of the header and
one or more objects (e.g., entities). The architecture 100 may include
additional,
fewer or different business services and entities to deliver and manage
provisioned
services.
Table 2 - Objects (e.g., Entities)
Address
Adjustment
Attribute
Billing Account
Billing Adjustment
Billing Profile
Contact
Customer
Invoice Data
Order
9
CA 02638268 2008-07-24
Organization
Payment Data
Product-Service
Product-Service-Account
Product-Service-Account-Address
Product-Service-Accou nt-Contact
Product-Service-Attribute
Product-Service-User Contact
Refill
Service Order
Technical Service Order
[027] Referring briefly to Figure 7, each business service 700 may include a
header 702 and objects 704 that represent logical entities such as a billing
account
entity 706, a customer entity 708, and an organization entity 710. The header
702 of
the business services may include attributes such as a customer code 712 to
identify
a customer, an organization code 714, a business event name 716, an execution
state 718 to indicate status, a business event instance id 720 to identify
multiple
instances and threads of a business event, and a received date 722 to time
stamp
when a system receives a business service. The architecture 100 may consult a
correlation code definition or other correlation code specification to
determine which
attributes the architecture 100 uses, and in what order, to form a correlation
code.
For example, the architecture may obtain a correlation code 724 by
concatenating
the ordered sequence of billing account entity 706, customer entity 708, and
organization entity 710 into a single correlation code 724. In another
example, the
architecture 100 may obtained a correlation code 726 by combining entities
from a
business service 700 in a different order or sequence-
[028] Table 3 shows example business services and entity combinations that the
architecture 100 may use to deliver and manage provisioned services. For
example,
the create customer business service may include the header, and the entities
customer, address, and organization, while the modify customer general data
business service may include the header and the entities customer and
organization.
CA 02638268 2008-07-24
Table 3 - Business Services (Entities) Combinations
Adjustment Post-Paid Account (Billing Account, Billing Adjustment,
Product-Service)
Adjustment Pre-Paid Account (Billing Account, Billing Adjustment,
Product-Service)
Asset Component (Attribute(s), Product-Service)
Create Billing Account (Billing Account, Address, Organization,
Billing Profile, Payment Data, Contact)
Create Customer (Customer, Address, Organization)
Refill (Billing Account, Billing Profile, Payment Data, Product-Service,
Refill)
Service Order for Provisioning (Service Order, Product-Service(s),
Product-Service-Account,
Prod uct-Service-Account-Address(s),
Product-Service-Account-Contact(s),
Product-Service-Attribute(s),
Product-Service-User-Contact(s))
Synchronize Account Bill to Address (Address, Billing Account, Organization)
Synchronize Account Bill to Person (Billing Account, Contact, Organization)
Synchronize Account Billing Profile (Billing Account, Billing Profile,
11
CA 02638268 2008-07-24
Organization)
Synchronize Account General Data (Billing Account, Organization)
Synchronize Account Payment Data (Billing Account, Billing Profile,
Organization, Payment Data)
Synchronize Customer General Data (Customer, Organization)
Synchronize Customer Physical Address (Address)
Task Execute (Technical Service Order, Order, Attribute(s))
Task Execute Response (Technical Service Order, Attribute(s))
[029] The architecture 100 may use business events (e.g., business service
requests) to exchange data between the systems within and in communication
with
architecture 100. For example, IOM system 110 may request a provisioning
system
114 or UD 112 to perform a particular operation that results in a task execute
event.
In one implementation, EAI/ESB system 102 receives request from the IOM system
110 and forwards the request to the appropriate provisioning system 114. The
task
execute event may be represented by a task execute business service that
contains
service requests that the IOM system 110 maps to system operations tasks
(e.g.,
create user on UD 112, and activate VOIP on a wireline provisioning system
114).
[030] The CCare system 104 may manage customer relationships so that
service providers 120 and customers 122 can access customer information
directly,
match customer needs with product service plans and offerings, remind
customers of
service requirements, and identify all the products purchased and/or in use by
a
customer 122. The CCare system 104 may include capabilities to help the
marketing department of the service provider 120 to identify and target the
best
customers of the service provider 120, manage marketing campaigns with clear
12
CA 02638268 2008-07-24
goals and objectives, and generate quality leads for the sales team of the
service
provider 120. The CCare system 104 may assist the service provider 120 to
improve
telesales, account, and sales management by optimizing information shared by
multiple employees, and streamlining existing processes (e..g., taking orders
using
mobile devices). The CCare system 104 may provide the service provider 120
with
functionality to form customized relationships with the customers 122,
consumers
124 (e.g.., potential customers) and distribution partners 126. The CCare
system 104
may improve customer satisfaction, identify the most profitable customers,
provide
customers with the highest level of service, and consequently, maximize
profits. The
CCare system 104 may provide the employees of the service provider 120 with
the
information and processes necessary to analyze customer profiles, understand
the
needs of the customer 122, and effectively build relationships between the
service
provider 120, the customer 124 and the distribution partners 126.
[031] The customer portal 106 provides customers 122 and consumers 124
directly accessible provisioning of service from a network (e.g.., the
Internet). In one
implementation, the customer portal 106 represents a dealer portal and/or
mobile
portal for commercial and residential customers to access and provision
services. In
one implementation, the customer portal 106 communicates with EAI/ESB system
102 through Service Oriented Architecture Protocol (SOAP) which provides an
approach to exchanging XML-based messages. The customer portal 106 provides
customers 122 and consumers 124 a browser to view, purchase and provision
available services, modify demographic information, billing account and
payment
data, view an invoice statement, balance, and refill pre-paid accounts.
[032] The billing system 108 may perform the activity of invoicing customers
122
for products and services. The main functions of the billing system 108 may
include
maintaining billing data, recurrent and usage charges for services, discounts,
service
rates, catalogue of services, and generating printed and electronic bills.
[033] The integrated order management (IOM) system 110 may provide the
architecture 100 a foundation for process automation, as well as the human
workflow
components used to provision a service. The IOM system 110 design may
implement service order and task level management used to successfully
provision a
service. The main functions of IOM system 110 may include process management,
13
CA 02638268 2008-07-24
workflow, order decomposition, order re-composition, task management, status
management, exception and SLA management, order and status reporting,
supplement processing, cancel processing, and move, add, change and delete
actions
[034] The unify directory (UD) system 112 may provide security and control
services functionality that centralize management of customer and service
related
information needed by value added service (VAS) applications and a set of
security
features to control user access to services through the UD system 112. The UD
system 112 may receive service requests from the IOM system 110 to add,
modify,
delete and search customers 122, users, products and services.
[035] The provisioning system 114 may provide services to set up a service
including configuring equipment, wiring, and transmission. The provisioning
system
114 may manage the functionality to activate and deactivate products and
services
offered by a service provider 120. The provisioning system 114 may manage
wireless and wireline provisioning, internet protocol television (IPTV), voice
over
internet protocol (VOIP), and dedicated services provisioning.
[036] The ERP (Enterprise Resource Planning) system 116 may manage
product planning, purchasing (e.g., materials and components used to deliver
products and services), maintaining inventories, interacting with suppliers,
providing
customer service, and tracking orders. The ERP system 116 may also include
application modules to manage the finance and human resources aspects of the
service provider business. The ERP system 116 may manage and track the
collection of the payments by customers 122 of invoices sent by the billing
system
108, record the payments, and match orders and payments to distribution
partners
126 (e.g., suppliers).
[037) In one implementation, the CCare system 104 manages all the entities
related to customer and account management and the orders for products and
service purchased by customers 122. The CCare system 104 may initiate the
operations devoted to activate, modify and remove customer data and order
activation and deactivation. The EAI/ESB system 102 may replicate and forward
entities as needed to the systems in communication with the architecture 100
to
provision and manage services. The EAI/ESB system 102 may map the CCare
14
CA 02638268 2008-07-24
system 104 event to a corresponding business service. The architecture 100 may
transform data forwarded to business services into a common object model used
by
the systems in communication with the architecture 100 to provision and manage
services. The EAI/ESB system 102 may provide logic to route events (e.g.
service
requests to business services) to applications using a predetermined
sequence.. The
EAI/ESB system 102 provides consumers 124 and customers 122 with the customer
portal 106 system that provides a set of invokable services. In one
implementation,
the customer portal 106 system forwards service requests to the EAI/ESB system
102 that the EAI/ESB forwards to CCare system 104 to provision and manage
services.
[038] As noted above, the architecture 100 implements a sophisticated
exception handling mechanism. Figure 2 shows a dataflow diagram 200 that
illustrates events that may occur to initiate the exception handler 202 to
manage an
exception 204. The dataflow diagram 200 illustrates a dataflow that the
architecture
100 may use to manage a new order for service (e.g.., create customer 206
service
request) from a new customer 122. In one implementation, a consumer 124 may
initiate a create customer event (e.g., create customer 206 service request)
to
become a customer 122 through a CCare system 104 interface. Many other data
flows may be defined in the architecture 100; the dataflow diagram 200 is one
example. The CCare system 104 forwards the create customer 206 service request
to the EAI/ESB system 102 and the EAI/ESB system 102 returns an
acknowledgement 208 to the CCare system 104 to indicate that the architecture
100
has updated entities with information corresponding to a customer, an address,
and
an organization representing the newly created customer 122. The CCare system
104 may initiate a create account event (e.g., create account 210 service
request)
corresponding to the create customer event (e.g., create customer 206 service
request) for a new customer, and forward the create account 210 service
request to
the EAI/ESB system 102. EAI/ESB system 102 may return an acknowledgement
212 to the CCare system 104 to indicate that the architecture 100 has updated
entities with information corresponding to a billing account, billing profile,
payment
data, and contact representing a newly created account for the customer 122.
The
CCare system 104 may also initiate a service order provisioning event (e.g.,
service
CA 02638268 2008-07-24
order provisioning 214 service request) corresponding to the new order for
service
by the new customer 122 and forward the service order provisioning 214 service
request to the EAI/ESB system 102. EAI/ESB system 102 may return an
acknowledgement 216 to the CCare system 104 to indicate that the architecture
100
has updated entities with information corresponding to a service order,
product-
service(s), product-service-account, product-service-account-address(s),
product-
service-account-contact(s), product-service-attribute(s), product-service-user-
contact(s) representing a new order for service for the customer 122.
[039] In one implementation, the CCare system 104 forwards billing information
to billing system 108 through EAI/ESB system 102. The EAl/ESB system 102 may
forward information received from one system to other systems using multiple
service requests. For example, the EAI/ESB system 102 may forward billing
information received from the CCare system 104 to the billing system 108 in a
create
customer 218 service request. In one implementation, the EAI/ESB system 102
forwards the create customer 218 service request to the billing system 108 and
the
ERP system 116 to create a billing account. Multiple billing accounts may be
created for and associated with a customer 122. The billing system 108 may map
the create customer 218 service request to an event that differentiates the
creation
of a residential customer from a business customer based on information
included in
the create customer 218 service request.
[040] In one implementation, the billing system 108 returns an
acknowledgement 220 to EAI/ESB system 102 with a value equal to "NOK" 222
when a service request (SR) exception 204 occurs, where the billing system 108
attempts to process the create customer 218 service request. The EAI/ESB
system
102 may forward the SR exception 204 to the exception handler 202 based on the
NOK 222 value of the acknowledgement 220. The exception handler 202 may halt
correlated events (e.g., modify customer related events or synchronize asset
component associated to the same customer) and lock the create customer 218
service request related to the SR exception 204. In one implementation, the
exception handler 202 sends the EAI/ESB system 102 a service request lock 224
to
lock the create customer 218 service request.
16
CA 02638268 2008-07-24
[041] The architecture 100 may resolve the SR exception 204 and unlock both
the create customer 218 service request and forward the IOM system 110 a
service
order provisioning service request 226 to perform a particular service
provisioning
operation (e.g., create user on UD 112, and activate VOIP on the provisioning
system 114). The IOM system 110 may send the provisioning system 114 and UD
112 a task execute service request 228 that initiates provisioning of services
and
results in provisioning information 230 being returned to IOM system 110
through a
task execute response 232. The IOM system 110 may send the provisioning system
114 multiple task execute service requests 234 that result in the provision
system
114 returning additional provisioning information 236 to the IOM system 110
through
task execute responses (e.g., 238 and 240). The IOM system 110 may send the
EAI/ESB system 102 multiple service item for provisioning responses (e.g., 242
and
244) to complete the provisioning of service for an order. The EAI/ESB system
102
may forward a service item for provisioning response 246 to the CCare system
104
and the CCare system 104 in response may return asset component information
248
to EAI/ESB system 102 using an asset component service request 250.
[042] Figure 3 illustrates the EAI/ESB system 102. The EAi/ESB system 102
may include a communications interface 304 used to communicate with various
components of the architecture 100, a processor 306 to execute logic used to
manage events and service requests, and memory 308. The EAIIESB system 102
may receive service requests (e.g., SR-310 and SR-312) and identify attributes
(e.g.,
attribute-1 314 and attribute-2 316) of a service request that define a
correlation
code (e.g., the correlation code 318 and the correlation code 320). In one
implementation, the EAI/ESB system 102 employs correlation code extractor
logic
322 to identify the attributes of a service request (e.g., SR-310 and SR-312)
used to
compose correlation codes (e.g., correlation code-1 318 and correlation code-2
320)
and vary the number of attributes used to compose correlation codes based on
the
characteristics of corresponding service request. The extractor logic 322 may
consult a correlation code definition 376 or other correlation code
specification stored
in the memory 308 to determine which attributes the architecture 100 uses, and
in
what order, to form a correlation code. The definition 376 may be pre-
configured
17
CA 02638268 2008-07-24
and may be dynamically changed, for example, using a user interface to the
architecture 100.
[043] The EAl/ESB system 102 may use a service request transformer 324 to
transform service requests (e.g., SR-1 310 and SR-2 312) to obtain
orchestrated
service requests (e.g., orchestrated SR-1 326 and orchestrated SR-2 328). As
an
example, orchestrated SR-1 326 and orchestrated SR-2 328 may represent create
customer 208 service request and service order provisioning service request
226,
respectively. Orchestrated service requests (e.g., orchestrated SR-1 326 and
orchestrated SR-2 328) may include correlation codes (e.g., correlation code-1
318
and correlation code-2 320). In one implementation, the architecture 100 uses
an
XSLT (eXtensible Stylesheet language transformation) processor 330 to obtain
orchestrated service requests (e.g., orchestrated SR-1 326 and orchestrated SR-
2
328). The architecture 100 may use the correlation codes (e.g., correlation
code-1
318 and correlation code-2 320) to group and relate multiple orchestrated
service
requests (e.g., create customer 206 service request and create customer 208
service request may be represented by orchestrated SR-1 326 and orchestrated
SR-
2 328, respectively, with correlation code-1 318 and correlation code-2 320
matching). In one implementation, the attributes used to compose a correlation
code
(e.g., correlation code-1 318 and correlation code-2 320) include customer
code-1
332, account code-1 336, organization code-1 344, product code-1 348, and an
order id-1 352. In one implementation, the correlation codes may be obtained
by
concatenating the values of selected attributes into a single correlation code
field, or
may be obtained by application of another function on the selected attributes.
[044] In one implementation, the architecture 100 initiates processing of a
currently orchestrated service request (e.g., orchestrated SR-1 326) using
orchestrated service processing logic 378 to extract the correlation code
(e.g.,
correlation code-1 318) from the currently orchestrated service request using
correlation code extractor logic 322. In one implementation, the memory 308 of
the
EAI/ESB system 102 includes an exception handier 202 that uses correlation
code
matcher logic 356 to determine whether the extracted correlation code matches
a
correlation code (e.g., correlation code-4 364) corresponding to an existing
service
request exception (e.g., SR exception-2 362). The exception handler 202 may
store
18
CA 02638268 2008-07-24
service request exceptions (e.g., SR exception-1 204 and SR exception-2 362)
in an
exception handler queue 366. The architecture 100 may attempt to process a
currently orchestrated service request (e.g., orchestrated SR-1 326 and
orchestrated
SR-2 328), where the architecture 100 determines that the exception handler
queue
366 does not include an existing service request exception with a
corresponding
correlation code that matches the currently orchestrated service request. For
example, where correlation code-1 318 does not match correlation code-3 360 or
correlation code-4 364, the architecture 100 may initiate processing of a
currently
orchestrated service request (e.g., orchestrated SR-1 326). However, the
architecture 100 may stop the processing of a currently orchestrated service
request,
where a service request exception (e.g., SR exception-1 204) occurs during
processing, and store the service request exception (e.g., SR exception-1 204)
with
a correlation code (e.g., correlation code-3 360) corresponding to the
currently
orchestrated service request (e.g., where correlation code-3 360 matches
correlation
code-1 318).
[045] In one implementation, the exception handler 202 employs an
orchestrated service request locker 368 to stop the process initiation of a
currently
orchestrated service request (e.g., orchestrated SR-1 326), where the
correlation
code matcher logic 356 determines that an existing service request exception
(e.g.,
SR exception-2 362) has a matching correlation code (e.g., where correlation
code-1
318 and correlation code-4 364 completely match or partially match according
to a
preconfigured matching criteria such as two of three correlation code
attributes
matching). The existing service request exception (e.g., SR exception-2 362)
may
represent an exception resulting from an attempt to process a previously
orchestrated service request (e.g., orchestrated SR-2 328). The exception
handler
202 may lock the currently orchestrated service request (e.g., orchestrated SR-
1
326) based on the correlation code (e.g., correlation code-1 318) of the
currently
orchestrated service request (e.g., orchestrated SR-1 326) matching the
correlation
code (e.g., correlation code-4 364) of the existing service request exception
(e.g., SR
exception-2 362), where correlation code-4 364 and correlation code-2 320 also
match because the existing service request exception (e.g., SR exception-2
362)
corresponds to the previously orchestrated service request (e.g,, orchestrated
SR-2
19
CA 02638268 2008-07-24
328). The architecture 100 may unlock the currently orchestrated service
request
and previously orchestrated service request when the architecture resolves a
corresponding service request exception based on the correlation codes (e.g.,
code-
1 318 and correlation code-2 320) of the currently orchestrated service
request and
the previously orchestrated service request (e.g., orchestrated SR-1 326 and
orchestrated SR-2 328) matching the correlation code of the resolved service
request exception.
[046] Figure 4 shows a flow diagram 400 for processing a service request. In
one implementation, the service request queue 370 receives a service request
(e.g.,
service request-1 310) and extracts the correlation code-1 318 to obtain an
orchestrated SR-1 326 (402). The architecture 100 initiates processing of the
orchestrated SR-1 326 (404) and determines whether the correlation code-1 318
of
the orchestrated SR-1 326 matches the correlation code (e..g,., correlation
code-4
364) of a serviced request exception (e.g., SR exception-2 362) in the
exception
queue 366 (406). Where the architecture 100 determines that the correlation
code-1
318 of the orchestrated SR-1 326 does not match the correlation code (e.g.,
correlation code-4 364) of a serviced request exception (e.g., SR exception-2
362),
the architecture 100 attempts to process the orchestrated service SR-1 326 to
completion unless an exception occurs (416). Where an exception occurs (408)
during the processing of the orchestrated service SR-1 326, then the
architecture
100 stores the service request exception (e.g., service request exception-1
204) into
the exception handler queue 366 (410) and locks the orchestrated service SR-1
326
(412).. The architecture 100 asynchronously continues to process other service
requests while the architecture 100 resolves the exception condition. Where
the
architecture 100 resolves the exception condition that resulted in the service
request
exception (e.g., service request exception-1 204), the architecture 100
unlocks all
locked orchestrated service requests (e.g., orchestrated SR-1 326 and
orchestrated
SR-2 328) and clears the exception handler queue 366 of the service request
exception (e.g., service request exception-1 204) (414). The architecture 100
resumes processing of the orchestrated service SR-1 326 (404).
[047] Figure 4 further illustrates that where the architecture 100 initializes
processing of an orchestrated SR-1 326 and determines that the correlation
code-1
CA 02638268 2008-07-24
318 of the orchestrated SR-1 326 does match the correlation code (e.g..,
correlation
code-4 364) of a serviced request exception (e-g., SR exception-2 362) in the
exception queue 366, the architecture 100 locks the orchestrated service SR-1
326
(412). Where the architecture 100 resolves the exception condition that
resulted in
the service request exception (e.g., service request exception-1 204), the
architecture 100 unlocks all locked orchestrated service requests (e.g.,
orchestrated
SR-1 326 and orchestrated SR-2 328) corresponding to the correlation code
matching the correlation code of the service request exception (e.g., SR
exception-2
362) and clears the exception handler queue of the service request exception
(e.g.,
SR exception-2 362) (414). The architecture 100 resumes processing of the
orchestrated service SR-1 326 (404).
[048] Figure 5 shows examples of entities the architecture 100 may use to
provision and manage services. In one implementation, the architecture 100
uses a
schema that includes the following entities: an address entity 502, an
attribute entity
504, a billing account entity 506, a billing adjustment entity 508, a billing
profile entity
510, a contact entity 512, a customer entity 514, an order entity 516, an
organization
entity 518, and a payment entity 520. The architecture 100 may use the
entities
(e.g., 502 through 520) in unique combinations to form service requests used
to
provision and manage services. An entity includes entity-attributes that
define the
entity. The number of entity-attributes included in an entity help refine the
definition
of and provide granularity to more efficiently manage the entity.
[049] Figure 6 shows additional examples of entities the architecture 100 may
use to provision and manage services. The architecture 100 may use a schema
that
includes the following entities: a product-service entity 602, a product-
service-
account entity 604, a product-service-account-address entity 606, a product-
service-
account-contact entity 608, a product-service-attribute entity 610, a product-
service-
user-contact entity 612, a refill entity 614, a service order entity 616, and
a technical
service order 618. The architecture 100 may use the entities (e.g., 602
through 620)
in unique combinations to form service requests used to provision and manage
services. In one implementation, the architecture 100 uses the entities (e.g.,
502
through 520 and 602 through 618) to form service requests used to provision
and
manage services.
21
CA 02638268 2008-07-24
[050] Figure 8 shows a hierarchy 800 of coarse grained service requests that
the architecture 100 may use to hide the complexity of provisioning and
managing
services. A coarse grained service request (e.g., create post-paid order
service
request 802) defines a progressively more granular set of component services
804
(e.g., also shown in Table 3), service request entities (e.g., entity-1,
entity-2, entity-3
and entity-4 704), and entity-attributes 808 (e.g., shown in detail in Figures
5 and 6)
used to provision and manage services. For example, create post-paid order
service
request 802 invokes the component services 804 that include entities 704
defined by
entity-attributes 808. The architecture 100 uses layers of granularity from
coarse
grained service requests, component services, service request entities and
entity.-
attributes to efficiently provision and manage services while hiding the
complexity
from customers 122 and consumers 124. Table 4 shows a list of coarse grained
business services that may invoke component services (e.g., shown in Table 3)
in
combinations that may be pre-configured and dynamically changed in response to
systems within and in communication with the architecture 100. Coarse grained
service requests and component services may be added, deleted and modified
from
time to time, as systems within and in communication with the architecture 100
change.
Table 4 - Coarse Grained Services Requests
Account Balance Inquiry
Account Usage Inquiry
Account Invoice Inquiry
Activation
Create Billing Account
Create New Customer
Create New Service Account
Create Post-Paid Order
Create Pre-Paid Order
Create Service Request
22
CA 02638268 2008-07-24
Modify Billing Account
Modify Customer Data
Modify Service Request
Retrieve Billing Account Data
Retrieve Customer Data
Retrieve Installed Assets
Retrieve Orders
Retrieve Product Configuration
Retrieve Product List
Retrieve Product Price
Retrieve Service Accounts
Retrieve Service Request
[0511 Figure 9 shows the matching and locking processes for the architecture
100. The architecture 100 may attempt to execute an orchestrated service
request
(e.g., OSR-2 906) by comparing the correlation code (e.g., CC-2 908) of the
orchestrated service request with the correlation codes (e.g_, CC-7 922, CC-2
924,
and CC-9 926) of the locked service request exceptions (e.g., LSRE-1 928, LSRE-
2
930, and LSRE-3 932) stored in the exception handler queue 366. Where the
correlation code (e.g., CC-2 908) of the orchestrated service request (e.g..,
OSR-2
906) matches the correlation code (e.g., CC-2 924) of a locked service request
(e.g.,
LSRE-2 930) the architecture 100 locks the orchestrated service request (e.g.,
OSR-
2 906). The architecture 100 asynchronously continues to process other service
requests (e.g., OSR-4 914) while the architecture 100 resolves the exception
condition. Where the architecture 100 resolves an exception condition the
architecture 100 unlocks locked service requests and completes processing of
the
service request. Where the architecture 100 determines that the correlation
code
(e.g., CC-2 908) of an orchestrated service request (e.g., OSR-2 906) does not
match the correlation code (e.g., CC-2 924) of a locked service request (e.g.,
LSRE-
2 930) the architecture 100 completes processing of the orchestrated service
request
(e.g.., OSR-2 906).
23
CA 02638268 2008-07-24
[052] The architecture 100 solves the technical problems for communications
service providers 120 of avoiding runaway errors (e.g., exceptions) and
minimizing
the resources required to manage exceptions by preventing redundant
exceptions.
The architecture 100 improves the ease of use by consumers 124, customers 122,
and distribution partners 126, accelerates the self-provisioning of services,
and
increases self-provisioning by customers 122 of services. The architecture 100
improves the cycle-time between the initial request for service and service
activation
by increasing the efficiency related to managing exceptions that occur while
processing service requests. According to the above, there is provided a
computer-
implemented method comprising: receiving a data object relating to a service
request
comprising service request attributes; identifying correlation attributes in
the service
request attributes;
extracting the correlation attributes and forming a correlation code from the
correlation attributes; adding the correlation code to the service request to
obtain an
orchestrated service request; queuing the orchestrated service request in a
service
request queue; processing the orchestrated service request by:
extracting the correlation code from the orchestrated service request to
obtain an
extracted correlation code;
comparing the extracted correlation code to a locked correlation code
associated
with a pending service request exception; and
when the extracted correlation code and the locked correlation code match:
searching the service request queue for matching service requests
comprising the extracted correlation code in addition to the orchestrated
service request; and
locking the orchestrated service request and the matching service request in
the service request queue so that they do not execute.
[053] Furthermore, there is provided a computer program product, in particular
embodied stored on a computer-readable storage medium, as a signal or as a
data
stream, comprising computer readable instructions which, when loaded and
executed on a suitable system perform the steps of the above computer-
implemented method.
24
CA 02638268 2008-07-24
[054] Particularly, there is provided a product comprising: a machine readable
medium; and logic stored on the medium operable to:
receive a service request comprising service request attributes;
identify correlation attributes in the service request attributes;
extract the correlation attributes and form a correlation code from the
correlation
attributes;
add the correlation code to the service request to obtain an orchestrated
service
request;
queue the orchestrated service request in a service request queue;
process the orchestrated service request by:
extracting the correlation code from the orchestrated service request to
obtain an extracted correlation code;
comparing the extracted correlation code to a locked correlation code
associated with a pending service request exception; and
when the extracted correlation code and the locked correlation code match:
searching the service request queue for matching service requests
comprising the extracted correlation code in addition to the orchestrated
service request; and
locking the orchestrated service request and the matching service
request in the service request queue so that they do not execute.
[055] In a particular example, the logic stored on the medium operable to
process the orchestrated service request is further operable to:
resolve the pending service request exception and responsively:
unlock the orchestrated service request; and
unlock the matching service request.
[056] In a further particular example, the logic stored on the medium is
further
operable to: form the correlation code by concatenating the correlation
attributes.
[057] In a further particular example, the logic stored on the medium is
further
operable to: vary the correlation attributes selected to form the correlation
code
based on the service request.
CA 02638268 2008-07-24
[058] In a further particular example, the logic stored on the medium is
further
operable to: transform the service request with an eXtensible Stylesheet
language
transformation (XSLT) processor to obtain the orchestrated service request.
[059] In a further particular example, the logic stored on the medium is
further
operable to define multiple granular reusable service requests including at
least one
of the following: a customer create service request; a customer modify general
date
service request; a customer modify physical address service request; a modify
customer data service request; an account modify general date service request;
an
account modify billing profile service request; an account modify bill to
person
service request; an account modify bill to address service request; an account
modify payment date service request; a service order provisioning service
request;
an asset component service request; a provisioning task service request; and a
task
execute response service request.
[060] In a further particular example, the logic stored on the medium is
further
operable to form the correlation code using a customer code, an account code,
an
organization code, a product code, an order identifier or any combination
thereof.
[069] According to the above, the disclosed service request execution
architecture promotes effectiveness of man-machine interaction, particularly
by
promoting acceptance and use of self-service provisioning by consumers,
leading to
increased cost-savings on the side of the service provider. The architecture
greatly
reduces the technical burden of managing exceptions that occur while
processing
requests for services. The architecture accelerates the process of fulfilling
requests
for services by efficiently and effectively reducing the system resources
needed to
process exceptions by eliminating redundant exceptions corresponding to
related
service requests.
[062] A number of implementations have been described. Nevertheless, it will
be understood that various modifications may be made without departing from
the
spirit and scope of the invention.. Accordingly, other implementations are
within the
scope of the following claims-
26
