TECHNICAL FIELD OF THE INVENTION

The invention relates to the field of cloud services management and provision.

STATE OF THE PRIOR ART

Generally, cloud service providers offering hybrid and or multi-cloud services to major corporation has the challenge of providing orchestration of a vast number of legacy infrastructures of multiple customers and multi-cloud environments (Private/Public/Various brands GCP, AWS, Azure, VMware, OracleVM).

Services Orchestration platform (1) such as ServiceNow (SNOW) has a repository architecture that is limited by a relational repository database wherein all possible infrastructure relations have to be pre-defined. This is a huge requirement for a service provider when the number of legacy infrastructures of the customer is very important. Said relational repository does not allow storage of the various technical details of multiple customer environments.

This means that the technical details of the customer environment will have to be retrieved from the source systems at the customer site which leads to a lack of performance to cater, for example, for user-portal based automated scenario's with ‘on-line’ response requirements.

There are many data formats necessary to describe all different CI's (Configuration Items or Control Instances) in non-standardized Legacy environments that a multi and hybrid cloud solutions of a cloud service provider is managing. Further these technical data are too detailed to be stored in a cloud management database (CMDB (10)) and should be up to date.

The combination of these both requirements:an enormous variety of Infrastructure landscapes in legacy environments of bigger customers does not fit easy in an normal relational Database, anda very high requirement for response time and volumes when updates are done in a large legacy environment while Customer wants to have automatic provisioning and instantaneous repository updates were not satisfied up to now.

Therefore, there is a need for a system that solves this typical problem (for example integration of Legacy and Hybrid/Multi Cloud)

SUMMARY OF THE INVENTION

The present invention therefore has the object to obviate certain drawback of the prior art by proposing a computing infrastructure to be the connection between a services orchestration platform (such as ServiceNow) and the complex automation scenario's (for example, and without limitation, provisioning of application database using ‘host’ data or service processing for other database request such as modifying user, changing parameter) in the ‘real’ Service provider infrastructures and data management environments.

This goal is achieved by a computing device comprising a No-SQL repository database for handling multiple legacy environments and registering a wide variety of configurations (software and hardware, and cloud) by storing technical data to support the E2E automation and authorization of Standard Service Requests (SSR) and wherein a table stored in is configured to hold data in No-SQL format and for providing managed services (standard service requests) in very complex environments using at least one other database (Oracle or Mysql or MS SQL or DB2) and for the automation of SSR's database (Standard Service Requests).

According to another feature, the No-SQL format used is JSON (JavaScript Object Notation).

According to another feature, each line of the stored RepoDB table defines configuration items (CI) corresponding to a system identity (with the attribute sys_id) and including the creator name and date of creation, the updater name and date of update, the type of system (host, instance, software set, database) and a string of technical detail data in JSON format.

According to another feature, the No-SQL repository database is configured for storing technical data concerning CI (Configuration Items or Control Instances) in a dedicated database and sending this data to a GUI (graphical user interface) of a service orchestration platform used by an end-user or a service requestor to present this data to said end-user or service requestor in the graphical user interface of user computer.

According to another feature, the RepoDB is used in a system for automation of services standard requests (SSR) in a service provision computing infrastructure, said system comprising at least:computing means implementing a services orchestration platform for orchestration and configuration management of services in the computing infrastructure;an automation execution engine for technical configuration management and automation of the components of the computing infrastructure;
the system being characterized in that the RepoDB is interacting, through a communication network, with:the services orchestration platform for interaction with end-user (GUI controls) through controls including SSR;an automation execution engine for updates after changes and execution of SSR.

Another goal of the invention also concerns a method for providing automation of standard service requests.

This goal is achieved by a process wherein after an end-user of a services orchestration platform, communicating with a RepoDB as described above, selects a new order (standard service requests) from a catalogue of said services orchestration platform through a graphical user interface (GUI) of a dedicated user portal, said GUI prompts said end-user to select a CI so as to populate controls or attributes commands in the graphical user interface (GUI) by mean of a message, containing data to be loaded and, sent by the RepoDB to the Services orchestration platform.

According to another feature, the type of data of such attributes or controls depends on the Standard Service Requests (SSR).

According to another feature, when the order is not included in the catalogue of the services orchestration platform workflow, an execution of such order is required by a command sent, by the service orchestration platform, to the automation execution engine to let execute the command on the target database defined by the CI selected by the end-user.

According to another feature, the end-user completes with required details of the order form displayed on the user interactive interface by means of a set of information included in the loaded data contained in the message sent by the RepoDB (12B).

According to another feature, after the order is completed, a refresh routine included in the automation execution engine (for example Ansible refresh playbook) is called to refresh specific data for a specific CI in the RepoDB.

