A method and system for load distribution in integrated scenarios

Abstract

The present disclosure generally describes methods, software, and systems for processing integrated processes. A set of processes are initially deployed to a single set of workers. A load balancing problem associated with initial runtime interactions of workers with the single set of workers is identified. In response to identifying the load balancing problem, the load balancing problem is analyzed to determine whether to automatically scale or generate a new set of workers. Load balancing is performed to start at least one new set of workers. At least one process to be moved to the at least one new set of workers is identified. Movement of the identified at least one process from a current set of workers to the new set of workers is performed.

Description

Background Art

[0001] The present disclosure relates to process integration flows. Summary of the invention

[0002] The present disclosure generally describes computer-implemented methods, software, and systems for allocating and managing workflows, including managing load distribution for integration scenarios. A computer-implemented method includes: initially deploying a set of processes to a single worker set; identifying a load balancing problem associated with an initial runtime interaction of a worker with the single worker set; in response to identifying the load balancing problem, analyzing the load balancing problem to determine whether to automatically scale or generate a new worker set; performing load balancing to start at least one new worker set; identifying at least one process to be moved to the at least one new worker set; and performing movement of the identified at least one process from the current worker set to the new worker set.

[0003] The foregoing and other implementations may each optionally include one or more of the following features, either alone or in combination. In particular, an implementation may include all of the following features:

[0004] In a first aspect, combinable with any of the preceding aspects, wherein the load balancing problem comprises an out of memory exception.

[0005] In a second aspect, combinable with any of the preceding aspects, identifying at least one process to move to the at least one new set of workers comprises randomly moving the at least one process.

[0006] In a third aspect, combinable with any of the preceding aspects, identifying at least one process to move to the at least one new set of workers comprises: performing pre-computation to define a complexity metric; and distributing the process across the set of workers based on the complexity metric.

[0007] In a fourth aspect, combinable with any of the preceding aspects, the complexity metric is a measure of the complexity of the process, including one or more of the multiple steps in the process or multiple specific steps in the process.

[0008] In a fifth aspect, combinable with any of the preceding aspects, the special steps include a mapping step and a scripting step.

[0009] In a sixth aspect, combinable with any of the preceding aspects, the process represents an integration scenario.

[0010] Details of one or more implementations of the subject matter of this specification will be set forth in the accompanying drawings and the following description. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a block diagram of an exemplary environment for performing load processing.

[0012] Figure 2 is a block diagram illustrating automatic scaling redistribution.

[0013] Figure 3 is a block diagram illustrating load-based redistribution.

[0014] Figure 4 is a block diagram illustrating examples of traditional applications and cloud native applications (CNAs).

[0015] Figure 5 This is a block diagram of an example of the execution process of iFlow (integration flow).

[0016] Figure 6 is a block diagram of an example of server-to-worker interaction.

[0017] Figure 7 is a block diagram illustrating an example of an architecture including an orchestrator, a runtime, and a platform.

[0018] Figure 8 is a block diagram illustrating an example of an architecture including an orchestrator, a runtime, and a platform.

[0019] Fig. 9 is a flow diagram of an example of a method for reassigning a process to a set of workers.

[0020] Fig.10 is a block diagram of an exemplary computer system for providing computing functionality associated with the algorithms, methods, functions, processes, flows, and procedures described in the present disclosure. DETAILED DESCRIPTION

[0021] The disclosure generally describes computer-implemented methods, software, and systems for load distribution of execution flows. For example, a flow can be an integrated flow iFlow representing an integration scenario. Using the techniques described in the present disclosure, the number of iFlows can be divided into manageable sizes for workers, thereby preventing overloading of workers. For example, a new set of workers can be started, which can solve the distribution problem. The techniques used help overcome the problem that the physical boundaries of workers limit execution capabilities. Distributing iFlows to different sets of workers can execute all iFlows.

[0022] The option of using a single iFlow container can avoid conflicts between iFlow instances of the same resource (constant throughput problem). This is because there is only one iFlow in the container, thus avoiding competition with other iFlows. However, there is a problem that due to the number of iFlows (for example, 56K iFlow bundles × 2 (high availability (HA)) = 112K in the current implementation), this option can extend the limitations of the underlying technology.

[0023] In the option of using k-iFlow containers, iFlow groups can be composed into iFlow sets that are deployed to independent sets of workers. The formula means that k1+k2+...+k i＝n Can be used to provide a runtime for each iFlow, where all iFlows are deployed directly.

[0024] The option of using API server / worker separation makes it easy to split iFlow using microservices. The API server can expose endpoints and the workers can contain the pipeline execution.

[0025] Figure 1 1 is a block diagram of an exemplary environment 100 for performing load processing. The environment 100 includes a cloud platform integration system 102 that operates in a cloud (eg, using a network 104) and provides integration services for workflows executed by users (eg, using at least one client 106).

[0026] The cloud platform integration system 102 includes a load handler 108 that manages related operations (including load balancing) and an autoscaler 110 that performs an automatic scaling process. The automatic scaling process may include creating homogeneous copies (or instances) of a particular set of workers. Thresholds are used to determine when automatic scaling should be performed (compared to creating a new worker set instantiation), and may include using metrics to help determine. Metrics may include metrics related to central processor unit (CPU) usage (e.g., "Does CPU usage X% (e.g., 80%) last for a predetermined threshold time period"). Metrics may also include metrics related to memory (e.g., "Is there N% memory usage within a predetermined time period?"). CPU and memory consumption are two metrics, but the complexity of iFlow is another metric. The complexity of iFlow can be based on bundle size (e.g., in kilobytes (KB)), iFlow size (e.g., the number of steps in iFlow), and iFlow step type.

[0027] For example, the autoscaler 110 may have limits when too many iFlows are deployed to a worker instance, which may require splitting the worker set. Thus, a combination of autoscaling and instantiating a new worker set may be used. The selection of one approach over another may be based on various criteria, including the number of iFlows and the number of worker instances.

[0028] For example, when the autoscaling alone cannot handle one or more of the requirements for additional resources or a new worker set, the worker set instantiator 112 can be configured to generate a new worker set. Various thresholds can be used to determine when to create a new worker set. For example, a first threshold can be associated with multiple instances (e.g., five instances) of a worker set. If the autoscaler 110 cannot distribute the load in a useful way, the process can be switched (or reallocated) to other worker sets. The second threshold can be established as the number of iFlows in the worker set. For example, if there are too many processes in the worker set, the processes can be reallocated to other existing or new worker sets. The term worker set instantiator 112 can be used synonymously with a content coordinator or can be referred to as a content coordinator. For example, a content coordinator can trigger the startup of a worker set, such as by delegating to a tenant resource manager.

[0029] In some implementations, to achieve high availability, a worker set can be instantiated with two worker instances (e.g., by default). If the autoscaler 110 increases the number of instances, it only does this for one worker set. The other worker sets are not affected because they process different iFlows.

[0030] The iFlow analyzer 114 can perform various tasks associated with analyzing resources. For example, the iFlow analyzer 114 can determine the resources required to execute the iFlow. The iFlow analyzer 114 can also determine the resources used during execution, including determining when the monitored load exceeds a predetermined threshold. The iFlow analyzer 114 can also analyze the use of specific resources associated with the iFlow and the worker set instance. In some implementations, the iFlow analyzer 114 can store (or be able to access) historical information about certain iFlows in order to obtain information for pre-calculation considerations and complexity metrics. For example, the calculation can determine the number of steps, the type of iFlow steps, and the historical execution of a specific iFlow. The iFlow analyzer 114 can notify the worker set instantiator 112 to instantiate additional worker sets.

[0031] The redistribution module 116 can be configured to cause redistribution of iFlows to occur between different sets of workers. For example, based on the iFlow analyzer results, the redistribution module 116 can move one or more specific iFlows to different sets of workers. The load balancer 117 can be used to balance the load.

[0032] The runtime environment 118 can be configured to manage one or more instantiated worker set instances 120, including managing the iFlow of the integration scenario executed in the worker set. For example, using a simple algorithm, the runtime environment 118 can start with only one worker set for the deployment of iFlow. Using a simple algorithm to distribute the worker set can include simply dividing the number of iFlows in half and evenly distributing iFlows between the two worker sets. The disadvantage of the simple algorithm is that the iFlow that may cause problems is not identified (for example, using additional resources based on complexity). Therefore, the simple algorithm can be mainly used as a divide-and-conquer strategy for splitting the worker set. Exemplary splits can include [10→5+5] or [10→5+2+3] (wherein the second group of five iFlow workers are subsequently split). Alternatively, using a pre-calculation algorithm and based on the known characteristics of iFlow, the runtime environment 118 can start multiple worker sets at deployment. The pre-calculation algorithm can use the iFlow analyzer 114 to balance the complexity in the worker set with equal probability. Using the iFlow analyzer 114 may prevent undesirable situations, such as where most complex iFlows are assigned to one set of workers, while non-complex iFlows are assigned to a different set of workers.

[0033] The cloud platform integration system 102 includes a memory 122 that can store an integration scenario 124. The process information (including iFlow definitions) defined in the integration scenario 124 can be used by the iFlow analyzer 114 to determine the static resources required based on, for example, the defined processes and process patterns. Each iFlow definition can include, for example, associated instantiation overhead and information about the resources required to execute the iFlow.

[0034] The load balancer rules 126 stored in the memory 122 may identify the autoscaler threshold and the worker set generation threshold. The historical information 128 stored in the memory 122 may include information about a particular process, such as resource consumption and other statistics about the particular process.

[0035] The cloud platform integration system 102 includes an interface 130 that provides interface services to the client 106. The cloud platform integration system 102 also includes a processor 132 that can execute instructions of the modules and components of the cloud platform integration system 102.

[0036] The cloud platform integration system 102 can be used to distribute iFlow in real time at runtime, so that resources can be used in a more efficient manner. Considerations about efficiency can be explained using examples that illustrate extreme conditions. In the unoptimized extreme case, all iFlows can run on one runtime (for example, the case of n iFlows), which may cause problems such as overloading the Open Services Gateway Initiative (OSGI) runtime with the number of bundles required to utilize iFlow. In this example, simultaneous execution of all iFlows may be completed on the same runtime, resulting in resource sharing problems. Therefore, when considering efficiency, the technology of k iFlow solutions can be used, where l>k>n.

[0037] Each iFlow can be classified based on the characteristics of the iFlow. For example, in a static case, before deploying the iFlow, the iFlow complexity of the iFlow bundle of the iFlow can be analyzed. The criteria for classifying the complexity of the iFlow can include, for example, bundle size (e.g., in kilobytes (KB)), iFlow size (e.g., the number of steps in the iFlow), and iFlow step type. When considering the iFlow step type, it is assumed that splitters, mappings, and script steps will generate significant memory and CPU usage.

[0038] In a dynamic situation, for example, analyzing the load of an iFlow after it is deployed, the resource usage of the iFlow can be measured in real time. For example, CPU usage, memory usage, number of requests (per iFlow), request size, and memory shortage can be measured, because anomalies can indicate that a specific iFlow at runtime is causing problems.

[0039] Various algorithmic approaches can be used in the distribution of iFlow. For example, a first algorithmic approach can start with a static analysis and populate the workers according to static criteria that are optimized based on dynamic measurements. This approach includes the challenge of redistributing iFlow from one worker to another. Advantages of this approach include optimizing resource usage and subsequent redistribution of iFlow. Disadvantages of this approach include the need for a complex redistribution algorithm.

[0040] For example, the second algorithmic approach can start with a static analysis and fill the workers based on static criteria. If the set of workers is full, the next set of workers can be used, but there is no dynamic redistribution. The challenge of this approach is to define static criteria in a good way to deal with resource consumption. The advantages of this approach include a solution to the problem of the number of OSGI bundles (because only a limited number of iFlows are running simultaneously at runtime) and the complexity of redistributing iFlows is low. The disadvantages of this approach include a lack of solution to the problem of resource consumption (because all iFlows are deployed to handle requests) and there is no redistribution of iFlows).

[0041] Different approaches for computing resource usage can depend on the number of iFlows. A single iFlow approach and n iFlow approaches can provide two extremes, and a k iFlow approach can provide a compromise. The advantages of the k iFlow approach can become apparent because in the case of k iFlows, the k iFlows can be run as a single iFlow (running each iFlow in its own worker set) or as n iFlows (running only one worker set). In the following example, the number of iFlows is 400, the runtime memory consumption is 1000MB, the iFlow memory consumption is 1 megabyte (MB), and the number of worker sets is 10.

[0042] In a single iFlow method, the memory consumption can be, for example, 400,400MB. The problem with a single iFlow method is that the fixed memory consumption at runtime can cause the overall memory consumption to be very high. The number of workers is the number of iFlows.

[0043] In n iFlow methods, the memory consumption can be, for example, 1400MB. n iFlow methods may have the following disadvantages. First, it is impossible to deploy more than 200 iFlows to a worker. Second, because iFlows run together at one runtime, an exception in one iFlow will cause all other iFlows to crash. However, the memory consumption (including reuse at runtime) may be efficient.

[0044] In k iFlow methods, the memory consumption may be, for example, 10,400MB, and the memory consumption of one worker may be 1040MB. k iFlow methods may be used as a tradeoff between n iFlow methods (which may create runtime issues due to the number of iFlows) and memory consumption. The number of workers may be defined by the number of worker sets (which may be dynamically configurable).

[0045] Figure 2200. Autoscaling 208 can solve the problem of workers under heavy load (e.g., iFlows 202a-202d in worker set 204). Autoscaling 208 can be used to split a worker under 90% load 206 into worker sets 210 and 212, each with 45% load 214. In this example, half of the iFlows 202a-202d end up in each of worker sets 210 and 212. However, autoscaling 208 cannot handle complex redistributions.

[0046] Figure 3 310 is a block diagram illustrating load-based redistribution 310. Prior to redistribution, iFlows 202a-202f are distributed among worker sets 302, 304, and 306, which include three, two, and one iFlows, respectively. Additionally, iFlow_2 202b and iFlow_3 202c are each determined to have a 45% load 308. In this example, worker set 302 has a 90% load 310a (heavy load), and worker sets 304 and 306 each have a 0% load 310b. Under redistribution 310, iFlow_3 202c may be moved from worker set 302 to worker set 306. Thus, worker sets 302 and 306 may have a 45% load 310c, while worker set 304 still has a 0% load 310b.

[0047] Redistribution 310 may not always be deterministic in determining which iFlow should be moved to another worker set and may result in suboptimal redistribution decisions with local optima. For example, after redistribution 310, iFlow_4 202d and iFlow_5 202e still do not have optimal resource usage.

[0048] Various options can be used to improve the effectiveness of redistribution. In a first redistribution option, an application programming interface (API) server can be used to analyze the usage of iFlows and the current allocation of iFlows to worker sets. The result is that unused iFlows may not be deployed. Effective redistribution may require an algorithm or framework to identify iFlows under heavy load. The redistribution algorithm needs to be able to launch workers with a changed set of iFlows, and this may further increase the complexity of the API server.

[0049] In the second redistribution option without using an API server, the redistribution algorithm still needs to analyze the load of iFlows and identify the iFlows that have been used. Challenges that arise without using an API server include relying on platform performance for scheduling. For example, platform performance must be used to achieve a stable uniform resource locator (URL) for endpoint consumers. Intelligent redistribution is required to identify iFlows under heavy load and provide iFlows to different sets of workers.

[0050] Figure 4 400a and a cloud native application (CNA) 400b. The traditional application 402 includes a user interface (UI) 404 that serves as a user front end. The process is executed in a runtime environment 406 using a persistent state of work 408. In the traditional application (app) 410, the size is actively managed 412, which may lead to over-provisioning resources and monolithic deployment 414. For the entire application, the state is maintained 416. In-process communication occurs 418, and implementations 420 are generated for projects and operations (ops).

[0051] It may be necessary to manually scale worker nodes, resulting in over-configuration of resources to satisfy each request. Types of situations where resources are scaled include, for example, peak (and very large) messages and constant throughput. In the case of peak (very large) messages, Cloud Platform Integration (CPI) may receive 100 megabytes (MB) Extensible Markup Language (XML) messages. XML serialization may result in an explosion of used memory (assuming a heap size of 500MB is used). If iFlow contains a mapping, a 6-fold averaging factor may be applied to memory consumption to convert messages from one format to another (e.g., 500MB×6=3000MB). In the case of constant throughput, CPI may receive a large number of messages, and mappings and scripts may generate significant memory requests. When an out-of-memory exception occurs, a memory crash may occur.

[0052] CNA 422 is elastically scalable 424 and has a microservices-based deployment 426. The state of the flow is isolated (428) in some components and loosely coupled by contract, with remote communication (430) occurring over the network. Deployment can be automated (432) for development operations (DevOps) and NoOps, including automation of deployment, monitoring, and management of iFlow.

[0053] CNA 434 includes a UI 436 that serves as a user front end. The process is facilitated using microservices 438-442 that utilize persistent state 444 and 446. Reliability equations 448 and 450 applicable to traditional app 410 and CNA 422 may be based on a mathematical relationship between mean time to failure (MTTF) and mean time to replacement (MTTR).

[0054] Various options can be used to manage iFlow containers. In the streaming option, iFlow pipelines can work with streaming to reduce memory consumption.

[0055] In the option of using split into microservices, the CNA architecture can suggest splitting the runtime into smaller units to handle the load with smaller units. Because the mapping engine is focused on performing mappings, the mapping engine does not require much memory. Peak scenarios may be suitable for this option because the complete iFlow does not have to be kept in memory. However, without flow delivery, the memory consumption of the mapping engine can be in the same dimension.

[0056] Figure 5 500 is a block diagram of an example of an execution process 500 of an iFlow. The execution process 500 covers a single iFlow worker, which is similar to a single iFlow container implementation, and in which the worker executes only one iFlow. A user 502 executing a task can interface with an API 504, which provides an endpoint 506, a runtime 508, and platform details 510. The API 504 can facilitate the execution and management of tasks 512 under the control of a worker instance 514. The worker instance 514 provides an integration flow 516, a runtime 518, and platform details 520. The API 504 and the worker instance 514 can process messages 522 created during the iFlow.

[0057]

[0058] Table 1 = Parameters and conditions per container size

[0059] Some architectural decisions can be made based on the evaluation of the API server / worker split in the case of a single iFlow worker set. A single iFlow worker set can provide a fair tradeoff between complexity and resource optimization, assuming the following: 1) a pre-warmed container pool is required because dynamic startup of containers is too time-consuming; 2) there is still a risk that costs may rise depending on utilization because resource sharing across containers is fairly low (where iFlow utilization per tenant is <50%); 3) the API server can be scheduled using a load balancer, allowing load balancing, failover, and autoscaling to be handled by the platform; 4) for timer-triggered iFlows (typically rare types of iFlows), containers can always be started;

[0060] 5) Combining k iFlow approaches with dynamic distribution may be impractical due to different sets of complex challenges; 6) The API server has the potential to become a single point of failure (depending on the deployment topology), which may adversely affect scalability and reliability; and 7) It is technically possible for multiple integration flows to expose the same endpoint.

[0061] In some implementations, a split of iFlow can occur. In conventional systems, iFlow can be converted from a packaged beans.xml into an OSGI bundle. Splitting means that the endpoint must be pushed to the API server and the remaining iFlow must go to the worker.

[0062] iFlow can be classified into three groups: 1) the group using Hypertext Transfer Protocol (HTTP) endpoints for on-demand execution of iFlow; 2) the group using fast scheduling, where the adapter polls periodically and if there is new data, processing must begin, for example, using File Transfer Protocol (FTP) or Java Message Service (JMS); and 3) the group using irregular scheduling, including one-time runs or specific scheduling mechanisms.

[0063] Techniques for splitting iFlow may include the following options. In the first option, the API server can reuse the same beans.xml. The beans.xml can be deployed to the API server where only the consumer is executed since the route definition changes dynamically.

[0064] The second option may use an API server with a specific beans.xml for the endpoints. In this option, the iFlow generation may create two bundles: 1) beans.xml with the consumer endpoints and the delegation to the worker endpoints; and 2) beans.xml with the rest of the functionality of iFlow.

[0065] A third option could use a Tomcat-API server and the iFlow generation could create an artifact where the Tomcat-API server provides a separate servlet for each iFlow and metadata to handle the redirection of the iFlow to the worker (generic redirection at runtime).

[0066] Figure 6 is a block diagram of an example of a server-to-worker interaction. The API server 602 can reuse the runtime to expose endpoints through at least one route 604 (and through routes 606 in worker nodes 608). Specific endpoint bundles can be executed on the API server. The advantage is that the scheduling adapter can be executed on the API server and there is no need to start workers for polling operations. Disadvantages include: the runtime footprint of the exposed endpoints is higher than the Tomcat runtime, and transaction processing for some adapters may become more complex, such as JMS and Applicability Statement 2 (AS2). Based on this information, the implementation can use a lightweight API server to avoid the splitting of beans.xml, and the routing can run entirely on the worker. The selected implementation can also be based on how the API server identifies the worker that will take over the work, which includes deploying the integration flow to the worker and evicting the iFlow if no request appears.

[0067] For example, the choice of architecture can be based on, for example, merging discovery with coordinator functionality, since the coordinator is responsible for distributing the lifecycle of bundles and nodes, e.g., deploying iFlow bundles to workers, so the state of workers and iFlow bundles can be available / stored at the node coordinator. Therefore, options for the coordinator can include the following.

[0068] The orchestrator can be thought of as an actor. However, an assessment may determine that the orchestrator has at least two purposes: node management and content management. Regarding node management, the orchestrator is responsible for all lifecycle operations of the node (including the API server). The orchestrator is responsible for starting and stopping applications / pods. The orchestrator collects information about the health of a single actor for each application instance, which queries the number of applications running for the health of each application. The orchestrator mounts file system volumes for each application / pod. The orchestrator defines and enforces security and network policies for each application / pod. The orchestrator provides bindings for the services required by each application and cleans up resources when the application / pod stops.

[0069] In some implementations, the coordinator can be split into two main domains based on the dimension of tenancy (e.g., multi-tenant node or tenant-specific). For example, there can be four options for the coordinator: 1) multi-tenant node coordinator and multi-tenant content coordinator; 2) multi-tenant node coordinator and tenant-specific content coordinator; 3) tenant-specific node coordinator and multi-tenant content coordinator; and 4) tenant-specific node coordinator and tenant-specific content coordinator.

[0070] Figure 7 800a includes a coordinator 802, a runtime 804, and a platform 806. The tenant resource manager 812 of the coordinator 802 is responsible for resource utilization and management of workers, shares, and databases. The content coordinator 810 of the coordinator 802 can handle content for a specific tenant. In the architecture 800a, the result is that the tenant resource manager 812 is multi-tenant and the content coordinator 810 is tenant-specific.

[0071] Figure 8 800b is a block diagram illustrating an example of an architecture 800b including an orchestrator 802, a runtime 804, and a platform 806. In the architecture 800b, a content orchestrator 810 is assigned to a microservice of the runtime 804 to process iFlow bundles of iFlows 820a and 820b of a worker instance 818.

[0072] The goal of the separation between the API server 814 and the worker instances 818 is to start a worker only when there is a request for a specific iFlow. This means that the worker node instances must be managed, which includes starting new workers (if the request does not use an iFlow instance) and stopping workers that are not used within a predetermined time frame. It can be assumed that there is a library of available workers for scheduling. In the case of a request arriving at the API server 814, the worker obtains the corresponding iFlow, redirects the message, and can handle the execution.

[0073] The API server 814 handles lifecycle management operations. The advantage is that the API server 814 completely handles workers and iFlows. The disadvantage is that there is an overlap in functionality with the content coordinator 810. The content coordinator 810 can be called each time a lifecycle operation is needed. The advantage is that the coordinator 802 has a clear responsibility to handle workers and iFlows. The disadvantage is that the API server 814 must contact the coordinator 802 about deployments that cross the boundaries of microservices and may violate the runtime 804. The API server 814 can call the content coordinator 810 to start new workers and stop unused workers.

[0074] Figure 8800b includes a coordinator 802, a runtime 804, and a platform 806. In the architecture 800b, iFlow can be deployed directly to a worker node, and all iFlows can be deployed to all worker nodes of a tenant. In an implementation using a single iFlow container, when iFlow is deployed to a worker with dynamic decomposition, the iFlow also needs to be deployed to the worker at a later point in time.

[0075] The API server 814 can trigger the deployment of iFlow to the worker. In this example, the coordinator 802 may become a potential bottleneck for deployment, and the worker node retrieves the bundle. In addition, the worker node can obtain the bundle from the repository and deploy the bundle without contacting any other node. Only the worker can handle the deployment of iFlow, and the worker needs to take over the content lifecycle tasks.

[0076] Message execution and communication can be delegated to workers. In some implementations, messages can be synchronized using HTTP. Messages can exist in object storage devices. Based on the size of the message, messages can be transmitted directly or using object storage devices, which can provide better resource utilization and thread management. In some implementations, messages can be sent asynchronously using queues (implying the use of object storage devices). Message delivery can rely entirely on the use of object storage devices. However, based on the size of the message, the message can be transmitted directly. The messaging technology used can depend on reliability, latency, and considerations of the use of message brokers or object storage devices.

[0077] Fig. 9 is a flowchart of an example of a method 900 for reassigning a process to a set of workers. For example, the method 900 may be performed by the cloud platform integration system 102. For clarity of presentation, the following description generally describes Figures 1 to 8 Method 900 in the context of .

[0078] At 902, a set of flows are initially deployed to a single worker set. As an example, iFlows 202a-202d may be deployed to worker set 204.

[0079] At 904, a load balancing problem associated with an initial runtime interaction with a worker of a single worker set is identified. For example, the load handler 108 may determine that the worker set 204 has a heavy load (eg, 90%).

[0080] At 906, in response to identifying the load balancing problem, the load balancing problem is analyzed to determine whether to automatically scale or generate a new worker set. For example, the load handler 108 can determine whether the worker set 204 should be automatically scaled (e.g., automatically scaled into worker sets 210 and 212), or whether a new worker set should be generated by the worker set instantiator 112.

[0081] At 908, load balancing is performed to start at least one new worker set. For example, the load handler 108 may create new worker sets 210 and 212 required to balance the load.

[0082] At 910 , at least one flow is identified to be moved to at least one new worker set. For example, iFlows 202 a - 202 d may be split among new worker sets 210 and 212 by the load handler 108 .

[0083] In some implementations, identifying at least one flow to be moved to at least one new worker set includes randomly moving the at least one flow. For example, a random one of iFlows 202a-202d may be selected by the load handler 108 to be moved to the new worker sets 210 and 212.

[0084] In some implementations, identifying at least one flow to be moved to at least one new worker set may include performing a pre-calculation to define a complexity metric (e.g., determining the complexity of iFlows 202a-202e that are candidates for reallocation). For example, the complexity may be based on one or more of a plurality of steps in a flow or a plurality of special steps in a flow. Special steps may include, for example, mapping steps and scripting steps. Flows may be distributed across worker sets based on the complexity metric. For example, the complexity of iFlows 202a-202e may determine which of the worker sets 302-306 will contain a particular iFlow in iFlows 202a-202e.

[0085] At 912, a move of the identified at least one process from the current set of workers to the new set of workers is performed. Figure 3 , the load handler 108 can move iFlow_3 202c to the worker set 306.

[0086] Fig.10 is a block diagram of an exemplary computer system 1000 for providing computing functionality associated with the algorithms, methods, functions, processes, flows, and procedures described in this disclosure.

[0087] The illustrated computer 1002 is intended to include any computing device (such as a server, desktop computer, laptop / notebook computer, wireless data port, smart phone, personal digital assistant (PDA), tablet computing device), one or more processors within these devices, or any other suitable processing device, including physical or virtual instances of computing devices (or both). In addition, the computer 1002 may include a computer that includes an input device (such as a keypad, keyboard, touch screen, or other device that can accept user information), and an output device (including digital data, visual or audio information (or a combination of information) or a graphical user interface (GUI)) that conveys information associated with the operation of the computer 1002.

[0088] The computer 1002 can act as a client, a network component, a server, a database or other persistent device, or any other component (or combination of roles) of a computer system for performing the subject matter described in the present disclosure. The illustrated computer 1002 is communicatively coupled to a network 1030. In some implementations, one or more components of the computer 1002 can be configured to operate within an environment, including a cloud-based, local, global, or other environment (or combination of environments).

[0089] At a high level, the computer 1002 is an electronic computing device that is operable to receive, transmit, process, store, or manage data and information associated with the described subject matter. According to some embodiments, the computer 1002 may also include or be communicatively coupled to an application server, an email server, a web server, a cache server, a streaming data server, a business intelligence (BI) server, or other server (or a combination of servers).

[0090] Computer 1002 may receive requests from client applications (e.g., executing on another computer 1002) over network 1030 and respond to the received requests by processing the requests in an appropriate software application. In addition, requests may be sent to computer 1002 from internal users (e.g., from a command console or through other appropriate access methods), external or third parties, other automated applications, and any other appropriate entity, person, system, or computer.

[0091] Each of the components of the computer 1002 may communicate using the system bus 1003. In some implementations, any or all components (hardware or software (or a combination of hardware and software)) of the computer 1002 may interface with each other or interface 1004 (or a combination of both) through the system bus 1003 using an API 1012 or a service layer 1013 (or a combination of the API 1012 and the service layer 1013). The API 1012 may include specifications for routines, data structures, and object classes. The API 1012 may be computer language independent or computer language dependent and refer to a complete interface, a single function, or even a set of APIs. The service layer 1013 provides software services to the computer 1002 or other components (whether or not shown) that are communicatively coupled to the computer 1002. The functions of the computer 1002 may be accessible to all service consumers using the service layer. Software services such as those provided by the service layer 1013 provide reusable defined business functions through defined interfaces. For example, the interface may be software written in JAVA, C++, or other suitable languages, thereby providing data in an extensible markup language (XML) format or other suitable format. Although shown as an integrated component of the computer 1002, alternative implementations may show the API 1012 or service layer 1013 as a separate component associated with other components of the computer 1002 or other components communicatively coupled to the computer 1002 (whether or not shown). In addition, without departing from the scope of the present disclosure, any or all portions of the API 1012 or service layer 1013 may be implemented as a child / sub-module of another software module, enterprise application, or hardware module.

[0092] Computer 1002 includes interface 1004. Although Fig.10 1002, two or more interfaces 1004 may be used depending on the specific needs, desires, or specific implementations of the computer 1002. The computer 1002 uses the interface 1004 to communicate with other systems in a distributed environment connected to a network 1030 (whether or not shown). Typically, the interface 1004 includes logic encoded in software or hardware (or a combination of software and hardware) and operable to communicate with the network 1030. More specifically, the interface 1004 may include software supporting one or more communication protocols associated with the communication, so that the network 1030 or the hardware of the interface is operable to transmit physical signals within and outside the computer 1002 shown.

[0093] Computer 1002 includes processor 1005. Although Fig.10A single processor 1005 is shown in the figure, but two or more processors may be used depending on the specific needs, desires, or specific implementation of the computer 1002. In general, the processor 1005 executes instructions and manipulates data to perform the operations of the computer 1002 and any algorithms, methods, functions, processes, procedures, and procedures described in this disclosure.

[0094] The computer 1002 also includes a memory 1006 that stores data of the computer 1002 or other components (or a combination of both) that may be connected to a network 1030 (whether or not shown). For example, the memory 1006 may be a database that stores data consistent with the present disclosure. Fig.10 Although a single memory 1006 is shown in the computer 1002, two or more memories may be used depending on the specific needs, desires, or specific implementation of the computer 1002 and the described functionality. Although the memory 1006 is shown as an integral component of the computer 1002, in alternative implementations, the memory 1006 may be external to the computer 1002.

[0095] The application 1007 is an algorithmic software engine that provides functionality, particularly with respect to the functionality described in the present disclosure, in accordance with the specific needs, desires, or specific implementations of the computer 1002. For example, the application 1007 may be implemented as one or more components, modules, applications, etc. Furthermore, although illustrated as a single application 1007, the application 1007 may be implemented as multiple applications 1007 on the computer 1002. Additionally, although illustrated as being integrated with the computer 1002, in alternative implementations, the application 1007 may be external to the computer 1002.

[0096] There may be any number of computers 1002 associated with or external to the computer system containing computer 1002, each of which communicates via network 1030. Furthermore, the terms "client," "user," and other appropriate terms may be used interchangeably as appropriate without departing from the scope of the present disclosure. Furthermore, the present disclosure contemplates that many users may use one computer 1002, or that one user may use multiple computers 1002.

[0097] In some implementations, the components of the above environment and system can be any computer or processing device, such as, for example, a blade server, a general-purpose personal computer (PC), a Macintosh, a workstation, a UNIX-based workstation, or any other suitable device. In other words, the present disclosure contemplates computers other than general-purpose computers, and computers without conventional operating systems. Furthermore, the components can be adapted to execute any operating system, including Linux, UNIX, Windows, Mac, or any other operating system. JavaTM 、Android TM , iOS or any other suitable operating system. According to some embodiments, the component may also include, or be communicatively coupled to, an email server, a web server, a cache server, a streaming data server, and / or other suitable servers.

[0098] The processor used in the above environment and system can be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or another suitable component. Generally, each processor can execute instructions and manipulate data to perform operations of various components. Specifically, each processor can perform the functions required to send requests and / or data to components of the environment and receive data from components of the environment, such as communicating between external, intermediate and target devices.

[0099] The above components, environment and system may include one or more memories. The memory may include any type of memory or database module, and may take the form of volatile and / or non-volatile memory, including but not limited to magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. The memory may store various objects or data, including caches, classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, repositories for storing business and / or dynamic information, and any other appropriate information (including any parameters, variables, algorithms, instructions, rules, constraints) for reference associated with the purpose of the target, intermediate and external devices. Other components within the memory are also possible.

[0100] Regardless of the specific implementation, "software" may include computer-readable instructions on a tangible medium, firmware, wired and / or programmed hardware, or any combination thereof (transitory or non-transitory as the case may be), which when executed is operable to perform at least the processes and operations described herein. In fact, each software component may be written or described in whole or in part in any suitable computer language, including C, C++, Java, PHP ... TM , Visual Basic, Assembler, Any suitable version of 4GL, and others. As appropriate, the software may alternatively include multiple sub-modules, third-party services, components, libraries, etc. Conversely, the features and functions of the various components may be combined into a single component as appropriate.

[0101] The device may include any computing device, such as a smart phone, a tablet computing device, a PDA, a desktop computer, a laptop / notebook computer, a wireless data port, one or more processors within these devices, or any other suitable processing device. For example, the device may include a computer including an input device (such as a keypad, a touch screen, or other device that can accept user information), and an output device (including digital data, visual information, or a GUI) that conveys information associated with the components of the above-mentioned environment and system. The GUI interfaces with at least a portion of the above-mentioned environment and system for any suitable purpose, including generating a visual representation of a web browser.

[0102] The accompanying drawings and accompanying descriptions illustrate exemplary processes and computer-implemented techniques. The above environment and system (or its software or other components) may be considered to use, implement or execute any suitable techniques for performing these and other tasks. It should be understood that these processes are only for illustrative purposes, and described or similar techniques may be performed at any appropriate time, including concurrent, separate, parallel and / or combined execution. In addition, many operations in these processes may occur simultaneously, concurrently, in parallel and / or in a different order than shown. In addition, as long as the method remains appropriate, the process may have additional operations, fewer operations and / or different operations.

[0103] In other words, although the present disclosure has been described in terms of certain implementations and generally associated methods, changes and permutations of these implementations and methods will be apparent to those skilled in the art. Therefore, the above description of exemplary implementations does not limit or constrain the present disclosure. Other changes, substitutions, and variations are also possible without departing from the spirit and scope of the present disclosure.

Claims

1. A computer-implemented method comprising: Initially deploy a set of processes to a single set of workers; identifying a load balancing problem associated with an initial runtime interaction of workers with the single set of workers; In response to identifying the load balancing problem, analyzing the load balancing problem to determine whether to automatically scale or generate a new set of workers; Perform load balancing to start at least one new set of workers; Identifying at least one process to be moved to the at least one new set of workers, wherein identifying at least one process to be moved to the at least one new set of workers comprises: performing pre-computation to define a complexity metric; and distributing processes across a set of workers based on the complexity metric; and A move of the identified at least one process from the current set of workers to the new set of workers is performed.

2. The computer implemented method of claim 1, wherein the load balancing problem comprises an out of memory exception.

3. The computer-implemented method of claim 1, wherein the complexity metric is a measure of the complexity of the process, including one or more of a plurality of steps in the process or a plurality of particular steps in the process.

4. The computer-implemented method of claim 3, wherein the special steps include mapping steps and scripting steps. The computer-implemented method of claim 1 , wherein the process represents an integration scenario.

6. A system comprising: a memory storing an information table for integrating scenarios, load balancer rules, and historical information; as well as A server performs operations including: Initially deploy a set of processes to a single set of workers; identifying a load balancing problem associated with an initial runtime interaction of workers with the single set of workers; In response to identifying the load balancing problem, analyzing the load balancing problem to determine whether to automatically scale or generate a new set of workers; Perform load balancing to start at least one new set of workers; Identifying at least one process to be moved to the at least one new set of workers, wherein identifying at least one process to be moved to the at least one new set of workers comprises: performing pre-computation to define a complexity metric; and distributing processes across a set of workers based on the complexity metric; and A move of the identified at least one process from the current set of workers to the new set of workers is performed.

7. The system of claim 6, wherein the load balancing problem comprises an out of memory exception.

8. The system of claim 6, wherein the complexity metric is a measure of the complexity of the process, including one or more of a plurality of steps in the process or a plurality of particular steps in the process.

9. The system of claim 8, wherein the special steps include mapping steps and scripting steps.

10. The system of claim 6, wherein the process represents an integration scenario.

11. A non-transitory computer-readable medium encoded with a computer program, the program comprising instructions that, when executed by one or more computers, cause the one or more computers to perform operations comprising: Initially deploy a set of processes to a single set of workers; identifying a load balancing problem associated with an initial runtime interaction of workers with the single set of workers; In response to identifying the load balancing problem, analyzing the load balancing problem to determine whether to automatically scale or generate a new set of workers; Perform load balancing to start at least one new set of workers; Identifying at least one process to be moved to the at least one new set of workers, wherein identifying at least one process to be moved to the at least one new set of workers comprises: performing pre-computation to define a complexity metric; and distributing processes across a set of workers based on the complexity metric; and A move of the identified at least one process from the current set of workers to the new set of workers is performed.

12. The non-transitory computer-readable medium of claim 11, wherein the load balancing problem comprises an out of memory exception.

13. The non-transitory computer-readable medium of claim 11, wherein the complexity metric is a measure of the complexity of the process, including one or more of a plurality of steps in the process or a plurality of particular steps in the process.

14. The non-transitory computer readable medium of claim 13, wherein the special steps include mapping steps and scripting steps.

Images