System and method for batch and scheduler migration in application environment migration

Abstract

The batch and scheduler migration method evaluates a batch job (412), scans its scheduling mechanisms and components (412a,...,412n), ascertains the amount of change to migrate the batch job (412) to a target batch service (430), and predicts evaluation statistics (302) that provide at least one of a functional readiness (304) and a timeline (306) for completing the migration of the batch job (412). The method generates transformed batch job structures (530a,...,530n) by partitioning the batch job (412) according to the target batch service (430) while preserving the scheduling mechanisms. Further, according to the predicted evaluation statistics (302) and the transformed batch job structures (530a, ..., 530n), it updates the containerized batch service components (532a, ..., 532n) of the target batch service (430) and migrates the batch job (412) to the target batch service (430) by replatforming the updated containerized batch service components (532a, ..., 532n).

Description

Technical Field

[0001] (Field of the Invention) The present disclosure generally relates to the field of computers, and more specifically, the present disclosure provides a system and method for batch and scheduler migration in application environment migration that can automatically migrate batch jobs and related schedulers from an older environment to a newer, faster environment while maintaining structural soundness and quality standards without the user having to spend cumbersome effort and time.

Background Art

[0002] (Background of the Invention) As times change, technology also changes. Since the invention of the wheel, we have now entered an era where we can order our commute on a mobile device. Thus, technology has made a huge leap from the era when computers were as large as a dance hall to the current era when they are as small as a fingernail. We have gradually engraved the technology that helps humanity with multiple applications. In this constantly changing and evolving field of technology, the application environment continues to improve, and there is a need to continuously update applications to meet their more advanced requirements.

[0003] A batch job is a unit of work executed by computing resources. Generally, batch jobs process large amounts of data at once. A job scheduler adjusts the timing of executing batch jobs, for example, based on specific intervals (specific time periods, weeks, months) or specific actions (based on the arrival of a file, the occurrence of an event, the completion of any job). It provides a batch execution environment for computing resources, monitoring, error and recovery capture, output, etc. for executing jobs, and manages job stages such as submission, hold, executable, start, execution, success, or failure. Further, it manages job queuing such as priority, execution hold, load balancing, etc. It also manages event monitoring, i.e., which events to monitor, when to monitor, and how to react to events.

[0004] Conventionally, batch and scheduler in an application environment have been migrated to a newer environment by completely reproducing the batch and scheduler to match the newer environment, but this has been time-consuming and has not provided much benefit to the existing batch and scheduler ecosystem. As the environment updates more quickly, a newer version is released before the batch and scheduler are migrated to the newer environment, leaving insufficient time to manually update all of the batch and schedulers. Additionally, among other things, when migrating batch and schedulers to different environments, there were also its own challenges including ensuring that connections are not lost during the conversion and guaranteeing migrations that are compatible with older and newer environments.

[0005] The adoption of cloud has become mainstream, and companies are leveraging cloud as an important part of their IT strategies. This is evident from the fact that major cloud providers such as AWS, Azure, and GCP have been growing year over year for the past several years. As a first phase, these companies have successfully adopted cloud by developing new applications on cloud using the principles of cloud-native design and hosting batch and schedulers on cloud solutions. Companies that have achieved success are now exploring ways to migrate the rest of their critical applications to the cloud in order to realize the broad benefits of cloud. However, the challenge is that migrating existing applications to the cloud gives rise to another set of problems, such as appropriate cloud migration approaches, balancing of risks, costs and timelines to complete cloud migration, complexity of existing applications, especially old batch and schedulers or applications without SMEs, maximizing savings in total cost of ownership (TCO), and increasing productivity, execution speed, and performance improvements for future releases.

[0006] Migration of batches and schedulers in an application environment requires complex parameters and effort, and due to time shortages caused by regular updates, while dealing with various problems related to batches and schedulers, their connections and components, there is a need to develop a system and method for batch and scheduler migration in application environment migration that can migrate batches and schedulers from one environment to another without the need for manual assistance or with minimal intervention.

Summary of the Invention

[0007] This summary is provided to introduce concepts related to a system and method for batch and scheduler migration in application environment migration, and those concepts are further described in the following detailed description. This summary is neither intended to identify the essential features of the claimed subject matter nor intended to be used to determine or limit the scope of the claimed subject matter.

[0008] In one embodiment, a method for batch and scheduler migration in application environment migration is disclosed. The method includes evaluating a batch job 412 of a source application environment by a processor 122 of an application server 102, and scanning at least one scheduling mechanism and components 412a, ..., 412n of the batch job 412 by the processor 122. The method further includes determining, by the processor 122, an amount of change for migrating the batch job 412 to a target batch service 430, and predicting, by the processor 122, an evaluation statistic 302 that provides at least one functional preparation 304 and timeline 306 for completing the migration of the batch job 412. The method further includes generating, by the processor 122, transformed batch job structures 530a, ..., 530n generated by splitting the batch job 412 according to the target batch service 430 while retaining the scheduling mechanism, and updating, by the processor 122, containerized batch service components 532a, ..., 532n of the target batch service 430 according to the predicted evaluation statistic 302 and the transformed batch job structures 530a, ..., 530n. Thereby, the processor 122 migrates the batch job 412 to the target batch service 430, where the migration replatforms the updated containerized batch service components 532a, ..., 532n.

[0009] In yet another embodiment, the amount of change for migrating the batch job 412 to the target batch service 430 is calculated based on the size and complexity of the batch job 412.

[0010] In yet another embodiment, the transformed batch job structures 530a, …, 530n are generated using a continuous integration and deployment framework 150 and an automated test framework 150.

[0011] In yet another embodiment, the evaluation statistic 302 provides at least one inhibiting factor for completing the migration of the batch job 412.

[0012] In yet another embodiment, the transformed batch job structures 530a,..., 530n are generated according to the target batch service 430 while maintaining the connections between the components 412a, 412b,..., 412n of the batch job 412.

[0013] In yet another embodiment, the transformed batch job structures 530a,..., 530n are identified by the AI engine 152.

[0014] In yet another embodiment, the batch job 412 of the application environment migrates to the target batch service 430, including steps of redevelopment of the environment from the source batch job to the target batch service, refactoring from the source batch job to the target batch service, rehosting from the source batch job to the target batch service, and replatforming from the source batch job to the target batch service.

[0015] In yet another embodiment, the target batch service 430 is a cloud-based batch service ecosystem.

[0016] In another embodiment, the method includes implementing a batch service definition and a service queue by the processor 122 according to the target application environment.

[0017] In another embodiment, the method includes accessing, by the processor 122, application code 202 including business logic, links, rule engines, libraries of available environments, standard tools, and coding languages.

[0018] In one embodiment, a system for batch and scheduler migration in application environment migration is disclosed. The system includes a processor 122 and a memory 126 coupled to the processor 122, and the processor 122 executes a plurality of modules 128 stored in the memory 126. The plurality of modules 128 includes an evaluation module 130 for evaluating a batch job 412 of a source application environment, scanning at least one scheduling mechanism and components 412a, ..., 412n of the batch job 412, and checking the amount of change for migrating the batch job 412 to a target batch service 430. The evaluation module 130 predicts evaluation statistics 302 that provide at least one functional preparation 304 and timeline 306 for completing the migration of the batch job 412. The plurality of modules 128 further includes a refactoring module 132 for generating transformed batch job structures 530a, ..., 530n generated by splitting the batch job 412 according to the target batch service 430 while maintaining the scheduling mechanism. The plurality of modules 128 further includes a refactoring module 132 for generating transformed batch job structures 530a, ..., 530n generated by splitting the batch job 412 according to the target batch service 430 while maintaining the scheduling mechanism. The plurality of modules 128 further includes a replatforming module 134 for updating containerized batch service components 532a, ..., 532n of the target batch service 430 according to the predicted evaluation statistics (302) and the transformed batch job structures (530a, ..., 530n), and migrating the batch job (412) to the target batch service (430). The migration replatforms the updated containerized batch service components (532a, ..., 532n).

[0019] In yet another embodiment, the system has an amount of change for migrating the batch job 412 to the target batch service 430 calculated based on the size and complexity of the batch job 412.

[0020] In yet another embodiment, the system has transformed batch job structures 530a, ..., 530n generated using a continuous integration and deployment framework 150 and an automated test framework 150.

[0021] In yet another embodiment, the system has evaluation statistics 302 that provide at least one inhibiting factor for completing the migration of batch job 412.

[0022] In yet another embodiment, the system has transformed batch job structures 530a, ..., 530n generated according to target batch service 430 while maintaining the connections between components 412a, 412b, ..., 412n of batch job 412.

[0023] In yet another embodiment, the system has transformed batch job structures (530a, ..., 530n) identified by an AI engine (152).

[0024] In yet another embodiment, the system includes migrating batch job 412 of an application environment to target batch service 430, which includes steps of redevelopment of the environment from a source batch job to the target batch service, refactoring from the source batch job to the target batch service, rehosting from the source batch job to the target batch service, and replatforming from the source batch job to the target batch service.

[0025] In yet another embodiment, the system includes target batch service 430, which is a cloud-based batch service ecosystem.

[0026] In another embodiment, the system includes a replatforming module 134 that further includes implementing, by processor 122, a batch service definition and a service queue according to a target application environment.

[0027] In another embodiment, the system further includes a plurality of modules 128 that are executed by the processor 122 to access application code 202 including business logic, links, rule engines, a library of available environments, standard tools, and coding languages.

[0028] A main object of the subject matter is to provide a system and method for batch and scheduler migration in application environment migration that can be used to migrate an application from one platform to another. More specifically, it can be used to migrate batches and schedulers from an older environment to a newer environment. The system and method for batch and scheduler migration in application environment migration can be customized based on the batches and schedulers to be migrated, as well as the older environment in which the batches and schedulers were developed and the newer environment to which the batches and schedulers are being migrated.

[0029] Another object of the subject matter is to provide batch and scheduler migration in application environment migration that accommodates multiple batches and schedulers while maintaining the connection of the multiple batches and schedulers. Further, the system and method for batch and scheduler migration in application environment migration may enable the selected batches and schedulers to be migrated from a wide range of environments to another wide range or ecosystem environment.

[0030] Another object of the subject matter is to provide a system and method for batch and scheduler migration in application environment migration that migrates batches and schedulers in an automated manner, either without requiring manual input or in a hybrid manner including automated and manual steps.

[0031] Another object of the subject matter is to provide batch and scheduler migration in application environment migration that eliminates repeatable patterns of work done by the development team, thereby reducing costs, and thereby reducing the time and effort spent by the development team to migrate batches and schedulers from older environments to newer environments.

[0032] Another object of the subject matter is to provide batch and scheduler migration in application environment migration that enhances control of inter-service communication, improves performance and scalability, improves reliability and efficiency, and ensures that data is transmitted securely.

[0033] Another object of the subject matter is to provide batch and scheduler migration in application environment migration that can be used to migrate source / legacy batch jobs and scheduler mechanisms, including but not limited to batch jobs, to cloud-based general batches and schedulers, including but not limited to Spring Batch, Azure Batch, AWS Batch, Azure Logical App, etc.

[0034] Another object of the subject matter is to provide batch and scheduler migration in application environment migration that migrates batches and schedulers from older environments to newer environments by reducing implementation costs, reducing total cost of ownership to increase profitability, improving execution speed, improving application performance, and improving application productivity.

[0035] Another object of the subject matter is to provide many advantages depending on specific aspects, embodiments, implementations and / or configurations.

[0036] Another object of the subject matter is to provide a platform that can provide reliable execution, scalability, and value-added services while reducing the labor and cost of operation.

[0037] Another object of the subject matter is to efficiently manage multiple instances simultaneously, work with various regulatory requirements, and enable resources to collaborate and cooperate closely, efficiently, and collectively with a user-friendly interface.

[0038] These and other embodiments, implementations, processes, and features of the subject matter will become more fully apparent upon reading the following detailed description together with the accompanying experimental details. However, neither the foregoing summary of the subject matter nor the following detailed description thereof represents any one potential embodiment or implementation, nor is it intended to limit the present disclosure or other alternative embodiments or implementations of the subject matter.

Brief Description of the Drawings

[0039] A clear understanding of the main features of the subject matter summarized above can be obtained by referring to the accompanying drawings showing the methods and systems of the subject matter. However, it is understood that such drawings show the preferred embodiments of the subject matter and, therefore, are not to be considered as limiting the scope with respect to other embodiments that the subject matter can contemplate. Therefore,

[0040]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0041] (DETAILED DESCRIPTION OF THE INVENTION) The following is a detailed description of embodiments of the present disclosure depicted in the accompanying drawings. The embodiments are such details in order to clearly convey the present disclosure. However, the amount of detail provided is not intended to limit the embodiments, but is intended to cover all modifications, equivalents, and alternatives within the spirit and scope of the present disclosure. The described aspects of the systems and methods for batch and scheduler migrations in application environment migration may be implemented in any number of different computing systems, environments, and / or configurations, but the embodiments are described in the context of the following exemplary system(s).

[0042] The present disclosure provides cloud replatforming of batch and scheduler from a source application environment's source batch jobs and related schedulers to a target application environment's target batch services and corresponding schedulers. Cloud replatforming of batch and scheduler involves migrating existing on-premises batch and scheduler to the cloud and leveraging cloud scalability and flexibility to efficiently operate the source batch jobs and related schedulers of the source application environment. Also, the source batch jobs and related schedulers of the source application environment structure are changed to reduce their total cost of ownership (TCO), which includes adopting more open-source and cloud-friendly software to reduce the license costs of virtual machines, application servers, and databases. The actual TCO reduction varies depending on the batch and scheduler and is determined after evaluating the source batch jobs and related schedulers. The present disclosure lists some important steps executed by the batch and scheduler, which vary depending on the batch and scheduler and can modify the existing batch and scheduler to function effectively on Cloud Platform or PaaS. However, all blockers related to the source and on-premises design patterns are changed, and all underlying links, dependencies, connections, and libraries are updated so that the source batch and related schedulers are compatible with containers or PaaS, application servers (such as Weblogic, WebSphere, JBoss), and the database can be replaced with open-source cloud-friendly software, the monolithic application can be separated into smaller microservices for efficiency and speed, and the source batch jobs and related schedulers can be transformed and replatformed with target cloud-based batch services and schedulers.

[0043] The present disclosure provides a mechanism for cloud platforming by simple containerization, including removing all code blockers that prevent containerization, deploying the source application into containers such as Docker and running it on the cloud. Further, the source application release process, including test case and CI / CD automation, is also automated. Additionally, the TCO of these applications can be reduced by re-platforming the source application and / or source database to lightweight open-source servers such as Tomcat for JAVA applications and legacy DB2 databases, reducing license costs and cloud computing costs. However, to ensure stability and performance, it is necessary to split the monolithic application into smaller services or refactored database structures or transformed message brokers, or transformed batches and schedulers to make all of these applications stateless and deploy them into separate containers while deploying them to separate Tomcat servers. In this way, the source application is migrated to the target application platform by decoupling the monolithic application and exposing it through APIs using the concept of microservices to make it a cloud-ready application. At the same time as splitting the monolithic application into microservices, CI / CD is also implemented to achieve fast and automated deployment. It performs batch and scheduler platforming, which includes transforming the source batch jobs and related schedulers into target batch services such as Spring Batch, Azure Service Bus, Azure Event Hubs, and AWS SNS. The following shows the structure for each component and the method for each step.

[0044] FIG. 1 shows a schematic module diagram 100 illustrating a method for batch and scheduler migration in application environment migration according to an embodiment of the present subject matter.

[0045] In one embodiment, batch and scheduler migration in an application environment migration system 120 implements a method for batch and scheduler migration in the application environment migration system on server 102, and system 120 includes a processor(s) 122, an interface(s) 124, a framework(s) 150, an AI engine 152, and a memory 126 coupled to the processor(s) 122. The processor(s) 122 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that operates signals based on batch and scheduler migration instructions. In particular, the processor(s) 122 is configured to fetch and execute computer-readable instructions stored in the memory 126. The framework 150 includes, but is not limited to, a continuous integration and continuous deployment framework, an automated test framework, and the like. The AI engine 152 includes, but is not limited to, a database (DB) replatforming engine, an app replatforming engine, a batch and scheduler replatforming engine, an open-source AI engine, and the like.

[0046] Although the present disclosure is described in the context of a scenario where the system is implemented as an application on a server, the system and method can be implemented on various computing systems. Computing systems that can implement the described method(s) include, but are not limited to, mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops, tablets, SCADA systems, smartphones, mobile computing devices, and the like.

[0047] The interface(s) 124 can include various software and hardware interfaces, such as, for example, a web interface, a graphical user interface, etc., enabling the system 120 to interact with a user. Further, the interface(s) 124 can enable the system 120 to communicate with other computing devices, such as a web server and an external data server (not shown). The interface(s) 124 can facilitate multiple communications within a wide variety of network and protocol types, including, for example, wired networks such as LAN, cable, and wireless networks such as WLAN, cellular, or satellite. The interface(s) 124 can include one or more ports for connecting a number of devices to each other or to another server.

[0048] The network used for communication between all elements of the application server and the cloud environment may be any of a wireless network, a wired network, or a combination thereof. The network may be implemented as one of various types of networks, such as an intranet, a local area network LAN, a wide area network WAN, the Internet, etc. The network may be a dedicated network or a shared network. A shared network represents an association of different types of networks that communicate with each other using various protocols, such as the Hypertext Transfer Protocol HTTP, the Transmission Control Protocol / Internet Protocol TCP / IP, the Wireless Application Protocol WAP, etc. Further, the network may include various network devices, such as routers, bridges, servers, computing devices, etc. The network further has access to storage devices located, for example, on a client site computer, a host site server or computer, in the cloud, or a combination thereof. The storage has one or more local and remote computer storage media including, for example, one or more memory storage devices, databases, etc.

[0049] Memory 126 may include any computer-readable medium known in the art, including, for example, volatile memory (e.g., RAM), and / or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, memory 126 includes module(s) 128 and system data 140.

[0050] Module 128 further includes an evaluation module 130, a refactoring module 132, a replatforming module 134, and other modules 136 including, but not limited to, a blocker evaluation module, a script generator module, etc. The script generator module further includes, but is not limited to, a test case generator, a build script generator, a Docker script generator, a pipeline script generator, a deployment script generator, etc. It is understood that such modules may be represented as a single module or as a combination of different modules. Further, the memory 126 further includes system data 140 that functions as a repository for storing data fetched, processed, received, and generated by one or more modules 128. The system data 140 includes, for example, operational data, workflow data, and other data in the storage 144. The system data 140 has a storage 144 that is optionally represented by 144a, 144b,..., 144n. In one embodiment, the system data 140 can access other databases via a web or cloud network. The storage 144 includes a plurality of databases including, but not limited to, evaluation module data, refactoring module data, replatforming module data, libraries, link identifiers, database adapters, database dictionaries, database parsers, technical dictionaries, file adapters, application parsers, pattern recognizers, open source libraries, technology stacks, etc. It is understood that such databases may be represented as a single database or as a combination of different databases. In one embodiment, the data can be stored in the memory 126 in the form of a data structure. Further, the aforementioned data can be organized using a data model such as a relational data model or a hierarchical data model.

[0051] Server 102 is further connected to a cloud environment 110 having a plurality of computing systems including, but not limited to, target application environment servers 104 and 106, and a database including, but not limited to, database 108. The computing systems and databases communicate with each other under the rules of cloud computing and it is essential to communicate with server 102 under the web or other available communication media / protocols. Computing system 104 is generally a distributed processing system including a plurality of computing devices connected by a network and communicating via the network. Software applications can be run "in the cloud" by configuring them to run across one or more computing devices within a particular cloud computing system. The computing devices of the cloud computing system may each run a separate copy of the software application, or, in some cases, may split and run the operations of the software application in parallel among different computing devices. The cloud computing system may include a plurality of cloud computing instances representing the resources available for the execution of an application. Each instance may be a physical computing device with a particular capability (such as storage size, processing speed, network bandwidth, etc.) or a virtual computing device with a particular capability. A particular cloud computing system may provide instance types with various sets of functions for running software applications.

[0052] In one embodiment, first, a user, including but not limited to a migration specialist, a database administrator, an application developer, a quality analyst, or a test specialist, can access the system 120 via the interface 124 using the server 102 using a user access device. The system 120 and related methods and related modules, sub-modules, and operations of the method can be described in detail using FIGS. 2, 3, 4, 5, 6, and 7 described below.

[0053] In one embodiment, the system 120 receives user instruction data by the interface 124 on the server 102. The module 128 of the system 120 processes the instructions using the processor 122 while using the system data 140, other modules 136, the framework 150, and support components. An evaluation module 130 for batch and scheduler migration in application environment migration is utilized before starting batch and scheduler migration from one environment to another.

[0054] The evaluation module 130 executes the evaluation of the batch job 412 in the source application environment, scans at least one scheduling mechanism and components 412a, 412b, ..., 412n of the batch job 412, and while confirming a detailed understanding of the amount of changes and the amount of changes that the source batch job and related scheduler in the source application environment must undergo, evaluates the risks, costs, timelines, and impacts of the changes on other dependent applications for migrating the batch job 412 to the target batch service 430. The evaluation module 130 predicts the evaluation statistics 302 that provide at least one functional preparation 304 and timeline 306 for completing the migration of the batch job 412. The evaluation module 130 understands the underlying connections and dependencies developed by various developers with various styles. Further, the predictive evaluation report 302 generated by the evaluation module 130 using the AI engine 152 provides deep details including the required timeline, the proportion of components / structures that need to be changed, multiple preparation parameters, warnings with multiple inhibitors or code blockers and reasons, highlighted parts that need to change batch and scheduler components, the number of services into which the monolith can be split, the types of services into which the monolith can be split, and batch and scheduler preparations for continuous integration and continuous deployment, but not limited to these. The evaluation report 302 generated by the evaluation module 130 provides an accurate estimate and timeline for completing the migration of the source batch job and related scheduler in the source application environment. In one embodiment, the RPA bot is configured to generate the evaluation report 302 using a proactive batch and scheduler migration of the Application Environment Migration Prediction (PAEMF) algorithm. In one embodiment, the RPA bot is a software bot, or a combination of a software bot and a hardware bot. In one embodiment, the software bot is a computer program that enables a processor to execute robotic process automation using AI.In another embodiment, the bot is a combination of hardware and software, and the hardware includes dedicated memory, processors, controllers, and other related chip sets for performing functions that enable robotic process automation, particularly for batch and scheduler migrations in application environment migrations.

[0055] The refactoring module 132 for batch and scheduler migrations in application environment migrations supports automated replatforming from source batch jobs and related scheduler migrations in application environment migrations to target batch services and related scheduler migrations in application environment migrations by generating a transformed batch job 550 having structures 530a, 550b, …, 530n that are generated by splitting the batch job 412 according to the target batch service 430 while maintaining the scheduling mechanism. The refactoring module 132 generates the transformed batch job structures 530a, …, 530n using a continuous integration and deployment framework 150, an automated test framework 150, and middleware replatforming and environmentally friendly design patterns.

[0056] Replatforming module 134 for batch and scheduler migration in application environment migration supports automated replatforming for source batch jobs and related scheduler migration in application environment migration to the target application environment to convert the batch and scheduler from one environment to another based on the size and complexity of the batch and scheduler. The replatforming module 134 updates the containerized batch service 532 with containerized batch service components 532a, ..., 532n of the target batch service 430 according to the predicted evaluation statistics 302 and the converted batch job structures 530a, ..., 530n, migrates the batch job 412 to the target batch service 430, where the migration replatforms the updated containerized batch service components 532a, ..., 532n. The replatforming module 134 also performs activities including, but not limited to, integrating the patterns of the source application environment with the design patterns of the target application environment, fine-tuning the code, resolving deployment issues, and implementing security to ensure that the migrated application functions fully. The replatforming module 134 supports multiple forms of environment migration including, but not limited to, rehosting environment migration, batch job and scheduler replatforming, batch job and scheduler refactoring, and native batch job and scheduler development.

[0057] Any application, such as a blocker evaluation module of another module 136 or a monolithic web application with an on-premises design pattern, can be input into the system and method for batch and scheduler migration in application environment migration. The blocker evaluation module of the system and method for batch and scheduler migration in application environment migration can discover the pattern of the on-premises design pattern of the monolithic web application. Further, this information can be transferred to the automated replatforming module of the system and method for batch and scheduler migration in application environment migration, as shown in FIG. 1.

[0058] The reference architecture of system 120 further has support components such as a test generator - the test generator generates test cases for unit, functional, and performance test cases for the generated APIs. A build script generator - the build script generator generates scripts for successfully building and running an application. A Docker script generator - the Docker script generator generates scripts for containerizing an application and its dependencies. A pipeline script generator - the pipeline script generator generates scripts for creating CI / CD pipelines for development, test, and production environments. A deployment script generator - the deployment script generator generates scripts for deploying an application to a target environment. A database adapter - the database adapter utility establishes connections to multiple database servers such as IBM DB2, Oracle, Microsoft SQL Server, Sybase ASE, PostgreSQL. A database dictionary - the database dictionary contains a vast number of database-related keywords and built-in functions used in the above-mentioned multiple database servers. A database parser - the database parser uses the database dictionary to analyze database objects and find patterns that are incompatible with the target database. An AI engine - the AI engine identifies existing and potential macro / micro services within legacy applications.Batch and scheduler Re-platform Engine - The batch and scheduler re-platform engine re-platforms source batch jobs and related scheduler objects, such as definitions, scheduling mechanisms, queues, etc., to target batch services and related scheduler-compatible objects. File Adapter - The file adapter provides access to the source files of the application. The files are scanned to create reports and are ultimately re-platformed as the target application. Technology Dictionary - The technology dictionary contains a vast number of technology-related patterns used within monolithic applications. Application Parser - The application parser uses pattern recognizers to analyze the application source code and find the entire inventory of technologies used by the application. This inventory is used for evaluation and re-platforming. Pattern Recognizer - The pattern recognizer recognizes patterns based on the technology dictionary to find the technologies used in the application. App Re-platform Engine - The app re-platform engine re-platforms the source application analyzed by the application parser. This engine generates applications ready to be deployed to the cloud. The Technology Stack includes, but is not limited to, JAVA 1.8, Maven, JUnit, NUnit, XUnit JMeter, Docker Jenkins, AWS CLI, Azure CLI, etc.

[0059] FIG. 2 shows a flowchart 200 illustrating the operation of an exemplary batch and scheduler migration system in an application environment migration system according to an embodiment of the present subject matter.

[0060] The present disclosure shows two important activities which are the source application environment evaluation and the source batch job and related schedule transformation to a desired target platform. These two activities are described in the following flowchart 200.

[0061] In one embodiment, a monolithic web application 202, such as a JAVA application or a.NET application, which is the source application of the source application environment, is the source application of the source application environment. The monolithic web application 202 is linked to various support components 204 including, but not limited to, databases, batches, integrations, applications, schedulers, on-premises ecosystem components, etc. The functions of the source batch job and the related scheduler 412 of the source ecosystem components linked to the source application environment are further described.

[0062] In the initial step, the Cloud Blocker Assessment 206 evaluates the source application and generates an assessment report 212 that includes code impairments, source code insights, and on-premises design patterns 214. The Cloud Blocker Assessment 206 also evaluates the source application, batches, and schedulers, scans the connections of the batches and schedulers, and generates an assessment report 212 that includes the batch job list, its connections, related scheduler mechanisms or rules, links, and dependencies. The on-premises design patterns 214 include, but are not limited to, EJB, RMI, STRUTS / SPRING, SOAP / XML, JSP / ASP, COM / COM++, ESB, etc. The evaluation of the source application includes the current application's technology stack and code analysis. The evaluation provides automated insights into the time, effort, and risks associated with the replatforming of the source application, source database, source batch jobs, and related schedulers, as well as other supporting components (but not limited to) such as message brokers. The evaluation includes the analysis of source batch jobs, related schedulers, and components, where an automated evaluation is performed on the source batch job 412 and the related scheduler that includes links, connections, and other dependencies, and inhibitors or blockers (such as packages / frameworks / APIs / libraries) that would fail the containerized cloud migration of the batch and scheduler preparation parameters are identified, thereby providing a detailed assessment report 212. This code evaluation is performed across the entire source application ecosystem that includes the application, database, batch jobs and their schedulers, integration and message brokers, build and deployment modules. The Cloud Blocker Assessment 206 will come to deeply understand the amount of change that the source application environment must undergo in order to assess the risks, costs, timelines, and impacts on other dependent components and applications.The report mainly provides the percentage of code that needs to be changed, code readiness, blockers and warnings and their reasons, the exact locations where code changes are needed, the number of services that can decompose the monolith, DevOps and CI / CD readiness, and the timeline for such implementation.

[0063] In the next step, an automated batch and scheduler conversion / refactoring 208 for the re - platforming of applications and support components from the source environment to the target environment is executed to generate cloud - ready applications and support components 210 such as Azure Batch from batch jobs, while maintaining the connection of source batch jobs and related schedulers in the target application environment, and after converting / refactoring the continuous integration and deployment framework 216, the automated test framework 218, the middleware re - platforming 220, and the source batch jobs and related schedulers of the source application environment into a cloud - friendly design pattern 222, which consists of a JAVA application or a.NET application, an Oracle database or a DB2 database, an IBM MQ message broker. Sub - steps of the automated refactoring 208 are to update batch and scheduler connections, dependencies, links and other support components, separate front - end and back - end, convert all batch jobs, their components and related scheduler mechanisms from source batch jobs to cloud - friendly batch services, and the corresponding schedulers such as Azure Batch, Spring Batch, AWS Batch, Azure Logical App. All components, connections, definitions, queues are transformed to operate with the target batch service and related schedulers, achieving the same desirable results as the source batch jobs and related schedulers. When the conversion of batch and scheduler components is complete, it is the step of splitting the source batch jobs and related schedulers into fine - grained components based on the design of the target application environment, fine - tuning code rules, resolving deployment issues, and implementing security that is completed by a consultant to fully function the target application, database, batch and scheduler.In one example, Tables A and B can be used to illustrate exemplary code conversion as an example.

[0064]

Table A

[0065]

Table B

[0066] Furthermore, batch and scheduler cloud refactoring involves several iterative steps such as analysis of batch and scheduler components, refactoring, library updates, compilation of build scripts, deployment scripts, containerization scripts, etc. This results in a significant improvement in time to market, which then reduces the overall cost and can achieve high-quality refactoring.

[0067] Figure 3 shows an exemplary evaluation report 302 automatically generated by an exemplary batch and scheduler migration system in an application environment migration system according to an embodiment of the present subject matter.

[0068] In one embodiment, after evaluating a source application environment including code defects, source code insights, database links, connections, batch and scheduler dependencies, batch and scheduler applications, on-premises design pattern 214, etc., the evaluation module 130 generates an evaluation report 302 in an exemplary view 300. The evaluation report 302 provides automated insights into the time, effort, and risks associated with refactoring the source application environment.

[0069] The evaluation includes analysis of the source batch job and related scheduler, i.e., the batch and scheduler, as well as batch and scheduler components, where it performs an automated evaluation and scan of the source batch job and related scheduler including connections and other dependencies, identifies inhibitors or blockers (such as packages / frameworks / APIs / libraries) that would fail cloud migration of the batch and schedule and preparation parameters, thereby providing a detailed evaluation report 302. It evaluates which on-premises batch and scheduler are being used and what messages it is passing within the components of the application, and also evaluates the compatibility and risks associated with cloud-based batch and scheduler or re-platforming to the target. Report generation is an automated process with some user configurations based on the source application and target application environments.

[0070] The evaluation report 302 obtains a deep understanding of the amount of change that the source batch job and related scheduler must pass through in order to evaluate risks, costs, timelines, and other dependent components as well as the impact on batches and schedulers, in the form of preparation parameters 304 and visual configurations 306. The amount of change is the sum of all changes required for batch and scheduler migration. The evaluation report 302 has various sections, and some exemplary figures for the application snapshot include parameters such as containerization preparation 304a, replatforming preparation 304b, DevOps preparation 304c, macro / micro API preparation 304n, batch app preparation 304n, scheduler replatforming preparation 304n, DB replatforming preparation 304n, cloud message broker preparation 304n, cloud batch processing service preparation 304n, etc. Each parameter displays the preparation status in percentages (%) or the like to indicate how much preparation completion status and / or how much non-prepared / blocking / inhibiting factor status there is for each parameter.For example, containerization preparation 304a indicates the container preparation rate with the preparation status and the required refactoring / inhibiting factor rate, replatform preparation 304b indicates the Tomcat preparation rate with the preparation status and the required refactoring / inhibiting factor rate, DevOps preparation 304c indicates the CD preparation rate with the preparation status and the CI preparation / inhibiting factor rate, macro / micro API preparation 304n indicates the macro API existing pointer with the preparation status and the existing / inhibiting factor status of the micro API, batch app preparation 304n indicates the replatform preparation rate with the batch app preparation status and the required refactoring blocker / inhibiting factor rate, the replatform preparation of the scheduler 304n indicates the replatform preparation rate with the AWS batch preparation status and the Azure Logic App preparation / inhibiting factor rate, the DB replatform preparation 304n indicates the replatform preparation rate with the PostgreSQL preparation status and the required refactoring blocker / inhibiting factor rate, the cloud message broker preparation 304n indicates the replatform preparation rate with the target Amazon MQ preparation status and the required refactoring blocker / inhibiting factor rate, and the cloud batch processing service preparation 304n indicates the replatform preparation rate with the target Azure Batch service preparation status and the required refactoring blocker / inhibiting factor rate, etc. One of the other sections of the report 302 has visual configurations 306 such as the database object spread [#Objects] 306a, the spread of database objects [#LoC] 306b, the platform configuration by Number 306n, the platform configuration by LoC 306n, etc.In one example, the database object spread [#Objects] 306a represents the spread or count or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables, the database object spread [#LoC] 306b represents the spread or count or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables, the platform configuration by number 306n represents the spread or count or percentage of JMS, XML configuration, web services, Maven build, configuration, HTML, servlets, style sheets, reactJS, JSP, Junit, POJOs, and the platform configuration by LoC 306n represents the spread or count or percentage of JMS, XML configuration, web services, Maven build, configuration, HTML, servlets, style sheets, reactJS, JSP, Junit, POJOs, etc.

[0071] Furthermore, the various sections of the assessment report 302 provide the following information sections, an application snapshot consisting of the frameworks / libraries / packages used, application containerization readiness, application server replatforming readiness to a Tomcat or Kestrel application server, database server replatforming readiness to PostgreSQL, etc., containerization readiness (to Docker / Kubernetes), batch and scheduler readiness for Amazon MQ cloud batches and schedulers, CI / CD readiness (unit / functional / performance test cases, build and continuous integration, available automation), macro and micro API candidates, API readiness (existing and potential APIs within the application).

[0072] In the current method, the end-to-end conversion function is provided by evaluating the source application environment, then they are converted to the cloud using cloud-friendly design patterns, and finally, the entire process is managed by providing transparent visibility for quick decision-making to stakeholders and decision-makers. All application dependencies, from database to batch programs, and from scheduler to message brokers, are comprehensively converted to the cloud. In the application analysis section of the evaluation report 302, the method analyzes the entire source application to identify blockers in the source code that contain design patterns that inhibit cloud migration. All dependencies are also analyzed, and an overall view is provided for design and planning purposes. It discovers and analyzes the inventory of application components, technology stack and its dependencies, identifies the business, data services and their API readiness of the application, identifies the blockers for containerization and cloud platforming & DevOps readiness, and identifies efforts for changes such as from JAVA vX.X to JAVA v1.8; from EJB (Session Bean / Entity Bean / MDB) to Spring Boot Service with Spring Framework (Pojo); from.NET vX.X to.NET Core v2.2, from IMB MQ to Amazon MQ, from batch jobs to Spring batch (as an example).

[0073] In the database analysis section of the evaluation report 302, the method analyzes the database to analyze and discover the database inventory, data object details, and database size, identify database replatforming readiness and blockers, identify application blockers and dependencies for database replatforming, and identify efforts for changes from Oracle / SQL Server / DB2 / Sybase to Postgres / MySQL, etc. In the batch & scheduler analysis section of the evaluation report 302, the method analyzes the batch & scheduler to analyze and discover the batch program inventory and batch scheduler, prepare the batch scheduler replatforming, identify blockers and dependencies, identify application batch services for batch replatforming, and identify efforts for changes from Autosys / ControlM to AWS Batch (AWS Cloud) / Azure Logic App (Azure Cloud) / Quartz (Private Cloud), etc. In the batch and scheduler analysis section of the evaluation report 302, the method analyzes the batch and scheduler to analyze and detect the batch and scheduler inventory and messaging objects, prepare the batch and scheduler replatforming, identify blockers and dependencies, identify application blockers and dependencies related to batch and scheduler replatforming, and identify efforts for changes to Azure Batch, etc.

[0074] Figure 4 shows an exemplary diagram 400 of exemplary batch and scheduler migration in an application environment migration method according to an embodiment of the present subject matter.

[0075] In one embodiment, an application deployment view 400 with pre- and post-replatforming is depicted using a method and system for source batch jobs and related scheduler migrations in application environment migration to a target application environment according to embodiments of the present subject matter. A monolithic application generally belongs to a source application environment resident or accessible by server 102 and is converted or migrated to a modernized replatformed application belonging to a target application environment resident or accessible by cloud environment 110. First, upon migration from the source application to the target application, code evaluation 206 is performed. By evaluating the application, code that inhibits containerization is removed and the amount of code changes necessary for modification is determined. The migration is performed in the following steps, and an application web server having an application accessible by server 102 is optionally converted to web front instances 422a, 422b, ..., 422n. The application server (IIS cluster) 202 is further refactored into an API management layer 426 having various App macro service instances 426a, 426b, 426c, ... 426n. The macro service instances are based on the size and complexity of the source application. In one embodiment, the refactoring module 132 performs factoring and repackaging 208 of the macro services in the target application environment.

[0076] The source application database 204 is also refactored into fine-grained database components 424a, 424b, 424c, …, 424n of the re-platformed target database 424 in the PaaS / CaaS cluster 424a. The web front instances 422a, 422b, ..., 422n and the macro service instances 426a, 426b, 426c, ..., 426n are further linked to components including but not limited to the service mesh, AKS cluster, App service, ACI, etc. in the cloud computing environment 110. In one embodiment, the source Oracle database is migrated to a PostgresSQl database along with the container / orchestration platform in the cloud environment 110.

[0077] The virtual machine instances 408a, 408b, ..., 408n of the source application are migrated to the container cluster in the cloud environment 110. Thus, the on-premises data center 410 of the source application environment 410 with the on-premises ecosystem 412 is re-platformed / migrated to the private / public cloud 428 in the cloud environment 110. In one embodiment, the components 412a, 412b, 412c, 412d, 412e..., 412n of the on-premises ecosystem 412 including but not limited to EBS, caching, local file, rule engine, message broker, batch and scheduler, authentication protocol, security platform, etc. are re-platformed / migrated to the private / public cloud 428 of independent or standard services / target components 430a, 430c, 430d, 430e, 430f, 430g, ···, 430h including but not limited to Azure Batch, Azure Logical App, AWS Batch service, Spring Batch, Azure Queue, Event Hub, Service Bus, AppInsights, Redis Cache, Storage, Vnet, Azure AD, etc.

[0078] In one embodiment, the method modifies existing on-premises applications to operate efficiently on the cloud using containers or PaaS, updates or changes all blockers related to source code and design patterns, and all underlying libraries to make them compatible with containers or PaaS, replatforms the application server and database to reduce TCO, and the monolithic application can be split into services to improve efficiency and speed.

[0079] In one example, Table C can be used as an example to illustrate replatforming migrations.

[0080]

Table C

[0081] In one embodiment, the current state goes up to a monolithic web application with session EJB calls having some data services from a JSP-based UI and a commercial application server, with session persistence and stateful services being the current state, and the migrated future state is a separated web application with a JSF WebFront and RESTful Spring Boot microservices (independent scaling) on a container via an API gateway.

[0082] FIG. 5 shows an exemplary diagram 500 of exemplary batch and scheduler migrations in an application environment migration method according to an embodiment of the present subject matter.

[0083] Cloud-native applications can complete a large number of tasks by converting batch jobs into small, independent components, migrating them to self-standing containers, and running them in parallel. It can take advantage of the inherent benefits of cloud computing, including time reduction, flexibility, scalability, and rapid deployment. Using a cloud-based batch and scheduling system, it can easily and efficiently execute thousands of batch jobs, dynamically and optimally provision the amount and type of computing resources based on the quantity and requirements of the batch jobs, and there is no need to install or manage batch software or server clusters, thus obtaining advantages compared to on-premises systems.

[0084] A batch job is a computer program or set of programs that are processed in batch mode, such as batch job 412. This means that a series of commands to be executed by the operating system are listed in a file (often called a batch file, command file, job script, or shell script) and submitted as a single unit for execution. These are jobs that can be run without end-user intervention or scheduled to run as long as resources permit. Batch processing is for frequently used programs that can be executed with minimal human intervention. Any job control language notifies the operating system of which program is to be executed, which files are needed by the program during execution, who (the submitter of the batch job), which programs to execute, where the input and output are located, and when the job is to be executed. It is like a manager of jobs waiting in a queue. It manages the priorities of a series of jobs and their associated input data and output results. Generally, there are two consecutive steps: editing and execution. A batch job scheduler is an application that executes batch jobs, schedulers, their components, and batch services. Most batch schedulers support multiple operating systems and platforms and define batch jobs and their schedules. A batch service is a cloud-based job scheduling and computing management platform that enables large-scale parallel and high-performance computing applications, such as target batch service 430, to be efficiently executed in the cloud. In one example, the Azure Batch service provides job scheduling and automatic scaling and management of the virtual machines that execute those jobs.

[0085] In one embodiment, an application deployment view 500 with pre- and post-replatforming is depicted using a method and system for source batch job and associated scheduler migration in application environment migration to a target application environment according to an embodiment of the present subject matter. A monolithic application generally belongs to a source application environment resident or accessible by a server 102 and is converted or migrated to a modernized replatformed application belonging to a target application environment resident or accessible by a cloud environment 110.

[0086] In one embodiment, a method for batch and scheduler migration in application environment migration is disclosed. The method includes evaluating a batch job 412 of a source application environment by a processor 122 of an application server 102, and scanning at least one scheduling mechanism and components 412a, ..., 412n of the batch job 412 by the processor 122. The method further includes determining an amount of change for migrating the batch job 412 to a target batch service 430 by the processor 122, and predicting an evaluation statistic 302 that provides at least one functional preparation 304 and a timeline 306 for completing the migration of the batch job 412 by the processor 122. The method further includes generating transformed batch job structures 530a, ..., 530n generated by splitting the batch job 412 according to the target batch service 430 while retaining the scheduling mechanism by the processor 122, and updating containerized batch service components 532a, ..., 532n of the target batch service 430 according to the predicted evaluation statistic 302 and the transformed batch job structures 530a, ..., 530n. Thereby, the processor 122 migrates the batch job 412 to the target batch service 430, where the migration replatforms the updated containerized batch service components 532a, ..., 532n.

[0087] First, regarding cloud replatforming, the method accesses an on-premises ecosystem 412 having batches and schedulers, or source batch jobs and related schedulers 412 having components such as definitions and queues, and components 412a, 412b, …, 412n of the on-premises ecosystem 412 including but not limited to EBS, cache, local files, rule engines, message brokers, authentication protocols, security platforms, etc., and is replatformed to a target batch service and related scheduler 430 having target components 430a, 430b, 430c, 430d, …, 430n including but not limited to Spring Batch, Azure Batch, Azure Logical App, AWS Batch service, Azure Queue, Event Hub, Service Bus, AppInsights, Redis Cache, storage, Vnet, Azure AD, AWS SNS, Amazon MQ, Azure Service Bus, Azure Event Hubs, etc. The method obtains a complete inventory of batch jobs and batch job components, such as the size and complexity of definitions, queues, connections, source batch jobs and related schedulers, and the compatibility and risks associated with replatforming to a cloud-friendly target batch service and related scheduler 430 like Azure Batch, and performs an evaluation 502 that conducts and executes an evaluation to divide the monolith into fine-grained containerized components. When this evaluation is complete, the evaluation step 502 generates an interactive HTML evaluation report 302 with a drill-down function in a format that is easy for technical and business users to consume.The evaluation report checks the amount of change for migrating the source batch job, scheduler, and components 412a, 412b, …, 412n to the target batch service and related scheduler 430, and predicts evaluation statistics 302 that provide the functional readiness parameters, inhibitors, and timeline for completing the migration of the batch job, scheduler, and components 412a, 412b, …, 412n. The evaluation report 302 is used by the database architect and application SMEs to consider the design of the newly replatformed database and corresponding applications by reviewing the provided cloud batch and scheduler service readiness among other parameters.

[0088] In the next batch job and scheduler conversion steps for performing batch and scheduler replatforming 504, the method performs the following two main functions. First, while retaining the scheduling mechanism, it generates transformed batch job structures 530a, 550b, ..., 530n by splitting the source batch job 412 according to the target batch service 430. The transformed batch job 530 includes the creation of small independent components 530a and priority and sequence components 530b. The step is to transform the batch job 412 into an intermediate structure along the target batch service 430. Examples include Spring Batch, Azure Batch, or AWS Batch. All components are transformed to operate with the target batch service and related scheduler to achieve the same desired results as the source batch job and related scheduler. When the batch job, scheduling mechanism, components, and connections are transformed, the batch and schedule are then split into fine-grained components based on the application design. The method helps to avoid data corruption and distributed transaction issues in the target application environment and enables proper functioning. Second, re-platforming by updating the containerized batch service components 532a, 532b, 532c,..., 532n of the target batch service 430 according to the predicted evaluation statistics 302 and the transformed batch job structure 530a,..., 530n. In this step, the containerized batch service 532 includes creating a batch processing service in the cloud 532a, creating job definitions and queues 532b, and configuring queuing and error handling 532c. Further, in one example, migrating the source batch job and related scheduler 412 to the target batch service and related scheduler 430 by re-platforming the updated containerized batch service components 532a,..., 532n to the cloud ecosystem 430 includes the target batch service and related scheduler 430 having Azure Batch 430a, Azure Logical App 430b, AWS Batch service 430c, Spring Batch 430d.

[0089] In another example, an exemplary batch and scheduler migration method automates the analysis and generates a report showing details about which on-premises batch and scheduling mechanisms are being used. The exemplary batch and scheduler migration method automates the analysis and generates a report showing details about which components are batch processes and which scheduling systems are being used. Further, it changes the batch job code to run smaller independent parallel components where each instance completes a part of the work. The creation of batch processing services, setting up job definitions, and queuing activities are performed manually in the cloud environment. The exemplary batch and scheduler migration method first scans the application source code to provide what components represent batch processing and what scheduling mechanisms are being used to schedule this batch job, and the compatibility and risks associated with re-platforming to a cloud-based batch processing system are evaluated. Once this evaluation is complete, the exemplary batch and scheduler migration method creates an interactive HTML report with drill-down capabilities in a form that is easy for technical and business users to consume. This evaluation report is used by architects and application SMEs to devise the design of the newly re-platformed batch processing. Once the design is ready, we can proceed to the next step of batch and scheduler system re-platforming. In the batch job re-platforming step, the exemplary batch and scheduler migration method and SMEs perform the following steps, namely, identify each batch, convert it into smaller independent components that can be transplanted into independent containers, and run them in parallel to complete a large number of tasks, and the SMEs manually create batch services on the cloud, set up job definitions, and queue activities in the cloud environment.The SME can create batch and scheduler services manually, or the SME can create batch and scheduler services manually, work in a hybrid or fully automated manner.

[0090] Exemplary batch and scheduler migration methods provide a function to understand the current batch jobs and scheduler systems used in the source application and a function to convert the batch job source code to use a cloud-based batch processing system in a more efficient and effective way.

[0091] FIG. 6 shows an exemplary flowchart 600 of a method for batch and scheduler migration in application environment migration according to an embodiment of the present subject matter.

[0092] In one embodiment, a method 600 for batch and scheduler migration in application environment migration is shown. The method can be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc. that perform a particular function or implement a particular abstract data type. The method can also be implemented in a distributed computing environment where functions are performed by remote processing devices linked via a communication network. In a distributed computing environment, computer-executable instructions can be located on both local and remote computer storage media including a memory storage device. The order in which the method is described is not intended to be construed as limiting, and any number of the described method blocks can be combined in any order to implement the method or an alternative method. Further, individual blocks can be removed from the method without departing from the spirit and scope of the disclosure described herein. Further, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method can be implemented in the system described above.

[0093] In step / block 602, the processor 122 of the application server 102 evaluates the batch jobs of the source application environment. In one embodiment, the batch jobs can be evaluated by the evaluation module 130.

[0094] In step / block 604, at least one scheduling mechanism and component of the batch job is scanned. In one embodiment, the batch jobs can be scanned by the evaluation module 130.

[0095] In step / block 606, check the amount of change for migrating the batch job to the target batch service. In one embodiment, the amount of change is checked by the evaluation module 130.

[0096] In step / block 608, predict the evaluation statistics that provide at least one functional preparation and timeline for completing the migration of the batch job. In one embodiment, the evaluation statistics can be predicted by the evaluation module 130.

[0097] Accordingly, method 600 assists in batch and scheduler migration in application environment migration by providing the predicted evaluation statistics and a timeline for migration from the source application environment to the target application environment.

[0098] FIG. 7 shows another exemplary flowchart 700 of a method for batch and scheduler migration in application environment migration according to an embodiment of the present subject matter.

[0099] In one embodiment, a method 700 for batch and scheduler migration in application environment migration is shown. The method can be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc. that perform a particular function or implement a particular abstract data type. The method can also be implemented in a distributed computing environment where functions are executed by remote processing devices linked via a communication network. In a distributed computing environment, computer-executable instructions can be located on both local and remote computer storage media including memory storage devices. The order in which the method is described is not intended to be construed as limiting, and any number of the described method blocks can be combined in any order to implement the method or an alternative method. Further, individual blocks can be removed from the method without departing from the spirit and scope of the disclosure described herein. Additionally, the method can be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method can be implemented in the system described above.

[0100] In step / block 702, the batch job of the source application environment is evaluated by the processor 122 of the application server 102. In one embodiment, the batch job can be evaluated by the evaluation module 130.

[0101] In step / block 704, at least one scheduling mechanism and component of the batch job are scanned. In one embodiment, the batch job can be scanned by the evaluation module 130.

[0102] At step / block 706, check the amount of change for migrating the batch job to the target batch service. In one embodiment, the amount of change is checked by the evaluation module 130.

[0103] At step / block 708, predict the evaluation statistics that provide at least one functional preparation and timeline for completing the migration of the batch job. In one embodiment, the evaluation statistics can be predicted by the evaluation module 130.

[0104] At step / block 710, generate a transformed batch job structure generated by splitting the batch job according to the target batch service while maintaining the scheduling mechanism. In one embodiment, the transformed batch job structure can be generated by the refactoring module 132.

[0105] At step / block 712, update the containerized batch service component of the target batch service according to the predicted evaluation statistics and the transformed batch job structure. In one embodiment, the containerized batch service component of the target batch service can be updated by the replatforming module 134.

[0106] At step / block 714, migrate the batch job to the target batch service by replatforming the updated containerized batch service component. In one embodiment, the batch job can be migrated to the target batch service by the replatforming module 134.

[0107] In this way, method 700 provides a predictive evaluation, refactors the code, and replatforms the batch and scheduler migrations from the source application environment to the target application environment, thereby assisting in in-batch and scheduler migrations in application environment migrations.

[0108] This solution is used to re-platform complex batches and schedulers to the cloud and deploy them to the production environment. Some examples are shown using methods and systems for source batch job and related scheduler migration in application environment migration to a target application environment according to embodiments of this subject matter. The following shows preparation, planning, and execution along with the results of the study. As an example, in the cloud re-platforming of a leading subprime mortgage company's JAVA batch application, the source application environment belongs to a leading subprime mortgage company that provides mortgage-backed securities and is a multi-billion-dollar company operating in the United States and is also a publicly traded company. The main business challenges are a complex JAVA batch application developed 10 years ago with an IBM MQ message broker, batch jobs, using Message-Driven Bean EJB (MDB) Pojo Services, JDBC, etc. along with the use of an Oracle database. This application is business-critical and processes major long-running processes. Due to the unavailability of the main SMEs who developed this application, there were challenges in cloud re-platforming. Using this solution approach, the Oracle database was re-platformed to Postgres using method steps, the Autosys scheduler was re-platformed to Quartz, the backend EJB (MDB) was re-platformed to a stand-alone Spring JMS with Spring Boot / Batch Service Apps with REST endpoints, and the message broker was re-platformed to Amazon MQ. Then each service app was deployed on individual containers on AWS ECS VPC, providing infinite scalability, high availability, high fault tolerance, and performance improvement. The centralized JOB dependencies of Autosys were refactored to self-managed dependencies using app-specific quartz schedulers, reducing the complexity of operations.Among the main benefits, mainly due to the elimination and containerization of WebLogic & Autosys, the TCO is reduced by more than 50%. The productivity of development is improved by macro services and CI / CD automation. When using automation, the total implementation cost is reduced by more than 50%, and the implementation is completed in 6 weeks (similarly, it takes 9 months if executed manually).

[0109] In another example, this solution was used to cloud - refactor a.NET web application of a consulting company that led us. The source application environment belongs to one of the largest professional service and accounting auditing institutions of a content management company with employees in over 700 offices in 150 countries around the world. The main business challenge is a complex.NET web application developed over the years using ASP.NET, C#, Telerik ORM in parallel with the use of Microsoft MQ and SQL Server databases. This application is business - critical as it handles the main B2C functions of a large professional service provider. This task became more complex due to the absence of the main SMEs who developed this application. Using the current solution approach, the source application is split into a web front - end and a service back - end. The legacy.NET services in the back - end using Telerik ORM are refactored into independent.NET Core service apps with an entity framework having REST endpoints. The web front - end and each service app are deployed into separate containers on the Azure cloud with Kestrel and NGINX, providing infinite scalability, high availability, high fault tolerance, and performance improvement. The web front - end and macro - services are made stateless using Redis cache. The message broker is refactored to RabbitMQ and the batch jobs to AWS Batch. The service REST API endpoints are protected by oAuth2. Automated testing + CI / CD is enabled for the web front - end and all macro - services. Among the top benefits, the refactoring platform results in a TCO reduction of over 45% mainly due to the abolition of IIS & Telerik ORM, a reduction of over 45% in the total implementation cost, an increase in development productivity with macro - services and CI / CD automation, and completion in 6 weeks compared to 7 months in the case of manual work.

[0110] Embodiments of systems and methods for batch and scheduler migration in application environment migration are described in terms of structural features and / or language specific to the method, but it is understood that the appended claims are not necessarily limited to the specific features or methods described. Rather, the specific functions and methods are disclosed as examples of embodiments for batch and scheduler migration in application environment migration.

Claims

1. Evaluating a batch job (412) of a source application environment by a processor (122) of an application server (102); Scanning, by the processor (122), the batch job (412) to identify at least one scheduling mechanism and components (412a,..., 412n) of the batch job (412); Confirming, by the processor (122), an amount of change for migrating the batch job (412) to a target batch service (430); Predicting, by the processor (122), evaluation statistics (302), the evaluation statistics (302) providing at least one functional preparation (304) and timeline (306) for completing the migration of the batch job (412); Generating, by the processor (122), a transformed batch job structure (530a,..., 530n), the transformed batch job structure (530a,..., 530n) being generated by dividing the batch job (412) according to the target batch service (430) while retaining the scheduling mechanism; Updating, by the processor (122), containerized batch service components (532a,..., 532n) of the target batch service (430) based on the predicted evaluation statistics (302) and the transformed batch job structure (530a,..., 530n); Migrating, by the processor (122), the batch job (412) to the target batch service (430), the migration including re-platforming the updated containerized batch service components (532a,..., 532n). A method comprising:

2. The method according to claim 1, wherein the amount of change for migrating the batch job (412) to the target batch service (430) is calculated based on the size and complexity of the batch job (412).

3. The method according to claim 1, wherein the transformed batch job structure (530a, …, 530n) is generated using a continuous integration and deployment framework (150) and an automated test framework (150).

4. The method according to claim 1, wherein the evaluation statistics (302) provide at least one inhibiting factor for completing the migration of the batch job (412).

5. The method according to claim 1, wherein the transformed batch job structure (530a, …, 530n) is generated according to the target batch service (430) while maintaining the connections between the components (412a, 412b, …, 412n) of the batch job (412).

6. The method according to claim 1, wherein the transformed batch job structure (530a, …, 530n) is identified by an artificial intelligence (AI) engine (152).

7. The method according to claim 1, further comprising implementing, by the processor (122), a batch service definition and a service queue according to a target application environment.

8. The method according to claim 1, further comprising accessing, by the processor (122), application code (202) including business logic, links, a rule engine, a library of available environments, standard tools, and a coding language.

9. The batch job (412) of the application environment migrates to the target batch service (430) including steps of redevelopment from a source batch job to a target batch service, refactoring from a source batch job to a target batch service, rehosting from a source batch job to a target batch service, and replatforming from a source batch job to a target batch service, according to claim 1.

10. The method according to claim 1, wherein the target batch service (430) is a cloud-based batch service ecosystem.

11. A processor (122), and a memory (126) coupled to the processor (122), wherein the processor (122) executes a plurality of modules (128) stored in the memory (126), and the plurality of modules (128) are An evaluation module (130) for evaluating a batch job (412) in a source application environment, scanning the batch job to identify at least one scheduling mechanism and components (412a,..., 412n) of the batch job (412), and checking the amount of change for migrating the batch job (412) to a target batch service (430), wherein the evaluation module (130) predicts evaluation statistics (302) that provide at least one functional preparation (304) and timeline (306) for completing the migration of the batch job (412). A refactoring module (132) for generating a transformed batch job structure (530a,..., 530n), wherein the transformed batch job structure (530a,..., 530n) is generated by splitting the batch job (412) according to the target batch service (430) while retaining the scheduling mechanism. A replatforming module (134) for updating containerized batch service components (532a,..., 532n) of the target batch service (430) based on the predicted evaluation statistics (302) and the transformed batch job structure (530a,..., 530n), and migrating the batch job (412) to the target batch service (430), wherein the migration replatforms the updated containerized batch service components (532a,..., 532n). A system comprising the replatforming module (134).

12. The system according to claim 11, wherein the amount of change for migrating the batch job (412) to the target batch service (430) is calculated based on the size and complexity of the batch job (412).

13. The system according to claim 11, wherein the transformed batch job structure (530a,..., 530n) is generated using a continuous integration and deployment framework (150) and an automated test framework (150).

14. The system according to claim 11, wherein the evaluation statistics (302) provide at least one inhibiting factor for completing the migration of the batch job (412).

15. The system according to claim 11, wherein the converted batch job structure (530a,..., 530n) is generated according to the target batch service (430) while maintaining the connection between the components (412a, 412b,..., 412n) of the batch job (412).

16. The system according to claim 11, wherein the converted batch job structure (530a,..., 530n) is identified by an artificial intelligence (AI) engine (152).

17. The system according to claim 11, wherein the replatforming module (134) further includes implementing a batch service definition and a service queue according to a target application environment by the processor (122).

18. The system according to claim 11, wherein the plurality of modules (128) further execute accessing, by the processor (122), application code (202) including business logic, links, a rule engine, a library of available environments, standard tools, and coding languages.

19. The batch job (412) in the application environment migrates to the target batch service (430) including steps of redevelopment from a source batch job to a target batch service, refactoring from a source batch job to a target batch service, rehosting from a source batch job to a target batch service, and replatforming from a source batch job to a target batch service.

20. The system according to claim 11, wherein the target batch service (430) is a cloud-based batch service ecosystem.

Images