WO2017058222A1

WO2017058222A1 - Data transfer requests

Info

Publication number: WO2017058222A1
Application number: PCT/US2015/053322
Authority: WO
Inventors: Robert SCALA; Rania MOHAMED
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-09-30
Filing date: 2015-09-30
Publication date: 2017-04-06

Abstract

Examples disclosed herein relate to data transfer requests. Some examples enable receiving a data transfer request, retrieving a set of configurations from the data transfer request, and determining, based on the set of configurations, an ordered set of data handling actions to be executed to process the data transfer request.

Description

DATA TRANSFER REQUESTS

BACKGROUND

[0001 ] The amount of data available in an enterprise environment (e.g., within a business) is continually on the rise. The data is rarely accumulated or stored in the same place. The data is distributed on multiple database platforms and/or different files. Additionally, the data may exist in various different formats. To serve their business objectives and demanding information technology (IT) workloads, many businesses seek to store their data in a place where storage resources are readily available, scalable, and cost-effective like a cloud computing environment.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a block diagram depicting an example data transfer requests system comprising various components including a client computing device in communication with a server computing device for processing data transfer requests.

[0004] FIG. 2 is a block diagram depicting an example data transfer requests system.

[0005] FIG. 3 is a block diagram depicting an example machine-readable storage medium comprising instructions executable by a processor for providing data transfer requests.

[0006] FIG. 4 is a block diagram depicting an example machine-readable storage medium comprising instructions executable by a processor for processing data transfer requests.

[0007] FIG. 5 is a flow diagram depicting an example method for processing data transfer requests. [0008] FIG. 6 is a flow diagram depicting an example method for processing data transfer requests.

DETAILED DESCRIPTION

[0009] The following detailed description refers to the accompanying drawings. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. It is to be expressly understood, however, that the drawings are for the purpose of illustration and description only. While several examples are described in this document, modifications, adaptations, and other implementations are possible. Accordingly, the following detailed description does not limit the disclosed examples. Instead, the proper scope of the disclosed examples may be defined by the appended claims.

[0010] The amount of data available in an enterprise environment (e.g., within a business) is continually on the rise. The data is rarely accumulated or stored in the same place. The data is distributed on multiple database platforms and/or different files. Additionally, the data may exist in various different formats. To serve their business objectives and demanding information technology (IT) workloads, many businesses seek to migrate their data to a place where storage resources are readily available, scalable, and cost-effective like a cloud computing environment. Once migrated, the data needs to be regularly synchronized to be kept up to date.

[001 1 ] Current data extraction, transformation, and loading (ETL) methods are generally very cumbersome. Most companies today write their own in-house routines for the above ETL operations. However, those in-house routines are written specific to one type of data format and would not work for another type of data format. This means that the companies have to develop ETL routines for individual data types (and/or database platforms/files that serve those data types), which would be a very time-consuming and challenging task.

[0012] Examples disclosed herein provide solutions to these challenges by providing a technique to process data transfer requests as defined by a particular tenant that is served by a cloud computing environment. A data transfer request, for example, may comprise a data migration request to migrate data to a cloud storage resource in the cloud computing environment or a data synchronization request to synchronize data with the cloud storage resource. Such a data transfer request may specify a particular set of configurations as defined and/or specified by each tenant. Once the request is received from a particular tenant, the request may be processed by retrieving the set of configurations from the request, and determining, based on the set of configurations, an ordered set of data handling actions to be executed to process the request. The ordered set of data handling actions determined for one data transfer request may be different from another ordered set of data handling actions determined for another request. For example, they may include different set of actions and/or actions in different orders.

[0013] Some examples enable receiving a first data transfer request from a first tenant of a plurality of tenants that are served by a cloud computing environment and receiving a second data transfer request from a second tenant of the plurality of tenants. Some examples may enable retrieving a first set of configurations from the first data transfer request, and determining, based on the first set of configurations, a first ordered set of data handling actions to be executed to process the first data transfer request. Some examples may enable retrieving a second set of configurations from the second data transfer request, and determining, based on the second set of configurations, a second ordered set of data handling actions to be executed to process the second data transfer request. The first ordered set of data handling actions may be different from the second ordered set of data handling actions. In this manner, each data transfer request may be processed according to the corresponding set of configurations that have been specifically defined for that particular request by the tenant, resulting in the data migration and/or synchronization as originally intended by the tenant.

[0014] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term "plurality," as used herein, is defined as two or more than two. The term "another," as used herein, is defined as at least a second or more. The term "coupled," as used herein, is defined as connected, whether directly without any intervening elements or indirectly with at least one intervening elements, unless otherwise indicated. Two elements can be coupled mechanically, electrically, or communicatively linked through a communication channel, pathway, network, or system. The term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will also be understood that, although the terms first, second, third, etc. may be used herein to describe various elements, these elements should not be limited by these terms, as these terms are only used to distinguish one element from another unless stated otherwise or the context indicates otherwise. As used herein, the term "includes" means includes but not limited to, the term "including" means including but not limited to. The term "based on" means based at least in part on.

[0015] FIG. 1 is a block diagram depicting an example system 1 10 comprising various components including a client computing device in communication with a server computing device for processing data transfer requests.

[0016] The various components may include client computing devices 140 (illustrated as 140A, 140B, ..., 140N) and server computing devices 130 (illustrated as server computing device 130A, 130B, ..., 130N). Each client computing device 140A, 140B, ..., 140N may communicate requests to and/or receive responses from server computing device 130. Server computing device 130 may receive and/or respond to requests from client computing devices 140. Client computing devices 140 may include any type of computing device providing a user interface through which a user can interact with a software application. For example, client computing devices 140 may include a laptop computing device, a desktop computing device, an all-in-one computing device, a thin client, a workstation, a tablet computing device, a mobile phone, an electronic book reader, a network-enabled appliance such as a "Smart" television, and/or other electronic device suitable for execution of the functionality described below. While server computing device 130 is depicted as a single computing device, server computing device 130 may include any number of integrated or distributed computing devices.

[0017] The various components may include remote storage resources (e.g., physical or virtual storage devices, databases, etc.) that may be accessible by server computing device 130 and/or client computing device 140 via a network 50. In some implementations, remote storage resources may represent cloud storage resources (illustrated as 150A, 150B, ..., 150N) that reside in a cloud computing environment 150. Cloud computing environment 150 may represent a private cloud, a public cloud, and/or a hybrid cloud.

[0018] The various components (e.g., components 130, 140, and 150) depicted in FIG. 1 may be coupled to at least one other component via network 50. Network 50 may comprise any infrastructure or combination of infrastructures that enable electronic communication between the components. For example, network 50 may include at least one of the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a SAN (Storage Area Network), a MAN (Metropolitan Area Network), a wireless network, a cellular communications network, a Public Switched Telephone Network, and/or other network. According to various implementations, system 1 10 and the various components described herein may be implemented in hardware and/or programming that configures hardware. Furthermore, in FIG. 1 and other Figures described herein, different numbers of components or entities than depicted may be used.

[0019] Server computing device 130 may comprise a request receive engine 131 , a configuration retrieve engine 132, an action determine engine 133, an action execute engine 134, and/or other engines. Client computing device 140 may comprise a request generate engine 141 , a request provide engine 142, and/or other engines. The term "engine", as used herein, refers to a combination of hardware and programming that performs a designated function. As is illustrated respect to FIGS. 3-4, the hardware of each engine, for example, may include one or both of a processor and a machine-readable storage medium, while the programming may be instructions or code stored on the machine-readable storage medium and executable by the processor to perform the designated function.

[0020] Request receive engine 131 may receive a data transfer request. In some implementations, the data transfer request may comprise at least one of: a data migration request and a data synchronization request. For example, a data migration request may represent a request to migrate data (e.g., data from various different sources) to a remote storage resource (e.g., a cloud storage resource in a cloud computing environment such as cloud computing environment 150). To keep the migrated data up-to-date, a data synchronization request may be made to synchronize the data between the source location and the remote storage resource.

[0021 ] The data transfer request may specify or otherwise define the data to be transferred (e.g., migrated or synchronized) as part of the request. The data being transferred may be originated from various sources such as a file, an email database, and/or any legacy databases. A source may be a local data storage (e.g., data storage 149 that is local to client computing device 140A, data storage 139 that is local to server computing device 130A) or any other external and/or remote data storage (although not illustrated in FIG. 1 ). In some situations, a source may store unstructured data and/or structured data in a particular format (e.g. Extensible Markup Language (XML) schema, Structured Query Language (SQL) database schema, a binary file format, a text file format, etc.).

[0022] The data transfer request may specify or otherwise define a set of configurations that is specific to that request. For example, the set of configurations may specify at least one of: an amount of data to be migrated (e.g., if the request is a data migration request), whether a synchronization occurs ad hoc or offline (e.g., if the request is a data synchronization request), a start and/or end time of the data transfer, a number of batches to be run for the data transfer request, parsing rules (e.g., instructions on how and/or when the data to be transferred should be parsed), mapping rules (e.g., instructions on how and/or when the data to be transferred should be transformed into a particular format), loading rules (e.g., instructions on where and/or when the data should be loaded), validation rules (e.g., instructions on how and/or when the data to be transferred should be validated for data consistency), and security rules (e.g., instructions on how and/or when the data to be transferred should be encrypted and/or decrypted). Since the set of configurations are made specific to a particular data transfer request, a first data transfer request may include a first set of configurations, a second data transfer request may include a second set of configurations, a third data transfer request may include a third set of configurations, and so on.

[0023] In some implementations, the set of configurations may specify a particular order in which different data handling actions (e.g., a parsing action, mapping action, loading action, validation action, security actions, etc.) should occur, which is further discussed herein with respect to action determine engine 133. For example, it may be specified that a parsing action, a mapping action, and a loading action occur in a particular order. In some instances, some interceptors (e.g., a validation action, a security action, etc.) may be designed to occur in between the parsing action and the mapping action, between the mapping action and the loading action, and/or after the loading action. For example, it may be desired to perform a validation action subsequent to the parsing action (and prior to the mapping action) to validate that the data has been parsed correctly. Another validation action may be performed subsequent to the mapping action (and prior to the loading action) to validate that the data has been formatted correctly. Similarly, a security action (e.g., encryption, decryption, etc.) may be designed to be performed after the loading action is complete, for example. In this way, each data transfer request can be customized based on different requirements of the data being transferred, a migration or synchronization timeline, business needs, and/or other factors.

[0024] In some implementations, a data transfer request may be received from a particular tenant among a plurality of tenants that are served by a cloud computing environment (e.g., cloud computing environment 150). A tenant may represent a group of users who share a common access to a dedicated set of virtual resources (e.g., storage resource, compute resource, software applications, etc.) in a cloud computing environment. For example, a tenant may represent a particular enterprise customer. A cloud computing environment may serve a plurality of tenants (e.g., multi-tenancy architecture) where each individual tenant may have its own objectives and needs to fulfill in data migration and/or synchronization. In doing so, a tenant (and/or any user thereof) may devise or otherwise generate a data transfer request by identifying a particular data source(s) and/or data to be transferred within such source(s) and/or specifying a desired set of configurations within the request.

[0025] In some implementations, a data transfer request may be generated by request generate engine 141 of client computing device 140 and/or provided by request provide engine 142 of client computing device 140 to server computing device 130. For example, request generate engine 141 may generate a data transfer request based on user input. A tenant (and/or any user thereof) may, via request generate engine 141 , identify a particular data source(s) (and/or data to be transferred within such source(s)) and/or specify a desired set of configurations within that request. The generated request may be sent or otherwise provided to server computing device 130 that may receive the request (via request receive engine 131 as discussed above), retrieve the set of configurations from the request (via configuration retrieve engine 132 as discussed above), determine an ordered set of data handling actions based on the set of configurations (via action determine engine 133 as discussed above), and/or execute the ordered set of data handling actions (via action execute engine 134 as discussed above). In other implementations, a data transfer request may be generated directly on server computing device 130. For example, a tenant (and/or any user thereof) may access a web-based application (that provides the functionalities of request generate engine 141 as discussed above) provided by server computing device using a web browser on client computing device 140.

[0026] Configuration retrieve engine 132 may retrieve or otherwise identify the set of configurations from the data transfer request (e.g., received by request receive engine 131 ). As discussed herein with respect to request receive engine 131 , the set of configurations may specify at least one of: an amount of data to be migrated (e.g., if the request is a data migration request), whether a synchronization occurs ad hoc or offline (e.g., if the request is a data synchronization request), a start and/or end time of the data transfer, a number of batches to be run for the data transfer request, parsing rules (e.g., instructions on how and/or when the data to be transferred should be parsed), mapping rules (e.g., instructions on how and/or when the data to be transferred should be transformed into a particular format), loading rules (e.g., instructions on where and/or when the data should be loaded), validation rules (e.g., instructions on how and/or when the data to be transferred should be validated for data consistency), and security rules (e.g., instructions on how and/or when the data to be transferred should be encrypted and/or decrypted). The set of configurations may further specify a particular order in which different data handling actions should occur.

[0027] Action determine engine 133 may determine, based on the set of configurations (e.g., retrieved by configuration retrieve engine 132), an ordered set of data handling actions to be executed to process the data transfer request (e.g., received by request receive engine 131 ). For example, a set of data handling actions may comprise at least one of: a parsing action that parses the data, a mapping action that maps the data to a particular data schema, a loading action that loads the data to a particular remote storage resource (e.g., cloud storage resource 150A in cloud computing environment 150), a validation action that validates the data for data consistency, and a security action that encrypts or decrypts the data.

[0028] An "ordered" set of data handling actions may arrange such data handling actions in a particular order of execution. Different ordered sets of data handling actions may have a different mix of actions and/or may arrange them in a different order of execution. For example, a first ordered set of data handling actions for a first data transfer request may begin with a parsing action, proceed to a validation action, to a mapping action, to a security action, and end with a loading action. A second ordered set of data handling actions for a second data transfer request may include the same set of data handling actions but in a different order (e.g., the parsing action, the mapping action, the validation action, the security action, and the loading action). A third ordered set of data handling actions for a third data transfer request may have at least one action that is different from the first ordered set of data handling actions. The third ordered set may, for example, begin with the mapping action, proceed to the validation action and security action, and end with the loading action.

[0029] Action execute engine 134 may execute the ordered set of data handling actions (e.g., as determined by action determine engine 133) by executing each data handling action of that set in the specified order. Any rules (e.g., parsing rules, mapping rules, loading rules, validation rules, security rules, etc.) specified in the set of configurations may be applied during the execution of corresponding data handling action. For example, for a particular data migration request, action execute engine 134 may execute a corresponding ordered set of data handling actions to migrate certain data to a designated remote storage resource according to the set of configurations defined and/or specified for that particular data migration request. For a particular data synchronization request, action execute engine 134 may execute a corresponding ordered set of data handling actions to synchronize certain data with a designated remote storage resource according to the set of configurations defined and/or specified for that particular data synchronization request.

[0030] In some implementations, action execute engine 134 may create a runtime environment that is dedicated to each data transfer request, in which the corresponding ordered set of data handling actions (e.g., corresponding to that request) can be executed. In other words, action execution engine 134 may execute a first ordered set of data handling actions (e.g., corresponding to a first data transfer request) in a first runtime environment and the second ordered set of data handling actions (e.g., corresponding to a second data transfer request) in a second runtime environment such that the execution of the first ordered set of data handling actions is isolated from the execution of the second set of data handling actions. This isolation technique is useful because the execution of one ordered set of data handling actions may interfere with the execution another set of data handling actions, potentially causing imbalanced use of processing resources and/or security concerns (e.g., especially when the data transfer requests were originated from different tenants who do not want to risk exposing their data being transferred to each other). [0031 ] In performing their respective functions, data transfer request system 1 10 may access data storage 139, 149, 150, and/or other suitable database(s). Data storage 139, 149, and/or 150 may represent any memory accessible to data transfer requests system 1 10 that can be used to store and retrieve data. Such data storage may comprise random access memory (RAM), read-only memory (ROM), electrically-erasable programmable read-only memory (EEPROM), cache memory, floppy disks, hard disks, optical disks, tapes, solid state drives, flash drives, portable compact disks, and/or other storage media for storing computer- executable instructions and/or data.

[0032] FIG. 2 is a block diagram depicting an example data transfer requests system 210. Data transfer requests system 210 may comprise a request receive engine 221 , a configuration retrieve engine 222, an action determine engine 223, an action execute engine 224, and/or other engines. Engines 221 -224 represent engines 131 -134, respectively.

[0033] FIG. 3 is a block diagram depicting an example machine-readable storage medium 310 comprising instructions executable by a processor for providing data transfer requests.

[0034] In the foregoing discussion, engines 141 -142 were described as combinations of hardware and programming. Engines 141 -142 may be implemented in a number of fashions. Referring to FIG. 3, the programming may be processor executable instructions 141 -142 stored on a machine-readable storage medium 310 and the hardware may include a processor 31 1 for executing those instructions. Thus, machine-readable storage medium 310 can be said to store program instructions or code that when executed by processor 31 1 implements data transfer requests system 1 10 of FIG. 1 .

[0035] In FIG. 3, the executable program instructions in machine-readable storage medium 310 are depicted as request generate instructions 321 and request provide instructions 322. Instructions 321 -322 represent program instructions that, when executed, cause processor 31 1 to implement engines 141 - 142, respectively. [0036] FIG. 4 is a block diagram depicting an example machine-readable storage medium 410 comprising instructions executable by a processor for processing data transfer requests.

[0037] In the foregoing discussion, engines 131 -134 were described as combinations of hardware and programming. Engines 131 -134 may be implemented in a number of fashions. Referring to FIG. 4, the programming may be processor executable instructions 421 -424 stored on a machine-readable storage medium 410 and the hardware may include a processor 41 1 for executing those instructions. Thus, machine-readable storage medium 410 can be said to store program instructions or code that when executed by processor 41 1 implements data transfer requests system 1 10 of FIG. 1 .

[0038] In FIG. 4, the executable program instructions in machine-readable storage medium 410 are depicted as request receive instructions 421 , configuration retrieve instructions 422, actions determine instructions 423, and action execute instructions 424. Instructions 421 -424 represent program instructions that, when executed, cause processor 41 1 to implement engines 131 - 134, respectively.

[0039] Machine-readable storage medium 310 (or machine-readable storage medium 410) may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. In some implementations, machine-readable storage medium 310 (or machine-readable storage medium 410) may be a non-transitory storage medium, where the term "non-transitory" does not encompass transitory propagating signals. Machine-readable storage medium 310 (or machine-readable storage medium 410) may be implemented in a single device or distributed across devices. Likewise, processor 31 1 (or processor 41 1 ) may represent any number of processors capable of executing instructions stored by machine-readable storage medium 310 (or machine- readable storage medium 410). Processor 31 1 (or processor 41 1 ) may be integrated in a single device or distributed across devices. Further, machine- readable storage medium 310 (or machine-readable storage medium 410) may be fully or partially integrated in the same device as processor 31 1 (or processor 41 1 ), or it may be separate but accessible to that device and processor 31 1 (or processor 41 1 ).

[0040] In one example, the program instructions may be part of an installation package that when installed can be executed by processor 31 1 (or processor 41 1 ) to implement data transfer requests system 1 10. In this case, machine-readable storage medium 310 (or machine-readable storage medium 410) may be a portable medium such as a floppy disk, CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, machine-readable storage medium 310 (or machine-readable storage medium 410) may include a hard disk, optical disk, tapes, solid state drives, RAM, ROM, EEPROM, or the like.

[0041 ] Processor 31 1 may be at least one central processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in machine-readable storage medium 310. Processor 31 1 may fetch, decode, and execute program instructions 321 -322, and/or other instructions. As an alternative or in addition to retrieving and executing instructions, processor 31 1 may include at least one electronic circuit comprising a number of electronic components for performing the functionality of at least one of instructions 321 -322, and/or other instructions.

[0042] Processor 41 1 may be at least one central processing unit (CPU), microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in machine-readable storage medium 410. Processor 41 1 may fetch, decode, and execute program instructions 421 -424, and/or other instructions. As an alternative or in addition to retrieving and executing instructions, processor 41 1 may include at least one electronic circuit comprising a number of electronic components for performing the functionality of at least one of instructions 421 -424, and/or other instructions.

[0043] FIG. 5 is a flow diagram depicting an example method 500 for processing data transfer requests. The various processing blocks and/or data flows depicted in FIG. 5 (and in the other drawing figures such as FIG. 6) are described in greater detail herein. The described processing blocks may be accomplished using some or all of the system components described in detail above and, in some implementations, various processing blocks may be performed in different sequences and various processing blocks may be omitted. Additional processing blocks may be performed along with some or all of the processing blocks shown in the depicted flow diagrams. Some processing blocks may be performed simultaneously. Accordingly, method 500 as illustrated (and described in greater detail below) is meant to be an example and, as such, should not be viewed as limiting. Method 500 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 410, and/or in the form of electronic circuitry.

[0044] In block 521 , method 500 may include receiving a first data transfer request from a first tenant of a plurality of tenants that are served by a cloud computing environment. The first data transfer request ma comprise a first data migration request or a first data synchronization request. Referring back to FIG. 1 , request receive engine 131 may be responsible for implementing block 521 .

[0045] In block 522, method 500 may include receiving a second data transfer request from a second tenant of the plurality of tenants. The second data transfer request may comprise a second data migration request or a second data synchronization request. Referring back to FIG. 1 , request receive engine 131 may be responsible for implementing block 522.

[0046] In block 523, method 500 may include retrieving a first set of configurations from the first data transfer request. Referring back to FIG. 1 , configuration retrieve engine 132 may be responsible for implementing block 523.

[0047] In block 524, method 500 may include determining, based on the first set of configurations, a first ordered set of data handling actions to be executed to process the first data transfer request. Referring back to FIG. 1 , action determine engine 133 may be responsible for implementing block 524.

[0048] In block 525, method 500 may include retrieving a second set of configurations from the second data transfer request. Referring back to FIG. 1 , configuration retrieve engine 132 may be responsible for implementing block 525.

[0049] In block 526, method 500 may include determining, based on the second set of configurations, a second ordered set of data handling actions to be executed to process the second data transfer request. The first ordered set of data handling actions may be different from the second ordered set of data handling actions. Referring back to FIG. 1 , action determine engine 133 may be responsible for implementing block 526.

[0050] FIG. 6 is a flow diagram depicting an example method 600 for processing data transfer requests. Method 600 as illustrated (and described in greater detail below) is meant be an example and, as such, should not be viewed as limiting. Method 600 may be implemented in the form of executable instructions stored on a machine-readable storage medium, such as storage medium 410, and/or in the form of electronic circuitry.

[0051 ] In block 621 , method 600 may include receiving a first data transfer request from a first tenant of a plurality of tenants that are served by a cloud computing environment. The first data transfer request ma comprise a first data migration request or a first data synchronization request. Referring back to FIG. 1 , request receive engine 131 may be responsible for implementing block 621 .

[0052] In block 622, method 600 may include receiving a second data transfer request from a second tenant of the plurality of tenants. The second data transfer request may comprise a second data migration request or a second data synchronization request. Referring back to FIG. 1 , request receive engine 131 may be responsible for implementing block 622.

[0053] In block 623, method 600 may include retrieving a first set of configurations from the first data transfer request. Referring back to FIG. 1 , configuration retrieve engine 132 may be responsible for implementing block 623.

[0054] In block 624, method 600 may include retrieving a second set of configurations from the second data transfer request. Referring back to FIG. 1 , configuration retrieve engine 132 may be responsible for implementing block 624.

[0055] In block 625, method 600 may include determining, based on the first set of configurations, a first ordered set of data handling actions to be executed to process the first data transfer request. Referring back to FIG. 1 , action determine engine 133 may be responsible for implementing block 625.

[0056] In block 626, method 600 may include determining, based on the second set of configurations, a second ordered set of data handling actions to be executed to process the second data transfer request. The first ordered set of data handling actions may be different from the second ordered set of data handling actions. Referring back to FIG. 1 , action determine engine 133 may be responsible for implementing block 626.

[0057] In block 627, method 600 may include executing, at runtime, the first and second ordered sets of data handling actions such that the runtime execution of the first ordered set of data handling actions is isolated from the runtime execution of the second set of data handling actions. Referring back to FIG. 1 , actions execute engine 134 may be responsible for implementing block 627.

[0058] The foregoing disclosure describes a number of example implementations for data transfer requests. The disclosed examples may include systems, devices, computer-readable storage media, and methods for data transfer requests. For purposes of explanation, certain examples are described with reference to the components illustrated in FIGS. 1 -4. The functionality of the illustrated components may overlap, however, and may be present in a fewer or greater number of elements and components.

[0059] Further, all or part of the functionality of illustrated elements may coexist or be distributed among several geographically dispersed locations. Moreover, the disclosed examples may be implemented in various environments and are not limited to the illustrated examples. Further, the sequence of operations described in connection with FIGS. 5-6 are examples and are not intended to be limiting. Additional or fewer operations or combinations of operations may be used or may vary without departing from the scope of the disclosed examples. Furthermore, implementations consistent with the disclosed examples need not perform the sequence of operations in any particular order. Thus, the present disclosure merely sets forth possible examples of implementations, and many variations and modifications may be made to the described examples. All such modifications and variations are intended to be included within the scope of this disclosure and protected by the following claims.

Claims

1 . A method for processing data transfer requests, the method comprising: receiving a first data transfer request from a first tenant of a plurality of tenants that are served by a cloud computing environment, the first data transfer request comprising a first data migration request or a first data synchronization request;

receiving a second data transfer request from a second tenant of the plurality of tenants, the second data transfer request comprising a second data migration request or a second data synchronization request;

retrieving a first set of configurations from the first data transfer request; determining, based on the first set of configurations, a first ordered set of data handling actions to be executed to process the first data transfer request; retrieving a second set of configurations from the second data transfer request; and

determining, based on the second set of configurations, a second ordered set of data handling actions to be executed to process the second data transfer request, wherein the first ordered set of data handling actions is different from the second ordered set of data handling actions.

2. The method of claim 1 , wherein the first data transfer request comprises the first data migration request, further comprising:

in response to the first data migration request, migrating data to a cloud storage resource in the cloud computing environment.

3. The method of claim 1 , wherein the first data transfer request comprises the first data synchronization request, further comprising:

in response to the first data synchronization request, synchronizing data with a cloud storage resource in the cloud computing environment.

4. The method of claim 1 , wherein the first or second set of configurations specify at least one of: an amount of data to be migrated, whether a synchronization occurs ad hoc or offline, parsing rules, mapping rules, loading rules, validation rules, and security rules.

5. The method of claim 4, further comprising:

executing the first ordered set of data handling actions according to the first set of configurations; and

executing the second ordered set of data handling actions according to the second set of configurations.

6. The method of claim 1 , further comprising:

executing the first ordered set of data handling actions in a first runtime environment and the second ordered set of data handling actions in a second runtime environment such that the execution of the first ordered set of data handling actions is isolated from the execution of the second set of data handling actions.

7. The method of claim 1 , wherein the first or second ordered set of data handling actions comprise at least one of: a parsing action that parses data, a mapping action that maps the data to a data schema, a loading action that loads the data to a cloud storage resource in the cloud computing environment, a validation action that validates the data for data consistency, and a security action that encrypts or decrypts the data, that are to be executed in a particular order.

8. A non-transitory machine-readable storage medium comprising instructions executable by a processor of a client computing device for providing data transfer requests, the machine-readable storage medium comprising: instructions to generate a first data transfer request to transfer a first set of data to a remote storage resource, the first data transfer request comprising a first set of configurations; instructions to generate a second data transfer request to transfer a second set of data to the remote storage resource, the second data transfer request comprising a second set of configurations;

instructions to provide the first data transfer request to a server computing device to cause the server computing device to determine a first ordered set of data handling actions to be executed to process the first data transfer request; and

instructions to provide the second data transfer request to the server computing device to cause the server computing device to determine a second ordered set of data handling actions to be executed to process the second data transfer request, wherein the first ordered set of data handling actions is different from the second ordered set of data handling actions.

9. The non-transitory machine-readable storage medium of claim 8, wherein the first ordered set of data handling actions comprises at least one of: a parsing action that parses the first set of data, a mapping action that maps the first set of data to a data schema, a loading action that loads the first set of data to the cloud storage resource, a validation action that validates the first set of data for data consistency, and a security action that encrypts or decrypts the first set of data, that are to be executed in a first order.

10. The non-transitory machine-readable storage medium of claim 8, wherein the second ordered set of data handling actions comprises at least one of: a parsing action that parses the second set of data, a mapping action that maps the second set of data to a data schema, a loading action that loads the second set of data to the cloud storage resource, a validation action that validates the second set of data for data consistency, and a security action that encrypts or decrypts the second set of data, that are to be executed in a second order.

1 1 . The non-transitory machine-readable storage medium of claim 8, wherein the server computing device executes the first ordered set of data handling actions according to the first set of configurations, and the server computing device executes the second ordered set of data handling actions according to the second set of configurations.

12. A system for processing data transfer requests comprising:

a request receive engine to:

receive a first data transfer request from a first tenant of a plurality of tenants that are served by a cloud computing environment, the first data transfer request comprising a first data migration request or a first data synchronization request, and

receive a second data transfer request from a second tenant of the plurality of tenants, the second data transfer request comprising a second data migration request or a second data synchronization request;

a configuration retrieve engine to:

retrieve a first set of configurations from the first data transfer request, and

retrieve a second set of configurations from the second data transfer request;

an action determine engine to:

determine, based on the first set of configurations, a first ordered set of data handling actions to be executed to process the first data transfer request, and

determine, based on the second set of configurations, a second ordered set of data handling actions to be executed to process the second data transfer request; and

an action execute engine to:

execute the first ordered set of data handling actions in a first runtime environment and the second ordered set of data handling actions in a second runtime environment such that the execution of the first ordered set of data handling actions is isolated from the execution of the second set of data handling actions.

13. The system of claim 12, wherein the first ordered set of data handling actions includes an action that is excluded from the second ordered set of data handling actions.

14. The system of claim 12, wherein the first ordered set of data handling actions includes a set of data handling actions in a first order, and the second ordered set of data handling actions includes the set of data handling actions in a second order.

15. The system of claim 12, the execution engine to:

execute the first ordered set of data handling actions according to the first set of configurations; and

execute the second ordered set of data handling actions according to the second set of configurations.