WO2017019098A1

WO2017019098A1 - Regulating compliance with a billing workflow

Info

Publication number: WO2017019098A1
Application number: PCT/US2015/042964
Authority: WO
Inventors: Fabio Gianetti; Robert Stuart PARKER; Daniel Dyer
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-07-30
Filing date: 2015-07-30
Publication date: 2017-02-02

Abstract

A technique includes receiving a request for a billing operation and regulating compliance of the billing operation request with a billing workflow that is defined by a billing vendor. The technique includes processing data representing the billing operation request in a processor-based machine to determine whether the request complies with the billing workflow; and selectively taking an action to correct the billing operation request based at least in part on the determination. A result of the selective correction is communicated to a billing engine.

Description

REGULATING COMPLIANCE WITH A BILLING WORKFLOW

BACKGROUND

[001] A cloud service generally refers to a service that allows end recipient computer systems (thin clients, portable computers, smartphones, desktop computers and so forth) to access a pool of hosted computing and/or storage resources (i.e., the cloud resources) and networks over a network (the Internet, for example). In this manner, the host, a cloud service provider, may, as examples, provide Software as a Service (SaaS) by hosting applications; Infrastructure as a Service (IaaS) by hosting equipment (servers, storage components, network components, etc.); or Platform as a Service (PaaS) by hosting a computing platform (operating system, hardware, storage, etc.). A typical cloud service incurs charges on a demand basis, is managed by a cloud service provider and may be scaled (scaled according to desired storage capacity, processing power, network bandwidth and so forth) by the end user.

BRIEF DESCRIPTION OF THE DRAWINGS

[002] Fig. 1 is a schematic drawing of a computer system according to an example implementation.

[003] Fig. 2A is an illustration of the initialization of a billing workflow injection system of Fig. 1 according to an example implementation.

[004] Fig. 2B is an illustration of the billing workflow injection system of Fig 1 performing validation processing of a billing operation request according to an example implementation.

[005] Fig. 2C is an illustration of the billing workflow injection system of Fig 1 reordering billing operation requests to regulate compliance with a predefined billing workflow according to an example implementation.

[006] Fig. 3 is flow diagram depicting a technique to regulate compliance with a predefined billing workflow according to an example implementation.

[007] Fig. 4 is schematic diagram of a cloud service manager of Fig. 1 according to an example implementation.

DETAILED DESCRIPTION

[008] A billing provider may define a billing workflow for various billing operations that are handled by the provider. In this context, "billing workflow" refers to a directed graph (i.e., an orchestration or blueprint), which is associated by a given billing vendor, or provider, and sets forth the order, or flow, in which certain billing tasks, or operations, are to be performed, as defined by the billing provider. The billing operations may include operations to create an account, create a customer, create a subscription, select a rate plan, select products, select services, set internal billing for a customer (showback or chargeback billing, as examples), link one or more of the foregoing together, and so forth. A billing workflow may vary from one billing provider to the next, with each workflow defining a different control flow and/or data flow for the billing provider's billing operations.

[009] A given billing provider may provide a billing engine that is constructed to adhere to the billing provider's billing workflow. As such, the billing engine may be constructed to receive billing operation requests (for corresponding billing operations) and process the requests in the order that is defined by the billing workflow. Moreover, the billing workflow may define one or more attributes (data identifying account identification, catalog information, and so forth) for each billing operation request. These attributes may be communicated to the billing engine with the billing operation requests and may be used by the billing engine to process the requests and perform the billing operations. If the billing operation requests that are sent to the billing engine are ordered incorrectly and/or are not accompanied by the appropriate attributes, as defined by the billing workflow, then the billing engine may reject the requests, erroneous operation of its billing engine may occur and/or the billing process may otherwise be disrupted, thereby potentially leading to time delays, costs and dissatisfaction with the billing process.

[0010] In accordance with example implementations that are described herein, a billing workflow injection system regulates compliance with a billing workflow that is associated with a particular billing provider by selectively taking actions to correct user- submitted billing operation requests that do not comply with the billing workflow. For a given user- submitted billing operation request, the actions may include automatically correcting the request and/or suggesting one or multiple corrections to the request. For example, in accordance with example implementations, the billing workflow injection system may correct incomplete billing operation requests (requests not proving all of the attribute(s) for the operation request, as defined by the workflow), and the billing workflow injection system may reorder billing operation requests, which do not comply with order that is defined by the billing workflow. As another example, the billing workflow injection system may suggest (via a message communicated to a graphical user interface (GUI), for example) that the user provide specific additional information for the billing operation request and resubmit the corrected request.

[0011] More specifically, in accordance with example implementations, the billing workflow injection system may include a user interface engine that allows selection of a pool of generic billing operations requests (requests to create an account, create a customer, create billing payment information, and so forth). The selectable billing operations requests may be generic in that the requests may which may apply to multiple billing workflows for multiple associated billing providers. In accordance with example implementations, a user may select a given billing operation by submitting a billing operation request (an application programming interface (API) request, for example) to a user interface of the workflow injection system, and this request may contain data that corresponds to one or multiple attributes. For purposes of regulating compliance of the requested billing operation to the specific billing workflow of the billing provider, the billing workflow injection system may include a transactions engine. More particularly, the billing operation request from the user may cause the user interface engine to communicate, or submit, a pending billing operation (called a "transaction" herein) to the transactions engine. The transactions engine may check the transaction according to the billing workflow and may undertake one or more of the following actions in response thereto: make one or multiple corrections to the transaction and/or the order of the transaction (relative to other pending billing operation request orders) before allowing the billing operation request to be routed to the billing provider's billing engine; and/or suggest one or multiple corrections to be handled by the user (by resubmitting the corresponding billing operation request, supplying additional information, and so forth).

[0012] As an example, the billing provider may define the following billing workflow to create an account (where the order in which the operations are listed below correspond to the time order in which the operations are to be performed): Billing Operation 1 : Verify Catalog Exists

Billing Operation 2: Verify Rate Plan(s) Exists

Billing Operation 3: Create an Instance of Account

Billing Operation 4: Create a Contact for the Account

Billing Operation 5: Create a Payment Method for the Account

[0013] The billing workflow above may be described in a human readable language, such L, as follows:

create_account:

description: Creating account based on existing Catalog and rate plan, tasks:

verify_catalog:

with-items: catalog_id

action: check_catalog_existence id=< $.catalog_id %>

status='ACTIVE'

on- success:

- verify_rate_plans

on-failure:

- abort verif y_rate_plans :

with-items: catalog_id in <% $.catalog_id %>

action: get_rate_plans catalog_id=< catalog_id %> status='ACTIVE'

publish:

rate_plans: <% $.rate_plans.id %>

on-success:

- create_account

on-failure:

- abort create_account:

with-items: catalog_id in <% $.catalog_id %> rate_plans in <%

$.rate_plans %>

action: create_rate_plans catalog_id=< catalog_id %> plans=<

rate_plans %>

publish:

account_id: : <% $.account.id %>

on-success:

- create_contact

- create_payment_method

on-failure:

- abort create_contact:

with-items: account_id in <% $.account_id %>

action: create_contact ccount_id =< account_id %>

publish:

contact_id: : <% $.contact.id %>

on-success:

- none create_payment_method:

with-items: account_id in <% $.account_id %>

action: create_cpayment ccount_id =< account_id %>

publish:

payment_id: : <% $.payment.id %>

on-success:

[0014] A user may submit billing operation requests that do not comply with above- described billing workflow. For example, the user may submit a billing operation request to create an instance of an account before the user submits billing operation requests to verify whether the catalog and rate plan(s) exist. For this scenario, the transactions engine may reorder the user- submitted billing operation requests (the transactions) into the appropriate order (an operation to verify that a catalog exists, an operation to verify that rate plan(s) exist and an operation to create an instance of an account, in that order) and send the reordered billing operation requests (i.e., the workflow compliant operation requests) to the billing engine. As another example, a user may submit a pending billing operation request to verify the rate plan(s) and provide data representing the rate plan identification (called "rate_plans.id" in the example workflow above) but not provide data identifying the catalog identification (called "catalog_id" in the example workflow above). However, the transactions engine, having previously processed the billing operation request to verify the catalog identification (for this example), may therefore know the catalog identification and correspondingly corrects the pending billing operation request to include data identifying the catalog identification before sending the corrected billing operation request to the billing engine.

[0015] Referring to Fig. 1, as a more specific example, in accordance with some implementations, a networked computer system 100 may include a cloud service manager 160, which, in turn, may include a billing workflow injection system 162, which regulates compliance with a predefined billing workflow that is used by a billing engine 172. In accordance with example implementations, the billing engine 172 may be a software plug-in that is provided by or on behalf of the billing provider. In this context, a "software plug-in" refers to machine executable instructions that are executed by a processor-based machine to cause the machine to process billing operations according the specific billing workflow that is promulgated by the billing provider.

[0016] For the example implementation depicted in Fig. 1, in addition to controlling billing for various cloud resources and/or services, the cloud service manager 160 may control the access to cloud resources 120. As an example, the cloud resources 120 may include one or multiple Infrastructure as a Service (IaaS) resources 120-1 (resources that provide hosted equipment, such as servers, storage components and network components as a service); Platform as a Service (PaaS) resources 120-2 (resources that provides hosted computing platforms, such as a platform containing an operating system, hardware, storage, and so forth); Software as a Service (SaaS) resources 120-3 (resources that provide hosted applications); DataBase as a Service (DBaaS) resources 120-4 (resources that provides hosted databases); as well as potentially other cloud services/cloud capability resources 120-5.

[0017] The cloud resources 120 may be coupled to the cloud service manager 160 by network fabric 129 for the example implementation depicted in Fig. 1. As examples, the network fabric may represent one or multiple types of network fabric (e.g., fabric including wide area network (WAN) connections, local area network (LAN) connections, wireless connections, Internet connections, and so forth). End user systems 150 (desktop computers, portable computers, smartphones, tablets, and so forth) may also be coupled to the network fabric 129 for purposes of accessing the cloud service manager 160.

[0018] The billing workflow injection system 162 may include a user interface engine 164 for purposes of receiving billing operation requests. In this manner, in accordance with example implementations, a user may (via a end user system 150) submit a billing operation request by submitting an application programming interface (API) request to an API 166 of the user interface engine 164. The API 166, in accordance with example implementations, represents a set of programming instructions and standards that the end user system 150 may use (via software executed on the end user system, for example) to access a pool 178 of available generic billing operation requests 180. The generic billing operation requests 180 may correspond to various billing operations (operations to create an account, create a customer, create a subscription, select a rate plan, select products, select services, set internal billing, link one or more of the foregoing together, and so forth). In accordance with example

implementations, the API 166 may have an associated schema defining the attributes for each generic billing operation request 180.

[0019] A given generic billing operation request 180 may be used for multiple billing providers and billing workflows. Therefore, the corresponding API request may be associated with a relatively large set of parameters or attributes, such that different subsets of the attributes may be used for different workflows. To submit a particular billing operation request for a specific billing workflow, the user, via the end user system 150, may select the appropriate API request (corresponding to one of the generic billing operation requests 180), provide at least the appropriate attributes that are defined by the specific billing workflow, and send the API request to the billing integration system API 166. [0020] In accordance with example implementations, the API 166 may generate a transaction that corresponds to the billing operation request associated with the received API request. The transactions engine 168, in accordance with example implementations, selectively validates and rejects the transactions that are provided by the billing system API 166. A validated transaction refers to a transaction that is accepted by the transactions engine 168, in that the transaction may either be 1.) correct (the transaction corresponds to a billing operation that was submitted in the correct order and contains the appropriate attributes, as defined by the billing workflow, for example) or 2.) incorrect but correctable (the transactions engine can correct an ordering of the corresponding billing operation or supplement an attribute not provided, for example). In accordance with example implementations, the transactions engine 168 may reject a transaction, which is incorrect and not correctable. In accordance with example implementations, the user interface engine 164 may communicate with the end user system 150 to indicate acceptance or rejection of the corresponding API request. In accordance with example implementations, for a rejected transaction, the transactions engine 168 may

communicated with the user interface engine 164 to cause the user interface engine 164 to communicate a message to the end user system 150 indicating how the corresponding API request (and corresponding billing operation request) is to be corrected to comply with the billing workflow.

[0021] The billing workflow injection system 160, in accordance with example implementations, includes a billing adaptor engine 170. The billing adaptor engine 170 may receive transactions from the transactions engine 168 and transform the transactions according to schema defined by the billing workflow before communicating corresponding billing operation requests to the billing engine 172.

[0022] Fig. 2A is an illustration 200 of operations associated with the initialization of the billing workflow injection system 162, in accordance with example implementations. As depicted in Fig. 2A, the billing engine 172 may be constructed to processing billing operations according to a specific billing workflow 204. As an example, the billing workflow 204 may be defined by a human readable language, such as YAML, and, in general, may set forth the schema that defines the attributes for each billing operation as well as the order in which the operations are to be processed. The billing engine 172 may publish the billing workflow (as indicated at reference numeral 212) to the billing adaptor engine 170. For example, in accordance with some implementations, the billing engine 172 may publish the workflow by communicating data representing a YAML language description (or another language description) of the workflow to the billing adaptor engine 170. The billing adaptor engine 170, in turn, may extract schema for the different billing operations and use these schema for communicating future billing operation requests to the billing engine 170. The billing adaptor engine 170 may program, or set, the workflow in the transactions engine 168, as indicated at 216. In accordance with example implementations, the billing adaptor engine 170 may set the workflow 204 in the transactions engine 168 by programming the transactions engine, such as by communicating data to the transactions engine 168, which the engine 168 may use to determine whether transactions comply with the billing workflow 204; communicating machine executable instructions to the transactions engine 168, which are executed by the transactions engine 168 to check whether transactions comply with the billing workflow 204; and so forth.

[0023] In accordance with example implementations, as part of the initialization of the billing workflow injection system, the user interface engine 164 may be configured to publish the billing workflow 204 to the user (via the user end system 150) in response to the user submitting the appropriate query to the engine 164.

[0024] Fig. 2B is an illustration 220 of the rejection of an API request 222 for a billing operation, in accordance with example implementations. As depicted in Fig. 2B, the billing integration system API 166 may receive the API request 222 for a billing operation and correspondingly submit a transaction to the transactions engine 168, as indicated at reference numeral 226. The transactions engine 168 may perform an operation 234 to validate the transaction, i.e., determine whether the transaction complies with the predefined billing workflow 204. In accordance with example implementations, the transactions engine 168 may validate the transaction if the transaction is fully compliant with the billing workflow 204 (the transaction corresponds to a billing operation that was submitted in the correct order and contains the appropriate attributes, as defined by the billing workflow, for example), or if the transaction does not fully comply with the billing workflow 204 but is correctable (the transactions engine 168 can correct an ordering of the corresponding billing operation or supplement an attribute not provided, for example). As depicted in Fig. 2B, for this example, the transactions engine 168 may determine that the transaction represented by the API request 222 is uncorrectable, and the transaction engine 168 may communicate 230 with the user interface engine 164 to indicate that the transaction (and corresponding API request 222) has been rejected. In accordance with example implementations, for a rejected transaction, the transactions engine 168 may cause the user interface engine 164 to communicate a message to the end user system 150 indicating how the corresponding API request (and corresponding billing operation request) is to be corrected to comply with the billing workflow 204.

[0025] Fig. 2C depicts an illustration 250 in which an API request 254 is associated with a billing operation request that does not comply with the billing workflow 204. However, for this example, the billing operation request is correctable. More specifically, for this example, an API request 254 may cause the billing integration system API 164 to submit a transaction (as indicated at 258) to the transactions engine 168. The transactions engine 168 may determine (at 262) whether the transaction is valid. For this example, the transaction engine 168 validates the transaction. However, the transactions engine 168 may determine that the corresponding pending billing operation request does not comply with the ordering that is defined by the billing workflow 204. For example, the transaction engine 168 may retain the pending billing operation request until the billing operation request(s) that precede the retained billing operation request have been received so that the transactions engine 168 may reorder these transactions, as indicated at reference numeral 263, so that the corresponding reordered billing operation requests now comply with the billing workflow 204. The transactions engine 168 may then send the correct billing operation requests to the billing adaptor engine 170, as depicted at 266, so that the billing adaptor engine 170 may perform the operations, as depicted at 270.

[0026] It is noted that the transactions engine 168 may perform corrections other than corrections related to billing operation request reordering. For example, the transactions engine 168 may supplement attribute data to correct a given billing operation request if the transaction engine 168 has this data stored from a previously processed billing operation request.

[0027] Referring to of Fig. 3, thus, in accordance with example implementations, a technique 300 includes receiving (block 304) a request for a billing operation. The technique 300 includes regulating compliance of the billing operation request with a predefined billing workflow, pursuant to block 308, where regulating compliance includes processing data representing the request in a processor-based machine to determine whether the request complies with the workflow and selectively taking an action to correct the billing operation request based at least in part on the determination. The technique 300 includes communicating a result of the selective correction to a billing engine, pursuant to block 312.

[0028] Referring to Fig. 4 in conjunction with Fig. 1, in accordance of example implementations, the cloud service manager 160 of Fig. 1 may include one or multiple physical machines 400 (in physical machines 400-1... 400-N, being depicted as examples in Fig. 4). The physical machine 400 may be an actual machine that is made up of actual hardware 410 and actual machine executable instructions, or software 450. Although the physical machines 400 are depicted in Fig. 4 as being contained within corresponding boxes, a particular physical machine 400 may be a distributed machine, which has multiple nodes that provide a distributed and parallel processing system.

[0029] In accordance with exemplary implementations, the physical machine 400 may be located within one cabinet (or rack); or alternatively, the physical machine 400 may be located in multiple cabinets (or racks).

[0030] A given physical machine 400 may include such hardware 410 as one or more processors 414 and a memory 420 that stores machine executable instructions, application data, configuration data and so forth. In general, the processor(s) 414 may be a processing core, a central processing unit (CPU), and so forth. Moreover, in general, the memory 420 is a non- transitory memory, which may include semiconductor storage devices, magnetic storage devices, optical storage devices, and so forth.

[0031] The physical machine 400 may include various other hardware components, such as a network interface 416 and one or more of the following: mass storage drives; a display, input devices, such as a mouse and a keyboard; removable media devices; and so forth.

[0032] The machine executable instructions 450 may, when executed by the processor(s) 414, cause the processor(s) 414 to form one or more of the user interface engine 166, the transactions engine 168, the billing engine 172 and the billing adaptor engine 170. In accordance with further example implementations, one or more of the components 166, 168, 170 and 172 may be constructed as a hardware component that is formed from dedicated hardware (one or more integrated circuits, for example). Thus, the components 166, 168, 170 and 172 may take on one or many different forms and may be based on software and/or hardware, depending on the particular implementation.

[0033] In general, the physical machines 400 may communicate with each other over a communication link 470. This communication link 470, in turn, may be coupled to the user end devices 150 (see Fig. 1) and as such, may form at least part of the network fabric 129 (see Fig. 1). The communication link 470 may represent one or more multiple buses or fast interconnects, in accordance with example implementations.

[0034] As an example, the cloud service manager 160 may be an application server farm, a cloud server farm, a storage server farm (or storage area network), a web server farm, a switch, a router farm, and so forth. Although two physical machines 400 (physical machines 400-1 and 400-N) are depicted in Fig. 4 for purposes of a non-limiting example, it is understood that the cloud service manager 160 may contain a single physical machine 400 or may contain more than two physical machines 400, depending on the particular implementation (i.e., "N" may be " 1," "2," or a number greater than "2").

[0035] While the present techniques have been described with respect to a number of embodiments, it will be appreciated that numerous modifications and variations may be applicable therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the scope of the present techniques.

Claims

WHAT IS CLAIMED IS:

1. An apparatus, comprising:

an application programming interface (API) to receive an operation request for a billing engine, the billing engine being associated with a billing workflow defined by a billing vendor; and

a transactions engine comprising a processor to regulate compliance of the operation request with the billing workflow, the transactions engine to:

be programmed with the billing workflow;

determine whether the operation request complies with the billing workflow; and selectively take an action to correct the operation request based at least in part on the determination of whether the operation request complies with the billing workflow.

2. The apparatus of claim 1, further comprising a billing adaptor to receive data representing a publication of the predefined billing work flow by the billing engine and program the transactions engine with the billing workflow in response thereto.

3. The apparatus of claim 1, wherein the transactions engine processes the operation request to regulate compliance with the billing workflow based at least in part on a transaction ordering defined by the billing workflow.

4. The apparatus of claim 1, wherein the transactions engine processes the operation request to regulate compliance with the billing workflow based at least in part on a at least one attribute defined by the billing workflow.

5. The apparatus of claim 1, wherein:

the transactions engine determines whether the billing operation request is valid; and selectively suggests a user correction to the billing operation request based at least in part on the determination on whether the billing operation request is valid.

6. The apparatus of claim 1, further comprising:

a billing adaptor,

wherein:

the transactions engine provides a second operation request in response to determination; and

the billing adaptor transforms the second operation request based on a schema associated with the billing workflow.

7. The apparatus of claim 1, wherein the transactions engine supplements the operation request with data derived from a billing operation previously processed by the transactions engine.

8. An article comprising a non-transitory computer readable storage medium to store instructions that when executed by a processor-based machine causes the processor-based machine to:

receive data representing a workflow for billing transactions associated with a billing provider;

receive billing operation requests generated by an application programming interface (API) in response to the API receiving associated API requests;

selectively reorder the received billing operation requests based at least in part on the workflow; and

generate billing operation requests for an associated billing engine based at least in part on the selective reordering.

9. The article of claim 8, the storage medium storing instructions that when executed by the processor-based machine causes the processor-based machine to selectively reject the billing operation requests generated by the API.

10. The article of claim 8, wherein the API is configured to recognize transactions associated with a plurality of billing systems associated with a plurality of billing providers.

11. The article of claim 8, the storage medium storing instructions that when executed by the processor-based machine cause the processor-based machine to selectively validate the billing operation requests.

12. A method comprising:

receiving a request for a billing operation;

regulating compliance of the billing operation request with a billing workflow defined by a billing vendor, comprising:

processing data representing the billing operation request in a processor-based machine to determine whether the request complies with the billing workflow; and

selectively take an action to correctthe billing operation request based at least in part on the determination; and

communicating a result of the selective correction to a billing engine.

13. The method of claim 12, wherein receiving the request comprises receiving data representing application programming interface (API) requests.

14. The method of claim 12, wherein the predefined workflow comprises a workflow of operations involved in creating an account, creating a customer identity, creating a subscription, verifying a rate plan, verifying a catalog and creating a payment method.

15. The method of claim 12, further comprising receiving data representing publication of the workflow by the billing engine and programming a transactions engine with the billing workflow to regulate compliance with the billing workflow.