Storage procedure calling and business process decoupling method and system based on declarative configuration
The declarative configuration method of decoupling stored procedure calls from business processes solves the problem of tight coupling between stored procedure calls and business processes, improves code maintainability and development efficiency, enhances system scalability, and is applicable to multiple databases and business processes.
Patent Information
- Application Number
- CN202510711418.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-29
- Publication Date
- 2025-09-19
AI Technical Summary
In the existing technology, the tight coupling of stored procedure calls and business processes leads to difficult code maintenance, low development efficiency and poor scalability, making it difficult to adapt to complex business changes.
A method of decoupling stored procedure calls from business processes based on declarative configuration is adopted. Through the CHECK module, syntax parser, stored procedure execution layer and business process control layer, declarative configuration and decoupling of stored procedure call information are achieved, and text files with custom syntax formats and ADO.NET are used for stored procedure calls.
It significantly reduces the amount of business code modifications when changing stored procedures, improves development efficiency and system scalability, reduces code conflicts, supports multiple database types and adapts to different business processes.
Smart Images

Figure CN120669988A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field related to database storage, and in particular to a method and system for decoupling stored procedure calls from business processes based on declarative configuration. Background Art
[0002] In the systems of the electronics manufacturing industry, database stored procedures are widely used. They can encapsulate complex data processing logic on the database side, improving the efficiency and security of data processing. With the continuous development of the business, business processes have become more and more complex, and the coupling problem between stored procedure calls and business processes has gradually become prominent. In the early days, developers mainly used hard coding to directly call stored procedures in business code. This method could meet the needs when the business scale was small, but as the business grew, code maintenance and expansion became increasingly difficult. Later, although some configuration ideas emerged, most of them were not flexible and efficient enough, and could not effectively solve the problem of strong coupling between stored procedure calls and business processes;
[0003] Existing technology:
[0004] In traditional C# development, ADO.NET is often used to call database stored procedures. The following is a simple example code:
[0005]
[0006]
[0007] In this example, the call to the stored procedure is directly embedded in the business code, and the business logic and the call to the stored procedure are tightly bound.
[0008] The above-mentioned prior art has the following problems:
[0009] (1) Difficulty in code maintenance: When the parameters, name, or logic of a stored procedure change, a large number of modifications must be made to the business code. For example, if the parameters of the stored procedure YourStoredProcedure change, the command.Parameters.AddWithValue code must be modified. According to statistics, in a medium-sized project, a single change to a stored procedure may result in modifications to hundreds of lines of business code, accounting for 20%-30% of the total business code.
[0010] (2) Low development efficiency: Because stored procedure calls are tightly coupled with business code, conflicts can easily arise when different developers modify stored procedures and business code. For example, if Developer A is modifying a stored procedure while Developer B is simultaneously modifying the business code that calls the stored procedure, this can lead to code conflicts and extend the development cycle. Generally speaking, such conflicts can extend the development cycle by 15%-25%.
[0011] (3) Poor scalability: Traditional methods are difficult to quickly adapt to new stored procedures or changes in business processes. When adding a new stored procedure call, the call logic needs to be rewritten in the business code, increasing development costs and time.
[0012] In order to solve the above problems, this application proposes a method and system for decoupling stored procedure calls from business processes based on declarative configuration. Summary of the Invention
[0013] The purpose of the present invention is to provide a method and system for decoupling stored procedure calls from business processes based on declarative configuration, aiming to solve the problem of strong binding between stored procedure calls and business codes in traditional coding mode, improve the maintainability of code, development efficiency and scalability of the system, and realize the decoupling of stored procedure calls from business processes.
[0014] To achieve the above object, the present invention provides the following technical solutions:
[0015] A system for decoupling stored procedure calls from business processes based on declarative configuration includes a CHECK module, a syntax parser, a stored procedure execution layer, and a business process control layer. The CHECK module outputs configuration information to the syntax parser, the syntax parser passes the parsing results to the stored procedure execution layer, and the execution results of the stored procedure execution layer are fed back to the business process control layer.
[0016] As a further solution of the present invention: the CHECK module is responsible for configuring the call information of the stored procedure in a declarative manner, and the configuration information is stored in a text in a custom syntax format.
[0017] As a further solution of the present invention: the syntax parser is used to parse the configuration file of the CHECK module and convert it into instructions that can be recognized by the system.
[0018] As a further solution of the present invention: the stored procedure execution layer is used to call the corresponding stored procedure according to the parsed instruction.
[0019] As a further solution of the present invention: the business process control layer is responsible for the flow of the business process and determines the next step of the business process according to the execution result of the stored procedure.
[0020] The decoupling method of stored procedure calls from business processes based on declarative configuration is as follows:
[0021] Step 1: Configure the stored procedure call information in the CHECK module configuration file according to the custom syntax format;
[0022] Step 2: The parser parses the configuration file and generates call instructions;
[0023] Step 3: The stored procedure execution layer calls the FULL_CHECK_USER stored procedure to determine the user;
[0024] Step 4: The business process control layer continues to process the business process according to the configured return action based on the execution result of the stored procedure.
[0025] As a further solution of the present invention: in step 3, the TSMT_MsdOpenexpiry stored procedure is called to unseal the MSD volume and record the log at the same time.
[0026] As a further solution of the present invention: in step three, ADO.NET is used to implement the call of the stored procedure.
[0027] As a further solution of the present invention: in step 2, the syntax parser reads the configuration file, parses the custom syntax, and converts the configuration information into a C# object.
[0028] Compared with the prior art, the present invention has the following beneficial effects:
[0029] (1) Improved decoupling capability: After using this solution, when a stored procedure is modified, only the configuration file of the CHECK module needs to be modified. The amount of business code modification is reduced by more than 90%, from hundreds of lines in traditional methods to just a few lines.
[0030] (2) Improved development efficiency: The development cycle is shortened by 30%-40%. Different developers can independently modify stored procedures and business processes, reducing code conflicts.
[0031] (3) Enhanced system scalability: This solution supports multiple database types, such as SQL Server, MySQL, etc., and can be easily adapted to different business processes, with scalability increased by more than 50%. BRIEF DESCRIPTION OF THE DRAWINGS
[0032] Figure 1 This is a system architecture diagram of the method and system for decoupling stored procedure calls from business processes based on declarative configuration.
[0033] Figure 2 This is a core execution flowchart of the method for decoupling stored procedure calls from business processes based on declarative configuration and the system.
[0034] Figure 3 This is a schematic diagram of a first embodiment of a method and system for decoupling stored procedure calls from business processes based on declarative configuration. DETAILED DESCRIPTION
[0035] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.
[0036] See also Figures 1 to 3 In an embodiment of the present invention, a system for decoupling stored procedure calls from business processes based on declarative configuration includes a CHECK module, a syntax parser, a stored procedure execution layer, and a business process control layer. The CHECK module is responsible for configuring the call information of the stored procedure in a declarative manner. The configuration information is stored in a text with a custom syntax format. The syntax parser is used to parse the configuration file of the CHECK module and convert it into instructions that the system can recognize. The stored procedure execution layer is used to call the corresponding stored procedure according to the parsed instructions. The business process control layer is responsible for the flow of the business process and determines the next step of the business process according to the execution result of the stored procedure.
[0037] Developers configure stored procedure call information in a declarative manner in the CHECK module file, for example:
[0038] [UNIT]=QUALITY_CHECK_01
[0039] [INPUT]=TXT;Part serial number:;@PART_SN;^[AZ]{2}\d{8}$
[0040] [CHECK]={#SP_VALIDATE_PART}
[0041] [RET]=1;<NEXT_STEP>
[0042] [RET]=0; <retry>;;BEEP=2
[0043] The parser reads the configuration file, parses the custom grammar, and converts the configuration information into a C# object. The following is a simple parsing example:
[0044]
[0045]
[0046]
[0047] The stored procedure execution layer calls the corresponding stored procedure according to the parsed instructions;
[0048] You can use ADO.NET to call stored procedures:
[0049]
[0050]
[0051] The business process control layer continues to advance the business process based on the execution results of the stored procedure and the configured return actions;
[0052]
[0053]
[0054] according to Figure 1 It can be seen that the CHECK module outputs configuration information to the syntax parser, the syntax parser passes the parsing results to the stored procedure execution layer, and the execution results of the stored procedure execution layer are fed back to the business process control layer;
[0055] according to Figure 2 It can be seen that Figure 2 The generated statement of the stored procedure is shown in detail, which reads the CHECK instruction, parses the stored procedure, queries the system table, obtains the parameter list, matches the variable parameters, and finally generates an executable statement.
[0056] CHECK syntax description:
[0057] Description: Calls a stored procedure.
[0058] Parameter Description: Parameter 1 is the name of the stored procedure.
[0059] Note: If there is a [GET][INPUT] before, the stored procedure in this check cannot have parameters, and all of them are regarded as parameters of this stored procedure.
[0060] Example: [CHECK] = (#end_tmuser);
[0061] 1. Test data design
[0062] Normal scenario test:
[0063] Enter a valid part serial number, the stored procedure is expected to return 1, and the business process proceeds to the next step.
[0064] Enter a valid user ID, and the stored procedure is expected to pass authentication and return 1.
[0065] Boundary condition testing:
[0066] Entering a part serial number with a length of 9 (exceeding the regular expression limit) is expected to trigger input validation failure, return 0, and prompt to try again.
[0067] Entering an empty user ID will trigger a stored procedure parameter exception, return -1, and log an error.
[0068] Abnormal scenario testing:
[0069] When the stored procedure execution times out, it is expected to catch the exception and return -1, triggering the retry mechanism.
[0070] If the database connection fails, the system is expected to throw a connection exception, terminate the current process and notify the administrator.
[0071] 2. Test methods
[0072] Automated testing framework: Use xUnit to simulate database connections and stored procedure calls, and write unit test cases.
[0073] Stress testing: Use JMeter to simulate high-concurrency scenarios and test the system's response time and stability under 1000+ concurrent requests.
[0074] Compatibility testing: Verify the system's cross-platform capabilities in SQL Server, MySQL, and PostgreSQL database environments.
[0075] 3. The test results are shown in Table 1:
[0076]
[0077]
[0078] Table 1
[0079] Example 1
[0080] In the MSD material unsealing registration process in a manufacturing industry, it is necessary to unseal and verify the MSD. It is necessary to determine whether it can be unsealed, record the operator, and call back the FULL_CHECK_USER and TSMT_MsdOpenexpiry unsealing stored procedures as follows:
[0081] [UNIT]=MSD_OPEN
[0082] [INPUT]=TXT;Please enter your user ID:;@USER_ID;^[a-zA-Z0-9]{1,10}$
[0083] [CHECK]={#FULL_CHECK_USER}
[0084] [RET]=0;<MSD_OPEN> ;;BEEP=2,2;
[0085] [RET]=1;<MSD_OPEN_01> ;;BEEP=1,1;
[0086] [UNIT]=MSD_OPEN_01
[0087] [INPUT]=TXT;Please enter Reel ID:;@ReelID;^[a-zA-Z0-9]{1,40}$
[0088] [GET]=TXT;@USER_ID
[0089] [CHECK]={#TSMT_MsdOpenexpiry}
[0090] [RET]=1;<MSD_OPEN_01> ;;BEEP=1,1;
[0091] [RET]=-1;<MSD_OPEN_01> ;;BEEP=2,2;
[0092] The decoupling method of stored procedure calls from business processes based on declarative configuration is as follows:
[0093] Step 1: Configure the stored procedure call information according to the custom syntax format in the CHECK module configuration file.
[0094] Step 2: The parser parses the configuration file and generates calling instructions.
[0095] Step 3: The stored procedure execution layer calls the FULL_CHECK_USER stored procedure to determine the user, calls the TSMT_MsdOpenexpiry stored procedure to unseal the MSD volume, and records the log at the same time.
[0096] Step 4: The business process control layer continues to process the business process according to the execution result (return value) of the stored procedure and the configured return action (such as entering the next step of detection or retrying).
[0097] Implementation results: Through the implementation of this solution, the code complexity of the quality inspection process was reduced by more than 50%, development efficiency was significantly improved, and the maintainability and scalability of the system were greatly enhanced.
[0098] Although the present invention has been described in detail with reference to the aforementioned embodiments, it is still possible for those skilled in the art to modify the technical solutions described in the aforementioned embodiments, or to make equivalent substitutions for some of the technical features therein. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.< / retry>
Claims
1. A system that decouples stored procedure calls from business processes based on declarative configuration, including a CHECK module, a syntax parser, a stored procedure execution layer, and a business process control layer. Its features include: The CHECK module outputs the configuration information to the syntax parser, the syntax parser passes the parsing result to the stored procedure execution layer, and the execution result of the stored procedure execution layer is fed back to the business process control layer.
2. The system for decoupling stored procedure calls from business processes based on declarative configuration according to claim 1, characterized in that: The CHECK module is responsible for configuring the call information of the stored procedure in a declarative manner. The configuration information is stored in a text in our custom syntax format.
3. The system for decoupling stored procedure calls from business processes based on declarative configuration according to claim 1, characterized in that: The syntax parser is used to parse the configuration file of the CHECK module and convert it into instructions that can be recognized by the system.
4. The system for decoupling stored procedure calls from business processes based on declarative configuration according to claim 1, characterized in that: The stored procedure execution layer is used to call the corresponding stored procedure according to the parsed instruction.
5. The system for decoupling stored procedure calls from business processes based on declarative configuration according to claim 1, characterized in that: The business process control layer is responsible for the flow of business processes and determines the next step of the business process based on the execution results of the stored procedure.
6. The method for decoupling stored procedure calls from business processes based on declarative configuration according to claim 1, characterized in that: The method steps are as follows: Step 1: Configure the stored procedure call information in the CHECK module configuration file according to the custom syntax format; Step 2: The parser parses the configuration file and generates call instructions; Step 3: The stored procedure execution layer calls the FULL_CHECK_USER stored procedure to determine the user; Step 4: The business process control layer continues to process the business process according to the configured return action based on the execution result of the stored procedure.
7. The method for decoupling stored procedure calls from business processes based on declarative configuration according to claim 6, characterized in that: In step 3, the TSMT_MsdOpenexpiry stored procedure is called to unseal the MSD volume and record the log at the same time.
8. The method for decoupling stored procedure calls from business processes based on declarative configuration according to claim 6, characterized in that: In step three, ADO.NET is used to implement the call of the stored procedure.
9. The method for decoupling stored procedure calls from business processes based on declarative configuration according to claim 6, characterized in that: In the step 2, the syntax parser reads the configuration file, parses the custom syntax, and converts the configuration information into a C# object.