Business management system and business management method

Abstract

The invention relates to the technical field of logistics management, in particular to a business management system and a business management method, the business management system comprises a service platform, the service platform is configured to adopt a unified API interface to perform communication interaction with a plurality of business clients, and the service platform is also configured to perform communication interaction with a plurality of supplier servers. By adopting the business management system provided by the invention, unified management, cost monitoring, flow configuration and resource allocation can be carried out on a plurality of business clients by adopting the service platform, and the supplier server is called in a unified and coordinated manner according to the service request of the business client every time so as to complete business processing; therefore, a communication interface between each service client and a plurality of supplier servers does not need to be developed, the workload is reduced, the service platform can perform unified management on a plurality of service clients to coordinate each supplier server to complete service processing, the service processing efficiency is improved, and information management is also facilitated.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of logistics management, and particularly relates to a business management system and a business management method. BACKGROUND

[0002] In the related art, when the business client of each department in an enterprise works, a third-party supplier server usually needs to be called to complete various business processing; for example, a third-party supplier server usually needs to be called to complete short message sending, voice sending, content review, image recognition, text recognition, online payment and settlement, etc. In the related art, each business system directly integrates the software development kit (SDK) or hyper text transfer protocol (HTTP) application programming interface (API) provided by each supplier as needed, and then each business system calls the third-party supplier server through the SDK or HTTP interface to complete various business processing. However, since a single business client usually includes various business types, and there is usually business crossing between each business system, each business part of an enterprise needs to develop a special SDK and API with multiple supplier servers, which increases the workload of system development; and a single business client interacts with multiple supplier servers to complete function calling, which makes it impossible to uniformly manage and coordinate the business-related data of multiple business departments in an enterprise, and also makes the information management cost of each business client high. SUMMARY

[0003] The present application provides a business management system and a business management method to solve the technical problem of high system development cost and information management cost when each business client in an enterprise interacts with multiple third-party supplier servers in the related art.

[0004] In a first aspect, the present application provides a business management system, which comprises a service middle station, the service middle station is configured to communicate and interact with multiple business clients by using a unified API interface, wherein different business types correspond to different API interfaces; and the service middle station is also configured to communicate and interact with multiple supplier servers, wherein the service middle station communicates with different supplier servers by using a unique identification address; The service middle station is configured to receive service request information sent by a service server, parse the service request information, obtain a service category identifier corresponding to the service request information, determine permission information corresponding to the service category according to the service category identifier, determine a target supplier server corresponding to the service category in the case where the service category has permission, and send a service call request to the target supplier server; receive a service request result fed back by the target supplier server according to the service call request, and feed back a processing result of the target supplier server for the service call request to the service server. The service request includes one or more of the following: short message verification, short message notification, identity information verification, one-key login, voice synthesis, information push, OCR identification, and online payment.

[0005] In a possible design, the service middle station is further configured to, in the case where it is determined that the service category has permission, determine whether an access frequency of the service category or the service server reaches a preset access frequency threshold, determine a target supplier server corresponding to the service category if yes, and send a service request to the target supplier server, and refuse the service category or the service server to access the target supplier server if no.

[0006] In a possible design, the service middle station is further configured to, for each supplier server of a same service category, obtain attribute information of each supplier server, and configure a traffic proportion of each supplier server according to the attribute information of each supplier server.

[0007] In a possible design, the service middle station is further configured to, for attribute information of each supplier server of a same service category, determine a priority order of the plurality of supplier servers according to the attribute information of each supplier server, and reduce the priority of a supplier server that fails or re-determine the priority order of the plurality of supplier servers when it is determined that the supplier server fails.

[0008] In a possible design, the service middle station is further configured to, each time the target supplier server is called, determine whether to charge according to a call feedback result, and send basic information of this time of calling the target supplier server to a big data platform after it is determined that the calling succeeds, where the big data platform is configured to record charging data of this time of calling the target supplier server according to the basic information. The big data platform is further configured to integrate the charging data according to department information, service type, or charging frequency, and feed back the integrated charging data to the service middle station.

[0009] In a possible design, the service middleware is further configured to parse the service request information, acquire a service category identifier and sensitive data in the service request information, determine an access right of the current service request information according to the service category identifier and the sensitive data, and when it is determined that the current service request information has the access right, determine a corresponding target supplier server according to the service category identifier and / or the sensitive data, and send a service invocation request to the corresponding target supplier server.

[0010] In a possible design, the service middleware is further configured to acquire an invocation quantity, an invocation time, and a number of requests initiated per second to the target supplier server during invocation of the target supplier server, and store the invocation quantity, the invocation time, and the number of requests initiated per second to the target supplier server.

[0011] In a possible design, the service middleware is further configured to, when a log request is received, generate an invocation log according to the invocation quantity, the invocation time, and the number of requests initiated per second to the target supplier server, and send the invocation log to a corresponding business client.

[0012] In a possible design, the service middleware is further configured to receive an information modification request, and modify corresponding configuration information according to the information modification request, where the information modification request is used to request modification of one or more of the following: access right of the business client, traffic proportion of the supplier server, priority order of a plurality of supplier servers, and selection strategy of the supplier server. The service middleware is further configured to record a modification event of the configuration information during modification of the configuration information, to generate an event snapshot and store the event snapshot.

[0013] In a second aspect, the present application further provides a business management method, applied to a service middleware, where the service middleware is configured to communicate with a plurality of business clients by using a unified API interface, and different business types correspond to different API interfaces; and the service middleware is further configured to communicate with a plurality of supplier servers, and a unique identification address is used between the service middleware and different supplier servers. The business management method includes the following steps. receiving service request information sent by a business server, parsing the service request information, and acquiring a service category identifier corresponding to the service request information; where the service request includes one or more of the following: SMS verification, SMS notification, identity information verification, one-key login, voice synthesis, information push, OCR identification, and online payment. According to the service category identifier, determine the permission information corresponding to the service category, and in the case that the service category has permission, determine the target supplier server corresponding to the service category, and send a service call request to the target supplier server; Receive the service request result fed back by the target supplier server according to the service call request, and feed back the processing result of the target supplier server to the service server.

[0014] The business management system provided by the first aspect can be used to uniformly manage multiple business clients by the service middle station, and each time the service request of the business client is used to uniformly coordinate the calling of the supplier server to complete the business processing. Therefore, it is not necessary to develop the communication interface between each business client and multiple supplier servers, the workload is reduced, the service middle station can uniformly manage multiple business clients to coordinate the supplier servers to complete the business processing, the business processing efficiency is improved, and the information management is facilitated.

[0015] The beneficial effects provided by the other aspects and the possible designs of the other aspects can be referred to the beneficial effects brought by the first aspect and the possible implementation manners of the first aspect, which will not be described herein. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 The business management system structure schematic diagram provided by the embodiment of the present application; Figure 2 The supplier information configuration schematic diagram provided by the embodiment of the present application; Figure 3 a service information configuration diagram provided by an embodiment of the present application; Figure 4 an access information configuration diagram provided by an embodiment of the present application; Figure 5 a service record configuration diagram provided by an embodiment of the present application; Figure 6 a service management method flowchart diagram provided by an embodiment of the present application. DETAILED DESCRIPTION

[0017] In the present application, “at least one” means one or more, and “multiple” means two or more. “And / or” describes the association relationship of the associated objects, which means that there can be three relationships, for example, A and / or B, which can represent the following three cases: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character “ / ” generally represents an “or” relationship between the associated objects. “At least one of the following” or similar expressions means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c alone, can represent: a alone, b alone, c alone, combination of a and b, combination of a and c, combination of b and c, or combination of a, b and c, where a, b, c can be single or multiple. In addition, the terms “first”, “second” are only for descriptive purposes, and cannot be understood as indicating or implying relative importance.

[0018] The terms “center”, “longitudinal”, “transverse”, “upper”, “lower”, “left”, “right”, “front”, “back”, and the like indicate the orientation or positional relationship shown in the drawings, which is only for the convenience of describing the present application and simplifying the description, and cannot be understood as indicating or implying that the devices or elements referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as limiting the present application.

[0019] The terms “connected” and “connected” should be broadly understood, for example, the “connected” or “connected” of the circuit structure can mean not only physical connection, but also electrical connection or signal connection, for example, it can be directly connected, that is, physically connected, or indirectly connected through at least one intermediate element, as long as the circuit is connected, it can also be the internal connection of two elements; In addition to signal connection through the circuit, signal connection through media medium, such as radio waves, can also be referred to. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0020] In the related art, when the business client of each department in an enterprise is working, a third-party supplier server usually needs to be called to complete short message sending, voice sending, content review, image recognition, character recognition, online payment and settlement, etc. Each business system directly integrates the software development kit or hypertext transfer protocol interface provided by each supplier as needed, and then each business system calls the third-party supplier server through the software development kit or hypertext transfer protocol interface to complete various business processing. However, since a single business client usually includes multiple business types, and there is usually business crossing between each business system, each business part of an enterprise needs to develop special software development kits and application programming interfaces with multiple supplier servers, resulting in an increase in the workload of system development; for example, general capabilities (authentication signature, retry and idempotency, callback signature verification, gray and flow control, monitoring and alarm) are mostly repeatedly constructed, and are inconsistent between different teams, resulting in a large development cost; and a single business client interacts with multiple supplier servers to complete function calls, so that the business-related data of multiple business departments in an enterprise cannot be uniformly managed and coordinated, for example, the billing of the same business type of multiple departments cannot be counted, multiple suppliers coexist but policy management is weak, usually relying only on manual switching or simple switches; SLA (Service Level Agreement) awareness, health detection, and automatic failover support are insufficient, and currently, usage measurement, cost settlement, and reconciliation processes rely on manual and semi-automatic scripts, and the standards across suppliers and businesses are difficult to unify, also making the information management cost of each business client high.

[0021] By analyzing the technical defects in the prior art, the following reasons exist: 1. There is no unified management capability between the business clients of each department, and the assets are not visible and the responsibilities are unclear.

[0022] Defects: It is not possible to accurately inventory the third-party services and suppliers that have been accessed, and it is not possible to clearly map to specific business parties, environments, and versions; it is difficult to share experience and best practices across teams.

[0023] Causes: There is a lack of centralized asset directory and metadata model (supplier, service, access party, environment, credential, SLA, compliance label, etc.); there is a lack of unified identification system and automatic discovery / registration mechanism, and information is scattered in code repositories, configuration centers, and personal documents; supplier information and technical access data belong to different systems (procurement / finance / R&D), and the fragmented data layer leads to fragmented views.

[0024] 2. The access process of the business client of each department is self-governed, and the general capabilities (that is, the capabilities of integrated SDK) cannot be reused.

[0025] Defect manifestation: The same general process (signature, retry backoff, fuse flow limiting, idempotent, callback verification, security audit) is repeatedly implemented and behaves inconsistently in different projects, with high maintenance cost and high defect rate.

[0026] Formation reason: Heterogeneous manufacturer agreements and authentication methods (multiple signature algorithms, clock requirements, inconsistent callback specifications); lack of abstraction layer and unified SDK to encapsulate and arrange commonalities; lack of standardized access templates and verification (such as mandatory capability list, gray and rollback strategy, observation index baseline), resulting in uneven implementation quality.

[0027] 3. Supplier selection is not flexible, and there is no automatic failover capability.

[0028] Defect manifestation: Once the main supplier fails, the business side needs to manually switch or urgently release; it cannot dynamically route and degrade based on real-time quality (success rate, latency, failure code); consistency and idempotency across suppliers are difficult to guarantee.

[0029] Formation reason: Supplier selection strategy is hard-coded in business code or coarse-grained configuration, lacking a policy engine; lacking a closed-loop data of health probe, SLA collection and quality evaluation; lacking semantic alignment and idempotent key design across suppliers, which may cause repeated charges and callback disorder during switching; fuse / limiting infrastructure mainly acts on single-service dimension, making it difficult to improve to the business semantic layer of "cross-supplier, cross-region".

[0030] There is no billing reconciliation capability between multiple departmental business clients, and the reconciliation process is cumbersome and risky. Defect manifestation: Different suppliers' measurement criteria, time window, granularity and bill format are inconsistent; manual or scripted reconciliation is inefficient, prone to errors and difficult to find in time; it is difficult to form cross-supplier cost analysis and optimization.

[0031] Formation reason: Lack of unified measurement model and caliber mapping (call, success, receipt, failure code grouping, retry deduplication, free quota, discount and package); lack of standardized collection and cleaning of call link and receipt events, which cannot support cascading verification of reconciliation; lack of big data pipeline (offline / real-time) and reconciliation rule engine, as well as automatic early warning and evidence capability for abnormal bills; lack of stable association keys (such as business order number, idempotent key, reconciliation batch number) between supplier bills and internal call data.

[0032] Other derived problems (e.g. insufficient compliance and observability). Defect manifestation: AK (Access Key ID) / SK (Secret Access Key) and sensitive configuration are managed in scattered manner, with weak audit and traceability capability; it is difficult to share call indicators across teams, and root cause positioning and capacity estimation are not accurate.

[0033] Causes: Lack of a unified mechanism for credential storage and rotation, and operational auditing; lack of a unified dimension for monitoring indicators, logs, and tracking across service providers and business parties; inability to form an end-to-end observable baseline and experience quality profile.

[0034] To overcome the deficiencies in the aforementioned related technologies, this application provides a business management system, which includes a service middle platform. The service middle platform is configured to communicate and interact with multiple business clients using a unified API interface, wherein different business types correspond to different API interfaces. Simultaneously, the service middle platform is also configured to communicate and interact with multiple supplier servers, wherein the service middle platform communicates with different supplier servers using unique identifier addresses. The service middle platform receives service request information sent by business servers, parses the service request information, obtains the service category identifier corresponding to the service request information, determines the permission information corresponding to the service category based on the service category identifier, and, if the service category has the necessary permissions, determines the target supplier server corresponding to the service category and sends a service call request to the target supplier server; receives the service request result fed back by the target supplier server based on the service call request, and feeds back the processing result of the target supplier server for the service call request to the business server. The service request includes one or more of the following: SMS verification, SMS notification, identity information verification, one-click login, speech synthesis, information push, OCR (Optical Character Recognition) recognition, and online payment.

[0035] As can be seen, the business management system provided in this application allows for unified management of multiple business clients using a service middleware platform. Each time a business client requests a service request, the system coordinates and calls the supplier server to complete the business processing. This eliminates the need to develop communication interfaces between each business client and multiple supplier servers, reducing workload. Furthermore, the service middleware platform can manage multiple business clients in a unified manner and coordinate the completion of business processing by each supplier server. Specifically, the service middleware platform can implement capabilities such as service backend management, third-party contract management, service access SOP (Standard Operating Procedure), service call billing, and service reconciliation. It can also support service provider selection and disaster recovery / descendancy capabilities, improving business processing efficiency and facilitating information management.

[0036] Figure 1 For a schematic diagram of the business management system structure provided in this application embodiment, please refer to [link / reference]. Figure 1As shown, this embodiment provides a business management system, which includes multiple business clients, a service platform, and multiple business servers. Specifically, the business management system includes a first business client, a second business client, ..., an Nth business client, a service platform, a first business server, a second business server, ..., an Nth business server; and the first business client, the second business client, and the Nth business client all communicate and interact with the first business server, the second business server, and the Nth business server through the service platform.

[0037] In this embodiment, the service platform is configured to communicate and interact with multiple business clients using a unified API interface, where different business types correspond to different API interfaces. The service platform is also configured to communicate and interact with multiple vendor servers, where the service platform communicates and interacts with different vendor servers using unique identifier addresses.

[0038] Specifically, the service platform acts as an intermediate management server, used to uniformly coordinate and manage the communication and interaction between various business clients and business servers. Therefore, the SDK and API interfaces between business clients, the service platform, and business servers need to be uniformly configured first. For example, configuring third-party service subclasses can include: service name, service category, service identifier, service status, SMS type, PUSH type, voice type, payment type, etc.; configuring the supplier information supported by the third-party service: supplier name, code (for billing), backend address (for easy management), etc.; configuring the third-party service application entry page, different third-party services may have template parameters, etc., which need to be filled in by the business party when applying and obtaining the application service number; after the business party actually calls it, the usage of the third-party service by the business party can be statistically analyzed through the service subclass, business application number, supplier number, etc.

[0039] Figure 2 For a schematic diagram of supplier information configuration provided in this application embodiment, please refer to [link / reference]. Figure 2As shown, the supplier information includes supplier contract expiration reminders, supplier configuration, supplier metadata, billing rule metadata, and supplier service details. The supplier contract expiration reminder mainly includes the supplier configuration ID (Identity document), service information, alarm method, alarm rules, and the recipient's contact number. Supplier configuration includes: unique identifier ID, supplier code, supplier name, supplier alias, supplier information (backend address, account), creator, and updater. The supplier metadata mainly includes the supplier code, supplier name, and supplier type; the billing rule metadata mainly includes the billing rule ID and billing rule; and the supplier service details table mainly includes the supplier configuration ID, service category ID, service subcategory ID, billing rule ID, creator, and updater.

[0040] Figure 3 For a schematic diagram of the service information configuration provided in the embodiments of this application, please refer to [link / reference]. Figure 3 As shown, the configured service information mainly includes service information, service subclasses, service subclass channel ratios, and billing rules. Service information includes: service category ID, category name, aggregation name (displayed on the page), template identifier, service application link, service description (displayed on the page), and availability status. Service subclasses mainly include service subclass ID, service category ID, service subclass name, availability status, and category code. Service subclass channel ratios mainly include service subclass ID and channel ratio. Service + Supplier + Billing Rules mainly include: service subclass ID, supplier code, and billing rule ID.

[0041] Figure 4 This is a schematic diagram of access information configuration provided in an embodiment of this application. The access information mainly refers to the configuration information related to the access service request. Please refer to [link / reference]. Figure 4 As shown, the access information mainly includes alarm configuration, template information, sensitive field metadata, service owner, and sensitive fields. Among them, alarm configuration includes service code, alarm rules, alarm threshold, interception threshold, and trigger time. Access information includes: service number, service subclass, associated template, and business unit. Template information mainly includes template ID, template name, template content, and other fields. Service owner includes service number and owner. Sensitive fields include template ID, placeholder, and sensitive field type.

[0042] Figure 5 This is a schematic diagram of the service record configuration provided in the embodiments of this application. Recording the service call process can facilitate information tracing and tracking. Please refer to [link / reference]. Figure 5As shown, the service record mainly includes service billing information and service call information. The service billing information mainly includes the service number, service subclass, number of calls, and number of billing transactions. The service call information mainly includes the service number, caller, service subclass, count, and statistical date.

[0043] The service platform receives service request information from the business server, parses the service request information to obtain the service category identifier corresponding to the service request information, determines the permission information corresponding to the service category based on the service category identifier, identifies the target supplier server corresponding to the service category if the service category has the necessary permissions, and sends a service call request to the target supplier server; it receives the service request result from the target supplier server based on the service call request, and feeds back the processing result of the target supplier server for the service call request to the business server. The service requests include one or more of the following: SMS verification, SMS notification, identity verification, one-click login, speech synthesis, push notifications, OCR (Optical Character Recognition) recognition, and online payment.

[0044] As can be seen, the business management system provided in this embodiment can use a service middle platform to uniformly manage multiple business clients. Each time, based on the service request of the business client, it uniformly coordinates and calls the supplier server to complete the business processing. This eliminates the need to develop communication interfaces between each business client and multiple supplier servers, reducing workload. Moreover, the service middle platform can uniformly manage multiple business clients and coordinate the completion of business processing by each supplier server. Specifically, the service middle platform can realize service backend management, third-party contract management, service access SOP (Standard Operating Procedure), service call billing, service reconciliation and other capabilities. It can also support service provider selection and disaster recovery and degradation capabilities, improving business processing efficiency and facilitating information management.

[0045] By abstracting third-party services, the system provides a unified and user-friendly API. Service IDs are applied for within the system, and authentication and call restrictions are implemented when business users call the API. When a business needs to use a specific third-party service, it must apply for a service ID corresponding to that service category on the platform. When the service is actually called, the system verifies whether the service ID is authorized to access the specific service; if not, an error is displayed. If service access limits or frequency restrictions are set during the application process, access will be blocked after reaching a certain threshold.

[0046] Each service caller (i.e., the business client) needs to apply for a service credential, i.e., a service number, in the background. Only after the application is approved can it pass the authentication and verification of the SDK. The service configuration of the service platform includes the basic service purpose, service subclass (the specific type of third-party service used), and service alarm configuration, etc.

[0047] In one embodiment of this application, the service platform is further configured to, if it is determined that the service category has the necessary permissions, determine whether the number of accesses to the service category or the business server has reached a preset access threshold. If so, the platform determines the target supplier server corresponding to the service category and sends a service request to the target supplier server. If not, the platform refuses the service category or the business server from accessing the target supplier server.

[0048] For example, counting is performed based on the service number dimension to determine whether the current service number has reached the daily threshold / monthly threshold / yearly threshold. If it exceeds the threshold by a certain percentage, it will be blocked.

[0049] In essence, for a service request to access the service platform, the platform first parses the information included in the request to obtain information such as the business client's ID and the corresponding service category identifier. For example, it can determine whether the business client has access permissions based on the ID; if not, an error is reported. Alternatively, after parsing the corresponding service category identifier, each service category identifier is represented by a unique service number. By applying for a service number from the service platform, authentication and call restrictions are implemented when the business calls the API. When a business needs to use a third-party service, it needs to apply for a service number under the corresponding service category from the service platform. When the service is actually called, the platform verifies whether the service number can access the specific service; if not, an error is reported; if access is granted, the current access request is allowed.

[0050] In one embodiment, the number of accesses and access thresholds for each business client or service number can be configured in the service middleware. If service access volume or access limit is set in the service middleware, access will be blocked after the access threshold is reached.

[0051] For example, after enabling intelligent alarm interception in the service platform, an alarm message is sent when the number of paid calls exceeds 60% of the estimated number, or the call request is intercepted when the number of paid calls exceeds 300% of the estimated number. When the call volume exceeds 60% of the estimated usage, a DingTalk work notification and a DingTalk group notification will be sent; when the call volume exceeds 240% of the estimated usage, a DingTalk work notification and a DingTalk phone notification will be sent. The user needs to click the "Process" button in the work notification within 5 minutes to cancel the reminder and adjust the estimated usage.

[0052] Most third-party service providers need to be confirmed through business procurement processes. However, during cooperation with suppliers, the usage ratio of a supplier may need to be changed due to price adjustments, contract expiration, or other reasons. The traditional approach is to hardcode the supplier usage ratio directly into the code, which cannot achieve flexible allocation or effective supplier selection.

[0053] To overcome the above-mentioned technical defects, in one embodiment of this application, the service platform is further configured to obtain the attribute information of each supplier server for each supplier server of the same service category, and configure the traffic ratio of each supplier server according to the attribute information of each supplier server.

[0054] For example, for multiple supplier servers with SMS sending capabilities, the system retrieves the throughput capacity, pricing data, and other attribute information for each supplier. Based on this comprehensive analysis, the system configures the traffic allocation for each supplier server; for example, the traffic allocation for supplier A: supplier B: supplier C can be configured as 30%:30%:40%. This system supports directly configuring the traffic allocation for each third-party service supplier in the service platform and supports setting primary and backup suppliers, providing a more flexible strategy for supplier selection.

[0055] In one embodiment of this application, the service platform is further configured to determine the priority order of multiple supplier servers based on the attribute information of each supplier server for the same service category; and when it is determined that a supplier server has failed, to reduce the priority of the failed supplier server or to re-determine the priority order of multiple supplier servers. In other words, in supplier selection, this embodiment supports flexible selection of multiple strategies (the priority of the strategy supports dynamic orchestration according to different service types, and also supports adding custom strategies). For example, under normal circumstances, the priority of supplier A (i.e., the corresponding supplier server A) is A. When the service platform detects that supplier server A has failed, it reduces the priority of supplier server A to B.

[0056] In one embodiment of this application, a specific business client or business number may be specified to call a specific vendor server for processing.

[0057] In one embodiment of this application, the service platform is further configured to determine whether to charge based on the call feedback result each time the target supplier server is called; after determining that the call is successful, the basic information of the target supplier server called this time is sent to the big data platform; the big data platform is configured to record the billing data of the target supplier server called this time based on the basic information; the big data platform is further configured to integrate the billing data according to department information, service type or number of billings, and feed back the integrated billing data to the service platform.

[0058] For example, it is necessary to apply for a service call number in the system, associate the access information with a billing department, and configure relevant templates and alarms. Each call record and subsequent billing information are then linked through the service call number. For instance, all billing items for department A are recorded, and after a period of time, all expenses for department A are consolidated and a detailed expense statement is output for user viewing and management. Alternatively, in one application scenario, the relevant expenses for SMS services in all departments of company A are statistically analyzed and retrieved, allowing users to view the billing status of a specific service type.

[0059] After collaborating with dozens of third-party suppliers, the system allows for the configuration of supplier pricing information within the service provision settings, tailored to the characteristics of different services. When business users actually call the API, the system records the result of each call: the caller's service ID, call success / failure, number of billing attempts, billing supplier, billing department, and other information. This data is collected into a big data platform using common billing metadata. On the big data platform, through the integration of underlying service information, the system can calculate the daily call volume and billing details for each service by each department, facilitating subsequent reconciliation and analysis by finance and other personnel.

[0060] By checking the system call logs and link records, the API call status at that time can be found over a period of time, thus enabling actual call backtracking.

[0061] In one embodiment, the big data platform can associate all detailed data information through metadata information, and finally integrate the data into key information such as department, service, number of calls, and number of billings through aggregation and other methods, making it convenient for users to view.

[0062] In one embodiment of this application, the service platform is further configured to parse service request information, obtain service category identifiers and sensitive data from the service request information, determine the access permissions of the current service request information based on the service category identifiers and sensitive data, and when it is determined that the current service request information has access permissions, determine the corresponding target supplier server based on the service category identifiers and sensitive data, and send a service call request to the corresponding target supplier server. In other embodiments, the corresponding target supplier server can also be determined based on either the service category identifier or the sensitive data.

[0063] For example, this system collects and integrates all calls to third-party services, maintains sensitive data and access authentication information, and avoids some compliance issues. For instance, facial data from liveness detection, cloud vendor AK / SK, WeChat access tokens, and other information are all stored uniformly on the service platform, avoiding problems such as scattered sensitive data and chaotic unified credential storage.

[0064] In one embodiment of this application, the service platform is further configured to obtain the call volume, call time, and number of requests sent to the target supplier server per second during the call to the target supplier server, and store the call volume, call time, and number of requests sent to the target supplier server per second.

[0065] Among them, the service platform supports relevant monitoring metrics at the supplier level for all third-party service calls. During the service request process, the service platform records information such as the time of all call requests, call volume, call response time, and call QPS (Query Per Second). It also generates link storage based on information such as call volume, call response time, and call QPS, and supports link tracing to facilitate users to view call information and link tracing, thereby improving information management efficiency.

[0066] In one embodiment of this application, the service platform is further configured to generate call logs based on the call volume, call time, and the number of requests sent to the target vendor server per second when a log request is received, and send the call logs to the corresponding business client to facilitate users in viewing call information and link tracing, thereby improving information management efficiency.

[0067] In one embodiment of this application, the service platform is further configured to receive information modification requests and modify the corresponding configuration information according to the information modification requests; the information modification requests are used to request modification of one or more of the following: the access permissions of the business client, the traffic share of the supplier server, the priority order of multiple supplier servers, and the selection strategy of the supplier server; the service platform is further configured to record the configuration information modification event during the modification process, so as to generate an event snapshot and store the event snapshot, so as to facilitate users to view the modified information and improve information management efficiency.

[0068] As can be seen from the above description, the business management system provided in this embodiment has the following technical advantages compared with the prior art: 1. Platform-based unified management: This embodiment uses the centralized management capabilities of the service platform to achieve full lifecycle management of suppliers, third-party services, and service access parties. It can also provide statistics and display of service usage and billing data, avoiding information fragmentation and increased operating costs caused by decentralized management of multiple systems.

[0069] 2. Standardized access and development: This embodiment provides a unified third-party service access SDK through a service platform, which standardizes and modularizes the common processes of different services, reduces development and maintenance costs, reduces repetitive work, and improves the speed and quality of new service launch.

[0070] 3. High availability and flexible switching strategy: The service platform supports flexible selection and strategic management of multiple vendors. Combined with a configurable degradation mechanism, it can achieve automatic degradation and uninterrupted business in the event of failure, significantly improving system availability and service continuity.

[0071] 4. Intelligent Billing and Reconciliation: Leveraging big data processing capabilities, it enables the automatic collection, cleaning, and comparison of billing data from multiple parties, improving reconciliation efficiency and accuracy, and reducing manual intervention and financial risks.

[0072] The following provides a business management method applied to a service middleware platform. The service middleware platform is configured to communicate and interact with multiple business clients using a unified API interface, where different business types correspond to different API interfaces. Simultaneously, the service middleware platform is also configured to communicate and interact with multiple vendor servers, where communication between the service middleware platform and different vendor servers uses unique identifier addresses. The business management method provided below can be referenced and corresponded to the business management systems provided in the above embodiments.

[0073] Figure 6 For a schematic diagram of the business management method provided in the embodiments of this application, please refer to [link / reference]. Figure 6 As shown, the business management method provided in this embodiment includes: S601. Receive service request information sent by the business server, parse the service request information, and obtain the service category identifier corresponding to the service request information; wherein, the service request includes one or more of the following: SMS verification, SMS notification, identity information verification, one-click login, speech synthesis, information push, OCR recognition, and online payment.

[0074] S602. Determine the permission information corresponding to the service category based on the service category identifier. If the service category has the necessary permissions, determine the target supplier server corresponding to the service category and send a service call request to the target supplier server.

[0075] S603. Receive the service request result fed back by the target supplier server based on the service call request, and feed back the processing result of the target supplier server on the service call request to the business server.

[0076] The business management method provided in this embodiment allows for unified management of multiple business clients using a service middleware platform. Each time a business client requests a service request, the platform coordinates and calls the supplier server to complete the business processing. This eliminates the need to develop communication interfaces between each business client and multiple supplier servers, reducing workload. Furthermore, the service middleware platform can uniformly manage multiple business clients and coordinate with each supplier server to complete business processing. Specifically, the service middleware platform can implement capabilities such as service backend management, third-party contract management, service access SOP (Standard Operating Procedure), service call billing, and service reconciliation. It can also support service provider selection and disaster recovery / descendancy capabilities, improving business processing efficiency and facilitating information management.

[0077] In one embodiment of this application, the business management method further includes: if it is determined that the service category has the necessary permissions, determining whether the number of accesses to the service category or the business server has reached a preset access threshold; if so, determining the target supplier server corresponding to the service category and sending a service request to the target supplier server; if not, denying the service category or the business server access to the target supplier server.

[0078] In one embodiment of this application, the business management method further includes: for each supplier server of the same service category, obtaining the attribute information of each supplier server, and configuring the traffic ratio of each supplier server according to the attribute information of each supplier server.

[0079] In one embodiment of this application, the business management method further includes: determining the priority order of multiple supplier servers based on the attribute information of each supplier server for the same service category; and when it is determined that a supplier server has failed, reducing the priority of the failed supplier server or re-determining the priority order of multiple supplier servers.

[0080] In one embodiment of this application, the business management method further includes: determining whether to charge based on the call feedback result each time the target supplier server is called; after determining that the call is successful, sending the basic information of the target supplier server called this time to the big data platform; the big data platform is used to record the billing data of the target supplier server called this time based on the basic information; the big data platform is also used to integrate the billing data according to department information, service type or billing frequency, and feed back the integrated billing data to the service middle platform.

[0081] In one embodiment of this application, the business management method further includes: parsing the service request information to obtain the service category identifier and sensitive data in the service request information; determining the access permissions of the current service request information based on the service category identifier and sensitive data; and when it is determined that the current service request information has access permissions, determining the corresponding target supplier server based on the service category identifier and / or sensitive data, and sending a service call request to the corresponding target supplier server.

[0082] In one embodiment of this application, the business management method further includes: during the process of calling the target supplier server, obtaining the call volume, call time, and the number of requests sent to the target supplier server per second, and storing the call volume, call time, and the number of requests sent to the target supplier server per second.

[0083] In one embodiment of this application, the business management method further includes: upon receiving a log request, generating a call log based on the call volume, call time, and the number of requests sent to the target vendor server per second, and sending the call log to the corresponding business client.

[0084] In one embodiment of this application, the service management method further includes: receiving an information modification request, modifying the corresponding configuration information according to the information modification request; the information modification request is used to request modification of one or more of the following: the access permission of the service client, the traffic share of the supplier server, the priority order of multiple supplier servers, and the selection strategy of the supplier server; recording the modification event of the configuration information during the modification process, so as to generate an event snapshot and store the event snapshot.

[0085] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive (SSD).

[0086] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments of this application.

[0087] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0088] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0089] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0090] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0091] If the aforementioned function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application embodiment, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a memory (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] Finally, it should be noted that the above embodiments are merely specific implementations of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A business management system, characterized in that, The business management system includes a service platform, which is configured to communicate and interact with multiple business clients using a unified API interface, wherein different business types correspond to different API interfaces; the service platform is also configured to communicate and interact with multiple vendor servers, wherein the service platform communicates with different vendor servers using unique identifier addresses. The service platform is used to receive service request information sent by the business server, parse the service request information to obtain the service category identifier corresponding to the service request information; determine the permission information corresponding to the service category based on the service category identifier; if the service category has the necessary permissions, determine the target supplier server corresponding to the service category and send a service call request to the target supplier server; receive the service request result fed back by the target supplier server based on the service call request, and feed back the processing result of the target supplier server for the service call request to the business server. The service requests include one or more of the following: SMS verification, SMS notification, identity information verification, one-click login, speech synthesis, information push, OCR recognition, and online payment.

2. The business management system according to claim 1, characterized in that, The service platform is further configured to, when determining that the service category has the necessary permissions, determine whether the number of accesses to the service category or the business server has reached a preset access threshold. If so, determine the target supplier server corresponding to the service category and send a service request to the target supplier server; otherwise, refuse the service category or the business server from accessing the target supplier server.

3. The business management system according to claim 2, characterized in that, The service platform is also used to obtain the attribute information of each supplier server for each supplier server of the same service category, and configure the traffic ratio of each supplier server according to the attribute information of each supplier server.

4. The business management system according to claim 3, characterized in that, The service platform is also used to determine the priority order of multiple supplier servers based on the attribute information of each supplier server for the same service category. And if it is determined that one of the vendor servers has failed, the priority of the failed vendor server will be reduced or the priority order of multiple vendor servers will be re-determined.

5. The business management system according to claim 3, characterized in that, The service platform is also used to determine whether to charge based on the call feedback result each time the target supplier server is called, and after confirming that the call is successful, to send the basic information of the target supplier server call to the big data platform. The big data platform is used to record the billing data of the call to the target supplier server based on the basic information. The big data platform is also used to integrate the billing data according to department information, service type or billing frequency, and feed the integrated billing data back to the service platform.

6. The business management system according to claim 3, characterized in that, The service platform is also used to parse the service request information, obtain the service category identifier and sensitive data in the service request information, determine the access permissions of the current service request information based on the service category identifier and sensitive data, and when it is determined that the current service request information has access permissions, determine the corresponding target supplier server based on the service category identifier and / or the sensitive data, and send a service call request to the corresponding target supplier server.

7. The business management system according to claim 6, characterized in that, The service platform is also used to obtain the call volume, call time, and number of requests sent to the target supplier server per second during the call to the target supplier server, and to store the call volume, call time, and number of requests sent to the target supplier server per second.

8. The business management system according to claim 7, characterized in that, The service platform is also used to generate call logs based on the call volume, call time, and the number of requests sent to the target supplier server per second when a log request is received, and to send the call logs to the corresponding business client.

9. The business management system according to claim 7, characterized in that, The service platform is also used to receive information modification requests and modify the corresponding configuration information according to the information modification requests; the information modification requests are used to request modification of one or more of the following: the access permissions of the business client, the traffic share of the supplier server, the priority order of multiple supplier servers, and the selection strategy of the supplier server; The service platform is also used to record events that modify the configuration information during the modification process, so as to generate and store event snapshots.

10. A business management method, applied in a service middle platform, characterized in that, The service platform is configured to communicate and interact with multiple business clients using a unified API interface, wherein different business types correspond to different API interfaces; the service platform is also configured to communicate and interact with multiple vendor servers, wherein the service platform communicates with different vendor servers using unique identifier addresses. The business management methods include: The system receives service request information sent by a business server, parses the service request information, and obtains the service category identifier corresponding to the service request information; wherein, the service request includes one or more of the following: SMS verification, SMS notification, identity information verification, one-click login, speech synthesis, information push, OCR recognition, and online payment. Based on the service category identifier, determine the permission information corresponding to the service category. If the service category has the necessary permissions, determine the target supplier server corresponding to the service category and send a service call request to the target supplier server. The system receives the service request result from the target supplier server based on the service call request, and then sends the processing result of the target supplier server for the service call request back to the business server.

Images