Interaction methods between the engineering consulting daily operation management system and third-party business systems

Abstract

This invention provides an interaction method between an engineering consulting daily operation management system and a third-party business system. The method includes: a communication middleware of a data interaction microservice receives internal request data, encapsulates a target request message, and sends it to the third-party business system; the third-party business system returns response data to the communication middleware, which then forwards the response data to the microservice's data acquisition layer, further converting it into standardized data; the microservice's intermediate processing layer performs routing processing on the standardized data before sending it to the corresponding business management module in the microservice's business logic layer; when sent to the customer management module, the standardized data is sent to the microservice's security control layer for authentication; when sent to the financial management module, the standardized data is sent to the security control layer for sensitive data encryption. This invention achieves an automated data interaction and mapping mechanism between the engineering consulting daily operation management system and the third-party business system.

Description

Technical Field

[0001] This invention relates to the field of computer software and information processing technology, and in particular to an interaction method between an engineering consulting daily operation management system and a third-party business system. Background Technology

[0002] Currently, the daily operation management system for engineering consulting serves as the sole entry point for consulting firms' daily operations, typically encompassing core business functions such as business management, operational management, and management of operations. However, most companies employ independent daily operation management systems while simultaneously utilizing multiple third-party professional systems to support project implementation. Nevertheless, these systems often lack effective integration methods, typically relying on manual data entry or simple data file import / export for data exchange. For instance, in some engineering consulting projects, cost estimators must manually input data from the engineering cost calculation system into the daily operation management system for full-process project management.

[0003] In existing technologies, due to the lack of effective integration, the data interaction efficiency between various systems is low, and they cannot work collaboratively. Consequently, it is impossible to achieve deep integration between engineering consulting project management processes and third-party professional systems, which limits the innovation and development of engineering consulting services.

[0004] Therefore, how to improve the efficiency of data interaction between the daily operation management system for engineering consulting and third-party professional systems, ensure data consistency, and thereby improve the management efficiency and quality of engineering consulting projects has become a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this invention is to provide an interaction method between an engineering consulting daily operation management system and a third-party business system, in order to solve the above-mentioned technical problems in the prior art.

[0006] On the one hand, in order to achieve the above objectives, the present invention provides an interaction method between an engineering consulting daily operation management system and a third-party business system.

[0007] The engineering consulting daily operation management system and the third-party business system interact via a data interaction microservice. This microservice includes a communication middleware, a data acquisition layer, a middle processing layer, a business logic layer, and a security control layer. The interaction method involves: when the engineering consulting daily operation management system needs to interact with the third-party business system, the communication middleware receives internal request data, encapsulates the target request message according to a preset specification, and sends it to the third-party business system. The third-party business system then sends response data to the communication middleware based on the target request message. The communication middleware forwards the response data to the data acquisition layer. The data acquisition layer extracts data from the response data, performs protocol conversion to obtain standardized data, and sends it to the middle processing layer. The middle processing layer routes the standardized data to the corresponding business management module in the business logic layer. These business management modules include a customer management module, a contract management module, a financial management module, and a project management module. When standardized data is sent to the customer management module, the customer management module sends the standardized data to the security control layer for authentication. When standardized data is sent to the financial management module, the financial management module sends the standardized data to the security control layer for sensitive data encryption.

[0008] Furthermore, before the intermediate processing layer performs routing processing on the standardized data, the interaction method also includes: the intermediate processing layer performs validation on the standardized data according to preset field validation rules; wherein, if the validation is successful, the intermediate processing layer performs routing processing on the standardized data; if the validation fails, the intermediate processing layer writes the standardized data into an error queue.

[0009] Furthermore, the intermediate processing layer performs the following steps to validate the standardized data according to the preset field validation rules: validate the standardized data according to customer-defined field rules, contract-defined field rules, project-defined field rules, invoice application-defined field rules, and invoice registration-defined field rules respectively.

[0010] Furthermore, the target request message encapsulated by the communication middleware according to the preset interface specification must at least meet the following requirements: adopt REST / JSON format with HTTPS protocol; carry public authentication parameter token; and include code, msg, and data fields in the message body, where the data field stores encrypted business data.

[0011] Furthermore, the steps of the data acquisition layer to extract data from the response data and perform protocol conversion to obtain standardized data include: parsing the response data and decrypting the data field; and generating standardized data from the decrypted data according to a preset field mapping model.

[0012] Furthermore, generating standardized data from the decrypted data according to the preset field mapping model includes: when the decrypted data is structured data, mapping field names, data types, and lengths is completed according to the preset field mapping table, the mapped structured data is serialized into JSON, and then written into the data content field of the standardized data after UTF-8 encoding; when the decrypted data is unstructured data, the source file format is identified through the file header, and if the source file format is not the target format, the format conversion program is called to convert the unstructured data into the predetermined format, and the converted file content is written into the data content field of the standardized data after Base64 encoding.

[0013] Furthermore, when the engineering consulting daily operation management system needs to interact with third-party business systems, it includes: predefining the collaboration rules and workflows between the engineering consulting daily operation management system and the third-party business systems; when the user's operation on the engineering consulting daily operation management system meets the collaboration rules, the interaction with the third-party business systems is automatically triggered according to the workflow.

[0014] Furthermore, after the communication middleware receives the internal request data and before encapsulating the target request message according to the preset specifications, the interaction method also includes: parsing the JWT carried by the internal request data; verifying the signature of the JWT using a preset public key; after the JWT signature verification is successful, extracting the organization identifier, user role identifier, and permission code from the payload of the JWT; and matching the organization identifier, user role identifier, and permission code with the policies in the preset permission configuration library. When the matching result meets the access conditions, the target request message is encapsulated according to the preset specifications.

[0015] Furthermore, before sending the target request message and before forwarding the response data to the data acquisition layer, the communication middleware calls the unified log interceptor to generate log events. These log events are asynchronously written to the log database in an event-driven manner.

[0016] On the other hand, to achieve the above objectives, the present invention provides an interactive device for data interaction between an engineering consulting daily operation management system and a third-party business system.

[0017] The interactive device includes a communication middleware, a data acquisition layer, an intermediate processing layer, a business logic layer, and a security control layer. Specifically: when the engineering consulting daily operation management system needs to interact with a third-party business system, the communication middleware receives internal request data, encapsulates the target request message according to a preset specification, and sends it to the third-party business system. The third-party business system sends response data to the communication middleware based on the target request message. The communication middleware also forwards the response data to the data acquisition layer. The data acquisition layer extracts data from the response data, performs protocol conversion to obtain standardized data, and sends it to the intermediate processing layer. The intermediate processing layer routes the standardized data to the corresponding business management module in the business logic layer. The business management modules include a customer management module, a contract management module, a financial management module, and a project management module. When standardized data is sent to the customer management module, the customer management module sends the standardized data to the security control layer for authentication. When standardized data is sent to the financial management module, the financial management module sends the standardized data to the security control layer for sensitive data encryption. Attached Figure Description

[0018] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A flowchart illustrating the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart illustrating the data processing in the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention. Figure 3 A schematic diagram illustrating the customer-defined field rules in the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention; and Figure 4 This is a block diagram of a data interaction microservice for the daily operation management system of engineering consulting and a third-party business system, provided in Embodiment 2 of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0020] Example 1 This invention provides a method for interaction between an engineering consulting daily operation management system and a third-party business system. The engineering consulting daily operation management system and the third-party business systems interact via a data interaction microservice. This data interaction microservice includes a communication middleware, a data acquisition layer, an intermediate processing layer, a business logic layer, and a security control layer. By introducing this data interaction microservice as an intermediary, the engineering consulting daily operation management system is loosely coupled with various third-party business systems, forming an automated data channel that integrates communication, protocol conversion, business routing, security, and auditing. Through unified interface specifications, field mapping, event-driven mechanisms, and layered security controls, the previously fragmented process relying on manual data entry or file import / export is transformed into second-level synchronization. Furthermore, it ensures data consistency, traceability, and confidentiality, significantly improving the efficiency and quality of the entire engineering consulting project management process. Specifically, Figure 1 This is a flowchart illustrating the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention. Figure 2 The flowchart of the data processing in the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention is as follows: Figure 1 and Figure 2 As shown, the interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment includes the following steps S101 to S106.

[0021] Step S101: When the engineering consulting daily operation management system needs to interact with a third-party business system, the communication middleware receives internal request data, encapsulates the target request message according to the preset specifications, and sends it to the third-party business system.

[0022] In this process, the third-party business system sends response data to the communication middleware based on the target request message.

[0023] Optionally, when integrating the business operations of a third-party business system into the engineering consulting daily operations management system, the user of the third-party business system shall submit basic information about the third-party business system, including system name, function description, access address, API interface documentation, etc. For the registration and authentication of the third-party business system, by verifying the legality, security and availability of the interface, a unique authentication identifier and access key shall be assigned to the third-party business system to ensure that only authorized third-party business systems can interact with and access the engineering consulting daily operations management system, thereby ensuring the reliability of the third-party business system.

[0024] After a third-party business system is integrated into the Engineering Consulting Daily Operation Management System, the Engineering Consulting Daily Operation Management System needs to interact with the third-party business system in response to user operations or when the established process meets the interaction conditions. The Engineering Consulting Daily Operation Management System sends relevant internal request data to the communication middleware. The communication middleware receives the internal request data, encapsulates the target request message according to the preset specifications, and then sends it to the third-party business system.

[0025] The communication middleware is responsible for the unified management of all inbound and outbound traffic. Internally, it receives internal request data from the engineering consulting daily operation management system, and externally, it establishes secure and reliable communication channels with third-party business systems. Depending on the timeliness and coupling requirements of the integration scenario, this layer can be implemented using either an API gateway or a message queue. These can be deployed separately or in combination. Implementing the communication middleware through an API gateway is suitable for synchronous scenarios, such as when a cost estimator clicks the cost analysis button and needs to immediately receive the third-party results to fill in the interface, or when a contract approval workflow calls an external electronic signature platform to generate a signature URL, which needs to be returned to the front end instantly. Alternatively, data transmission and business collaboration can be achieved by sending and receiving messages to and from a message queue. This approach enables asynchronous communication between systems, reduces coupling, and improves system scalability and stability. It is particularly suitable for scenarios with low real-time requirements, such as when a large number of historical cost lists or BIM model files need to be synchronized to a data lake, allowing for delays of several minutes, or when a financial system generates hundreds of invoice records at night and sends them one by one to a Kafka message, which is then consumed by the engineering consulting daily operation management system in the early morning to update the internal ledger.

[0026] Optionally, in one embodiment, the target request message encapsulated by the communication middleware according to the preset interface specification shall at least meet the following requirements: adopting REST / JSON format of HTTPS protocol; carrying public authentication parameter token; and including code, msg, and data fields in the message body, wherein the data field stores encrypted business data.

[0027] Specifically, all API calls will use HTTPS protocol RESTful API, with request methods POST / PUT / GET / DELETE and request types application / json. Both API requests and responses will be encoded using UTF-8 character set. A common request parameter used by every API is the token. The request body contains three common parameters: code, data, and msg. Code is the status code, with 0 indicating success and other values ​​indicating failure. msg is the request message content, such as "success" or "fail". data is the response data; both the API call request and response parameters contain a data node, which stores encrypted business data.

[0028] Taking a third-party business system as an example of a cost estimation subsystem, when a business module of the engineering consulting daily operations management system needs to call a third-party cost analysis platform, it first generates internal request data in a JSON structure, where the fields follow the unified data model of the engineering consulting daily operations management system. Upon receiving this data, the communication middleware refers to a pre-configured OpenAPI description. This description requires the entire message to use HTTPS transmission, REST / JSON structure, and UTF-8 character set, and the request body to include three fixed fields: code, msg, and data. The middleware compresses the internal JSON, encrypts it using a tenant-specific AES-256 key, and inserts it into the data field, while simultaneously writing Authorization: Bearer in the HTTP Header. <jwt>After the message is encapsulated, it is immediately sent synchronously to the third-party business system via the POST method. Alternatively, it can be configured to be asynchronously published to a Kafka topic for consumption by the third-party business system.

[0029] Step S102: The communication middleware forwards the response data to the data acquisition layer.

[0030] After the third-party business system completes its processing, it returns a response data packet that also conforms to the "code / msg / data" format. The communication middleware first calls the unified log interceptor to package the response header, response body, time consumption, and other metadata into a LogEvent and asynchronously writes it to the log database. Then, it passes the entire response data through to the data acquisition layer intact. At this time, the middleware does not parse the business fields; it only acts as a security gateway and log entry point.

[0031] Step S103: The data acquisition layer extracts data from the response data, performs protocol conversion, obtains standardized data, and sends it to the intermediate processing layer.

[0032] Upon receiving the response, the data acquisition layer decrypts the `data` field using the tenant key. If decryption fails, the entire packet is added to the decryption failure queue for manual or timed retries. Upon successful decryption, the third-party fields are mapped to the field names of the engineering consulting daily operations management system based on the field mapping table. Type conversion, length truncation, and enumeration validity checks are then performed. The results are assembled into standardized JSON conforming to the unified data model of the engineering consulting daily operations management system. After the conversion, this JSON is sent as the message body to the middle processing layer.

[0033] Step S104: The intermediate processing layer performs routing processing on the standardized data to send it to the corresponding business management module of the business logic layer.

[0034] The business management module includes customer management, contract management, financial management, and project management modules.

[0035] Optionally, the intermediate processing layer first performs secondary validation on the data according to custom field rules and regular expressions such as customer, contract, project, invoice application, and invoice registration. If the validation fails, the data is written to a dedicated error queue and displayed on the background monitoring page; data that passes the validation is routed to the corresponding business management module based on the entity type (e.g., entity="CostItem"), and the message is published to the event channel prefixed with "client.", "contract.", "finance.", or "project."

[0036] Step S105: When standardized data is sent to the customer management module, the customer management module sends the standardized data to the security control layer for authentication.

[0037] Step S106: When standardized data is sent to the financial management module, the financial management module sends the standardized data to the security control layer for sensitive data encryption processing.

[0038] When a message enters the customer management module, it reads the project:read or client:writescope from the JWT and calls the security control layer to verify whether the corresponding permissions are available; if successful, it creates or updates the customer profile.

[0039] When a message enters the financial management module, the financial management module receives the message. After the main message is sent, the security control layer is invoked to re-encrypt fields such as amount and bank account using the RSA public key, and then the information is stored in the financial database. It can also push the invoice confirmation information back to the third-party ERP system.

[0040] When a message enters the contract management module, the system can determine whether it's a new contract or a contract update based on the message body. If the contract number doesn't exist in the database, a master contract record is created; if it already exists, only the changed fields (such as amount and milestone date) are synchronized, and the change history is written. Once processed, key results (contract amount adjustments, milestone status changes, etc.) are pushed as events to the `finance.adjustment` topic for automatic reconciliation by the finance module.

[0041] When a message enters the project management module, data can be implemented across three dimensions: Planning dimension, updating the baseline duration and progress percentage; Cost dimension, writing the latest cost or budget adjustments to the project cost table; and Quality dimension, if the message carries a defect list, registering quality issues and generating remediation tasks. If the update triggers an alert rule (such as schedule delays or cost overruns), the project management module immediately publishes an alert event to the alert.project topic, notifying the project manager and simultaneously notifying the scheduling or collaboration platform.

[0042] In the interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment, data interaction is carried out through data interaction microservices. Through the collaboration of the communication middleware, data acquisition layer, intermediate processing layer, business logic layer and security control layer of the data interaction microservices, a bidirectional data link between the engineering consulting daily operation management system and the third-party business system is successfully established. The communication middleware is responsible for standard interfaces and secure entry and exit points. The data acquisition layer completes protocol conversion and data standardization. The intermediate processing layer provides field verification and intelligent routing. The business logic layer realizes business implementation. The security control layer builds a barrier for identity authentication and data confidentiality, which improves data synchronization from manual entry and file export to real-time automatic, solving the pain points of low data transmission efficiency, poor collaboration and data inconsistency between systems.

[0043] In summary, the automated data interaction and mapping mechanism avoids errors and delays caused by manual data entry, ensuring real-time data synchronization and consistency between the engineering consulting work management system and third-party systems, providing accurate data support for project decision-making. Actual testing showed that for major business data with large volumes, such as clients, contracts, engineering consulting projects, and finances, the data error rate decreased from approximately 5% (from manual entry) to near zero. By reducing a significant amount of repetitive data entry and enabling automated data interaction and functional collaboration between systems, the execution cycle of engineering consulting projects was shortened. For example, for a medium-sized engineering consulting project, the overall execution time was reduced from an average of 60 days to approximately 45 days, improving work efficiency by about 25%. Furthermore, by adopting a universal integration and adaptation layer architecture and standardized data interaction methods, there is no need for customized development for each third-party business system. When a third-party business system is upgraded or replaced, only minor configuration adjustments are required in the integration and adaptation layer, significantly reducing system integration and maintenance costs. It is estimated that integration costs can be reduced by approximately 60% - 70% compared to traditional customized development methods. This achieves deep functional synergy between the engineering consulting operation management system and third-party business systems, seamlessly integrating the professional functions of third-party business systems into the engineering consulting project management process, providing technical support for innovation in engineering consulting business, and enhancing the core competitiveness of enterprises.

[0044] Optionally, in one embodiment, before the intermediate processing layer performs routing processing on the standardized data, the interaction method further includes: the intermediate processing layer validating the standardized data according to preset field validation rules. If the validation is successful, the intermediate processing layer performs routing processing on the standardized data. If the validation fails, the intermediate processing layer writes the standardized data to an error queue.

[0045] In this embodiment, before the data is formally routed to each business module, the intermediate processing layer performs field-level validation and isolates abnormal data into a dedicated error queue. This achieves two benefits: first, it ensures that the data entering core modules such as customers, contracts, projects, and finance conforms to the format and business constraints, preventing the spread of dirty data; second, it decouples erroneous data from normal data, which neither blocks the main process nor obstructs the process, but also provides a clear entry point for subsequent batch compensation, manual correction, and quality analysis, thus significantly improving data consistency, system stability, and maintainability.

[0046] Specifically, the middleware layer is the logical hub running through the entire interaction chain. Located after the data acquisition layer and before the business logic layer, it performs intelligent routing based on entity type (customer, contract, finance, project) and executes field-level data governance before routing. Optionally, field validation rules include structural validation, content validation, and inter-domain validation. Structural validation checks for field existence, data type matching (integer, floating-point, boolean, date, etc.), and length limits. Content validation verifies the validity of enumerated values ​​(e.g., contract status can only be "draft / active / closed") and regular expression validation (customer mobile phone number format, tax ID format). Inter-domain validation verifies business association constraints, such as contract amount not being less than 0 and not less than the paid amount. Field validation rules can be configured in YAML or database table format, supporting hot updates without requiring a service restart.

[0047] When the standardized data meets all the rules, the intermediate processing layer immediately encapsulates the message into a business event and delivers it to the corresponding Topic: client. → Customer Management Module; contract. → Contract Management Module; Finance. →Financial Management Module; project. → Project Management Module. If any rule fails, the intermediate processing layer writes the message to the error queue along with a list of failure reasons.

[0048] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment takes the two-stage verification-routing link as the core, embedding field-level data governance into the shortest closed loop of the entire data interaction pipeline. The verification stage controls the entry point, discovers and isolates dirty data in the first place, and the routing stage only receives compliant data, ensuring that the back-end business processing is simple and efficient. The error queue provides a traceable, replayable and observable compensation path, forming a closed-loop governance.

[0049] Optionally, in one embodiment, the step of the intermediate processing layer validating the standardized data according to preset field validation rules includes: validating the standardized data according to customer-defined field rules, contract-defined field rules, project-defined field rules, invoice application-defined field rules, and invoice registration-defined field rules respectively.

[0050] In this embodiment, custom field validation is embedded in the data interaction chain, ensuring that different business entities (customers, contracts, projects, invoice applications, invoice registrations) meet their respective customized formats and business constraints before flowing into the backend business modules. This preserves the flexibility of configurable enterprise fields and scalable forms while ensuring data consistency and compliance in multi-tenant, multi-version parallel scenarios. Adding or modifying fields requires no code changes; configuration in the rule base takes effect immediately, enabling flexible expansion. Dirty data is intercepted at the entity's rule level without affecting other entities, achieving precise isolation. A unified validation engine and hot update mechanism eliminate the need for manual script repair and subsequent rollback costs, achieving low-cost operation and maintenance.

[0051] Specifically, each business entity can maintain a field definition table and a validation rule table. Figure 3 This is a schematic diagram illustrating the customer-defined field rules in the interaction method between the engineering consulting daily operation management system and the third-party business system provided in Embodiment 1 of the present invention, as shown below. Figure 3 As shown, the field definition table describes field names, data types, whether they are required, whether they are displayed, input methods, default values, etc.; the validation rule table stores enumerated valid values, regular expressions, and cross-field relationships. For example, the reason for delay cannot be empty and its length is ≤200. The middle processing layer pulls the five types of rules for the corresponding tenant from the configuration center at startup or when rules are updated and loads them into the local cache. Each rule item contains a unique version number for easy comparison and incremental refresh, without blocking messages being processed. When standardized data arrives at the middle processing layer, it first identifies which rule type it belongs to, then searches the locally cached rule set according to that type and executes each rule one by one. Data that successfully validates continues into the routing logic, while data that fails validation is written to the error queue along with metadata such as rule type, field name, and reason for failure.

[0052] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment is adopted to verify the data according to the five categories of custom field rule verification mechanism. The fields are configurable and can take into account the data quality.

[0053] Optionally, in one embodiment, the step of the data acquisition layer extracting data from the response data and performing protocol conversion to obtain standardized data includes: parsing the response data and decrypting the data field; generating standardized data from the decrypted data according to a preset field mapping model.

[0054] Specifically, a data mapping table can be established at the data acquisition layer to clarify the correspondence between data elements in the engineering consulting operation management system and the third-party business system. Upon receiving response data from the third-party business system, the `data` field is decrypted, and then the data is transformed and integrated according to the data mapping table to obtain standardized data.

[0055] Alternatively, an AI model (such as AutoML) can be used to automatically learn data mapping relationships, forming a mapping AI model between data elements in the engineering consulting operation management system and third-party business systems. When response data is received from the third-party business system, the `data` field is decrypted and then input into the mapping AI model. The mapping AI model performs data transformation and integration based on the learned data mapping relationships to obtain standardized data.

[0056] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment is adopted. By establishing a data mapping table or mapping AI model, the automatic mapping and integration of data elements between different systems is realized, ensuring the accuracy and consistency of data transmission between systems and solving the problem of data heterogeneity. This allows the standardized data processed by the third-party business system to be inserted into or updated into the corresponding database table of the engineering consulting operation management system in subsequent processing, thereby achieving seamless data integration.

[0057] Optionally, in one embodiment, generating standardized data from the decrypted data according to a preset field mapping model includes: when the decrypted data is structured data, mapping field names, data types, and lengths according to a preset field mapping table, serializing the mapped structured data into JSON, and writing it into the data content field of the standardized data after UTF-8 encoding. When the decrypted data is unstructured data, identifying the source file format through the file header; if the source file format is not the target format, calling a format conversion program to convert the unstructured data into a predetermined format, and writing the converted file content into the data content field of the standardized data after Base64 encoding.

[0058] In this embodiment, to address the parsing errors and data loss caused by inconsistent formats, type conflicts, and difficulties in encapsulating binary data when heterogeneous data flows between systems, different processing methods are applied to the two main categories of structured and unstructured data. Regardless of whether the source data comes from database records or file streams, it always ends up as a UTF-8 string that can be processed by a JSON parser in one go. Meanwhile, the binary content can be securely embedded into REST / JSON messages after Base64 encoding, and both the field mapping table and the format conversion program can be hot-updated, supporting the addition of new fields and new file formats at any time without modifying the core code.

[0059] Specifically, when the decryption result has a clear row and column structure (such as the quotation line or contract line returned by a third-party system), the intermediate processing layer first looks up the field mapping table. This field mapping table includes source field names, target field names, target types, and maximum lengths, etc. Fields are mapped one by one according to this dictionary. After all fields are mapped, an object conforming to the unified model of the engineering consulting daily operation management system is generated. Then, a JSON serializer is called to convert the object into text, explicitly specifying UTF-8 encoding. The string obtained through UTF-8 byte sequencing is written into the data field of the standardized data, that is, the data content field of the standardized data, and can then be transmitted downstream using the unified "code / msg / data" message specification of the entire platform.

[0060] If the decryption result is a file stream or image stream, the MIME type is first inferred from the file header. If the MIME type does not match the target format, an external tool is called. For example, images can be converted to PNG→JPEG or TIFF→JPEG using ImageMagick; documents can be converted from DOCX to PDF using LibreOfficeheadless. After conversion, the file content remains binary. To embed JSON, Base64 encoding is performed to obtain an ASCII-safe string; this string is then written to the data field of the standardized data, i.e., the data content field of the standardized data. Downstream modules only need to reverse-engineer the Base64 encoding to obtain the correct and uniform file format.

[0061] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment realizes the content alignment of structured data and unstructured data, and assimilates the two types of data into the data area. When facing complex scenarios where structured and unstructured data coexist, it not only maintains the integrity of data semantics, but also greatly improves the stability and maintainability of cross-system interaction.

[0062] Optionally, in one embodiment, when the engineering consulting daily operation management system needs to interact with a third-party business system, the following is included: pre-defining collaboration rules and workflows between the engineering consulting daily operation management system and the third-party business system; when the user's operation on the engineering consulting daily operation management system meets the collaboration rules, the interaction with the third-party business system is automatically triggered according to the workflow.

[0063] Specifically, based on the business processes of engineering consulting projects, collaboration rules and workflows between systems are defined in the business process collaboration module. For example, during the project design phase, when the engineering consulting work management system creates a design task, it automatically triggers the creation of a task in the third-party engineering drawing design system and transfers the relevant design requirements and basic data. After the third-party business system completes the design, it returns the drawing data, which the engineering consulting work management system automatically receives and reviews. After the task preparation work is completed, it returns the corresponding deliverables, archived documents, and other information to the third-party business system to achieve automation and collaboration of the business process.

[0064] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment can be customized through microservices to define the collaboration rules and workflows between the systems. This enables functional collaboration between the engineering consulting operation management system and the third-party business system, deeply integrating the professional functions of the third-party business system into the engineering consulting project management process, and improving the automation and intelligence level of business processing.

[0065] Optionally, in one embodiment, after the communication middleware receives the internal request data and before encapsulating the target request message according to a preset specification, the interaction method further includes: parsing the JWT carried by the internal request data; performing signature verification on the JWT using a preset public key; after the JWT signature verification is successful, extracting the organization identifier, user role identifier, and permission code from the payload portion of the JWT; and matching the organization identifier, user role identifier, and permission code with policies in a preset permission configuration library, wherein when the matching result meets the access conditions, the target request message is encapsulated according to the preset specification.

[0066] In this embodiment, JWT authentication and gateway-level access policy matching are embedded in the front-end node of the communication middleware. Before encapsulating the target request message, the authenticity of the caller's identity, the organization's authorization status, and the role-permission matching are quickly determined. This ensures that any traffic with forged tokens, expired tokens, or unenabled organizations will be rejected at the source, thus avoiding the occupation of downstream resources and ensuring that outbound data flows only come from legitimate and authorized entities.

[0067] Specifically, when the communication middleware receives internal request data, it retrieves the JWT string from the token field. The middleware first caches the RSA or EC public key issued by the identity center, using this key to digitally sign and verify the JWT string, including timestamps. If verification fails or the token expires, a verification failure message is immediately returned. If verification succeeds, the middleware reads the orgId (organization identifier), roles (array of user role identifiers), and scopes (array of permission codes) from the JWT string payload and temporarily stores them in the current request context. The communication middleware maintains a high-speed cache of permission configuration libraries in memory. Each record describes the organization / role / interface mode and the allow / deny relationship, matching in the following order: first, determine if the orgId enables third-party integration functionality; if not, immediately deny; then, determine if the caller's role is in the allowed list; finally, check if the scopes cover the access granularity declared by the current interface. Only after all three checks pass does the communication middleware proceed to encapsulate the target request message according to the preset interface specification, write the encrypted business payload into the data field, and then send it to the third-party business system.

[0068] The interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment supports relatively large consulting companies in setting up third-party data integration services for certain organizations, with access control down to the corresponding departments. A JWT token issuance mechanism is used, where the token contains user roles and permission codes (e.g., cost ["project:read", "workdoc:write"]). Role hierarchies can be defined based on the RBAC model (e.g., "Project Manager" inherits permissions from "Project Member"), and interface access permissions are dynamically verified. Through JWT signature verification, three-element identity extraction, and policy matching, this series of actions is then encapsulated and forwarded. The communication middleware completes a high-performance, stateless, and configurable security gate at the network egress. Both the policy library and public keys support hot loading, allowing organization activation switches, role authorization, or public key rotation to take effect in real time without restarting the gateway or affecting ongoing requests.

[0069] Optionally, in one embodiment, the communication middleware calls the unified log interceptor to generate log events before sending the target request message and before forwarding the response data to the data acquisition layer. The log events are asynchronously written to the log database in an event-driven manner.

[0070] Specifically, a unified log interceptor is defined for all third-party external business system integration interfaces to uniformly record the request source, including IP, tenant information, account information, etc. Both request parameters and return messages are asynchronously written to the log database using event-driven technology, thereby supporting callers to track and analyze abnormal request situations online.

[0071] By adopting the interaction method between the engineering consulting daily operation management system and the third-party business system provided in this embodiment, log collection is upgraded from blocking I / O to a fully decoupled event-driven mode. Log interceptors are triggered uniformly at the two key nodes of outbound and inbound communication middleware to ensure that all call paths use the same fields and formats. The generated log events are written to the log library through an event-driven asynchronous link. This ensures full traceability of cross-system calls and avoids the impact of synchronous disk writes on business latency, achieving high-performance, non-loss-prone, and easily analyzable log governance capabilities.

[0072] Example 2 Corresponding to Embodiment 1 above, Embodiment 2 of the present invention provides an interactive device for data interaction between an engineering consulting daily operation management system and a third-party business system. The corresponding technical features and effects can be referred to Embodiment 1 above, and will not be repeated in this embodiment. Figure 3 This is a block diagram of the interactive device provided in Embodiment 2 of the present invention, as shown below. Figure 3 As shown, the interactive device includes: a communication middleware 201, a data acquisition layer 202, an intermediate processing layer 203, a business logic layer 204, and a security control layer 205.

[0073] In the engineering consulting daily operation management system, when interaction with third-party business systems is required, the communication middleware 201 receives internal request data, encapsulates the target request message according to preset specifications, and sends it to the third-party business system. The third-party business system then sends response data to the communication middleware 202 based on the target request message. The communication middleware 201 also forwards the response data to the data acquisition layer. The data acquisition layer 202 extracts data from the response data, performs protocol conversion to obtain standardized data, and sends it to the intermediate processing layer 203. The intermediate processing layer 203 routes the standardized data to the corresponding business management module in the business logic layer 204. The business management modules include a customer management module, a contract management module, a financial management module, and a project management module. When standardized data is sent to the customer management module, it sends the standardized data to the security control layer 205 for authentication. When standardized data is sent to the financial management module, it sends the standardized data to the security control layer 205 for sensitive data encryption.

[0074] Optionally, in one embodiment, before routing the standardized data, the intermediate processing layer further validates the standardized data according to preset field validation rules. If the validation is successful, the intermediate processing layer performs routing processing on the standardized data. If the validation fails, the intermediate processing layer further writes the standardized data into an error queue.

[0075] Optionally, in one embodiment, when the intermediate processing layer verifies the standardized data according to preset field verification rules, the specific steps include: verifying the standardized data according to customer-defined field rules, contract-defined field rules, project-defined field rules, invoice application-defined field rules, and invoice registration-defined field rules respectively.

[0076] Optionally, in one embodiment, the target request message encapsulated by the communication middleware according to the preset interface specification shall at least meet the following requirements: adopting REST / JSON format of HTTPS protocol; carrying public authentication parameter token; and including code, msg, and data fields in the message body, wherein the data field stores encrypted business data.

[0077] Optionally, in one embodiment, when the data acquisition layer extracts data from the response data and performs protocol conversion to obtain standardized data, the specific steps include: parsing the response data and decrypting the data field; generating standardized data from the decrypted data according to a preset field mapping model.

[0078] Optionally, in one embodiment, generating standardized data from the decrypted data according to a preset field mapping model includes: when the decrypted data is structured data, mapping field names, data types, and lengths according to a preset field mapping table, serializing the mapped structured data into JSON, and writing it into the data content field of the standardized data after UTF-8 encoding. When the decrypted data is unstructured data, identifying the source file format through the file header; if the source file format is not the target format, calling a format conversion program to convert the unstructured data into a predetermined format, and writing the converted file content into the data content field of the standardized data after Base64 encoding.

[0079] Optionally, in one embodiment, when the engineering consulting daily operation management system needs to interact with a third-party business system, the following is included: pre-defining collaboration rules and workflows between the engineering consulting daily operation management system and the third-party business system; when the user's operation on the engineering consulting daily operation management system meets the collaboration rules, the interaction with the third-party business system is automatically triggered according to the workflow.

[0080] Optionally, in one embodiment, the communication middleware is further configured to, after receiving the internal request data and before encapsulating the target request message according to a preset specification, parse the JWT carried by the internal request data; perform signature verification on the JWT using a preset public key; after the JWT signature verification is successful, extract the organization identifier, user role identifier, and permission code from the payload portion of the JWT; and match the organization identifier, user role identifier, and permission code with policies in a preset permission configuration library, wherein, when the matching result meets the access conditions, encapsulate the target request message according to the preset specification.

[0081] Optionally, in one embodiment, the communication middleware is further configured to call the unified log interceptor to generate log events before sending the target request message and before forwarding the response data to the data acquisition layer, wherein the log events are asynchronously written to the log database in an event-driven manner.

[0082] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0083] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0085] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.< / jwt>

Claims

1. A method for interaction between an engineering consulting daily operation management system and a third-party business system, characterized in that, The engineering consulting daily operation management system and the third-party business system interact with each other via a data interaction microservice. This data interaction microservice includes a communication middleware, a data acquisition layer, a middleware processing layer, a business logic layer, and a security control layer. The interaction method includes: When the engineering consulting daily operation management system needs to interact with a third-party business system, the communication middleware receives internal request data, encapsulates the target request message according to a preset specification, and sends it to the third-party business system. The third-party business system sends response data to the communication middleware according to the target request message. The communication middleware forwards the response data to the data acquisition layer; The data acquisition layer extracts data from the response data, performs protocol conversion to obtain standardized data, and sends it to the intermediate processing layer. The intermediate processing layer performs routing processing on the standardized data to send it to the corresponding business management module of the business logic layer, wherein the business management module includes a customer management module, a contract management module, a financial management module, and a project management module; When the standardized data is sent to the customer management module, the customer management module sends the standardized data to the security control layer for authentication. When the standardized data is sent to the financial management module, the financial management module sends the standardized data to the security control layer for sensitive data encryption.

2. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 1, characterized in that, Before the intermediate processing layer performs routing processing on the standardized data, the interaction method further includes: The intermediate processing layer validates the standardized data according to preset field validation rules; If the verification is successful, the intermediate processing layer performs routing processing on the standardized data; if the verification fails, the intermediate processing layer writes the standardized data into an error queue.

3. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 2, characterized in that, The intermediate processing layer performs the following steps to validate the standardized data according to preset field validation rules: The standardized data is validated according to customer-defined field rules, contract-defined field rules, project-defined field rules, invoice application-defined field rules, and invoice registration-defined field rules.

4. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 1, characterized in that, The target request message encapsulated by the communication middleware according to the preset interface specification must at least satisfy: It uses REST / JSON format with HTTPS protocol; Carry a public authentication parameter token; The message body contains code, msg, and data fields, with the data field storing encrypted business data.

5. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 4, characterized in that, The steps of the data acquisition layer extracting data from the response data and performing protocol conversion to obtain standardized data include: Parse the response data and decrypt the data field; The decrypted data is used to generate standardized data according to a preset field mapping model.

6. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 5, characterized in that, The decrypted data is then used to generate standardized data according to a preset field mapping model, including: When the decrypted data is structured data, the field name, data type and length are mapped according to the preset field mapping table. The mapped structured data is serialized into JSON and written into the data content field of the standardized data after being encoded in UTF-8. When the decrypted data is unstructured, the source file format is identified by the file header. If the source file format is not the target format, the format conversion program is called to convert the unstructured data into the predetermined format. The converted file content is then Base64 encoded and written into the data content field of the standardized data.

7. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 1, characterized in that, When the engineering consulting daily operation management system needs to interact with third-party business systems, it includes: Predefine the collaboration rules and workflows between the engineering consulting daily operation management system and the third-party business system; When a user's operation on the engineering consulting daily operation management system meets the collaboration rules, the interaction with the third-party business system is automatically triggered according to the workflow.

8. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 1, characterized in that, After the communication middleware receives the internal request data, and before encapsulating the target request message according to a preset specification, the interaction method further includes: Parse the JWT carried in the internal request data; The JWT is signed and verified using a preset public key; Once the JWT signature verification is successful, the organization identifier, user role identifier, and permission code are extracted from the payload portion of the JWT. Based on the organization identifier, the user role identifier, and the permission code, a match is made with policies in a pre-configured permission configuration library. When the matching result meets the access conditions, the target request message is encapsulated according to the preset specifications.

9. The interaction method between the engineering consulting daily operation management system and the third-party business system according to claim 1, characterized in that, Before sending the target request message and before forwarding the response data to the data acquisition layer, the communication middleware calls the unified log interceptor to generate log events, wherein the log events are asynchronously written to the log database in an event-driven manner.

10. An interactive device for data interaction between an engineering consulting daily operation management system and a third-party business system, characterized in that, The interactive device includes: a communication middleware, a data acquisition layer, an intermediate processing layer, a business logic layer, and a security control layer, wherein: When the engineering consulting daily operation management system needs to interact with a third-party business system, the communication middleware is used to receive internal request data, encapsulate the target request message according to the preset specification, and send it to the third-party business system. The third-party business system sends response data to the communication middleware according to the target request message. The communication middleware is also used to forward the response data to the data acquisition layer; The data acquisition layer is used to extract data from the response data, perform protocol conversion, obtain standardized data, and send it to the intermediate processing layer. The intermediate processing layer is used to route the standardized data to send it to the corresponding business management module of the business logic layer. The business management module includes a customer management module, a contract management module, a financial management module, and a project management module. When the standardized data is sent to the customer management module, the customer management module is used to send the standardized data to the security control layer for authentication processing; When the standardized data is sent to the financial management module, the financial management module sends the standardized data to the security control layer for sensitive data encryption.

Images