KR102621742B1 - An automation service system using a no-code based automation service platform and method thereof, and computer program - Google Patents

Abstract

The present invention provides a user who inputs and sets at least one of the name, execution cycle, and operating conditions of the target task of the work scenario, and a machine that automatically programs the work scenario according to the user's input value and automatically executes it according to the user's input value. Code-based automation platform; Includes an automated service system using a no-code-based automated service platform that includes.

Description

An automation service system using a no-code based automation service platform and method thereof, and computer program}

The present invention relates to an automated service system and method using a no-code-based automated service platform, and a computer program that executes the same.

The rise of no-code technologies in recent years has been driven by several factors, including the growing demand for digital transformation across many industries, the need for businesses to be more agile and responsive to changing market conditions, and the shortage of skilled workers.

Among recently proposed technologies, no-code-based automation service platforms are excellent at solving the problem of time-consuming and repetitive tasks that can be automated but require programming skills.

In other words, the no-code-based automation service platform uses a no-code work automation solution that allows you to program the work you want without the need to write code, so non-technical staff such as sales, human resources, and administration can perform repetitive tasks without writing code. It has the advantage of making the process faster and more efficient by creating scenarios and automating them.

The recent rise of such no-code technologies has helped many industries address a number of factors, including the growing demand for digital transformation, the need for businesses to be more agile and responsive to changing market conditions, and the shortage of skilled workers. there was.

For example, no-code solutions allow non-technical staff to automate tasks and processes, freeing developers to focus on more complex projects, reducing costs, increasing efficiency, and improving overall business performance.

However, conventionally, many no-code-based tools like the above save scenarios written by users in files or DB 140, and a specific back-end process reads them at a set time and executes them sequentially, which is in the advanced digitalization era. is becoming another bottleneck.

For example, conventionally, many tasks need to be executed at the same time, but the backend process is not linearly auto-scaled, so problems that should be executed exactly at the set time frequently occur late or early.

Additionally, with this process method, it is difficult to trace the cause or status of a problem when it occurs later, depending on whether or not the internal log is recorded. Therefore, even if work increases rapidly, a service that can maintain high availability while operating independently on a cloud basis is needed to enable Auto-Scaleout.

In addition, the prior art lacks services that can monitor problematic situations, determine the location of my work, and maintain data transparency and security, so supplementation is urgently needed.

KR 10-2022-0084792 A(2022.06.21)

The present invention was created to solve the above-described conventional problems, and the purpose of the present invention is to provide an automated service system and method using a no-code-based automated service platform that can maintain data transparency and security.

The present invention may include the following embodiments to achieve the above object.

An embodiment of the present invention automatically programs a work scenario according to the user's input value and a user who inputs and sets at least one of the name, execution cycle, and operating conditions of the target task of the work scenario, and automatically programs the work scenario according to the user's input value. An automated service system using a no-code-based automated service platform can be provided.

In the above embodiment, the no-code-based automation platform includes code (program) to perform the set task, metadata containing how to express the customer's UI, a plug-in containing metadata necessary for execution, and the user's input value. A no-code web builder unit that searches and outputs the location of the metadata of the plug-in that matches at least one of the job name, execution cycle, and operating conditions, and the name, execution cycle, and metadata of the job from the no-code web builder unit. An engine core that receives at least one of the positions and sequentially loads the metadata of the task execution searched in the no-code web builder part when it corresponds to the task execution cycle, and the user's input value and metadata of the task execution from the engine core A container engine that receives and registers module information converted into action logic predefined as a program in an executable form, and after going through the process of checking for errors in the predefined action logic of the container engine, a work scenario as a program in executable form. It may include a task creation unit that creates a job, and a task execution unit that loads and executes the job scenario created in the task creation unit if the execution conditions set in the job scenario are met.

In addition, the no-code web builder unit searches the plug-in of the target code (program) according to the command received or entered from the user, and if it meets the execution conditions, searches the task within the plug-in and provides authentication and metadata required for the task. You can output a selection list of conditions based on data.

In addition, the plug-in is a form for receiving input from the user by a no-code web builder, including a list of required data, UI component information that makes up the UI panel for authentication, operation settings, and environment settings, and predefined information supported by the plug-in. It contains metadata information of the action in which the logic is implemented, action information that allows the addition of a new plug-in to perform a specific action, platform supportable versions and descriptions, multilingual information, information about the app implemented by the plug-in, plug-in creator, It may include plug-in information including at least one of the following: plug-in license, plug-in production date, latest update date, required library list, and other restrictions, and predefined logic for each action, including program logic for functions that can be automated through plug-ins. .

In addition, the engine core is built with one main and multiple subs, and the multiple subs maintain the main through communication, control whether to automatically execute work scenarios, monitor the execution process and results, and store them in storage. It is characterized by

In addition, the engine core includes a storage module that accesses and manages metadata information stored in storage, a scheduler module that includes NTP (Network Time Protocol) and a watchdog for time synchronization, and an engine that executes user programs. It may include a monitoring module that collects at least one information among occurring errors, logs, response time, and CPU load, and monitors the execution process of the work scenario.

In the above embodiment, the structured form of the container engine's predefined action logic may be function action_logic(input:InputProps):OutputProps {//actual program}.

In addition, the task creation unit verifies the input/output of the action logic for packaging into a program, records information necessary for auditing in storage, and issues an exit code to return resources upon completion.

In addition, the task execution unit loads metadata containing execution information and authentication information and an independently executable program, and if it corresponds to the set execution time, executes the task scenario to determine whether it succeeds or fails, and dumps information in case of an error. can be stored in storage.

The present invention relates to an automated service method using a no-code-based automated service platform by the system of the above embodiment, a) an input value including at least one of the task start time, target code, and scenario entered by the user in the absence of service. A step of storing the job setting information, and b) receiving the user's job information and the metadata location of the plug-in from the engine core, and sequentially loading the plug-in metadata required for the job when it corresponds to the work time and sending it to the container engine. and c) modularizing the plug-in metadata and user input values received from the service processing member into predefined logic, programming it into an automatically executable program, automatically executing it, and storing the results in storage. You can.

In step b) of the above embodiment, b-1) when a task is activated by a user's input command, the engine core receives and stores information including at least one of the task's execution cycle, schedule, task type, and task scenario. step, b-2) the engine core checks the plug-in list and loads the meta data of the plug-in, and b-3) the engine core cross-verifies the meta data of the loaded plug-in and the user's input data to detect errors. A step of sending error information to the user when an error occurs, and b-4) If the engine core determines that the task scenario entered by the user is an executable program, metadata and plug-in information required for execution to make it a task that can be executed periodically. , It may include packaging user input data containing authentication information and transmitting it to the container engine.

In addition, step c) includes receiving metadata containing at least one of the user's input data, plug-in metadata, X509 certificate, program information, runtime information, and user's subscription information from c-1) container engine; , c-2) Decrypting the data loaded from the container engine, checking whether it is normal, and converting it into a predefined action logic form so that it can be executed, and c-3) The task creation unit is created in an executable form in the container engine. A step of registering a work schedule by setting the automation program and decrypted metadata as input, c-4) A step of the task execution unit executing the registered program according to the setting information and storing the result, c-5) The task execution unit may check whether the task of the program has been completed by checking the result value and the exit code of the program, and may include a step of storing the completion information in storage when the task execution is completed.

In addition, another embodiment of the present invention is a computer program stored in a recording medium readable by the computing device in combination with a computing device to execute an automated service method using a no-code-based automated service platform of any of the other embodiments. may include.

The present invention provides a container that is logically isolated and operates like a real server, so that the user can enjoy the same security as if the task was executed on an actually isolated server.

In addition, because the present invention is based on a standardized environment, it can be implemented in a data center in a desired location on a public cloud or private cloud, allowing users to maintain security and perform their work in an isolated environment with minimal interference. It makes it possible to perform at the correct time.

In addition, the present invention can receive the advantages of container-based scalability, so even if the amount of work increases explosively, it can be expanded by simply scaling up the engine without building a separate IDC, and can be automatically expanded in connection with traffic. It can be built.

In addition, the present invention has a standardized environment configuration, so users can develop their own plug-ins using the framework and run them on the system, thereby ensuring openness.

Figure 1 is a block diagram showing an automated service system using a no-code-based automated service platform according to the present invention.
Figure 2 is a block diagram showing a plug-in.
Figure 3 is a diagram showing an example of a UI component.
Figure 4 is an overall structural diagram of the engine core.
Figure 5 is a diagram of the internal structure of the engine core.
Figure 6 is a block diagram showing the task creation process.
Figure 7 is a flowchart showing step S100 in the automated service method using the no-code-based automated service platform according to the present invention.
Figure 8 is a flowchart showing step S200.
Figure 9 is a flowchart showing step S300.

Although the present invention may be subject to various changes and may have various embodiments, specific embodiments will be described in detail by illustrating them in the drawings. This is not intended to limit the present invention to specific embodiments, and is not intended to limit the present invention to any of the changes, equivalents, or substitutes included in the spirit and scope of the present invention for connecting and/or fixing structures extending in different directions. It must be understood as applicable.

The terms used herein are only used to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly dictates otherwise.

In this specification, terms such as “comprise” or “have” are intended to indicate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that it does not exclude in advance the existence or possibility of addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

Hereinafter, a preferred embodiment of an automated service system and method using a no-code-based automated service platform according to the present invention will be described with reference to the accompanying drawings.

Figure 1 is a block diagram showing an automated service system using a no-code-based automated service platform according to the present invention.

Referring to Figure 1, the present invention automatically programs a work scenario according to the user's input value, a user (terminal) that inputs and sets the target program of the work scenario, the repetition cycle of the scenario, and operating conditions, and the user's input value. It includes a no-code-based automation platform that automatically executes according to the requirements.

Users are terminals capable of computing operations and wired and wireless Internet communication, such as desktops and mobile terminals. Register the program that is the target of work and enter work scenario values (e.g., operation conditions, repetition cycle, end condition, operation period, etc.) through the registered program.

The no-code-based automation platform automatically programs work scenarios according to user input values and automatically executes work scenarios according to user input conditions. Here, the no-code-based automation platform converts the input scenario into predefined action logic and reprograms it for automation, enabling automatic execution of the scenario even without separate code (program).

To this end, the no-code-based automation platform may include a service member 100, a library member, and a service processing member 300.

The service member 100 may include a no-code web builder unit 110, a dashboard 120, a data backend unit 130, a DB 140, and a CACHE 150.

Among them, the no-code web builder unit 110 provides a function that allows the user to easily express the work scenario including the code name, start condition, and repetition cycle that the user wants to automate in logic form. In other words, when a user accesses this system through a website or app, he or she can set his or her desired tasks, schedule, and conditions through the screen and menu provided by the no-code web builder unit 110.

The no-code web builder unit 110 can query a list of predefined plug-ins 210 according to task information input from the user, query tasks that can be executed in each plug-in 210, and output the results. .

Additionally, the no-code web builder unit 110 can set an execution cycle so that the inquiry of the plug-in 210 as described above can be automatically executed.

For a more specific explanation, for example, the no-code web builder unit 110 connects the plug-in 210 (Plug-in) of the target code (e.g., Mail) by a command received or input from the user. If it meets the execution condition (for example, receipt of a new email), you can search for a work scenario that includes a scenario after receiving a new email within the plug-in 210.

Here, the no-code web builder unit 110 uses a plug-in 210 to enable selection of conditions through authentication and metadata (e.g., text containing an email, email sender) required for the task according to the user's input command. It is possible to query and search metadata.

The data backend unit 130 receives data set by the user through API and performs CRUD (Create, Read, Update, Delete) operations on the received data through DB 140 and CACHE 150.

The dashboard 120 outputs the results of work performed by the data backend unit 130. Therefore, the user can view the execution/failure/error details of the task on the dashboard 120.

The library member 200 includes a framework 220, a plug-in 210, and an engine core 230.

The framework 220 is a common framework 220 for codes used in the service member 100, library member 200, and service processing member 300, and contains information on methods and data types for data connection between modules. It can provide a standardized environment where internal and external users can write common code.

The plug-in 210 includes user plug-ins entered and registered by the user, and plug-ins provided in advance.

This plug-in 210 includes code for processing tasks, metadata containing how to express the UI to customers, and metadata necessary for execution. The plug-in 210 provides the above metadata to the user and service processing unit. The plug-in 210 will be described with reference to FIG. 2 .

Figure 2 is a block diagram showing a plug-in, and Figure 3 is a diagram showing an example of a plug-in.

Referring to Figures 2 and 3, the plug-in 210 contains a common interface and metadata information used by a customer to access data set in a specific platform/logic when creating a scenario.

To this end, the plug-in 210 may include UI component information, plug-in information, predefined logic for each action, action information, and an interface.

The interface includes the type of required data required to execute predefined logic for each action and whether input is required.

Referring to Figure 3a, UI component information is a pre-implemented component that allows data displayed in the interface for receiving information from customers to be received in UI form. It processes a specific task in the form of a program using input in advance and exports it as output. This is a component whose coding has been completed.

Here, the UI component information includes metadata (eg, title, description, logo, etc.) about the part shown to the user by the no-code web builder unit 110.

For example, the plug-in 210 is pre-produced and can be selected by the user on the screen by using the plug-in 210 meta information to configure a component as shown in Figure 3a on a web page and select a specific plug-in 210 from the component. Then, the plug-in 210 exposes a form (UI component information) for the user to input a list of required data (e.g., mail 1, mail 2, spreadsheet). Through this, users can perform authentication/operation settings/block environment settings such as specific blocks (e.g. email) on the UI panel.

Through this, the user can register his or her mail account in the component information displayed on the screen and then immediately check whether or not the mail has been received and check the mail, or whether or not data for a spreadsheet has been received or edited and confirmed.

Referring to FIG. 3B, action information contains metadata information of an action in which predefined logic supported by the corresponding plug-in 210 is implemented. Here, the action is a function. If the user adds an email plug-in and wants to perform specific actions (functions) when receiving an email in his or her mailbox, a new plug-in can be added below.

More specifically, the action information includes at least one of the required input information required for the description, title, and processing of functions that can be automated through the corresponding plug-in 210 (e.g., when receiving a new email, when returning an email, etc.), and executing the task. Period or delay time may also be included.

Plugin information is information about the plug-in 210, including minimum platform supportable version and description, multilingual information, information about the app implemented by the plug-in 210, plug-in 210 creator, plug-in license, plug-in production date, and most recent update date. , a list of required libraries, and at least one of the following constraints:

Through this, the plug-in 210 can pre-verify the user input value using the corresponding information.

Predefined logic for each action includes program logic for functions that can be automated through the plug-in 210 (e.g. when receiving a new email, returning an email, etc.) . The predefined logic for each action achieves the goal by executing the corresponding code when multiple functions combined by the actual user are combined.

For example, if a user combines an email plugin, a storage plugin, and a spreadsheet plugin, they can upload attachments from new emails to a specific cloud and organize the paths in a spreadsheet.

The engine core 230 can control task scheduling, auditing, etc., and provide task processing tools to the service processing unit.

For example, the present invention does not include a backend process for executing automated tasks. Therefore, the execution information of the automated service stores all executable information as metadata in the form of code in the form of Code As A Service. At this time, metadata contains execution cycle, execution condition information, and constraints in the form of YAML (Yet Another Markup Language) or JSON.

The engine core 230 reads the information contained in the above metadata and searches and schedules tasks based on the service execution cycle and metadata location. This is explained with reference to FIGS. 4 and 5.

Figure 4 is an overall structural diagram of the engine core, and Figure 5 is an internal structural diagram of the engine core.

Referring to Figures 4 and 5, the engine core 230 manages task information before each task is executed, and collects and processes the configuration information required for the task before a specific time (user-defined) when execution is required. It plays the main role.

In addition, the engine core 230 can control resource recovery of processes that have passed through the entire process of the service processing member 300 and control the service processing member to re-execute tasks that were executed and ended in the middle according to user conditions.

Additionally, in the present invention, the engine core 230 can be constructed with one main and multiple subs to avoid the well-known structural problem of Single Point of Failure. The main and multiple subs can operate as one server, and distributed processing is possible depending on the type of work or capacity.

In addition, the engine core 230 maintains the main system through broadcast communication and manages the automation process through communication between subs. And the engine core 230 can select the sub as the main when a failure occurs in the main. At this time, the logic may follow the Znode method, which is a known technology.

Referring to FIG. 5, the internal structure of each engine core named main/sub may include a storage module, a scheduler module 232, a process module 233, and a monitoring module 234. there is.

The storage module 231 is used to access and manage metadata information stored in the storage 350. For example, the storage 350 stores logs generated during the execution of an automation program, error information, temporary files used in actions, files saved by the user, etc. Additionally, the storage 350 stores the user's encrypted account information and subscription information (for billing) required to run the program.

The present invention is based on a completely isolated container, so when a task is executed, a container is created and when it is finished, temporarily stored files may disappear. Therefore, the storage module 231 stores the above information in the storage 350, loads the corresponding file according to the input command, and outputs and executes the file. In addition, files stored in the storage 350 can be output after going through an authentication process.

The scheduler module 232 may include NTP (Network Time Protocol) and a watchdog for accurate time synchronization for each core in order to process tasks at the correct time.

The process module 233 coordinates a global lock for synchronization of each node to prevent a task from being executed multiple times, logic for selecting the main among multiple subs in the event of a main failure, and error processing.

The monitoring module 234 includes logic for managing the work automation process. For example, the monitoring module 234 monitors whether the task is well prepared and the computer (container) is well prepared, as configuring serverless based on containers is like buying a new computer each time and executing and deleting the program. Each process is monitored to see if the computer (container resource) has been properly returned.

Additionally, the monitoring module 234 collects errors, logs, and various monitoring indicators (response time, CPU load, etc.) that occur in the engine where the actual user's program is executed.

The service processing member 300 may include a container engine 310, a job creation unit 320, a job execution unit 330, a job organizing unit 340, and a storage 350.

As the container engine 310 operates based on a standardized Kubernetes engine, it is logically isolated and can operate like a real server, and is built based on a standardized environment, so it is a data center in a desired location on a public cloud or private cloud. It can be performed in

Therefore, users can obtain the same security as if the task was executed on an actual isolated server, there is no need to build a separate IDC, and it can be automatically expanded in conjunction with traffic.

To be more specific, the container engine 310 receives metadata of task execution received from the engine core 230 and retrieves the code for the customized task in the form of a module. Then, the container engine 310 takes the authentication or configuration information entered through the task execution command and converts it into a form that can be input into the module.

In the information of the plug-in 210 described above, predefined execution logic of the action is written. Since the logic in question is not a program but the internal logic of the program, in order for the program (code) to become a complete program, it must be created in an executable (for example, .exe) form.

To this end, the container engine 310 performs a process of programming predefined action logic into an executable program.

A simple example of predefined logic is as follows.

function action_logic(input:InputProps):OutputProps {

//actual program

}

In other words, the container engine 310 takes code such as predefined logic from the plug-in information added by the user and changes it into a structured form as above to create an executable program.

Accordingly, the code of the actions selected by the user (eg, when a new email is received) is converted into a structured form in the form of a predefined module by the container engine 310.

In addition, the container engine 310 is configured based on standardized Kubernetes, so it creates a container that performs the above process for each work scenario, and the container can be deleted after the work is completed.

The task creation unit 320 programs (.exes) the module information and metadata converted from the container engine 310 into a predefined structured form into one program that sequentially connects input and output. . This is explained with reference to FIG. 6.

Figure 6 is a block diagram showing the job service creation process of the job creation unit.

Referring to FIG. 6, the task creation unit 320 generates an independently executable task service (for example, setting information in the form of a task scenario). For example, the task creation unit 320 records information necessary for auditing, such as verification of input/output of action logic for programming and errors/logs, in the storage 350, and issues an Exit code to return resources upon completion. Allows modules to operate as programs.

For example, the task creation unit 320 generates action logic when an email is received, branching action logic depending on the presence or absence of an attachment related to receiving the email, action logic depending on the presence or absence of drive storage, and spreadsheet columns. Action logic is sequentially created according to the presence or absence of additions.

Here, the action logic is a programmed module as above, and is converted into an executable form after going through the process of verifying the input value, whether the user takes action, and whether there is an error in the task creation unit 320 itself.

Then, the task creation unit 320 stores result/occurrence data according to each action logic in the storage 350.

The task execution unit 330 loads program execution information metadata (eg, authentication information, execution information) and an independently executable program. Accordingly, when the set execution time corresponds to the set execution time, the task execution unit 330 executes the task service and stores success or failure information and dump information (Dump) in case of an error in the storage 350.

The task organizing unit 340 performs the task of organizing all computing resources required for task execution.

The present invention includes the above-described configuration, and hereinafter, an automated service method using a no-code-based automated service platform according to the present invention will be described.

The automated service method using the no-code-based automated service platform according to the present invention includes a step S100 of storing the user's work, a step S200 of preparing to execute the automation program of the engine core 230, and automation of the service processing member 300. It includes the S300 step of executing the task as a program.

Of these, step S100 will be described with reference to FIG. 7, step S200 with reference to FIG. 8, and step S300 with reference to FIG. 9.

Figure 7 is a flowchart showing step S100 in the automated service method using the no-code-based automated service platform according to the present invention.

Referring to FIG. 7, step S100 includes step S110 in which the service member 100 verifies task-related data entered by the user, step S120 in which the version of metadata is checked, and step S130 in which compliance with the minimum operating version is checked. It includes a step S140 of storing data, and a step S150 of checking whether the operation is active or not.

Step S110 is a step in which the service member 100 verifies whether there is an error in the data entered by the user. Service member 100 checks whether input values such as string and date are correct according to the schema that defines the user's input data through plug-in metadata, and checks whether required input values of the plug-in, such as authentication or file location, have been entered by the user. .

Step S120 is a step to check the metadata version. The service member 100 checks the metadata version when, for example, a web application defines a program to be executed on a screen where the user inputs a user's input. At this time, the no-code web builder unit 110 or the data backend unit 130 of the service member 100 checks the version information of the schema representing the metadata of the plug-in 210.

This can be viewed as an acceptable version if it can operate even if there are no new items in the existing data stored by previously created tasks when new items are created as the metadata is upgraded.

Step S130 is a step to check compliance with the operating version. Here, the absence of service 100 prevents the plug-in from being displayed in the component list in advance or exposes an information pop-up if the version of the plug-in previously selected by the user does not fall within the range of plug-in operation versions supported.

For this purpose, when the data of the user-defined program (action connection data of the plug-in 210 and the action) is delivered to the data backend 130 in JSON format, the service member 100 provides user information and user information based on the DB 140. Authentication information is compared, and the transmitted user data is secondarily verified by comparing it with metadata (plugin information) of the predefined plug-in 210.

Step S140 is a step in which the data backend unit 130 stores data in the DB 140. Stored information may include author information, addition and modification times, and data for configuring the screen.

Step S150 is a step to check whether the task is activated. The service member 100 can check whether or not a task is activated according to the user's input value. Here, task activation means, for example, execution of a task set to continuously retrieve mail at time intervals (e.g. 5 minutes) set by the user. This task activation or non-existence step may be executed in conjunction with step S300 of the service processing member 300, which will be described later.

Figure 8 is a flowchart showing step S200.

Referring to FIG. 8, step S200 includes step S210 of loading a scheduled task, step S220 of checking whether it is executed, step S230 of checking whether the data is normal, and checking the list of plug-ins 210 and loading metadata. It includes steps S240, step S250 of cross-verification, and step S260 of packaging and transmitting data.

Step S210 is a step of loading execution information of the scheduled task in the engine core 230. Here, when a task is activated by a command input by the user, the engine core 230 executes the task periodically according to a set schedule to process the task. At this time, information such as the execution cycle, schedule, task type, and task scenario of the task is transmitted as execution information and the information is stored.

Step S220 is a step in which the engine core 230 checks execution by cross-comparing data stored in the database and data loaded. For example, if only user input values are used for execution information, there is a possibility that system manipulation, information theft, or security problems may occur due to user values. Therefore, the engine core 230 undergoes authentication and authorization through cross-matching with user information (e.g., account information, subscription information) stored in the server.

Step S230 is a step in which the engine core 230 checks whether the data is normal. For example, if the data is normal, the operation may proceed, and if not, an error may occur. Therefore, the engine core 230 outputs error information to the user when an error occurs.

Step S240 is a step in which the engine core 230 checks the plug-in 210 list and loads metadata. The user's input data may include information related to the scenario in which the task is executed.

For example, if the information related to the scenario for task execution is created and stored before the plug-in 210 is newly developed or updated, and then activated by the user, a situation may occur where it cannot be operated now even if the information was normal at the time. there is.

Therefore, the engine core 230 loads the metadata of the plug-in 210 for cross-verification.

The S250 step is a cross-verification step by the engine core. The engine core 230 may cross-verify the loaded metadata and the user's input data in step S240 and transmit error information to the user if an error occurs.

Step S260 is a step in which the engine core 230 packages and transmits data. If the task scenario entered by the user is determined to be an executable program, the engine core 230 packages the information necessary for execution (e.g., metadata, plug-in information, user input data) to make it a task that can be executed periodically. Information (including authentication data) is transmitted to the container engine 310.

Figure 9 is a flowchart showing step S300.

Referring to FIG. 9, step S300 includes step S310 of loading metadata from the service processing member 300, step S320 of unpackaging, step S330 of inputting program/execution time information and metadata, and registering execution. Step S340, step S350 of executing the task, step S360 of checking whether execution has been completed, step S370 of storing and transmitting related information to the engine core 230 when execution completion is detected, and an error error if execution is not completed. It includes step S380 of generating metadata and dumps and transmitting them to the engine core 230.

In step S310, the service processing member 300 (e.g., container engine 310) receives user input data from the no-code web builder unit 110, and predefined plug-in metadata (module) from the library member 200. This is a step of retrieving metadata including at least one of information), X509 certificate, program information, execution time information, and user subscription information from the DB 140 and/or storage 350.

Step S320 is a step of decoding and cross-verifying data loaded from the container engine 310 of the service processing member 300. Metadata is stored encrypted by default. Therefore, after loading the metadata, the container engine 310 decrypts the encrypted metadata and cross-verifies it to check whether it is normal.

Step S330 is a step where the service processing member 300 inputs and registers cross-verified metadata and program and execution time information input from the user into the work schedule. The task creation unit 320 verifies the schedule of the scheduler module 232 by setting the automated program created in an executable form in the container engine 310 and the decrypted metadata as input and registers the task schedule.

Step S340 is a step in which the service processing member 300 executes a registered program. The task execution unit 330 automatically executes the registered program according to the set task schedule or set conditions and outputs the results.

Step S350 is a step in which the service processing member 300 checks whether execution has been completed. The task execution unit 330 checks whether the program has completed its work by checking the result value and the ExitCode of the program. Here, ExitCode can follow the ExitCode mechanism of a typical Linux program, and the output value is recorded if an error occurs during execution, so you can check whether it is running normally.

Step S360 is a step in which the service processing member 300 confirms that task execution is complete and stores the information in the storage 350. Here, the task execution unit 330 transmits all information related to program execution to the engine core 230. And the engine core 230 stores the received information in the storage 350.

Step S370 is a step in which, if it is confirmed that it was not executed in step S350, error meta data and dump information are generated and transmitted to the engine core 230. Here, the engine core 230 stores the received error metadata and dump information in the storage 350.

As described above, the present invention has been described with reference to the illustrative drawings, but the present invention is not limited to the embodiments and drawings described above, and those skilled in the art in the technical field to which the present invention pertains within the scope of the patent claims. Various implementations are possible.

100: No service
110: No-code web builder part
120: Dashboard
130: Data backend unit
140 : DB
150 : CACHE
200: Library absent
210: plug-in
220: Framework
230: Engine core
300: Service processing absence
310: container engine
320: Task creation unit
330: task execution unit
340: Work organizer
350: Storage

Claims (13)

A no-code-based automation platform that automatically programs work scenarios according to input values of a user who inputs and sets at least one of the name, execution cycle, and operating conditions of the target task of the work scenario, and automatically executes the work scenarios according to the user input values; Including,
The no-code based automation platform is
A plug-in 210 containing code (program) to perform a set task, metadata containing how to express the customer's UI, and metadata necessary for execution;
A no-code web builder unit 110 that searches for and outputs the location of metadata of the plug-in 210 that matches at least one of the task name, execution cycle, and operating conditions included in the user's input value;
At least one of the name, execution cycle, and location of meta data of the task is received from the no-code web builder unit 110, and if it corresponds to the execution cycle of the task, the meta data of the task execution searched by the no-code web builder unit 110 An engine core 230 that sequentially loads data;
A container engine 310 that receives user input and task execution metadata from the engine core 230 and registers module information converted into action logic predefined as an executable program;
A task creation unit 320 that generates a task scenario as a program in an executable form after going through a process of checking for errors in the predefined action logic of the container engine 310; and
a task execution unit 330 that loads and executes the task scenario generated by the task creation unit 320 if the execution conditions set in the task scenario are met; Including,
Engine core 230 is
It is constructed with one main and a plurality of subs, and the plurality of subs maintain the main through communication, control whether or not to automatically execute work scenarios, monitor the execution process and results, and store them in the storage 350; Automation service system using a no-code-based automation service platform characterized by .
delete The method of claim 1, wherein the no-code web builder unit 110 checks the plug-in 210 of the target code (program) according to a command received or input from the user, and if it meets the execution conditions, plug-in 210 ) to search for tasks within the task and output a selection list of conditions through authentication and metadata required for the task; Automation service system using a no-code-based automation service platform characterized by .
The method of claim 1, wherein the plug-in 210
A list of required data as a form to be input by the user by the no-code web builder unit 110, and UI component information constituting a UI panel for authentication, operation settings, and environment settings;
Action information that contains metadata information of an action in which predefined logic supported by the corresponding plug-in 210 is implemented, allowing the addition of a new plug-in 210 to perform a specific action;
Platform supportable versions and descriptions, multilingual information, information about apps implemented by plug-in (210), plug-in (210) creator, plug-in (210) license, plug-in (210) production date, latest update date, list of required libraries, etc. Plugin information including at least one of the constraints; and
Predefined logic for each action, including program logic for functions that can be automated through the plug-in 210; Automation service system using a no-code-based automation service platform that includes.
delete In claim 1, the engine core 230 is
a storage module 231 that accesses and manages metadata information stored in the storage 350;
Scheduler module 232 including Network Time Protocol (NTP) and watchdog for time synchronization; and
a monitoring module 234 that collects information on at least one of errors, logs, response time, and CPU load that occur in the engine in which the user's program runs, and monitors the execution process of the work scenario; Automation service system using a no-code-based automation service platform that includes.
The method of claim 1, wherein the structured form of predefined action logic of the container engine 310 is
function action_logic(input:InputProps):OutputProps {
//actual program
}
being; Automation service system using a no-code-based automation service platform characterized by .
The method of claim 1, wherein the task creation unit 320
Verifying the input/output of the action logic to package it as a program, recording information required for auditing in the storage 350, and issuing an Exit code to return resources upon termination; Automation service system using a no-code-based automation service platform characterized by .
The method in claim 1, wherein the task execution unit 330
Loads metadata containing execution information and authentication information and an independently executable program, executes a task scenario when it falls within the set execution time, determines whether it succeeds or fails, and stores dump information (Dump) in case of an error (350). to save to; Automation service system using a no-code-based automation service platform characterized by .
In the automated service method using a no-code-based automated service platform by the system of claim 1,
a) storing job setting information including an input value included in at least one of the job start time, target code, and scenario entered by the user in the service member 100;
b) Receiving the user's task information and the metadata location of the plug-in 210 from the engine core 230, and sequentially loading the plug-in metadata required for the task when it corresponds to the task time and transmitting it to the container engine 310. ; and
c) modularizing the plug-in metadata and user input values received from the service processing member 300 into predefined logic, programming it into an automatically executable program, automatically executing the result, and storing the result in the storage 350; Including,
Step b) is
b-1) When a task is activated by a user's input command, the engine core 230 receives and stores information including at least one of the execution cycle, schedule, task type, and task scenario of the task;
b-2) the engine core 230 checking the plug-in 210 list and loading metadata of the plug-in 210;
b-3) the engine core 230 cross-verifies the metadata of the loaded plug-in 210 and the user's input data and, if an error occurs, transmits error information to the user; and
b-4) If the engine core 230 determines that the task scenario entered by the user is an executable program, the engine core 230 collects user input data including metadata, plug-in information, and authentication information required for execution to make it a task that can be executed periodically. packaging and transmitting to the container engine 310; Automation service method using a no-code-based automation service platform including.
delete The method of claim 10, wherein step c) is
c-1) Receiving metadata containing at least one of the user's input data, plug-in metadata (module information), X509 certificate, program information, runtime information, and user's subscription information from the container engine 310. ;
c-2) Decoding the data loaded from the container engine 310, checking whether it is normal, and converting it into a predefined action logic form so that it can be executed;
c-3) the task creation unit 320 registering a task schedule by setting an automated program made executable in the container engine 310 and decrypted metadata as input;
c-4) the task execution unit 330 executing the registered program according to the setting information and storing the result; and
c-5) the task execution unit 330 checks the result value and the ExitCode of the program to determine whether the task of the program has been completed, and when task execution is completed, storing the completion information in the storage 350; Automation service method using a code-based automation service platform.
Combined with a computing device,
A computer program stored in a recording medium readable by a computing device to execute an automated service method using the no-code-based automated service platform of any one of claims 10 and 12.

Images