systems and methods for cooperative batch scheduling in multitenancy computing systems are described. A number of batch requests are received in the computing system, where each batch request includes a job reference, and a start time when the execution of the referenced job to be launched. duration of execution is estimated for each job referenced by the requests. The estimation is based on predefined criteria that include a product of median execution times for at least one recurring operation. An anonymous load chart is created based on the start times and the estimated duration of execution of each job referenced by the plurality of batch requests. The anonymous load chart may take into account the available capacity of the computing system. The anonymous load chart is exposed to a number of isolated users of the computing system for cooperative batch scheduling.
|
13. A computer system for enabling collaborative batch scheduling in a shared resources environment for a plurality of isolated clients, the system comprising:
a computer memory to store program code; and
a processor to execute the program code to:
estimate a duration of an execution of each of a first plurality of batch jobs based on a corresponding job type and a corresponding execution start time, wherein estimating the duration of the execution of each of the first plurality of batch jobs comprises:
dividing a batch job of the first plurality of batch jobs to a plurality of recurring operations,
assigning a median duration for processing a single instance of an operation of the plurality of recurring operations, wherein assigning the median duration comprises:
estimating the median duration in accordance with a forecasted capacity of the shared resources during the execution of the batch job, and
adding, to the duration of the execution of each of the first plurality of batch jobs, a result of multiplication between the median duration and a number of recurrences of the operation in the batch job; and
generate a report for a resource consumption of the shared resources environment for a predefined future period, the resource consumption resulting from the estimated duration of the execution of the first plurality of batch jobs and the corresponding start times, wherein the report is accessible by at least one of the plurality of isolated clients of the shared resources environment.
1. A non-transitory computer readable storage medium storing instructions, which when executed by a computer, cause the computer to:
receive a plurality of job requests at a shared computer system from one or more of a plurality of isolated tenants of the shared computer system, wherein each job request of the plurality of job requests includes a reference to a corresponding job of a plurality of jobs and a start time for beginning an execution of the referenced job;
for each job of the plurality of jobs referenced by the plurality of job requests, estimate, by the shared computer system, a duration of execution of the job based on a type of the job, wherein estimating the duration of execution of a job comprises:
identifying a plurality of objects of a specific type to be processed during the execution of the job,
assigning a median duration for processing an object of the specific type, wherein assigning the median duration comprises:
estimating the median duration in accordance with an expected capacity of the shared computer system during the execution of the job, and
adding, to the duration of execution of the job, a result of a multiplication between the median duration and a cardinality of the plurality of objects;
create a distribution over a future period of time of load levels of the shared computer system resulting from the start times and the estimated durations of execution of the plurality of jobs referenced by the plurality of job requests; and
expose a load chart of the distribution of the load levels of the shared computer system to at least one of the plurality of isolated tenants of the shared computer system to enable collaborative job scheduling between the isolated tenants for the future period of time.
8. A computerized method for enabling collaborative batch scheduling in a multitenancy computer application environment for a plurality of isolated tenants, the method comprising:
receiving, from one or more of the plurality of isolated tenants of the multitenancy application environment, a plurality of requests for execution of a plurality of corresponding batches in the multitenancy application environment, wherein each request of the plurality of requests includes a job type of a corresponding batch and a start time for beginning an execution of the corresponding batch;
for each of the plurality of requests, estimating a duration of execution of the corresponding batch based on the job type, wherein estimating the duration of execution of a batch comprises:
identifying a plurality of similar objects to be processed during the execution of the batch,
assigning a median duration for processing an object of the plurality of similar objects, wherein assigning the median duration comprises,
estimating the median duration in accordance with an expected capacity of the multitenancy application environment during the execution of the batch, and
including a result of a multiplication between the median duration and the number of the similar objects in the duration of the execution of the batch;
creating a distribution over a future period of time of load levels of the multitenancy application environment resulting from the start times and the estimated duration of execution of each batch of the plurality of batches; and
exposing a load chart of the distribution of the load levels of the multitenancy application environment to at least one of the plurality of isolated tenants of the multitenancy application environment for collaborative batch scheduling between the isolated tenants for the future period of time.
2. The computer readable storage medium of
receive an additional job request from one of the plurality of isolated tenants at the shared computer system after the creation of the distribution, wherein the additional job request includes a reference to an additional job and a start time for an execution of the additional job;
estimate a duration of execution of the additional job referenced by the additional job request; and
update the load levels of the shared computer system in the distribution in accordance with the start time for the execution of the additional job and the estimated duration of execution of the additional job.
3. The computer readable storage medium of
after creating the distribution, receive an additional job request from one of the plurality of isolated tenants at the shared computer system, wherein the additional job request includes a reference to an additional job and a time period for an execution of the additional job;
estimate a duration of execution of the additional job referenced by the additional job request;
assign a start time for the execution of the additional job based on:
the time period for the execution of the additional job,
the estimated duration of execution of the additional job, and
the distribution over the future period of time of the load levels of the shared computer system; and
update the load levels of the shared computer system in the distribution in accordance with the start time for the execution of the additional job and the estimated duration of execution of the additional job.
4. The computer readable storage medium of
update the median duration for processing an object of the specific type with the actual duration for processing the object of the plurality of objects of the specific type, after the job is completed.
5. The computer readable storage medium of
estimating an expected load level of the shared computer system based on a system capacity for the future time period per a timeslot, wherein the duration of the future time period and the timeslot are one or more of predefined and dynamically selected.
6. The computer readable storage medium of
rendering a graphical user interface (GUI) including the distribution over the future period of time of the load levels on at least one display device corresponding to the at least one of the plurality of isolated tenants.
7. The computer readable storage medium of
associate one or more of a plurality of colors and a plurality of fill patterns with a plurality of load levels to illustrate the distribution of the load levels in the load chart.
9. The method of
after creating the distribution, receiving, from one of the plurality of isolated tenants, an additional request for execution of an additional batch in the multitenancy application environment, wherein the additional request includes a job type and a start time for an execution of the additional batch;
estimating a duration of execution of the additional batch; and
updating the load levels of the multitenancy application environment in the distribution in accordance with the start time for the execution of the additional batch and the estimated duration of execution of the additional batch.
10. The method of
after creating the distribution, receiving, from one of the plurality of isolated tenants, an additional request for execution of an additional batch in the multitenancy application environment, wherein the additional request includes a job type and a time period for an execution of the additional batch;
estimating a duration of execution of the additional batch;
assigning a start time for the execution of the additional batch based on the time period for the execution of the additional batch, the estimated duration of execution of the additional batch and the distribution over the future period of time of the load levels of the multitenancy application environment; and
updating the load levels of the multitenancy application environment in the distribution in accordance with the start time for the execution of the additional batch and the estimated duration of execution of the additional batch.
11. The method of
updating the median duration for processing an object of the plurality of similar objects with the actual duration the plurality of similar objects were processed.
12. The method of
estimating an expected load level of the multitenancy application environment based on a system capacity for the future period per a timeslot, wherein the future period and the timeslot are one or more of predefined and dynamically selected.
14. The computer system of
estimate a duration of an execution of at least one of a second plurality of batch jobs based on a job type; and
update the report for the resource consumption of the shared resources environment for the predefined future period based on the estimated duration of the execution of the at least one of the second plurality of batch jobs and at least one corresponding start time.
15. The system of
updating the median duration for processing a single instance of the recurring operations with an actual duration for processing of at least one instance of the plurality of recurring operations.
|
|||||||||||||||||||||||||||
The field relates generally to data processing and digital processing systems. More specifically, the field is related to cooperative batch scheduling within a shared computer systems environment.
The shift from on-premise software towards offering and using software as a service (SaaS) is one of the trends in the current development of the information technology (IT) industry. According to this model, instead of licensing software products that are installed on customer's servers, the customers pay for using software services provided over public or private computer networks. This approach has many advantages, for example, the customers avoid the costs associated with hosting the necessary software applications. The software vendors are also interested in selling software services to ensure regular income without giving up any of the ownership rights of their software. Therefore, in recent years there has been a proliferation of software of all kinds, and even hardware services provided over a network, mainly over the internet.
There are different approaches and solutions for providing software and hardware services over the internet. Typically, the customers do not own the hardware infrastructure and the software applications running on it, and the vendors employ utility computing models similar to the traditional utility services (e.g., electricity, water, etc.). Other vendors bill on a subscription basis. In either case, the customers pay for a service with particular characteristics and quality of service level. For example, when a customer buys a storage space, part of the agreement may be the size and a minimum response time to read and write requests. Similarly, the software services provided by the vendors over networks must comply with a required level of availability. To guarantee the necessary quality of service even at peak moments, the vendors have to ensure sufficient computer power in terms of hardware and software resources per customer.
There is a mutual interest between the vendors and the customers for high rates of the shared resources utilization to minimize idle computing power. The more efficient the usage of the available hardware and software resources, the lower is the pricing of the services provided. As a result, multitenancy architectures are adopted where a single computer system with a single instance of software runs to serve multiple, different customer organizations, e.g., tenants. This way, it is not necessary to setup a separate computer system with a separate instance of the software for each customer. The customers that share the same software and hardware resources are anonymous to each other and have to be completely isolated from one another. The complete isolation between customers is one of the most stringent requirements for providing software or hardware services over the internet. Because of the isolation, a customer is able to manage the consumption of shared resources only according to its needs, without an overview of the demand generated by other customers for the same resources. Hence, the vendors still need to store excessive computing power to handle peak resource consumptions.
Various embodiments of systems and methods for cooperative batch scheduling in multitenancy computing systems are described herein. A number of batch job requests are received in a computing system, where each batch job request includes batch job identification (ID), e.g., a batch job reference, and a start time when the execution of the referenced batch job is to be launched. In one aspect, duration of execution is estimated for each batch job referenced by the requests. The estimation is based on predefined criteria that includes a product of median execution times for at least one recurring operation and the number of operations to be executed. In another aspect, an anonymous load chart is created based on the start times and the estimated duration of the execution of each batch job referenced by the plurality of batch job requests. The anonymous load chart may take into account the available capacity of the computing system. The anonymous load chart is exposed to a number of isolated users of the computing system for further re-scheduling of the requested batch jobs, or for scheduling of new batch jobs, according with the load distribution for a certain period.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for cooperative batch scheduling in multitenancy systems are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
According to one embodiment, the term “multitenancy” refers to a computer system architecture where a single instance of software runs on one or more servers to provide services to several isolated customers. The isolated consumers may access the computer system via a private or a public network, e.g., via the internet. The title of this document and the description of the embodiments below refer to multitenancy systems. However, similar techniques and principles may be embodied within other computing environments not compliant with the definition of multitenancy, where shared resources are accessed by a number of users.
Each of the tenants 105 operates with its own set of data, logically isolated from data that belongs to the other tenants 105. Security services 125 control the access to the shared resources provided through the application servers 115. Security services 125 prevent any of tenants 105 from accidentally or maliciously viewing or changing data belonging to another tenant.
The data pertinent to tenants 105 may be kept in storage 130 together with various system and application data, e.g., source code, deployment information, system logs, etc. Depending on the implementation and the configuration of the multitenancy computing environment 100, a separate database may be created for each of the tenants 105 in storage 130. Alternatively, the multiple tenants 105 are hosted in the same database, where each of the tenants 105 may operate with its own set of tables grouped in a corresponding database schema. The data for all tenants 105 may also be stored in the same tables of a same database schema.
The multitenancy computer environment 100 must guarantee that tenants 105 are isolated from each other. Respectively, none of the tenants 105 can access data pertinent to another tenant. None of the tenants 105 should even be aware that other tenants share the same resources. Despite all the positive aspects of multitenancy, when the resources in multitenancy computer environment 100 are depleted, e.g., when the system is overloaded, tenants 105 may suffer bad performance. Moreover, the tenants 105 are not always aware of how to manage the scarce resources more efficiently, e.g., collaboratively. Therefore, to avoid low performance due to overload during peak resource consumption, multitenancy computing environment 100 provides a mechanism for collaborative job scheduling between the tenants 105. The provided mechanism does not compromise the isolation and anonymity between the tenants 105.
Today's computer applications have to be a lot more interactive than traditional transaction processing monitors. Users expect sub-second response times for almost all requests they submit, no matter how complex a request is or how many concurrent users per tenants load the system. Moreover, the modern computer applications still have to support long running batch jobs, or simple batches, for tasks that cannot be done within seconds or even minutes. While there is typically some flexibility in scheduling the start of execution of these batch jobs, they need to be scheduled carefully not to slow down the interactive processing that is going on in parallel. Therefore, the collaborative scheduling of batch jobs may significantly improve the overall system performance, and reduce the risks for the availability of the provided services.
At 205, a number of batch job requests are received in a multitenancy system. Each of the received requests includes a reference to a corresponding batch job and a start time when the execution of the referenced batch job to be triggered. At 210, a duration of execution is estimated for each of the batch jobs referenced in the received requests. The estimated durations are used to generate or create an anonymous load chart for the multitenancy system at 215. The estimation of the execution durations and the creation of anonymous load chart may be performed by one or more centralized system processes of the multitenancy system with sufficient privileges to access information regarding the different tenants.
At 220, the anonymous load chart is displayed to one or more of the isolated tenants, e.g., one or more users of the isolated tenants. In the anonymous load chart no information specific for any of the tenants is provided. According to one embodiment, the load chart simply shows the forecasted system load per time slot for a predefined future period of time. The expected load of the multitenancy system may be presented relative to the available capacity of the system. The available capacity of the multitenancy system may vary due to different factors. For example, usually there is more capacity available at nights and during weekends when it is less likely for the users to request interactive services related to tasks that are performed during business hours. The capacity may also depend on factors like scheduled downtimes of application servers, planned database administration procedures, etc.
As shown in
At 315, a median duration for processing the identified object is assigned. The median duration is an individual factor or coefficient showing an average time for processing an object of a particular type, e.g., an object similar to the object identified at 305. The duration of the execution of the batch job is estimated at 320 by calculating the product of the determined number of objects similar to the identified object, and the assigned median duration for processing the identified object.
Once the batch job is completed the actual processed number of objects may be used to update the initial assumption so that the estimation of the execution duration for the same batch job may become more precise over time. Similarly the median duration may be measured in a test system and serve as an initial value that is adjusted over time by comparing the estimated runtime with the actual runtime after each execution of the batch job. In one embodiment, the median duration may be updated with an actual duration for processing of an object similar to the identified object, as illustrated with 325.
A batch job may include processing objects of different types. In such a case, the actions illustrated with blocks 305 to 325 may repeat for every type of object included in a batch job. The duration for executing the batch job will be estimated as a total sum of each product of the number of objects and the assigned median duration per object type.
Typically, the job scheduling in a computer system is a centralized process performed by scheduler tools or directly by system administrators. The execution of jobs within particular time periods as requested by a number of users is scheduled and managed on a central level based on the available capacity of the computer system. The job scheduling may be a very resource consuming task for the administrators of multi-user computer environments. Even when specialized tools for job scheduling are utilized, peak resource consumptions are possible due to competing job requests. While it is difficult to maintain centralized job scheduling in complex multi-user systems, it is almost impossible to accomplish in multitenancy systems, as the complete isolation between tenants is one of the requirements any multitenancy system must comply with.
An overview of the expected resource consumption of a multi-user or multitenancy computer system may help the users of the system to request job executions for more appropriate times in order to avoid system overload. This is especially relevant for batch job requests with long runtimes. Generally, every user or tenant of a computer system is interested to behave cooperatively as system overload or peak resource consumption decreases the performance of the system for the user, as well as for the rest of the users. The system overload also increases the duration of the batch run and therefore creates a risk that it will not be completed by a given deadline. Additionally, the users and the tenants can be stimulated through further incentives to support cooperative behavior. For example, additional fees may be charged to a tenant for batch jobs scheduled at peak times. Different fees may be charged depending on the number of the batch jobs scheduled at peak times as well.
In one embodiment, a batch job execution request may specify either a start time, or an execution period for running the batch job. The users of the system have access to the anonymous load chart showing the expected system load. The user may specify the most appropriate start time or execution period for the batch job based on the expected system load, and the estimated duration of the batch job execution. At 415, it is verified whether the new or rescheduled batch job request includes a start time for triggering the execution. If start time is not specified, the system may automatically select a start time for the execution of the referenced batch job at 420 based on the expected system load.
When the start time is specified or selected, at 425, a check is performed to verify whether the requested batch job execution is scheduled for a busy period according to the anonymous load chart. If the execution of the batch job is not scheduled for a busy period, an incentive for the isolated user or the tenant may be assigned at 430. However, if the execution is scheduled for a busy period, a penalty may be assigned to the user at 435. The incentive versus penalty assignments play a role to stimulate the collaboration between isolated users of different tenants of a multitenancy system based on the anonymous load chart, according to one embodiment. At 440, the anonymous load chart is updated based on the specified start time and the estimated duration of the requested batch job execution.
The expected load of the multitenancy system is illustrated by load bars 506 to 512 with different colors or with different fill patterns per time slot. The load bars 506 to 512 are spread throughout the time slots for every day of the week as illustrated in
Area 515 of the GUI 500 provides the users of the multitenancy system with means to schedule new batch jobs, according to one embodiment. A user may define batch job identification (ID) 516, e.g., a reference to a particular batch job. The batch job ID 516 may unambiguously define the requested batch job. A batch job may be also defined by its job type 517 in the batch job scheduler area 515. In one embodiment, a user may enter values for one or more different parameters in 522, when such parameters are required during the batch job execution. Batch job description 518 provides information for the referenced batch job. The scheduled date for executing the referenced batch job is defined in 519, and the start time may be entered in 520. The multitenancy system may automatically estimate the duration of the execution of the requested batch job based on the information provided in fields 516 to 520. The job type 517 may define an object type to be counted as well as a median duration for processing an object of this object type. The estimated duration is illustrated by the bar 521, where the length of the bar 521 corresponds to the execution duration.
The GUI 500 may also include a legend area 525, where the meaning of the different colors or the different fill patterns of the bars 506 to 512 is explained. For example, sample bars 526 to 529 in different colors or fill patterns may be used to define the corresponding load levels relative to the available system capacity.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
| Patent | Priority | Assignee | Title |
| 10055215, | Oct 05 2016 | SAP SE | Enabling corrections during upgrade procedure |
| 10078520, | Mar 16 2017 | Flexera Software LLC | Calculating wait time for batch scheduler jobs |
| 10185552, | May 12 2017 | SAP SE | Enforcing content constraints on delivery and end user changes |
| 10230708, | May 20 2016 | SAP SE | Application managed service instances |
| 10268472, | May 16 2017 | SAP SE | Upgrading systems with replicated data |
| 10268692, | Feb 15 2017 | SAP SE | Multi-procedure support in data migration |
| 10298591, | Apr 28 2017 | SAP SE | Secure integration of independent cloud foundry applications in a fiori launchpad |
| 10437795, | May 12 2017 | SAP SE | Upgrading systems with changing constraints |
| 10452646, | Oct 26 2017 | SAP SE | Deploying changes in a multi-tenancy database system |
| 10482080, | Oct 26 2017 | SAP SE | Exchanging shared containers and adapting tenants in multi-tenancy database systems |
| 10491700, | Nov 18 2016 | SAP SE | Application managed service instances |
| 10523662, | Sep 16 2016 | SAP SE | In-memory database advanced programming model |
| 10534585, | Oct 29 2018 | SAP SE | Integrated development environment with deep insights and recommendations |
| 10536461, | Dec 19 2017 | SAP SE | Service identity propagation between applications and reusable services |
| 10606665, | Dec 16 2014 | Microsoft Technology Licensing, LLC | Job scheduling and monitoring in a distributed computing environment |
| 10621167, | Oct 26 2017 | NETWORK NEXT, INC | Data separation and write redirection in multi-tenancy database systems |
| 10642609, | Dec 13 2018 | SAP SE | Integrating preview systems for early validation and maintenance in development-to-production landscapes provisioned by continuous delivery |
| 10657276, | Oct 26 2017 | SAP SE | System sharing types in multi-tenancy database systems |
| 10659449, | May 20 2016 | SAP SE | Application managed service instances |
| 10673962, | Nov 28 2017 | SAP SE | Service cross-consumption based on an open service broker application programming interface |
| 10684999, | Oct 05 2016 | SAP SE | Multi-procedure support in data migration |
| 10685007, | Mar 29 2016 | SAP SE | Table content transport and delivery |
| 10686882, | May 18 2018 | SAP SE | Change management using a thing-model on an internet-of-things platform |
| 10693989, | Apr 28 2017 | SAP SE | Brokering services from partner cloud platforms |
| 10700949, | Dec 13 2018 | SAP SE | Stacking of tentant-aware services |
| 10706170, | Mar 16 2017 | SAP SE | Tenant table sharing with content separation |
| 10713277, | Oct 26 2017 | SAP SE | Patching content across shared and tenant containers in multi-tenancy database systems |
| 10715405, | Jan 30 2018 | SAP SE | Tenant isolated data in shared reusable services |
| 10733168, | Oct 26 2017 | SAP SE | Deploying changes to key patterns in multi-tenancy database systems |
| 10740315, | Oct 26 2017 | SAP SE | Transitioning between system sharing types in multi-tenancy database systems |
| 10740318, | Oct 26 2017 | SAP SE | Key pattern management in multi-tenancy database systems |
| 10789220, | Mar 28 2017 | SAP SE | Management of database API schema |
| 10853693, | Dec 04 2018 | SAP SE | Software logistic for learning applications |
| 10871962, | May 27 2016 | SAP SE | Zero downtime maintenance in constrained systems |
| 10891217, | Dec 10 2018 | SAP SE | Optimizing test coverage based on actual use |
| 10915551, | Jun 04 2018 | SAP SE | Change management for shared objects in multi-tenancy systems |
| 10936624, | Jun 12 2018 | SAP SE | Development and productive use of system with parallel use of production data and zero downtime of software changes |
| 10942892, | May 18 2018 | SAP SE | Transport handling of foreign key checks |
| 10956150, | Dec 13 2018 | SAP SE | Integrating preview systems for early validation and maintenance in development-to-production landscapes provisioned by continuous delivery |
| 10977212, | May 03 2018 | SAP SE | Data partitioning based on estimated growth |
| 10983762, | Jun 27 2019 | SAP SE | Application assessment system to achieve interface design consistency across micro services |
| 11029961, | Mar 16 2017 | Flexera Software LLC | Calculating wait time for batch scheduler jobs |
| 11030164, | Jan 18 2018 | SAP SE | Artifact deployment for application managed service instances |
| 11121943, | Dec 13 2018 | SAP SE | Amplifying scaling elasticity of microservice meshes |
| 11218388, | Jan 30 2018 | SAP SE | Tenant isolated data in shared reusable services |
| 11232126, | Nov 21 2018 | SAP SE | Zero downtime upgrade of systems with database-side replication |
| 11249812, | Jul 25 2019 | SAP SE | Temporary compensation of outages |
| 11269717, | Sep 24 2019 | SAP SE | Issue-resolution automation |
| 11310328, | May 03 2019 | SAP SE | Generic command line interface to an extensible list of cloud platform services |
| 11354302, | Jun 16 2020 | SAP SE | Automatic creation and synchronization of graph database objects |
| 11537364, | Jun 27 2019 | SAP SE | Application assessment system to achieve interface design consistency across micro services |
| 11561836, | Dec 11 2019 | SAP SE | Optimizing distribution of heterogeneous software process workloads |
| 11561956, | Oct 26 2017 | SAP SE | Key pattern management in multi-tenancy database systems |
| 11693945, | Nov 18 2016 | SAP SE | Secure calls between applications |
| 11797879, | May 13 2019 | SAP SE | Machine learning on distributed customer data while protecting privacy |
| 9684546, | Dec 16 2014 | Microsoft Technology Licensing, LLC | Job scheduling and monitoring in a distributed computing environment |
| 9703554, | Dec 07 2015 | SAP SE | Custom code migration suggestion system based on actual change references |
| 9898279, | Mar 31 2016 | SAP SE | Optimizing ABAP development as a service |
| Patent | Priority | Assignee | Title |
| 6665716, | Dec 09 1998 | Hitachi, Ltd. | Method of analyzing delay factor in job system |
| 7263695, | Mar 25 2003 | CLOUDEBEES, INC ; CLOUDBEES, INC | System and method for processing recursive invocations within a program build |
| 7793292, | Sep 13 2006 | Fisher-Rosemount Systems, Inc | Compact batch viewing techniques for use in batch processes |
| 20070067201, | |||
| 20080320477, | |||
| 20090217273, | |||
| 20100115520, | |||
| 20100250174, | |||
| 20100262948, | |||
| 20110161959, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jun 30 2010 | EBERLEIN, PETER | SAP AG | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 026108 | /0646 | |
| Jul 01 2010 | SAP SE | (assignment on the face of the patent) | / | |||
| Jul 07 2014 | SAP AG | SAP SE | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 033625 | /0223 |
| Date | Maintenance Fee Events |
| Oct 11 2016 | ASPN: Payor Number Assigned. |
| Nov 05 2018 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Nov 07 2022 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Date | Maintenance Schedule |
| May 12 2018 | 4 years fee payment window open |
| Nov 12 2018 | 6 months grace period start (w surcharge) |
| May 12 2019 | patent expiry (for year 4) |
| May 12 2021 | 2 years to revive unintentionally abandoned end. (for year 4) |
| May 12 2022 | 8 years fee payment window open |
| Nov 12 2022 | 6 months grace period start (w surcharge) |
| May 12 2023 | patent expiry (for year 8) |
| May 12 2025 | 2 years to revive unintentionally abandoned end. (for year 8) |
| May 12 2026 | 12 years fee payment window open |
| Nov 12 2026 | 6 months grace period start (w surcharge) |
| May 12 2027 | patent expiry (for year 12) |
| May 12 2029 | 2 years to revive unintentionally abandoned end. (for year 12) |