WO2017074320A1 - Mise à l'échelle de services pour traitement par lots - Google Patents

Mise à l'échelle de services pour traitement par lots Download PDF

Info

Publication number
WO2017074320A1
WO2017074320A1 PCT/US2015/057615 US2015057615W WO2017074320A1 WO 2017074320 A1 WO2017074320 A1 WO 2017074320A1 US 2015057615 W US2015057615 W US 2015057615W WO 2017074320 A1 WO2017074320 A1 WO 2017074320A1
Authority
WO
WIPO (PCT)
Prior art keywords
batch
transaction
processing
request
transactions
Prior art date
Application number
PCT/US2015/057615
Other languages
English (en)
Inventor
Chandra Kamalakantha
Parag Doshi
Steve MARNEY
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2015/057615 priority Critical patent/WO2017074320A1/fr
Publication of WO2017074320A1 publication Critical patent/WO2017074320A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • Enterprises are increasingly opting to utilize business solutions, such as software as a service (SaaS), for example, hosted by third-party service providers, or vendors, in cloud computing environments.
  • SaaS software as a service
  • business enterprises eliminate the installation, running, maintaining, and supporting of the services (e.g. applications) on the enterprise's own computers.
  • HRM human resource management
  • users often submit requests to applications using high-volume, or batch, transactions rather than interactive transactions.
  • Figure 1 is a block and schematic diagram illustrating a computing system including a workload management system according to one example.
  • Figure 2 is a block diagram illustrating a resource manager of workload management system according to one example.
  • Figure 3 is a flow diagram illustrating a method of managing workload for batch processing according to one example.
  • Figure 4 is a block and schematic diagram generally illustrating a computing system for implementing a workload management system according to one example.
  • SaaS software as a service
  • the vendor networks, or clouds are typically front-ended by API (Application Program Interface) gateways through which users (also sometimes referred to as tenants, customers, and clients) can access and interact with desired services, including SaaS applications, such as human resource management (HRM) applications (e.g. WorkdayTM), customer relationship management (CRM) applications, and enterprise resource planning (ERP) applications, to name a few.
  • HRM human resource management
  • CRM customer relationship management
  • ERP enterprise resource planning
  • API gateways can manage interactive transactions; i.e. online transaction processing (OLTP) transactions
  • API gateways are not configured to support high volume batch transactions; i.e., online analytical processing (OLAP), which are utilized by users for many types of business solution applications.
  • batch transactions must be submitted via different entry points to the vendor network (e.g. via B2B ebXML Gateways).
  • computing systems currently lack the ability to effectively manage downstream complexities associated with batch transactions such as automatic scaling of computing resources to accommodate processing of the batch transaction, implementation of processing policies for different clients and transaction types, transaction prioritization, partial failure handling, and separation of billing for individual transactions within a batch, which is increasing in importance with the trend toward utility-based billing.
  • the present disclosure provides a computing system including a workload management system that enables batch transactions to be submitted and received via an API gateway and, based on requirements of the batch
  • examples of the present disclosure further enables the computing system to dynamically scale computing resources (e.g. scale-out of a requested application instance) to meet expected computing requirements of the batch transaction. Additionally, examples of the present disclosure further enables utility-based billing, implementation of processing policies for different clients and transaction types, transaction prioritization, and partial failure handling. By providing such features, a computing system employing a workload management system in accordance with examples of the present disclosure enables batch-on-demand processing.
  • FIG. 1 is a block and schematic diagram generally illustrating a computing system 10 including a workload management system 20 having a parser 22 and a resource manager 24 that enable batch-on-demand processing for batch transaction requests received via API gateways for business solutions, such as SaaS applications, according to one example of the present disclosure.
  • computing system 10 includes an interface 30, and network resources 40, with network resources 40 including a plurality of server systems, illustrated as server systems 42a-n. Server systems 42a-n are in
  • a network 46 such as a local area network (LAN) and/or a wide area network (WAN), such as the internet, such that server systems 42a-n and workload management system 20 may be geographically local to one another (e.g. a same data center) or geographically separated (e.g. multiple data centers).
  • LAN local area network
  • WAN wide area network
  • server systems 42a-n and workload management system 20 may be geographically local to one another (e.g. a same data center) or geographically separated (e.g. multiple data centers).
  • Sever systems 42a-n host a plurality of business services 44, where business services 44 include any number of different types of business services offered to users of computing system 10, such as business applications (SaaS), compute resources, storage resources, and the network itself (e.g. firewall, load balancer), for example.
  • a given business service 44 may reside on a single server system 42, or may reside on multiple server systems.
  • Interface 30 enables any number of external user systems, illustrated as user systems 50a-n, to communicate with workload management system 20 and to business services 44 to which the user has access via the internet and/or intranet, such as via a VPN (virtual private network), for example.
  • users may submit transaction requests, including real-time interactive transaction requests (OLTP transactions), via a user portal 32 (e.g., a graphical user interface (GUI)) and API (application program interface) gateway 34, such as through a web browser, for example.
  • GUI graphical user interface
  • API gateway 34 such as through a web browser, for example.
  • users may submit transaction requests to workload management system 20 through API gateway 34 via application programs or requesting applications, such as illustrated by requesting application 56, including high-volume or batch transaction requests.
  • interface 30 via API gateway 34, submits the transaction request to parser 22 of workload management system 20.
  • Transaction requests may be submitted in any number of different platform-independent structured data formats, such as XML (extensible markup language), CSV (comma separated value), and Excel, for example.
  • XML documents may have a number of fields including metadata providing information about the transaction request, such as the item of interest (e.g. the requested or targeted business service), the type of data being requested, operations being requested (e.g. Create/Read/Update/Delete (CRUD)), and any number of other fields.
  • XML documents with transaction requests may be encapsulated within additional XML data which defines a messaging framework.
  • a Simple Object Access Protocol SOAP
  • SOAP Simple Object Access Protocol
  • XML documents may define individual sections of the document such as an "envelope" (which may include a specification of the document type and intended business service being requested) and a message body (e.g. details of the transaction request).
  • SOAP Simple Object Access Protocol
  • parser 22 receives and parses the transaction request for identifying information to determine whether the transaction request is a batch transaction request.
  • identifying information may include any number of characters, symbols, and language, such as certain operational language (e.g., CRUD, the names of targeted business services) and other identifiers such as delimiters between individual transactions (e.g. XML tags).
  • parser 22 in one example, based on the identifying information, develops a batch profile of the batch transaction request including information such as the particular business services 44 being requested, the number of transactions associated with each targeted business service, priorities that may be assigned to any of the transactions, and the tenants and/or sub-tenants associated with the
  • Parser 22 submits the batch transaction request along with the associated batch profile to resource manager 24.
  • Resource manager 24 monitors the ongoing capacity of computing system 10 and each of the business services of the plurality of business services 44. In one example, from the batch profile, resource manager 24 determines a capacity required for each targeted business service 44 to process associated transactions of the batch transaction, and based on the ongoing capacity of each of the targeted business services 44, individually scales the targeted business services 44, or portions of the targeted business services, in order to meet expected capacity requirement to process the batch transaction request. In one example, resource manager 24 may scale (e.g. in/out, up/down) certain targeted business services 44 (e.g. adding a business service application instance, adding a core to a server to increase processing capacity) and maintain other business services at their current capacities.
  • targeted business services 44 e.g. adding a business service application instance, adding a core to a server to increase processing capacity
  • resource manager 24 In addition to scaling business services 44, resource manager 24, as will be described in greater detail below, further provides multi-tenant prioritization of batch transaction processing which meets individualized processing requirements for each tenant (e.g. service level agreements), failure handling of individual transactions of batch transactions, and utility-based pricing for individual transactions of a batch for individual tenants.
  • individualized processing requirements for each tenant e.g. service level agreements
  • failure handling of individual transactions of batch transactions e.g. failure handling of individual transactions of batch transactions
  • utility-based pricing for individual transactions of a batch for individual tenants.
  • FIG. 2 is a block and schematic diagram illustrating an example of resource manager 24 according to the present disclosure.
  • resource manager 24 includes a dispatcher 60, a scheduler 62, a policy manager 64, a billing manager 66, a service deployer 68, a batch engine 70, and a detect-to-correct (DTC) module 72.
  • parser 22 receives a transaction request from a customer via API gateway 34.
  • the transaction request can be an interactive request from a user via user portal 32, or can be a programmatic request, such as from a user application 56.
  • Parser 22 searches the transaction request for metadata indicative of the content of the transaction, including whether certain flags are present, and searching for keywords such as known command language, delimiters, customer identifiers, transaction types, and business services being requested, for example.
  • parser 22 determines whether the transaction request is a batch transaction request and, if so, develops a batch profile for the batch transaction request.
  • the batch profile includes information such as the tenant, or tenants, of computing system 10 which are associated with the batch transaction request submitted by a customer/user.
  • the customer submitting the batch transaction request may be a tenant of computing system 10, wherein transactions of the batch transaction request are associated with a single tenant (in this instance, the submitting customer).
  • the customer submitting the batch transaction request to the computing system 10 may be a tenant, wherein the tenant may include or be associated with multiple sub-tenants.
  • the submitting tenant may represent a corporation, with sub-tenants representing different divisions, business units, or departments thereof.
  • the submitting tenant may be a business entity providing services to other businesses, wherein such other businesses represent sub-tenants of the submitting tenant.
  • the batch profile includes information such as the business services of the plurality of business services being requested (including by sub-tenant if applicable), the number of transactions associated with each of the requested business services (including by sub-tenant if applicable), whether the
  • transactions have the same or different priorities (e.g., transactions of the batch may be individually flagged for high processing priority by the submitting customer), and any number of other properties.
  • dispatcher 60 of resource manager 24 receives the batch transaction request and corresponding batch profile from parser 22. In one example, based on the batch profile, dispatcher 60
  • the batch transaction request determines whether the batch transaction request includes transactions for just a single tenant, for multiple tenants, or for one or more sub-tenants of a tenant, and determines processing priorities for the transactions of the batch transaction request, wherein transactions associated with different tenants (and/or subtenants), or different transactions of the batch for a same tenant may have different processing requirements and priorities.
  • dispatcher 60 communicates with policy manager 64 to determine data processing policies employed by computing system 10, including service level agreements (SLAs) that are in place with tenants and/or sub-tenants that set forth contractual requirements as to which business services 44 are being provided, prices, and how transactions are to processed (e.g. criteria such as times, response times, frequency, quality, etc.).
  • SLAs service level agreements
  • sub-tenants that set forth contractual requirements as to which business services 44 are being provided, prices, and how transactions are to processed (e.g. criteria such as times, response times, frequency, quality, etc.).
  • one tenant may have an SLA which requires that all transactions are to be processed within a given time period from submittal (e.g. immediately, within 2-hours, 4-hours, 24-hours, etc.).
  • Another tenant may have an SLA whereby processing is limited to a certain number of transactions within a set time period (e.g., transactions per hour).
  • Another tenant may have an SLA whereby all batch transaction processing is to be done at off-peak processing times.
  • a tenant may have an SLA whereby transactions for some types of business services 44 may have a higher priority than transactions for other types of business services.
  • computing system 10 may offer different service level tiers from which tenants may choose, with each tier having different pricing and performance criteria.
  • different subtenants of a same tenant e.g., different business units of same corporation
  • Any number of different SLAs may be employed by any number of different tenants.
  • Computing system 10 may also employ its own processing policies.
  • computing system 10 may employ a processing policy which dictates that all interactive transactions are given the highest processing priority and will be processed before batch transaction requests.
  • dispatcher 60 In addition to determining processing requirements of transactions of the batch transaction request (e.g. priorities, delivery times, etc.), dispatcher 60 communicates with DTC module 72 to determine current loads on computing system 10.
  • DTC module 72 includes a monitoring system 73 which monitors current capacities of network 40, including the capacities of resources associated with the handling of interactive transactions and the capacities of resources and components of business services 44 targeted by transactions of the received batch transaction request, and provides such capacity information to dispatcher 60.
  • dispatcher 60 In addition to capacity information provided by DTC module 72 for transactions currently being processed by computing system 10, in one example, dispatcher 60 also monitors the types (e.g. targeted business services) and priorities of transactions that have previously been received but are awaiting processing (e.g., transactions received and queued, but not yet being processed).
  • types e.g. targeted business services
  • priorities of transactions e.g., transactions received and queued, but not yet being processed.
  • dispatcher 60 determines whether the current capacities of computing system 10, including business services 44 targeted by the current batch transaction request, are to be scaled (e.g. in/out, up/down). For example, according to one scenario, dispatcher 60 may determine that the transactions of the current batch transaction request have a priority (e.g.
  • dispatcher 60 may decide to scale (e.g. scale-out/scale-up) certain business services 44 targeted by transactions of the batch transaction request in order to fulfill requirements of SLA(s) corresponding to tenant(s) of the batch transaction request.
  • dispatcher 60 may determine that the transactions of the current batch request have a priority that requires immediate processing, but that each of the business services 44 targeted by the batch transaction request has a capacity sufficient to process the batch transaction while fulfilling the requirements of relevant SLAs and without adversely impacting the processing of other transactions (e.g. both interactive and batch transactions). In such a scenario, dispatcher 60 will determine that business services 44 are not to be scaled (e.g., scale-out/scale-up) at this time.
  • dispatcher 60 determines to scale a business service 44, dispatcher instructs service deployer 68 to scale (in/out, up/down) the appropriate components of the business service 44 accordingly.
  • resource manager 24 when scaling a given business service 44, rather than monolithically scaling the entire business service 44, scales those independently scalable
  • each of the business services of the plurality of business services 44 may be implemented with a multi-tier, multi-node distributed system architecture having a plurality of independently scalable layers or components, with each component running on one or more servers of a given server system 42 or across multiple server systems 42.
  • a given business service 44 may have a Web application component (sometimes referred to as a "presentation layer") which serves as a user interface for Web access of the business service, an application component or layer running business application logic, and a data component or layer such as database, with each of the components of the business service being distributed on its own set or cluster of servers (virtual or actual), and with each group having a corresponding load balancer to balance processing loads between the servers of the cluster.
  • a given business service 44 may include one or more independently scalable microservice components that are distributed across their own sets or clusters of servers (virtual or actual).
  • service deployer 68 includes a deployment topology model 69 for each business service of the plurality of business services 44 which logically defines the architectural topology of each of the different components of the business service as they are distributed across sets of servers and how they are networked and configured to interact with one another (i.e., how the business service design is instantiated in the network).
  • dispatcher 60 accesses the deployment topology model for the given business service and compares the expected workloads of transactions of the batch transaction to be run against each component of the given business service to the current capacities of each of the components.
  • dispatcher 60 may deem that certain components of the business service are to be scaled (i.e., excluding other components).
  • Scaling refers to increasing (or decreasing) the capacity of the business service, or components of the business service, to handle the expected processing loads of transactions. For example, in one scenario, based on the types of received transactions for a given business service, dispatcher 60 may determine that the transactions will be compute-intensive and thereby deem it prudent to provide additional compute capacity to the application layer of the business service.
  • dispatcher 60 may scale "up" the application layer by allocating additional hardware, such as processing units and/or memory, to one or more instances of business application software operating on servers of the group of servers of the application layer.
  • dispatcher 60 may provide the additional capacity by scaling "out" the application layer through the addition of one or more servers.
  • additional server(s) may be a virtual machine including a desired operating system and loaded with the business application software.
  • additional server(s) may be a physical server which are allocated to the application layer from a pool of available servers and loaded with the business application software. In either case, the virtual and physical servers are added to the system architecture of the business service, with IP addresses of the virtual and physical servers being provided to the corresponding load balancer.
  • each of the business services 44 may have any number of configurations and layers. For example, each of the above described tiers or layers, such as the application layer, may be further divided into additional layers or tiers. Additionally, a given business service 44 could include (or interact with) one or more independently scalable microservices (also referred to here as components). Regardless of how many tiers or components are employed to deploy the system architecture, by referencing the deployment topology models 69 in this fashion, rather than broadly and inefficiently scaling the entire business service architecture, dispatcher 60 scales those components of a given business service 44 that are expected to require scaling (e.g. scaled up/out for expected additional processing loads) without scaling other components.
  • scaling e.g. scaled up/out for expected additional processing loads
  • dispatcher 60 In addition to using batch profiles of incoming batch transaction requests to determine whether to scale business services, dispatcher 60 also uses batch profile information to determine the order in which the batch transaction requests will be submitted for processing as they are received in order to meet the processing requirements of corresponding SLAs in the most efficient manner (e.g. cost-efficient manner).
  • a first batch transaction request may be received which dispatcher 60 deems can be delayed (e.g., the tenant has exceeded agreed upon processing limits for a given time period as defined by the SLA, processing can be delayed until off-peak times in accordance with the SLA).
  • a second batch transaction request is received which dispatcher 60 determines, based on the types of transactions and
  • dispatcher 60 submits the second batch transaction request to queue 63 of scheduler 62 for processing while holding the first batch transaction request for later processing.
  • dispatcher 60 may receive a batch transaction request that it deems to have a higher processing priority than batch transactions already submitted to queue 63 for processing. According to such a scenario, dispatcher 60 may instruct scheduler 62 to place the batch transaction request in queue 63 for processing ahead of earlier received batch transaction requests having lesser processing priorities. In another example, if a high number of interactive transactions are being received, dispatcher 60 may temporarily put various batch transactions "on hold" in order to temporarily increase capacity for processing of the interactive transactions. In view of the above, according to one example of the present disclosure, dispatcher 60 receives and schedules incoming batch transaction requests for processing to meet the performance requirements set forth by corresponding SLAs (e.g. SLOs (service level objectives)) while minimizing scaling of business services 44.
  • SLAs e.g. SLOs (service level objectives)
  • dispatcher 60 submits the batch transaction request to scheduler 62, which provides batch transaction requests from queue 63 to batch engine 70 for processing.
  • Batch engine 70 "de-batches" the batch transaction and assigns a batch ID to the batch and transaction IDs to each transaction of the batch, with each transaction ID being correlated to the corresponding batch ID.
  • Batch engine 70 determines the most efficient way in which to submit the batch transactions to the appropriate business services 44 for processing. For example, in one scenario, batch engine 70 may break the batch transaction into sub-batches for processing in parallel, such as by sorting the transactions based on the business service to which the transactions are targeted and concurrently submitting the transactions to the corresponding business services, and submitting transactions for a same business service to different application instances of the business service.
  • business services 44 communicate data associated with the processing to each transaction to logs 71 maintained by batch engine 70.
  • the logs track any number of parameters associated with each transaction such as a date/time stamps, processing time, whether the transaction processed successfully, whether an error occurred during
  • DTC module 72 monitors logs 71 for errors that may occur during processing of each of the transactions of the batch transaction. In one example, if an error is detected, DTC module 72 responds based on error handling policies, such as error handling policies set forth in SLAs for the tenant associated with the transaction, or general error handling policies of computing system 10, for example.
  • error handling policies such as error handling policies set forth in SLAs for the tenant associated with the transaction, or general error handling policies of computing system 10, for example.
  • DTC module 72 may submit a failed transaction to batch engine 70 a predetermined number of times for reprocessing as set forth by the appropriate error handling policy in an attempt to achieve successful processing. In one example, DTC module 72 submits failed transactions to an error queue of batch engine 70 for re-processing. In one example, in response to a transaction error being submitted by DTC module 72, batch engine 70 may suspend processing of the associated batch transaction and resubmit the failed transaction for re-processing before restarting processing of the batch. In one example, DTC module 70 may halt processing of the entire batch if too many errors are occurring in the processing of the batch as it may be an indication that the batch contains faulty data.
  • billing manager 66 will ensure the tenant is or is not "double-billed" for both the failed processing and successful processing of a same transaction. In other examples, such as when transactions are deemed to have failed based on the submission of faulty data, billing manager 66, based on error-handling policies, may or may not bill for processing the failed transactions.
  • batch engine 70 When processing of a batch transaction request is complete, including instances when all transactions have been successfully processed and instances when some transactions may not have been successfully completed, batch engine 70 assembles the log/status information and outputs for the batch transaction based on the batch ID and corresponding transaction IDs into a response, and returns the response to a location, or locations, based on destination information in the batch profile (e.g. FTP server, HTTP server, etc.).
  • batch profile e.g. FTP server, HTTP server, etc.
  • billing manager 66 accesses logs for processing times and resource consumption (e.g., CPU, memory, storage) associated with each transaction of the batch. In one example, based on pricing polices (such as defined by corresponding SLAs, for example) and processing times for each transaction, billing manager 66 determines a price for each individual transaction and assembles an overall bill for the batch transaction. In one example, billing manager 66 provides separate billing for each tenant associated with the batch transaction based on different pricing policies for each tenant. In one example, the price per transaction may vary from tenant to tenant depending on requirements of the corresponding SLAs (e.g. the type of business service accessed, and the time of day (e.g. off-peak)). As such, workload management system 20 provides utility-based pricing for batch transactions. However, it is noted that, depending on SLAs and pricing policies, billing manager 66 may simply charge a lump sum price for batch transactions for certain tenants.
  • resource consumption e.g., CPU, memory, storage
  • billing manager 66 determines a price for each individual transaction and
  • workload management system 20 enables computing system 10 to provide batch-on-demand processing by providing the ability to scale selected components of business services based on actual processing loads and expected processing loads from received batch
  • workload management system 20 employs batch profiles of incoming batch transaction requests and processing policies, including tenant/sub-tenant SLAs, to schedule and process batch transactions in the most efficient fashion (minimizing the amount of business services scaling, for example) while meeting processing requirements (e.g., SLOs) of SLAs corresponding to tenants that are impacted by the batch transaction request.
  • Workload management system 20, in accordance with the present disclosure further enables batch-on-demand processing by detecting and handling partial failures of batch transaction requests and restart procedures in view of error-handling policies (which may be unique for each tenant).
  • workload management system 20 enables utility-based pricing for each transaction of a batch transaction and on a tenant- by-tenant basis.
  • FIG. 3 is a flow diagram illustrating a method 100 of managing workload for batch processing according to one example of the present disclosure.
  • method 100 includes monitoring ongoing capacities of a plurality of business services hosed on a network, such as via DTC module 72 monitoring business services 44 hosted on server systems 42a-n, for example. Capacities include loads being processed in response to previously received batch transaction requests as well as OLTP.
  • method 100 includes receiving transaction requests for the plurality of business services, such as via API gateway 34 of interface 30, for example.
  • the method includes parsing metadata of each transaction request as it is received to determine whether the transaction request is a batch request, such as via parser 22. If so, at 108, the method includes providing, based on the metadata, a batch profile of the batch request comprising processing parameters of the batch request, including business services targeted by the batch request, such as via parser 22. At 1 10, method 100 includes scaling targeted business services based at least on monitored capacities of the targeted business services, on the batch profile, and on processing policies. In one example, scaling of business services may also be in response to OLTP loads on the computing system, and to both OLTP and OLAP processing loads.
  • the processing parameters further comprising a number of transactions of the batch request associated with each targeted business service, types of transactions, tenants of the computing system associated with the batch request, and a number of transactions associated with each tenant, with scaling including maintaining a deployment topology model for each business service that logically defines an architectural topology of components of each business service as implemented across the networked server systems, and scaling selected components of a targeted business service based on the monitored capacity, the batch profile, the processing policies, and of the deployment topology model.
  • workload management system 20 including parser 22 and resource manager 24, may be implemented by a computing system, which may be any combination of hardware and programming to implement the functionalities of workload management system 20 as described herein.
  • programming for workload management system 20 may be
  • the at least one non-transitory machine-readable storage medium stores instructions that, when executed by the at least one processing resource, implement workload management system 20.
  • FIG. 4 is a block and schematic diagram generally illustrating a computing system 200 for implementing workload management system 20 according to one example.
  • computing system or computing device 200 includes processing units 202 and system memory 204, where system memory 204 may be volatile (e.g. RAM), non-volatile (e.g. ROM, flash memory, etc.), or some combination thereof.
  • system memory 204 may be volatile (e.g. RAM), non-volatile (e.g. ROM, flash memory, etc.), or some combination thereof.
  • Computing device 200 may also have additional features/functionality and additional or different hardware.
  • computing device 200 may include input devices 210 (e.g.
  • keyboard, mouse, etc. e.g. keyboard
  • output devices 212 e.g. display
  • communication connections 214 that allow computing device 10 to communicate with other computers/applications 216, wherein the various elements of computing device 200 are communicatively coupled together via communication links 218.
  • computing device 200 may include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape.
  • additional storage is illustrated in Figure 4 as removable storage 206 and non-removable storage 208.
  • Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any suitable method or technology for non-transitory storage of information such as computer readable instructions, data structures, program modules, or other data, and does not include transitory storage media.
  • Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, and magnetic disc storage or other magnetic storage devices, for example.
  • System memory 204, removable storage 206, and non-removable storage 208 represent examples of computer storage media, including non- transitory computer readable storage media, storing computer executable instructions that when executed by one or more processors units of processing units 202 causes the one or more processors to perform the functionality of a system, such as workload management system 20.
  • system memory 204 stores computer executable instructions for workload management system 20, including parser instructions 220 and resource manager instructions 240, that when executed by one or more processing units of processing units 202 implement the functionalities of workload management system 20 as described herein.
  • one or more of the at least one machine-readable medium storing instructions for workload management system 20 may be separate from but accessible to computing device 200. In other examples, hardware and programming may be divided among multiple computing devices.
  • the computer executable instructions can be part of an installation package that, when installed, can be executed by the at least one processing unit to implement the functionality of workload management system 20.
  • the machine-readable storage medium may be a portable medium, such as a CD, DVD, or flash drive, for example, or a memory maintained by a server from which the installation package can be downloaded and installed.
  • the computer executable instructions may be part of an application, applications, or component already installed on
  • the machine readable storage medium may include memory such as a hard drive, solid state drive, or the like.
  • the functionalities of workload management system 20 may be implemented in the form of electronic circuitry.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Debugging And Monitoring (AREA)

Abstract

L'invention concerne une mise à l'échelle de services pour un traitement par lots. Des exemples comprennent la réception de demandes de transaction pour des services commerciaux hébergés sur un réseau, lorsque chaque demande de transaction est reçue, l'analyse de métadonnées de la demande de transaction pour déterminer si la demande de transaction est une demande par lots et, lorsque la demande de transaction est une demande par lots, la génération, sur la base des métadonnées, d'un profil de lot de la demande par lots comprenant des paramètres de traitement de la demande par lots, y compris des services commerciaux ciblés par la demande par lots, la surveillance de capacités en cours du réseau, y compris chacun des services commerciaux ; et la mise à l'échelle de services commerciaux ciblés sur la base au moins des capacités surveillées, du profil de lot et des politiques de traitement.
PCT/US2015/057615 2015-10-27 2015-10-27 Mise à l'échelle de services pour traitement par lots WO2017074320A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/057615 WO2017074320A1 (fr) 2015-10-27 2015-10-27 Mise à l'échelle de services pour traitement par lots

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/057615 WO2017074320A1 (fr) 2015-10-27 2015-10-27 Mise à l'échelle de services pour traitement par lots

Publications (1)

Publication Number Publication Date
WO2017074320A1 true WO2017074320A1 (fr) 2017-05-04

Family

ID=58630847

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/057615 WO2017074320A1 (fr) 2015-10-27 2015-10-27 Mise à l'échelle de services pour traitement par lots

Country Status (1)

Country Link
WO (1) WO2017074320A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10817357B2 (en) 2018-04-30 2020-10-27 Servicenow, Inc. Batch representational state transfer (REST) application programming interface (API)
CN113450220A (zh) * 2021-06-30 2021-09-28 中国建设银行股份有限公司 一种基于分散批处理的处理方法和装置
CN113656180A (zh) * 2021-08-19 2021-11-16 中国银行股份有限公司 单元化架构下批量处理文件的系统、方法及相关产品
CN113781226A (zh) * 2021-09-14 2021-12-10 中电金信软件有限公司 一种批量交易数据处理方法和装置
WO2023093194A1 (fr) * 2021-11-24 2023-06-01 华为云计算技术有限公司 Procédé de surveillance en nuage et plateforme de gestion en nuage
CN116775255A (zh) * 2023-08-15 2023-09-19 长沙伊士格信息科技有限责任公司 一种支持广泛集成场景的全域集成系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050278250A1 (en) * 2004-06-10 2005-12-15 Kays Zair Transaction processing payment system
US20110307291A1 (en) * 2010-06-14 2011-12-15 Jerome Rolia Creating a capacity planning scenario
US20120072972A1 (en) * 2010-09-20 2012-03-22 Microsoft Corporation Secondary credentials for batch system
US20120179824A1 (en) * 2005-03-16 2012-07-12 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US20140282556A1 (en) * 2010-04-20 2014-09-18 Salesforce.Com, Inc. Methods and systems for batch processing in an on-demand service environment

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050278250A1 (en) * 2004-06-10 2005-12-15 Kays Zair Transaction processing payment system
US20120179824A1 (en) * 2005-03-16 2012-07-12 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US20140282556A1 (en) * 2010-04-20 2014-09-18 Salesforce.Com, Inc. Methods and systems for batch processing in an on-demand service environment
US20110307291A1 (en) * 2010-06-14 2011-12-15 Jerome Rolia Creating a capacity planning scenario
US20120072972A1 (en) * 2010-09-20 2012-03-22 Microsoft Corporation Secondary credentials for batch system

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10817357B2 (en) 2018-04-30 2020-10-27 Servicenow, Inc. Batch representational state transfer (REST) application programming interface (API)
US11489838B2 (en) 2018-04-30 2022-11-01 Servicenow, Inc. Batch representational state transfer (REST) application programming interface (API)
CN113450220A (zh) * 2021-06-30 2021-09-28 中国建设银行股份有限公司 一种基于分散批处理的处理方法和装置
CN113656180A (zh) * 2021-08-19 2021-11-16 中国银行股份有限公司 单元化架构下批量处理文件的系统、方法及相关产品
CN113781226A (zh) * 2021-09-14 2021-12-10 中电金信软件有限公司 一种批量交易数据处理方法和装置
WO2023093194A1 (fr) * 2021-11-24 2023-06-01 华为云计算技术有限公司 Procédé de surveillance en nuage et plateforme de gestion en nuage
CN116775255A (zh) * 2023-08-15 2023-09-19 长沙伊士格信息科技有限责任公司 一种支持广泛集成场景的全域集成系统
CN116775255B (zh) * 2023-08-15 2023-11-21 长沙伊士格信息科技有限责任公司 一种支持广泛集成场景的全域集成系统

Similar Documents

Publication Publication Date Title
US11005969B2 (en) Problem solving in a message queuing system in a computer network
US11250025B2 (en) Methods and systems for bulk uploading of data in an on-demand service environment
US9755990B2 (en) Automated reconfiguration of shared network resources
CA2900948C (fr) Planificateur de taches a moindre cout
WO2017074320A1 (fr) Mise à l'échelle de services pour traitement par lots
US8380557B2 (en) Multi-tenant database management for service level agreement (SLA) profit maximization
CN104937584B (zh) 基于共享资源的质量向经优先级排序的虚拟机和应用程序提供优化的服务质量
US8701117B2 (en) Resource consumption template processing model
US8381219B2 (en) Monitoring performance on workload scheduling systems
US20150067028A1 (en) Message driven method and system for optimal management of dynamic production workflows in a distributed environment
US11507417B2 (en) Job scheduling based on job execution history
US9348709B2 (en) Managing nodes in a distributed computing environment
US20220276904A1 (en) Job execution with managed compute environments
US10331488B2 (en) Multilayered resource scheduling
US20230104787A1 (en) Multi-tenancy interference model for scaling in container orchestration systems
US20190253488A1 (en) Transaction process management by dynamic transaction aggregation
US20190377596A1 (en) Flexible batch job scheduling in virtualization environments
US10908969B2 (en) Model driven dynamic management of enterprise workloads through adaptive tiering
US20220405133A1 (en) Dynamic renewable runtime resource management
US9934268B2 (en) Providing consistent tenant experiences for multi-tenant databases
US20130145004A1 (en) Provisioning using presence detection
WO2021096346A1 (fr) Système mis en œuvre par ordinateur permettant la gestion de journaux de conteneurs et procédé associé
US20220398134A1 (en) Allocation of services to containers

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15907428

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15907428

Country of ref document: EP

Kind code of ref document: A1