WO2019223182A1

WO2019223182A1 - Cross-scheduling platform dependency implementation method and apparatus, device, and storage medium

Info

Publication number: WO2019223182A1
Application number: PCT/CN2018/104708
Authority: WO
Inventors: 刘斌; 袁贺强
Original assignee: 平安科技（深圳）有限公司
Priority date: 2018-05-21
Filing date: 2018-09-08
Publication date: 2019-11-28
Also published as: CN108710532A; CN108710532B

Abstract

A cross-scheduling platform dependency implementation method and apparatus, a device, and a storage medium. The method comprises: a first scheduling platform acquiring a first scheduling task identifier (S101); the first scheduling platform searching in a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, the execution of a first scheduling task corresponding to the first scheduling task identifier depending on the execution of a second scheduling task corresponding to the second scheduling task identifier (S102); the first scheduling platform using a cross-platform script language to poll regarding whether a log table of a second scheduling platform has a flag file that shows the second scheduling task corresponding to the second scheduling task identifier is successfully operated (S103); if the log table of the second scheduling platform has a flag file that shows the second scheduling task corresponding to the second scheduling task identifier is successfully operated, the first scheduling platform executing the first scheduling task corresponding to the first scheduling task identifier (S104). Said method facilitates searching for and monitoring the operation result of a scheduling task, implementing the dependency of tasks between scheduling platforms.

Description

Method, device, equipment and storage medium for implementing dependency across scheduling platforms

This application claims the priority of a Chinese patent application filed on May 21, 2018 with the Chinese Patent Office, application number 201810486735.8, and invention name "Cross-platform platform dependent implementation method, device, device, and storage medium", its entire content Incorporated by reference in this application.

Technical field

The present application relates to the field of computer technology, and in particular, to a method, an apparatus, a device, and a storage medium for implementing a dependency across a scheduling platform.

Background technique

At present, there are many types of big data tasks running on different scheduling platforms. Due to the different methods and rules of tasks running on different scheduling platforms, it is not possible to directly rely on data, which can not form an effective and rigorous data flow. Timing to implement dependencies is prone to problems such as incomplete data and long waiting times.

For example, there is a project A that uses OOZIE (OOZIE is a server based on a workflow engine) to schedule tasks. Data exists in hadoop HIVE (Hadoop, Hadoop Distributed File System, HDFS for short), which is a distributed system infrastructure. Hive is a A data warehouse architecture built on the Hadoop file system, and analyzes and manages the data stored in HDFS) table; another project B uses linkdo (linkdo is a distributed task scheduling platform) scheduling The data of the hadoop task and the project B task depends on the generation of the data in the HIVE table in the project A. If there is no dependency, it can only be achieved by staggering the execution time. For example, the task of project A runs at 5 o'clock and is expected to be completed in 1-3 hours, then the task of project B can only be set to be executed after 8 o'clock.

Because the running time of the task fluctuates daily, if the task of project A is completed in 1 hour, then project B will be set to execute at 8 o'clock, and it will wait for two hours; or when the task of project B is executed, A The project's mission data has not yet been fully generated.

Summary of the Invention

Based on this, it is necessary to provide a method, an apparatus, a device, and a storage medium for implementing a dependency across a scheduling platform in response to the problems that the existing technology is apt to cause long task running time and data error.

A cross-platform platform dependency implementation method includes:

The first scheduling platform acquires a first scheduling task identifier;

The first scheduling platform searches a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, wherein execution of the first scheduling task corresponding to the first scheduling task identifier depends on the Execution of the second scheduled task corresponding to the second scheduled task identifier;

The first scheduling platform uses a cross-platform scripting language to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

If a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task corresponding to the first scheduling task identifier Scheduling tasks.

A dependency implementation device across a scheduling platform includes:

An obtaining module, configured to obtain a first scheduling task identifier by the first scheduling platform;

The searching module is configured to search the first scheduling platform for a second scheduling task identifier corresponding to the first scheduling task identifier in a first configuration table, where the first scheduling task corresponding to the first scheduling task identifier is The execution depends on the execution of the second scheduling task corresponding to the second scheduling task identifier;

A polling module, configured to use a cross-platform scripting language for the first scheduling platform to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

The execution module is configured to: if a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task. Identifies the corresponding first scheduled task.

A computer device includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor causes the processor to perform the following steps:

The first scheduling platform acquires a first scheduling task identifier;

A storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the following steps:

The first scheduling platform acquires a first scheduling task identifier;

The above-mentioned dependent implementation method, device, device and storage medium of the scheduling platform obtains the first scheduling task identifier through the first scheduling platform, and the first scheduling platform looks up the first configuration table corresponding to the first scheduling task identifier The second scheduling task identifier, wherein the execution of the first scheduling task corresponding to the first scheduling task identifier depends on the execution of the second scheduling task corresponding to the second scheduling task identifier, and the first scheduling platform uses Platform scripting language, polling the log table of the second scheduling platform for a flag file corresponding to the second scheduling task identifier for the successful running of the second scheduling task, if the log table of the second scheduling platform exists with the second scheduling platform A flag file indicating that the second scheduling task corresponding to the scheduling task identifier runs successfully, the first scheduling platform executes the first scheduling task corresponding to the first scheduling task identifier, and if the log table of the second scheduling platform does not exist with the A flag file corresponding to the second scheduling task identifier that the second scheduling task runs successfully, the first calling platform calls The monitoring program of the two platforms checks the execution progress of the second scheduling task, realizes the dependency between the scheduling platforms, avoids the incomplete data appearing in the timing dependency, and realizes the integration and integration between the scheduling platforms.

BRIEF DESCRIPTION OF THE DRAWINGS

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the detailed description of the preferred embodiments below. The drawings are only for the purpose of illustrating preferred embodiments and are not to be considered as limiting the present application.

FIG. 1 is a flowchart of a method for implementing a dependency across a scheduling platform in an embodiment; FIG.

2 is a structural block diagram of a device for implementing a dependency across a scheduling platform in an embodiment;

FIG. 3 is a block diagram of the internal structure of a computer device in one embodiment.

Detailed ways

In order to make the purpose, technical solution, and advantages of the present application clearer, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application, and are not used to limit the application.

Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms "a", "an", "the" and "the" may include plural forms. It should be further understood that the word "comprising" used in the specification of the present application refers to the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, Integers, steps, operations, elements, components, and / or groups thereof.

As a better embodiment, as shown in FIG. 1, a dependency implementation method across a scheduling platform includes:

Step S101: The first scheduling platform obtains a first scheduling task identifier; the first scheduling platform is a distributed scheduling platform, and may be any one of Oozie, Linkdo, Control-M, XXL-JOB, and TivoliWorkloadScheduler; among them,

The distributed task scheduling platform XXL-JOB is an open source framework based on the open source Quartz scheduling kernel. Scheduling tasks are a whole. You cannot edit the flowchart of a large task and track the execution status of each node. You cannot configure dependencies between multiple tasks and run them sequentially, such as upstream tasks sending signals to downstream tasks. IBM's Tivoli Workload Scheduler can correspond to cron under Unix, but it enhances a lot of functions for enterprise scheduling, such as can handle scheduling based on dependencies and event-driven, can manage multiple time zones, and so on. Cron can only schedule based on time on a single server, while TWS can replace cron and use its own background program to handle job scheduling with richer functions. Oozie is a workflow engine server that runs task workflows such as hadoop map / reduce and hive. Control-M, using C / S mode, installs the Enterprise Manager and server on the server, and installs the agent on the controlled host. The agent can submit the job stream defined by Control-M on the host and return the running result. On the Enterprise Manager, you can comprehensively monitor the operation of all batch jobs. There are multiple ways to control the operating conditions and process intervention of JOB.

The first scheduling task identifier is set to uniquely distinguish a scheduling task to be executed on the first scheduling platform, and may be a combination of letters, numbers, and underscores of a preset rule. In this embodiment, the specific implementation steps for the first scheduling platform to obtain the first scheduling task may be: the first scheduling platform sequentially scans the current status of each task in a preset scheduling task table, and if the current status is ready or ready Status, obtain the ready status or the scheduled task ID corresponding to the ready status. The scheduling task table sets scheduling task information such as the scheduling task name, the scheduling task identifier, and the scheduling task status. The scheduling task status is set to represent the current status of the scheduling task, including the ready status / ready status and completion status. It can be understood that, in this embodiment, the scheduling task information is stored separately.

In other embodiments, the scheduling task information may be stored in the same task table as the non-scheduled task information of the first scheduling platform (that is, the task information executed by the first scheduling platform itself without the need to implement execution by calling other platforms). The specific implementation steps for the first scheduling platform to obtain the first scheduling task may be: the first scheduling platform reads the task type of each task in turn in a preset task table, and if the task type is a scheduling task, obtaining the scheduling task If the current state is the ready state or the ready state, obtain the scheduling task identifier corresponding to the ready state or the ready state.

Step S102, the first scheduling platform searches a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, wherein the execution dependency of the first scheduling task corresponding to the first scheduling task identifier is Execution of a second scheduling task corresponding to the second scheduling task identifier;

The second calling platform is a called platform that corresponds to the first scheduling platform and uses a different framework from the first scheduling platform. For example, the first scheduling platform uses a platform of the XXL-JOB framework, so the second calling platform may use Oozie. , Linkdo, Control-M, or TivoliWorkloadScheduler framework platform; the second scheduling platform identifier is set to uniquely distinguish the scheduling task to be executed on the second scheduling platform, can also be preset rules of letters, numbers and underlined A combination string; the first configuration table is set on the first scheduling platform and stores a mapping relationship between the first scheduling task task identifier and the second platform task identifier, wherein the first scheduling task corresponding to the first scheduling task identifier The execution depends on the execution of the second scheduling task corresponding to the second scheduling task identifier, that is, after the second scheduling task corresponding to the second scheduling platform identifier is successfully executed, the first scheduling task corresponding to the first scheduling platform identifier is executed.

The following table is an example of setting the fields of the first configuration table in an embodiment. In this embodiment, the first scheduling platform uses the platform of the XXL-JOB framework, and the second calling platform uses the platform of the Oozie framework. oozie_task_name is the first scheduled task identifier, and the field task_name is the second scheduled task identifier:

Table 1

Step S103: The first scheduling platform uses a cross-platform scripting language to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

The log table is set in advance on the second scheduling platform, and is set to receive a flag file that the second scheduling task runs successfully. After the second scheduling platform executes the second scheduling task, it generates a flag file according to the running status of the scheduling task, and stores the flag file in the created log table.

The following table is an example of a log table in an embodiment, where RUN-DATA is the running data, OOZIE-TASK-NAME is the OOZIE task name, TASK-NAME is the task name, and CHECK-TIME is the check time.

Table 2

In this embodiment, a cross-platform scripting language is invoked through the crontab of LINUX. One of Python, Perl, Ruby, PHP, Lua, and Java can be selected as a cross-platform scripting language. Through the crontab function of Linux, every one minute The selected cross-platform scripting language is triggered once, and the cross-platform scripting language utilizes its detection function to use the cross-platform scripting language on the first scheduling platform every one minute to poll the log table of the second scheduling platform for existence with the second scheduling The flag file corresponding to the successful execution of the second scheduling task corresponding to the task identifier, and if a flag file corresponding to the second scheduling task identifier to successfully run exists, the virtual task in the scheduling platform is set to a completed state.

In step S104, if a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes corresponding to the first scheduling task identifier. The first scheduled task.

In this embodiment, if a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling corresponding to the first scheduling task identifier task. The first scheduling platform is the active side, and the second scheduling platform is the passive side. The first scheduling platform initiates a query to query the flag in the second scheduling platform. If the flag is completed, the first scheduling platform will trigger his own task to start running to achieve the purpose of dependence. The mark can be agreed, it can be a file with time and task tags, or it can be a field in the database.

In one embodiment, if there is no flag file corresponding to the second scheduling task identifier in the log table of the second scheduling platform, the first calling platform invokes the monitoring of the second platform. A program to view the execution progress of the second scheduled task.

In this embodiment, if a log file of the second scheduling task corresponding to the second scheduling task identifier does not exist in the log table of the second scheduling platform, the first calling platform invokes a monitoring program of the second platform to view the Implementation progress of the second scheduling task. If the task on the platform wants to run, you need to first check the flag of the dependent platform. If the flag is generated, then run it. If the flag is not generated, you need to continue the inspection after two minutes.

In one embodiment, the first scheduling platform and the second scheduling platform are any one of Oozie, Linkdo, Control-M, XXL-JOB, or TivoliWorkloadScheduler.

The first scheduling platform and the second scheduling platform can be selected from Oozie, Linkdo, Control-M, XXL-JOB, and Tivoli Workload Scheduler as the second scheduling platform. The second scheduling platform should be the same as the first scheduling platform. Can't be the same. Oozie is a workflow engine server for running tasks such as hadoop map / reduce and hive. At the same time, Oozie is also a java web program running in a java servlet container, such as in tomcat. Oozie uses action as the basic unit. Multiple actions form a DAG diagram. Control-M, using C / S mode, installs the Enterprise Manager and server on the server, and installs the agent on the controlled host. The agent can submit the job stream defined by Control-M on the host and return the running result. On the Enterprise Manager, you can comprehensively monitor the operation of all batch jobs. There are multiple ways to control the operating conditions and process intervention of JOB. The distributed task scheduling platform XXL-JOB is an open source framework based on the open source Quartz scheduling kernel. Scheduling tasks are a whole. You cannot edit the flowchart of a large task and track the execution status of each node. You cannot configure dependencies between multiple tasks and run them sequentially, such as upstream tasks sending signals to downstream tasks. Tivoli Workload Scheduler is a task scheduling software belonging to IBM, which can correspond to cron under Unix, but it has enhanced a lot of functions for enterprise scheduling, such as can handle scheduling based on dependencies and event-driven, can manage multiple time zones, and so on. Cron can only schedule based on time on a single server, while TWS can replace cron and use its own background program to handle job scheduling with richer functions.

In one embodiment, the cross-platform scripting language is any one of Python, Perl, Ruby, PHP, Lua, or Java.

A scripting language is an executable file written in a certain format using a specific descriptive language, also known as a macro or batch file. Scripts can usually be called and executed temporarily by an application. Scripting languages have rapid development, efficient execution, interpretation rather than compilation and execution, and powerful communication capabilities with program components written in other languages. Among them, any of the common scripting languages Python, Perl, Ruby, PHP, Lua, or Java can implement communication across scheduling platforms.

As shown in FIG. 2, in one embodiment, a dependency implementation device across a scheduling platform is provided. The dependency implementation device includes:

In an embodiment, the cross-platform dependency implementation device further includes a monitoring module configured to set a flag indicating that the second scheduling task corresponding to the second scheduling task identifier runs successfully if no log table of the second scheduling platform exists. File, the first calling platform calls a monitoring program of the second platform to view the execution progress of the second scheduling task.

In one embodiment, the acquisition module includes:

A scanning unit, configured to scan the current status of each task in turn by the first scheduling platform in a preset scheduling task table;

The determining unit is configured to obtain a scheduling task identifier corresponding to the ready state or the ready state if the current state is a ready state or a ready state, and the scheduling task identifier is set to the first scheduling task identifier.

In one embodiment, as shown in FIG. 3, a computer device is proposed. The computer device includes a processor, a nonvolatile storage medium, a memory, and a network interface connected through a system bus. The non-volatile storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The database may store control information sequences. When the computer-readable instructions are executed by the processor, the processor may enable the processor to query. , Download and verify electronic invoices. The processor of the computer device is configured to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor may cause the processor to execute the steps in the method for implementing a dependency across a scheduling platform in the foregoing embodiments.

In one embodiment, a storage medium storing computer-readable instructions is provided. When the computer-readable instructions are executed by one or more processors, the one or more processors are caused to perform cross-scheduling in the foregoing embodiments. Platform-dependent implementation steps. The storage medium may be a non-volatile storage medium.

A person of ordinary skill in the art may understand that all or part of the steps in the various methods of the foregoing embodiments may be implemented by a program instructing related hardware. The program may be stored in a computer-readable storage medium. The storage medium may include: Read-only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks, etc.

The technical features of the embodiments described above can be arbitrarily combined. In order to simplify the description, all possible combinations of the technical features in the above embodiments have not been described. However, as long as there is no contradiction in the combination of these technical features, It should be considered as the scope described in this specification.

The above-mentioned embodiments only express some exemplary embodiments of the present application, and their descriptions are more specific and detailed, but cannot be understood as a limitation on the scope of the patent of the present application. It should be noted that, for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can be made, and these all belong to the protection scope of the present application. Therefore, the protection scope of this application patent shall be subject to the appended claims.

Claims

A cross-platform platform dependency implementation method includes:

The first scheduling platform acquires a first scheduling task identifier;

The first scheduling platform searches a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, wherein execution of the first scheduling task corresponding to the first scheduling task identifier depends on the Execution of the second scheduled task corresponding to the second scheduled task identifier;

The first scheduling platform uses a cross-platform scripting language to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

If a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task corresponding to the first scheduling task identifier Scheduling tasks.
The method for implementing a cross-platform platform dependency according to claim 1, wherein the method further comprises:

If a log file of the second scheduling task corresponding to the second scheduling task identifier does not exist in the log table of the second scheduling platform, the first calling platform invokes a monitoring program of the second platform to view the first scheduling task. The progress of the implementation of the second scheduling task.
The cross-platform platform dependent implementation method according to claim 1, wherein the first scheduling platform and the second scheduling platform are any one of Oozie, Linkdo, Control-M, XXL-JOB, or TivoliWorkloadScheduler .
The cross-platform platform dependent implementation method according to claim 1, wherein the cross-platform scripting language is any one of Python, Perl, Ruby, PHP, Lua, or Java.
The method for implementing a dependency across a scheduling platform according to claim 1, wherein the first scheduling platform obtaining the first scheduling task identifier comprises: the first scheduling platform sequentially scanning each task in a preset scheduling task table If the current state is a ready state or a ready state, obtaining a scheduling task identifier corresponding to the ready state or the ready state, and the scheduling task identifier is set to the first scheduling task identifier.
A dependency implementation device across a scheduling platform includes:

An obtaining module, configured to obtain a first scheduling task identifier by the first scheduling platform;

The searching module is configured to search the first scheduling platform for a second scheduling task identifier corresponding to the first scheduling task identifier in a first configuration table, where the first scheduling task corresponding to the first scheduling task identifier is The execution depends on the execution of the second scheduling task corresponding to the second scheduling task identifier;

A polling module, configured to use a cross-platform scripting language for the first scheduling platform to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

The execution module is configured to: if a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task. Identifies the corresponding first scheduled task.
The device according to claim 6, further comprising a monitoring module configured to run if a second scheduling task corresponding to the second scheduling task identifier does not exist in a log table of the second scheduling platform If the flag file is successful, the first calling platform invokes a monitoring program of the second platform to view the execution progress of the second scheduling task.
The dependent implementation device for a cross-scheduling platform according to claim 6, wherein the first scheduling platform and the second scheduling platform are any one of Oozie, Linkdo, Control-M, XXL-JOB, or TivoliWorkloadScheduler .
The dependent implementation device for a cross-scheduling platform according to claim 6, wherein the cross-platform scripting language is any one of Python, Perl, Ruby, PHP, Lua, or Java.
The device for implementing a dependency of a cross-scheduling platform according to claim 6, wherein the acquisition module comprises:

A scanning unit, configured to scan the current status of each task in turn by the first scheduling platform in a preset scheduling task table;

The determining unit is configured to obtain a scheduling task identifier corresponding to the ready state or the ready state if the current state is a ready state or a ready state, and the scheduling task identifier is set to the first scheduling task identifier.
A computer device includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor causes the processor to perform the following steps:

The first scheduling platform acquires a first scheduling task identifier;

The first scheduling platform searches a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, wherein execution of the first scheduling task corresponding to the first scheduling task identifier depends on the Execution of the second scheduled task corresponding to the second scheduled task identifier;

The first scheduling platform uses a cross-platform scripting language to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

If a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task corresponding to the first scheduling task identifier Scheduling tasks.
The computer device according to claim 11, wherein the computer-readable instructions, when executed by the processor, further cause the processor to perform the following steps:

If a log file of the second scheduling task corresponding to the second scheduling task identifier does not exist in the log table of the second scheduling platform, the first calling platform invokes a monitoring program of the second platform to view the first scheduling task. The progress of the implementation of the second scheduling task.
The computer device according to claim 11, wherein the first scheduling platform and the second scheduling platform are any one of Oozie, Linkdo, Control-M, XXL-JOB, or TivoliWorkloadScheduler.
The computer device according to claim 11, wherein the cross-platform scripting language is any one of Python, Perl, Ruby, PHP, Lua, or Java.
The computer device according to claim 11, wherein the first scheduling platform obtains a first scheduling task identifier, so that the processor performs the following steps:

The first scheduling platform sequentially scans the current status of each task in a preset scheduling task table, and if the current status is a ready state or a ready state, obtaining the scheduled task corresponding to the ready state or the ready state An identifier, and the scheduling task identifier is set to the first scheduling task identifier.
A storage medium storing computer-readable instructions, wherein when the computer-readable instructions are executed by one or more processors, the one or more processors execute the following steps:

The first scheduling platform acquires a first scheduling task identifier;

The first scheduling platform searches a first configuration table for a second scheduling task identifier corresponding to the first scheduling task identifier, wherein execution of the first scheduling task corresponding to the first scheduling task identifier depends on the Execution of the second scheduled task corresponding to the second scheduled task identifier;

The first scheduling platform uses a cross-platform scripting language to poll a log table of the second scheduling platform whether a flag file corresponding to the second scheduling task identifier runs successfully;

If a log file of the second scheduling task corresponding to the second scheduling task identifier exists in the log table of the second scheduling platform, the first scheduling platform executes the first scheduling task corresponding to the first scheduling task identifier Scheduling tasks.
The storage medium of claim 16, wherein the computer-readable instructions, when executed by one or more processors, further cause the one or more processors to perform the following steps:

If a log file of the second scheduling task corresponding to the second scheduling task identifier does not exist in the log table of the second scheduling platform, the first calling platform invokes a monitoring program of the second platform to view the first scheduling task. The progress of the implementation of the second scheduling task.
The storage medium according to claim 16, wherein the first scheduling platform and the second scheduling platform are any one of Oozie, Linkdo, Control-M, XXL-JOB, or TivoliWorkloadScheduler.
The storage medium according to claim 16, wherein the cross-platform scripting language is any one of Python, Perl, Ruby, PHP, Lua, or Java.
The storage medium according to claim 16, wherein the first scheduling platform obtains a first scheduling task identifier, so that one or more processors perform the following steps:

The first scheduling platform sequentially scans the current status of each task in a preset scheduling task table, and if the current status is a ready state or a ready state, obtaining the scheduled task corresponding to the ready state or the ready state An identifier, and the scheduling task identifier is set to the first scheduling task identifier.