A method for cleaning historical versions of rule files based on blaze decision engine

Abstract

This invention relates to the field of Linux software technology and discloses a method for cleaning up historical versions of rule files based on the Blaze decision engine. The method includes the following steps: Step 1: Prepare a script to obtain file paths, named getFilePaths.sh; Step 2: Place the getFilePaths.sh script in the rule base project path; Step 3: Execute the getFilePaths.sh script; Step 4: Open the Qizheng decision engine system - delete historical version project; Step 5: Create a script based on the generated deletion paths and upload it to the server for execution. With this invention, users only need to execute a simple script, getFilePaths.sh, which automatically obtains all file paths in the specified directory and generates a list, saving significant time and effort. Users can use familiar tools such as Excel to process the generated file paths and delete unnecessary paths through simple batch replacement operations, achieving the beneficial effects of simple cleaning, ease of operation, and easy understanding.

Description

Technical Field

[0001] This invention relates to the field of Linux software technology, specifically to a method for cleaning up historical versions of rule files based on the Blaze decision engine. Background Technology

[0002] During the use of the Fico Blaze decision engine, each time the rule component submits and checks in a new version, a historical version file is generated in the backend. Due to the large number of projects and configured rules, this leads to an ever-growing number of historical rule version files, consuming a significant portion of the project's space. This, in turn, causes Blaze to lag, project loading to slow down, and other issues affecting system efficiency. Therefore, cleaning up the historical rule version files generated in the backend can effectively reduce project space consumption and improve system efficiency.

[0003] The system is deployed on a Linux server. Due to the complex filtering logic for deleting historical version files, it is difficult to clean them up directly using a shell script. The script is complex to write, very difficult to write, and prone to problems. Summary of the Invention

[0004] Technical problems to be solved:

[0005] To address the shortcomings of existing technologies, this invention provides a method for cleaning up historical versions of rule files based on the Blaze decision engine. This method is simple to implement, easy to operate and understand; the cleaning operation is more efficient, accurate and less risky than manual deletion, thus solving the problems mentioned above.

[0006] Technical solution:

[0007] To achieve the above objectives, the present invention provides the following technical solution: a method for cleaning up historical versions of rule files based on the Blaze decision engine, comprising the following steps:

[0008] Step 1: Prepare a script to get file paths, named getFilePaths.sh;

[0009] Step 2: Place the getFilePaths.sh script in the rule base project path;

[0010] Step 3: Execute the getFilePaths.sh script to obtain the file_paths.txt file. Use the sz file_paths.txt command to download it to your local machine. Copy the contents of file_paths.txt into Excel. Use Excel's replace function to delete the path before Business User Projects / . Save the file to the root directory of drive D.

[0011] Step 4: Open the Qizheng Decision Engine System - Delete historical version projects;

[0012] Step 5: Create a script based on the generated deletion path and upload it to the server to run.

[0013] Preferably, the script content in step one is as follows:

[0014] #! / bin / bash

[0015] # Specify the path to the output txt file

[0016] output_file="file_paths.txt"

[0017] script_dir=$(pwd)

[0018] target_dir="$script_dir / Business User Projects"

[0019] find "$target_dir" -type f | sort>"$output_file"

[0020] echo "File path has been saved to $output_file".

[0021] Preferably, the rule base path in step two is: / home / hcuser / app / Blaze77 / BlazeRepository.

[0022] Preferably, step four includes the following detailed steps:

[0023] S4.1 Initialize printing: Print the log and indicate that processing has begun;

[0024] S4.2 Set the file import path: Import the .xlsx file to be deleted from drive D, and print the file import path log;

[0025] S4.3 Obtain the original data of the file: Extract the contents of sheet1 in the .xlsx file to be deleted and save it to the file path memory table. The file path memory table only has one column: file path.

[0026] S4.4 File Category Path Storage: Traverse the file path memory table saved in S4.3, and insert the results into the file category 1 memory table based on the following conditions: the file path contains / __Attic / and does not contain version and does not contain innovator_attbs. The file category 1 memory table also only has the file path 1 column.

[0027] S4.5, Number of records in the memory table for print file category 1;

[0028] S4.6, Generate the path partitioning table rule set:

[0029] S4.7. Obtain the array of deduplicated rule names: Summarize the path partition table, with the summary columns being first, middle, last1, last2, and max(last2), the grouping columns being first and last1, and the condition column being empty. Insert all the deduplicated data into the deduplicated path partition table and print the number of records in the log deduplicated path partition table.

[0030] S4.8 Generate the final path storage table rule set: Traverse the deduplicated path partitioning table in memory;

[0031] S4.9, Final Path Table Generation: Traverse the path storage table, concatenate the first, middle, last1, buchong, and last2 of the path storage table together, and store them in the file path field of the final path table memory table. The buchong field is a supplementary delimiter field used for concatenating paths, and its value is a single underscore _.

[0032] S4.10, End Printing: Save the data of the final path table to: D drive: Files to be deleted version path final table.xlsx; Print log, total number of files to be deleted: retrieve the number of records in the final path table; Print log, final table export path: D:\\Files to be deleted version path final table.xlsx; Print log, -----***Processing ended***-------.

[0033] Preferably, step S4.6 further includes the following detailed steps:

[0034] S4.6.1 Character segmentation: Traverse the file category 1 memory table, assign the file path field of the file category 1 memory table to the path (temporary variable) and print it out, then split the path into a character array according to / __Attic / and assign it to the segmentation array variable, then take the [1]th data of the segmentation array variable, and then split the array according to _ and assign it to the secondary segmentation array variable;

[0035] S4.6.2, Determine Storage: The created path partitioning memory table is judged based on the length of the secondary partitioning array variable. Therefore, if the storage rule satisfies the "otherwise" logic, data is inserted into the path partitioning memory table. The first field stores the 0th position of the partitioning array, i.e.: Self-operated Cash Loan Folder / ZYSX Self-operated Quota / Decision Flow Management; the middle field stores / __Attic / ; the last1 field stores: ZYSX_N070 Quota Pricing Strategy; and the last2 field stores: 1.

[0036] Preferably, step S4.8 further includes the following detailed steps:

[0037] S4.8.1 Variable initialization: Convert the last2 field of the deduplicated path partitioning table to int type and assign it to the i variable, and assign the last1 field of the deduplicated path partitioning table to the rule name variable;

[0038] S4.8.2 Traverse the path partition table: The condition is that the value of the rule name variable is equal to the value of the last1 field of the path partition table and the value of the first field of the path partition table after deduplication is equal to the first value of the path partition table.

[0039] S4.8.3 Path Storage Table Generation: Insert records into the path storage table memory table. Insert the fields in the path partition table into the path storage table according to the corresponding relationship. The path storage table has an additional buchong field with the value stored as an underscore (_). Insert 2 records at a time. Insert .innovator_attbs into the last2 field of the path storage table.

[0040] Preferably, the length of the example quadratic segmentation array in S4.6.1 is 3.

[0041] Preferably, the path partitioning memory table built in S4.6.2 has 4 fields.

[0042] Preferably, in S4.8.2, the last2 field of the conversion path partitioning table has an integer value less than variable i.

[0043] Preferably, the difference between the second and first lines of the median deposit certificate underline in S4.8.3 is that the last2 field should be concatenated with the last2 in the path partitioning table;

[0044] Preferably, the detailed steps of step five are as follows:

[0045] S5.1 Copy the file version path final table.xlsx to be deleted in step 3 to a text file, open it, replace spaces with backslashes \, search for the & symbol, replace it with \& or delete the path containing the & symbol, search for English parentheses, and replace () with \(\). Note: Only replace English format.

[0046] S5.2 Copy the replaced text to Excel, add `rm -rf`, then copy it to a TXT file and add a first line.

[0047] Compared with existing technologies, this invention provides a method for cleaning up historical versions of rule files based on the Blaze decision engine, which has the following beneficial effects:

[0048] 1. This invention effectively achieves a highly efficient, easy-to-operate, and easy-to-understand cleanup process through multiple simplified operation steps and automated scripts. The overall method refines complex cleanup logic into clear and specific steps, allowing users to easily follow along. Users only need to execute a simple script, getFilePaths.sh, which automatically retrieves all file paths in a specified directory and generates a list, saving significant time and effort. Users can then use familiar tools such as Excel to process the generated file paths, deleting unnecessary paths through simple batch replacement operations—a process that is intuitive and convenient. In subsequent steps, the method uses conditional filtering and categorization of file paths to explicitly retain only files that meet specific criteria. This easily understandable logical design reduces the risk of errors and ensures accurate filtering results. The detailed logging function included in the cleanup process provides real-time feedback on the processing status, enhancing the user's sense of control over the operation. Whether technical or non-technical, this user-friendly design allows everyone to more easily participate in the maintenance of rule files, achieving the beneficial effects of simple cleanup, ease of operation, and easy understanding.

[0049] 2. This invention sets clear filtering criteria, ensuring that only files meeting specific requirements are retained or deleted. This reduces errors that may occur during manual selection. Because the entire cleanup process follows a unified processing standard, the logical consistency of different steps reduces the risk of inconsistencies and omissions during operation, ensuring the accuracy of the final result. Real-time logging provides timely feedback on the current operation status, helping users monitor the execution process and reducing errors caused by improper operation. The fully automated process minimizes human intervention, reduces the risk of accidentally deleting important files, enhances system security, and achieves the beneficial effects of higher efficiency, higher accuracy, and lower risk compared to manual deletion. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of the method flow of the present invention; Detailed Implementation

[0051] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] Please see Figure 1 ,

[0053] The entire cleaning process is broken down into clearly defined steps, each with a specific purpose. This breakdown makes the process less confusing and reduces operational complexity.

[0054] For example, the steps to obtain file paths are very intuitive; you only need to execute a script to automatically generate the required list of file paths.

[0055] The getFilePaths.sh script automates the process of retrieving file paths, improving efficiency. Users simply execute the script, and the system automatically handles file searching and saving, reducing manual intervention.

[0056] The script is designed so that even non-professional users can easily understand its functions and learn how to use it.

[0057] Using Excel for data processing makes full use of many tools that users are already familiar with. Excel's replace function facilitates batch editing of paths, reducing the learning curve.

[0058] This step transforms complex text processing into simple graphical operations, making it easy for even those without a programming background to complete.

[0059] In step four, the complex path cleanup logic is simplified into a few clear conditional judgments through conditional filtering and classification. Users only need to focus on specific keywords and path structures, making file classification easier and more intuitive.

[0060] This method helps users quickly identify files that need to be deleted, reducing the time spent on manual checks.

[0061] Each step has a specific operating guide, and this step-by-step design makes it easy for users to follow, especially for those who are unfamiliar with the system or file management.

[0062] The specified path and the determinacy of the output file allow users to clearly understand their goals when performing each step.

[0063] The method includes a logging function that provides real-time feedback on the processing status, enhancing the user's sense of control and security. Knowing the current processing flow reduces uncertainty and increases confidence.

[0064] This method is based on general-purpose scripts and Excel tools, making it highly applicable and not dependent on specific operating systems or software versions, thus making it more flexible.

[0065] This approach can be adapted to suit the specific needs of different user groups.

[0066] By automating and simplifying the process, this method significantly improves the efficiency of cleaning up historical rule files, saving time and labor costs. These savings are particularly important in long-term rule management.

[0067] Clear path filtering criteria and classification logic provide accurate file identification, reduce the risk of accidental deletion and omission, and help maintain the cleanliness and effectiveness of the system.

[0068] The process is simplified into easy-to-understand steps, enhancing the user experience. Both technical and non-technical personnel can easily participate in the maintenance of the rule files.

[0069] This method can be easily reused and modified to adapt to possible future changes, such as updates to the file structure or new classification requirements, thereby improving the long-term effectiveness of the method.

[0070] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for cleaning up historical versions of rule files based on the Blaze decision engine, characterized in that, Includes the following steps: Step 1: Prepare a script to get file paths, named getFilePaths.sh; Step 2: Place the getFilePaths.sh script in the rule base project path; Step 3: Execute the getFilePaths.sh script to obtain the file_paths.txt file. Use the sz file_paths.txt command to download it to your local machine. Copy the contents of file_paths.txt into Excel. Use Excel's replace function to delete the path before Business User Projects / . Save the file to the root directory of drive D. Step 4: Open the Qizheng Decision Engine System - Delete historical version projects; Step 5: Create a script based on the generated deletion path and upload it to the server to run; The script content in step one is as follows: #! / bin / bash # Specify the path to the output txt file output_file="file_paths.txt" script_dir=$(pwd) target_dir="$script_dir / Business User Projects" find "$target_dir" -type f | sort>"$output_file" echo "File path has been saved to $output_file"; The rule base path in step two is: / home / hcuser / app / Blaze77 / BlazeRepository; Step four includes the following detailed steps: S4.1 Initialize printing: Print the log and indicate that processing has begun; S4.2 Set the file import path: Import the .xlsx file to be deleted from drive D, and print the file import path log; S4.3 Obtain the original data of the file: Extract the contents of sheet1 in the .xlsx file to be deleted and save it to the file path memory table. The file path memory table only has one column: file path. S4.4 File Category Path Storage: Traverse the file path memory table saved in S4.3, and insert the results into the file category 1 memory table based on the following conditions: the file path contains / __Attic / and does not contain version and does not contain innovator_attbs. The file category 1 memory table also only has the file path 1 column. S4.5, Number of records in the memory table for print file category 1; S4.6, Generate the path partitioning table rule set: S4.

7. Obtain the array of deduplicated rule names: Summarize the path partition table, with the summary columns being first, middle, last1, last2, max(last2), the grouping columns being first, last1, and the condition column being empty. Insert all the deduplicated data into the deduplicated path partition table and print the number of records in the log deduplicated path partition table. S4.8 Generate the final path storage table rule set: Traverse the deduplicated path partitioning table in memory; S4.9, Final Path Table Generation: Traverse the path storage table, concatenate the first, middle, last1, buchong, and last2 of the path storage table together, and store them in the file path field of the final path table memory table. The buchong field is a supplementary delimiter field used for concatenating paths, and its value is a single underscore _. S4.

10. End printing: Save the final path table data to: file_to_be_deleted_version_path_final_table.xlsx in drive D; Print logs showing the total number of files to be deleted: retrieve the number of records from the final path table; print logs showing the final table export path: D:\\files to be deleted version path final table.xlsx; Print log, -----***Processing complete***-------.

2. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 1, characterized in that: S4.6 further includes the following detailed steps: S4.6.1 Character segmentation: Traverse the file category 1 memory table, assign the file path field of the file category 1 memory table to the path (temporary variable) and print it out, then split the path into a character array according to / __Attic / and assign it to the segmentation array variable, then take the [1]th data of the segmentation array variable, and then split the array according to _ and assign it to the secondary segmentation array variable; S4.6.2, Determine Storage: The created path partitioning memory table is judged based on the length of the secondary partitioning array variable. Therefore, if the storage rule satisfies the "otherwise" logic, data is inserted into the path partitioning memory table. The first field stores the 0th position of the partitioning array, i.e.: Self-operated Cash Loan Folder / ZYSX Self-operated Quota / Decision Flow Management; the middle field stores / __Attic / ; the last1 field stores: ZYSX_N070 Quota Pricing Strategy; and the last2 field stores:

1.

3. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 2, characterized in that: S4.8 also includes the following detailed steps: S4.8.1 Variable initialization: Convert the last2 field of the deduplicated path partitioning table to int type and assign it to the i variable, and assign the last1 field of the deduplicated path partitioning table to the rule name variable; S4.8.2 Traverse the path partition table: The condition is that the value of the rule name variable is equal to the value of the last1 field of the path partition table and the value of the first field of the path partition table after deduplication is equal to the first value of the path partition table. S4.8.3 Path Storage Table Generation: Insert records into the path storage table memory table. Insert the fields in the path partition table into the path storage table according to the corresponding relationship. The path storage table has an additional buchong field with the value stored as an underscore (_). Insert 2 records at a time. Insert .innovator_attbs into the last2 field of the path storage table.

4. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 3, characterized in that: The length of the example quadratic segment array in S4.6.1 is 3.

5. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 4, characterized in that: The path partitioning memory table built in S4.6.2 has 4 fields.

6. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 5, characterized in that: In S4.8.2, the last2 field of the conversion path partition table is an integer value less than variable i. In S4.8.3, the difference between the second and first values ​​of the value deposit slip underline is that the last2 field should be concatenated with the last2 values ​​in the path partition table.

7. The method for cleaning up historical versions of rule files based on the Blaze decision engine according to claim 1, characterized in that: The detailed steps of step five are as follows: S5.1 Copy the file version path final table.xlsx to be deleted in step 3 to a text file, open it, replace spaces with backslashes \, search for the & symbol, replace it with \& or delete the path containing the & symbol, search for English parentheses, and replace () with \(\). Note: Only replace English format. S5.2 Copy the replaced text to Excel, add `rm -rf`, then copy it to a TXT file and add a first line.

Images