FR2887056A1 - SYSTEM AND METHOD FOR MANAGING AND SERVER OF ORCHESTRATION OF SERVICES PROVIDED BY SERVICE PROVIDER SYSTEMS - Google Patents

Abstract

The method of managing services by an orchestration server (1) for a user in a network, at least one service being performed by performing at least two actions provided by different provider systems, comprises the steps of: a) receiving (11) a service request from the user, b) selecting (12) an execution flow comprising a timing of actions to be executed and a billing flow adapted to the requested service , c) sending (14, 17, 21) an order of execution of an action to a receiving system, d) receiving (15, 18, 22) the result of the action, steps c) and d ) being repeated as many times as defined in the selected execution flow and in the order defined by it, e) sending (24) to the user the response corresponding to the requested service, and said method further comprises at least one step (13, 16, 19, 20, 23) of sending at least one billing order according to the billing flow selected.

Description

The present invention relates to a system, a server and a method of

  managing services in a network, at least one service being performed by executing at least two actions provided by different service providers.

  Many protocols and architectures exist to allow the online payment of goods or services provided for a customer by an application.

  However, there are more and more services that, to be realized, require the implementation of several basic functions, or actions, provided by different providers.

  Thus, for example, a localized SMS sending service with presence information requires the use of an SMS management function, a location function and a presence function.

  To carry out this service, the service provider must therefore coordinate the execution of the actions of each service provider and the related invoicing.

  Currently, three billing architectures are used.

  In the first architecture, each provider invoices its services independently of each other. Each provider therefore has a direct link with the user account management server, or billing server.

  This architecture has the disadvantage of generating a micro billing of each action while the user has requested a single and global service. Moreover, in case of failure of an action located downstream of the successive stream of actions, the customer is debited with the price of the successful actions upstream while the service has not been obtained. To avoid this, a correlation must be made at the billing server, correlation in practice very complex to implement.

  Also, in a second architecture, the service provider charges the service in a global manner. This one has a direct link with the billing server.

  However, this architecture has the disadvantage of allowing service providers the ability to bill their action directly, creating a risk of double invoicing. Thus a service provider can bill his action while the service provider invoices the service rendered overall, including the price of the service rendered by the service provider.

  Finally, in a third architecture, the provider of the last action generally invoices the service and is therefore in relation with the billing server.

  This architecture has the disadvantage of forcing the last provider to adapt its billing to the requested service with a complex system of coordination and collection of information with other providers.

  The object of the invention is therefore to propose a system and a server which eliminate all the aforementioned drawbacks and which therefore make it possible to implement billing in a reliable and easy-to-use manner.

  The object of the invention is therefore an orchestration server of a service management system for a user in a network, at least one service being performed by executing at least two actions provided by provider systems. different, said server comprising - first means of communication with interface means, these interface means being adapted to allow the user to request the execution of a service and to present to the user the result obtained by the requested service; second means of communication with an accounting management server, said server being adapted to credit and / or debit the user's account according to billing orders; third means of communication with the provider systems, characterized in that it further comprises: means for storing a workflow and a billing flow for each service, the workflow defining the timing actions to perform the service and the billing flow defining the billing rules to be applied for the service, connected to: - means of activation of suitable services for each requested service and according to the stored workflow corresponding to this service, to sequence orders of execution of actions and to transmit these orders to the systems providing, and to - means of management of the invoicing of each requested service able to determine, according to the success or the failure the execution of the actions performed for the service and the billing flow defined, the billing orders to be sent to the account management server.

  Another object of the invention is a service management system for a user in a network, at least one service being provided by the execution of at least two actions provided by different service providers, said system comprising: means for interfacing with the user adapted to enable the latter to request the execution of a service and to present to the user the result obtained by the requested service, - an account management server of the user capable of crediting and / or debiting this account according to billing orders, characterized in that it furthermore comprises an orchestration server 15 as defined above, this server being connected to the interface means, to the server account management and service systems.

  A third object of the invention is a service management method by an orchestration server for a user in a network, at least one service being performed by executing at least two actions provided by different provider systems, said method comprising the steps of: a) receiving a service request from the user, then b) selecting an execution flow and a billing flow adapted to the requested service, said execution flow comprising a timing of actions to be executed, c) sending an execution order of an action to a provider system, d) receiving the result of the action performed, and steps c) and d) being repeated as many times as Once defined in the selected execution flow and in the order defined by it, e) sending the user the corresponding response to the requested service, and said method further comprising at least one transmitting step at least one order of billing based on the selected billing flow.

  Other features of this third object are: the step of issuing at least one billing order comprises a first sub-step i) authorization request to verify that the account of the user is compatible with the billing order, this first sub-step being executed before step c), and a second substep ii) confirmation to trigger or cancel the corresponding billing; the authorization sub-step, respectively the confirmation sub-step, is executed before each step of sending an execution command, respectively after each step of receiving the result of the action; the authorization sub-step, respectively the confirmation sub-step, is executed before the first step of sending an execution command, respectively after the last reception step defined in the stream; the authorization sub-step, respectively the confirmation sub-step, is executed before the first step of sending an order as defined in the execution flow, respectively after each step of receiving a result of an action ; and the authorization sub-step also initiates a quota and the validation sub-step transfers the amount of quota consumed to the account management server and the step of sending an execution command sends the quota to the server provider and the step of receiving the response transmits to the orchestration server the amount of quota consumed.

  A fourth subject of the invention is a computer program product comprising program code instructions recorded on a computer readable medium, for implementing the steps of the preceding method when said program is running on a computer.

  The invention will be better understood on reading the description which follows, made solely by way of example, and with reference to the appended drawings in which: FIG. 1 is a simplified diagram of a system and a server according to a preferred embodiment of the invention; and FIG. 2 is a temporal diagram of the flows between the different elements of the system of FIG. 1 during the execution of a service.

  With reference to FIG. 1, a service management system comprises an orchestration server 1.

  This orchestration server 1 is connected to means SP1, SP2, SP3, interface, or service providers, by first means 2 of communication.

  These service providers SP1, SP2, SP3 allow a user to select a service, or a service, and, in return, provide him with the selected service. Such a service is, for example, a localized SMS sending service.

  The orchestration server 1 is also connected to a user account management server SGC by second means 3 of communication.

  The SGC account management server is also referred to in the literature as the billing server. Conventionally, the SGC server has three roles: the valuation of an event, that is to say, the supply of a price, the billing and the management of the accounts. The SGC account management server receives billing orders from the orchestration server 1 and debits or credits the accounts of the users according to these orders. In particular, it should be noted that the use of the term billing in this description does not necessarily imply the issuance of an invoice but corresponds to a movement of values.

  The SGC account management server is also able to process authorization requests as well as confirmation requests from the orchestration server 1. Although optional, these two types of requests are, in practice, regularly implemented.

  A request for authorization makes it possible to control that a billable event associated with a user can be realized. It thus makes it possible to determine if the user is sufficiently solvent to grant him access to a resource. In a non-exhaustive way, following a request for authorization, the SGC account management server checks that the user is known, that he has enough credit and that he has not exceeded the consumption thresholds that he have been awarded, that he is not part of a list of forbidden users, that he has agreed to be billed, ...

  A confirmation request informs the SGC account management server that a particular action has been successfully completed and can be billed. This therefore corresponds to a proper billing order since, following the receipt of this confirmation request, the account management server SGC debits the user's account of the planned amount.

  A request for confirmation is not necessarily linked to a request for authorization, some actions can be executed and invoiced without prior authorization.

  In the following description, we use the term partial confirmation request when it corresponds to the execution of only part of a service requested by the user.

  The orchestration server 1 is also connected to service providers El, E2, E3, also called enablers in the Anglo-Saxon technical literature, by third means 4 of communication.

  It should be understood that the first, second and third communication means 2, 3, 4 are differentiated in this description at the functional level. In a preferred implementation, the different servers are connected to the same network to the TCP / IP standard, the data packets being directed according to the addresses of each server. Thus, physically, the orchestration server 1 has a single network card and a single physical connection with the TCP / IP network. Other network architectures may be chosen by those skilled in the art to obtain the desired functionalities while adapting to local constraints such as, for example, attachment to several private and / or public networks.

  The orchestration server 1 comprises means 5 for storing the workflows and the billing flow of each service.

  For a given service, a workflow (English workflow) defines the sequence of calls to the service providers El, E2, E3 to perform the requested service.

  Thus, the workflow defines the different service providers El, E2, E3 that make up the service and the sequential order of their calls.

  It also defines how each service provider El, E2, E3 must perform the requested action, that is to say its parameterization.

  The billing flow for a service defines the billing scenario for this service.

  For each service, a generic scenario out of three is chosen.

  The first generic scenario operates in the form of a global authorization of partial confirmations. In this scenario, the orchestration server 1 makes a global authorization request for the entire service to the SGC account management server and sends partial confirmations for performing each action of a provider server. This global authorization request is usually made before the start of the service and is repeated as many times as necessary.

  The second generic scenario runs on global authorization mode a global confirmation. In this scenario, the orchestration server 1 makes a global authorization request for all service to the SGC account management server and sends a global confirmation for the entire service. The global authorization request is made in general before the start of the service actions and is repeated as many times as necessary. The global confirmation usually takes place after the completion of the service actions.

  The third generic scenario operates under the Partial Confirmations Partial Confirmations mode. In this scenario, authorization requests are executed in general before an action, or action group, is executed for the service, and confirmation is usually performed after this action or group has been executed. of shares.

  In addition to these generic scenarios, the billing flow defines for each action its billing method, even its free and the behavior to be held in case of failure: this action can be billed regardless of the success or failure of the action. It can also be billed, or not, based on the success of previous or next actions, regardless of the overall success of the service.

  Indeed, the invoicing of an action can take place independently of the results of the other actions of the service, or, on the contrary, be conditioned to the success of all the actions of the service. In the latter case, the failure to perform an action results in the cancellation of the invoicing of the successful actions upstream of the execution flow.

  As an example, assume that an X service requires four A, B, C, and D actions, with A, C, and D being paid, and the B action free.

  Actions Paid / Free Dependency

A P -

B G -

C P D

D P -

  The Dependency column defines that the invoicing of the action C depends on the success of the action D. Thus, if the actions A and C have been invoiced but the action D fails, then the invoicing related to the action C is canceled and billing related to Action A is maintained.

  The orchestration server 1 also comprises means 6 for activating services which, for each requested service, select in the storage means 5 the corresponding workflow and, according to the timing defined in this workflow, issue commands execution of the actions towards the service providers El, E2, E3, receive the responses thereof and thus build the service.

  The orchestration server 1 comprises means 7 for managing the billing which, for each service requested, select the corresponding billing flow. Depending on the rules of this billing flow and the success or failure of the actions clocked by the activation means 6, these means 7 for managing the billing issue billing orders to the server SGC management of accounts.

  The operation of the orchestration server 1 and more generally of the service management system will now be explained in connection with FIG. 2, which represents a scenario of realization of a service.

  In this figure, the time flow takes place from top to bottom, the different horizontal arrows representing the interactions between the different servers. From the left, the first column symbolizes the user U, the second column, the service provider SP, the third column, the orchestration server 1, the fourth column, the different service providers and the fifth column, the SGC server account management.

  After an interaction with the user U, the service provider SP 11 issues a service request to the orchestration server 1.

  The orchestration server 1 searches in 12 for the execution flow and the billing flow of the requested service.

  For the sake of clarity, it is assumed that the billing flow corresponds to a scenario, an overall authorization of partial confirmations. The skilled person knows, without difficulty, adapt the scenario presented to other types of generic scenarios.

  At 13, the orchestration server 1 sends a global authorization request to the account management server SGC.

  This authorization request has, for example, the form Authorize (serviceid, actions, params) where service-id is the identifier of the service, actions is the list of service providers involved and params represents all the parameters useful for the valuation of the service. service.

  In case of a positive response, the orchestration server 1 receives a trx-id transmission identifier.

  Then, for the first action to be executed, this one being defined as being performed by the provider El, the orchestration server 1 sends in 14 a request for execution of the action, for example in the form Function-E1- Request (trx-id, trx-id-E1, actions, params) where trx-id is the global transaction identifier obtained previously, trx- id-E1 is the transaction-specific transaction identifier for the action the E1 provider server, actions is the action to execute and params the parameters necessary for the execution and the valuation of this action. The identifier trx-id-E1 is created by the orchestration server 1 and is linked to the global identifier trx-id.

  At 15, the service provider El sends the corresponding response. This is positive or negative depending on the success or failure of the action. It contains the trx-id-E1 identifier to identify the answer and link it to the correct service.

  At 16, the orchestration server 1 sends a confirmation to the SCG account management server. This is a partial confirmation that concerns only the action that has just been performed. It should be noted that, in case of failure of the action, this confirmation can actually be a billing cancellation.

  For the next action to be performed by the provider server E2, the execution request steps 17, 18 response and partial confirmation 19 are again executed.

  This cycle is repeated as many times as necessary to execute all the actions defined for the requested service.

  As an illustration, Figure 2 shows an optional authorization step. In this generic scenario, this authorization step is executed when the total amount authorized by the previous authorization request has been consumed. The orchestration server 1 then issues a new authorization request similar to that described in step 13.

  Once the authorization has been obtained, the last action with the service provider E3 is requested at 21, the response being made at 22 and the billing confirmation at 23.

  All the actions having been executed and the service that can be rendered to the user, the orchestration server 1 returns the response at 24 to the service provider SP which informs the user at 25.

  In a variant, this service management system also operates with an accounting management server SGC adapted to manage quotas, that is to say units of service or access rights to the service. A quota may contain several monetary or non-monetary resources, such as memory sizes, usage times, etc. Quota therefore means a plurality of consumption variables.

  It is then conceivable that the authorization request corresponds to a quota request, the response being a usable quota and the confirmation becomes information on the quota consumed by the action.

  The request to execute an action contains the quota available for the execution of the action and the corresponding response provides the quota consumed and the remaining quota, which corresponds to the difference between the available quota and the quota consumed.

  The service management system and the orchestration server described advantageously make it possible, by centralizing flows, and in particular billing flows, to simplify and make reliable the billing of services implementing actions provided by several service providers.

  This system and this server advantageously make it possible to migrate the existing systems to this new system because the interfaces with the management servers are not modified. The same applies to service providers and service providers, the adaptation being handled by the orchestration server.

  By centralizing the management of the execution and billing of services, the system and the orchestration server advantageously allow precise management of billing. Thus, authorizations and billing confirmations are adaptable precisely to the needs of each service.

  Similarly, quota management advantageously allows great flexibility in the management of allocated resources.

Claims (9)

  An orchestration server (1) of a service management system for a user in a network, at least one service being performed by executing at least two actions provided by provider systems (E1, E2, E3), said server comprising - first means (2) of communication with interface means (SP1, SP2, SP3), these interface means being adapted to allow the user to request the execution of a service and to present to the user the result obtained by the requested service; second means (3) of communication with an accounting management server (CMS), said server being adapted to credit and / or debit the user's account according to billing orders; the third means (4) of communication with the service providers, characterized in that it further comprises: means (5) for storing a workflow and a billing flow for each service, the workflow defining the timing of the actions to perform the service and the billing flow defining the billing rules to be applied for the service, connected to: - means (6) for enabling suitable services, for each service requested and according to the stored workflow corresponding to this service, to sequence action execution orders and to transmit these orders to the service providers, and to - means (7) for managing the billing of each requested service able to determine, based on the success or failure of the execution of the actions performed for the service and the billing flow defined, the billing orders to be sent to the management server.   2. Service management system for a user in a network, at least one service being performed by performing at least two actions provided by different provider systems, said system comprising: - means (SP1, SP2, SP3) ) user interface adapted to enable the user to request the execution of a service and to present to the user the result obtained by the requested service, - an account management server (CMS) of the user able to credit and / or debit this account according to billing orders, characterized in that it further comprises an orchestration server (1) according to claim 1, the server being connected to the means interface, to the account management server and to the service providers.   A service management method by an orchestration server (1) for a user in a network, at least one service being performed by performing at least two actions provided by different provider systems, said method comprising steps of: a) receiving (11) a service request from the user, then b) selecting (12) a flow of execution and a billing flow adapted to the requested service, said flow of execution comprising a timing of actions to be performed, c) sending (14, 17, 21) an execution order of an action to a provider system, d) receiving (15, 18, 22) the result of the action executed, the steps c) and d) being repeated as many times as defined in the selected execution flow and in the order defined by it, e) sending (24) to the user of the response corresponding to the requested service, and said method further comprising at least one emissio step (13, 16, 19, 20, 23) n at least one billing order based on the selected billing flow.   4. Method according to claim 3, characterized in that the step of issuing at least one billing order comprises a first sub-step i) authorization request to verify that the account of the user is compatible with the billing order, this first sub-step being executed before step c), and a second substep ii) confirmation to trigger or cancel the corresponding billing.   5. Method according to claim 4, characterized in that the authorization sub-step, respectively the confirmation sub-step, is executed before each step of sending an execution command, respectively after each step of receiving the result. of the action.   6. Method according to claim 4, characterized in that the authorization sub-step, respectively the confirmation sub-step, is executed before the first step of sending an execution command, respectively after the last reception step. , defined in the stream.   7. Method according to claim 4, characterized in that the authorization sub-step, respectively the confirmation sub-step, is executed before the first step of sending an order as defined in the execution flow, respectively after each step of receiving a result of an action.   8. Method according to claim 4, 5, 6 or 7, characterized in that the authorization sub-step also initiates a quota and the validation sub-step transfers the amount of quota consumed to the accounting management server and that the step of sending an execution order sends the quota to the provider server and the step of receiving the response transmits to the orchestration server the amount of quota consumed.   A computer program product comprising program code instructions recorded on a computer readable medium, for carrying out the steps of the method according to claims 3 to 8 when said program is running on a computer.