Communication platform service object determination method and device, equipment, medium and product

Abstract

The invention provides a communication platform service object determination method and device, equipment, a medium and a product, and relates to the technical field of data processing. The method comprises the following steps: receiving a service request containing a tenant identifier and a service demand parameter of a service module, screening a preset adapter list based on the service demand parameter to determine a candidate adaptive unit list, and matching a preset strategy mapping table according to the tenant identifier to obtain a target routing strategy; and finally, screening out a target adaptation unit and a corresponding communication address from the candidate adaptation units according to a target routing strategy so as to call the target service object and return response data to the service module. Therefore, a high coupling condition caused by dependence on point-to-point direct connection when an existing communication platform and external heterogeneous services are integrated is effectively avoided, a personalized demand that a tenant selects the external services as required is realized, the flexibility and expansibility of the system and the adaptation capability of the external services are improved, and the system performance is improved. The problem that tenant-level dynamic service selection is difficult to realize under a multi-tenant architecture is solved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, equipment, medium and product for determining the service objects of a communication platform. Background Technology

[0002] Currently, in the integrated development of enterprise-level SaaS communication platforms, the platform needs to integrate various heterogeneous external services to achieve functional expansion, such as call center, speech recognition, text-to-speech, and natural language processing services. These services are typically provided by different vendors, and their interface protocols, data formats, and functional characteristics vary significantly. In a multi-tenant architecture, the platform needs to dynamically configure the external services and policies available to each tenant.

[0003] However, in existing technologies, the integration of SaaS platforms with external services heavily relies on point-to-point direct connections or traditional enterprise service buses, resulting in high system coupling, high maintenance costs, and difficulty in achieving dynamic service selection at the tenant level. Furthermore, when external service providers change, API versions are upgraded, or services fail, existing solutions often require modification of business code or reconfiguration of integration logic, limiting the system's flexibility and scalability. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for determining the service objects of a communication platform, in order to solve the problems in the prior art.

[0005] Firstly, this application provides a method for determining the service object of a communication platform, including:

[0006] Receive service requests sent by the business module; wherein the service request includes a tenant identifier and business requirement parameters;

[0007] The system filters the preset adapter list based on the business requirement parameters to determine the candidate adaptation unit list; and matches the tenant identifier in the preset policy mapping table to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies.

[0008] Based on the target routing strategy, the candidate adapter list is filtered to determine the matching target adapter and the communication address corresponding to the target adapter.

[0009] Invoke the corresponding target service object based on the communication address;

[0010] Receive the response data returned by the target service object and return the response data to the business module.

[0011] In one possible design, before receiving the service request sent by the service module, the following is also included:

[0012] Receive registration requests from multiple service objects corresponding to their corresponding adaptation units;

[0013] Obtain the metadata of each adaptation unit, wherein the metadata includes service type, capability description, communication address and health status;

[0014] The metadata of each adapter unit is verified, and the adapter units that pass the verification are stored in the preset adapter list.

[0015] In one possible design, the business requirement parameters include functional requirements, geographic requirements, and service quality requirements;

[0016] The step of filtering the preset adapter list based on the business requirement parameters to determine the candidate adapter unit list includes:

[0017] Filter the adapters whose health status is available from the preset adapter list to obtain an initial filter list;

[0018] Based on the functional requirements, the regional requirements, and the service quality requirements, the initial filtering list is matched to determine multiple candidate adaptation units that match all three requirements.

[0019] The list of candidate adapters is determined based on the multiple candidate adapters.

[0020] In one possible design, the routing strategy includes a cost-first strategy;

[0021] The step of filtering the candidate adapter list based on the target routing policy to determine the matching target adapter and the communication address corresponding to the target adapter includes:

[0022] When the target routing strategy is a cost-first strategy, extract the cost parameters of each candidate adaptation unit in the candidate adaptation unit list;

[0023] The candidate adaptation unit with the lowest cost parameter among all the candidate adaptation units is selected as the target adaptation unit.

[0024] Extract the communication address of the target adapter unit, the communication address including a Uniform Resource Identifier and protocol type information.

[0025] In one possible design, the step of invoking the corresponding target service object based on the communication address includes:

[0026] The service request is converted into a target request that matches the protocol format of the target adaptation unit;

[0027] Based on the Uniform Resource Identifier and Protocol Type information in the communication address, the target request is sent to the corresponding target service object through the target adaptation unit.

[0028] In one possible design, receiving the response data returned by the target service object and returning the response data to the business module includes:

[0029] The target adaptation unit receives the response data returned by the target service object.

[0030] The response data is converted into a standardized response format; wherein the standardized response format includes response status codes and business result data;

[0031] Perform integrity verification on the format-converted response data;

[0032] If the response data passes verification, the format-converted response data is returned to the business module.

[0033] In one possible design, after invoking the corresponding target service object based on the communication address, the process further includes:

[0034] If no response data is received from the target service object within a preset time, the target service object is called again, and the number of retries to call the target service object is recorded.

[0035] If the number of retries exceeds a preset threshold and no response data is received from the target service object, a backup adapter unit is selected from the candidate adapter unit list, and the corresponding backup service object is called based on the communication address of the backup adapter unit.

[0036] Secondly, this application provides a service interface determination device for a communication platform, comprising:

[0037] The request receiving module is used to receive service requests sent by the business module; wherein the service request includes a tenant identifier and business requirement parameters;

[0038] The adaptation filtering and policy matching module is used to filter the candidate adaptation unit list based on the business requirement parameters to determine the candidate adaptation unit list; and to match the tenant identifier in the preset policy mapping table to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies.

[0039] The target adaptation decision module is used to filter the candidate adaptation unit list based on the target routing strategy to determine the matching target adaptation unit and the communication address corresponding to the target adaptation unit.

[0040] The service invocation module is used to invoke the corresponding target service object based on the communication address;

[0041] The response receiving and return module is used to receive the response data returned by the target service object and return the response data to the business module.

[0042] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0043] The memory stores computer-executed instructions;

[0044] The processor executes computer execution instructions stored in the memory to implement the method as described in any of the first aspects.

[0045] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0046] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0047] This application provides a method, apparatus, device, medium, and product for determining service objects in a communication platform. The method receives a service request from a business module containing a tenant identifier and business requirement parameters. First, it filters a preset adapter list based on the business requirement parameters to determine a list of candidate adaptation units. Then, it matches the tenant identifier with a preset policy mapping table to obtain the target routing policy. Finally, it filters the target adaptation unit and its corresponding communication address from the candidate adaptation units according to the target routing policy, calls the target service object, and returns response data to the business module. This effectively avoids the high coupling caused by point-to-point direct connections when integrating existing SaaS communication platforms with external heterogeneous services. It reduces maintenance costs caused by changes in external service providers, API version upgrades, or service failures. It eliminates the need to modify business code or reconfigure integration logic. Furthermore, it enables tenants to select external services on demand, improving the system's flexibility, scalability, and adaptability to external services. It also solves the problem of difficulty in achieving dynamic service selection at the tenant level in multi-tenant architectures. Attached Figure Description

[0048] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0049] Figure 1 An application scenario diagram corresponding to a method for determining a communication platform service object provided in an embodiment of this application;

[0050] Figure 2 A flowchart illustrating a method for determining a communication platform service object according to an embodiment of this application;

[0051] Figure 3 A flowchart illustrating a method for determining a communication platform service object, provided in yet another embodiment of this application;

[0052] Figure 4 A schematic diagram of the structure of a device for determining a communication platform service object provided in an embodiment of this application;

[0053] Figure 5 This is a structural example diagram of an electronic device provided in an embodiment of this application.

[0054] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0055] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0056] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0057] In the integration and development of current enterprise-level SaaS (Software as a Service) communication platforms, the platform needs to integrate various heterogeneous external services to achieve functional expansion, such as call center (CTI, Computer Telephony Integration), automatic speech recognition (ASR, Automatic Speech Recognition), text-to-speech (TTS, Text-to-Speech), and natural language processing (NLP). These services are typically provided by different vendors, and their interface protocols, data formats, and functional characteristics vary significantly. For example, the intelligent outbound calling module of a SaaS platform needs to call the CTI service to initiate a call, but different vendors' CTI services may support different operations (such as whether they support recording), or have different concurrency capabilities in specific regions (such as Asia and Europe). In a multi-tenant architecture, the platform needs to dynamically configure the external services available to each tenant and their policies (such as cost priority, SLA guarantees, etc.).

[0058] However, in existing technologies, the integration of SaaS platforms with external services heavily relies on point-to-point direct connections or traditional ESB (Enterprise Service Bus), resulting in high system coupling, high maintenance costs, and difficulty in achieving dynamic service selection at the tenant level. Furthermore, when external service providers change, API versions are upgraded, or services fail, existing solutions often require modification of business code or reconfiguration of integration logic, limiting the system's flexibility and scalability.

[0059] Therefore, there is an urgent need for a unified method for determining the service objects of communication platforms to address the system decoupling, flexible configuration, and intelligent decision-making requirements of SaaS platforms in multi-tenant and multi-service provider integration scenarios.

[0060] Therefore, to address the technical challenges faced by enterprise-level SaaS communication platforms in integrating heterogeneous external services, such as high coupling, high maintenance costs, and difficulties in dynamic tenant configuration, the following solutions are proposed. First, to address the strong binding between the system and external services caused by existing point-to-point direct connections and traditional ESB integration methods, which require isolating business modules from specific external services through an abstraction layer, a pre-defined adapter list is conceived. This encapsulates external services from different vendors and with different protocols into standardized adaptation units, allowing business modules to connect to various heterogeneous services without needing to concern themselves with the underlying service implementation, thus achieving decoupling. Second, to address the differences in tenant policy requirements (such as cost and SLA) under a multi-tenant architecture, and the need for dynamic response to service changes, a pre-defined mapping table between tenant identifiers and routing policies is conceived. This allows the system to accurately match tenant policy requirements based on tenant identifiers. Furthermore, the logic of combining business requirements to determine the adaptation scope and tenant policies to determine the final selection is implemented. Candidate adaptation units are first screened according to business requirements, and then the selection method for target adaptation units is determined according to tenant policies. This ensures the matching of adaptation units with business requirements, meets the personalized selection needs of tenants, and thus solves the coupling, maintenance, and dynamic adaptation problems of existing technologies.

[0061] Figure 1 An application scenario diagram corresponding to a method for determining a communication platform service object provided in an embodiment of this application is shown, such as... Figure 1 As shown, the application scenario provided in this embodiment includes: a business module 11 of a SaaS communication platform, a service object determination device 12, and a target service object 13. Both the business module 11 and the target service object 13 are communicatively connected to the service object determination device 12.

[0062] Specifically, in the SaaS communication platform, the business module 11, as the entity initiating the service request, sends a service request to the service object determination device 12 when there is a business need. This service request includes a tenant identifier and business requirement parameters. The tenant identifier is used to uniquely identify different tenants, while the business requirement parameters describe in detail the specific functionalities, performance, and other requirements of the business.

[0063] Specifically, after receiving a service request from the service module 11, the service object determination device 12 first filters a preset adapter list based on service requirement parameters. This preset adapter list records various adapter units and the range of service requirements they can handle. Through filtering, the service object determination device 12 determines a list of candidate adapter units that can meet the current service requirement parameters. The service object determination device 12 also matches a preset policy mapping table based on tenant identifiers. The preset policy mapping table stores the correspondence between multiple tenant identifiers and routing policies. Different tenants may correspond to different routing policies to meet their personalized service needs. Through matching, the service object determination device 12 determines the target routing policy corresponding to the tenant identifier. After obtaining the candidate adapter unit list and the target routing policy, the service object determination device 12 further filters the candidate adapter unit list based on the target routing policy. Through filtering, the service object determination device finally determines the matching target adapter unit and obtains the communication address corresponding to the target adapter unit.

[0064] Specifically, the service object determination device initiates a call request to the corresponding target service object 13 based on the communication address of the determined target adapter unit. The target service object 13 is the entity that actually provides the specific business functions; upon receiving the call request, it begins executing the corresponding business logic. After completing the business processing, the target service object 13 returns the generated response data to the service object determination device 12. Upon receiving the response data, the service object determination device 12 then returns the response data to the business module 11 that initially initiated the service request, thereby completing the entire process of determining the service object and processing the business on the communication platform.

[0065] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0066] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0067] Figure 2A flowchart illustrating a method for determining a communication platform service object according to an embodiment of this application is shown below. Figure 2 As shown, the execution subject of this embodiment is a device for determining a communication platform service object. This device can be implemented by a computer program, or by a medium storing the relevant computer program, such as a USB flash drive and / or optical disc; or it can be implemented by a physical device integrating or installing the relevant computer program, such as a chip or electronic device. The electronic device may be a computer or a server, etc. The method for determining a communication platform service object provided in this embodiment includes the following steps:

[0068] S201. Receive service requests sent by the business module; the service request includes the tenant identifier and business requirement parameters.

[0069] Specifically, the service request includes a tenant identifier and business requirement parameters. The tenant identifier uniquely identifies the tenant within the SaaS communication platform (e.g., enterprise user "enterprise-456"), ensuring accurate matching of subsequent routing strategies with the tenant's personalized configuration. The business requirement parameters represent the tenant's service requests, including but not limited to business functionality requirements (e.g., whether recording is supported), service region (e.g., Asia, North America), concurrency requirements, and service quality level.

[0070] For example, when the intelligent outbound calling module of the SaaS platform initiates an outbound call, the tenant identifier in the service request sent is "enterprise-456", and the business requirement parameters include the calling number "+8613800138000", the called number "+8613912345678", the calling region "Asia", and the functional requirement "requires recording, does not require IVR".

[0071] It should be noted that in this embodiment, the business module does not need to pay attention to specific external service providers, but only needs to send service requests through the device for determining the service object of the communication platform, thereby decoupling the core business from external services.

[0072] S202. Based on business requirement parameters, filter the preset adapter list to determine the candidate adaptation unit list; and based on tenant identifier, match the preset policy mapping table to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies.

[0073] The preset adapter list is a pre-obtained table storing registration information for multiple adapter units (i.e., adapters for different external service providers). The preset adapter list includes descriptions of each adapter unit's supported service types, functionalities, service regions, and health status. Based on business requirement parameters, the adapter units in the preset adapter list are filtered, eliminating those that do not meet the business requirements, and retaining the qualified adapter units to form a candidate adapter unit list.

[0074] Optionally, when an external service provider fails or its policies are adjusted, there is no need to modify the business code or restart the system. By updating the preset adapter list, subsequent screening steps can match other eligible service objects based on the updated preset adapter list, thus ensuring service continuity.

[0075] Optionally, if the functional requirements (such as support for recording), service region, and other conditions in the business requirement parameters do not match the capability description of the adaptation unit, or if the adaptation unit is in an "unhealthy" state, then the adaptation unit will be directly excluded; only adaptation units whose capability descriptions cover the business requirements and whose status is healthy will be retained.

[0076] For example, the preset adapter list contains two adapter units, CTIADaptorVendorA and CTIADaptorVendorB. The business requirement parameters are "Asia region, recording required". CTIADaptorVendorA supports the Asia region and recording, and is in good condition, so it is included in the candidate list. However, CTIADaptorVendorB supports the Asia region but does not support recording, and does not meet the functional requirements, so it is excluded.

[0077] The preset policy mapping table is a pre-defined table that maps multiple tenant identifiers to routing policies. Routing policies are service selection rules preset by tenants based on their needs. Routing policies can include, but are not limited to, cost-priority, performance-priority, feature-priority, and region-priority policies. By accurately matching the tenant identifier in the service request against the preset policy mapping table, the target routing policy corresponding to that tenant is obtained.

[0078] For example, if the tenant "enterprise-456" has a default routing policy in the policy mapping table that is "select the lowest cost supplier while meeting functional requirements", then this policy will be determined as the target routing policy after matching.

[0079] S203. Based on the target routing policy, filter the candidate adapter list to determine the matching target adapter and the communication address corresponding to the target adapter.

[0080] Optionally, for each candidate adapter in the candidate adapter list, decision information (such as cost, response time, concurrency limit, etc.) can be extracted from the capability description of each candidate adapter, and a second screening can be performed in combination with the target routing strategy to finally determine the unique matching target adapter and obtain the communication address corresponding to the target adapter (such as Camel endpoint URI "vm:cti-vendor-x").

[0081] Optionally, if the target routing strategy prioritizes performance, the candidate adaptation unit with the shortest response time and the highest concurrency limit is selected; if the target routing strategy prioritizes functionality, the candidate adaptation unit with more comprehensive functionality is selected.

[0082] For example, if the candidate adapter list only contains CTIADaptorVendorA and the target routing policy is "cost priority", then CTIADaptorVendorA is directly determined as the target adapter, and its communication address is "vm:cti-vendor-x". If the candidate list contains multiple adapters, the matching degree of each adapter needs to be calculated according to the policy, and the adapter with the highest matching degree is selected as the target adapter.

[0083] S204. Invoke the corresponding target service object based on the communication address.

[0084] The target adapter unit serves as an adaptation bridge between the external service provider and the communication platform, and its communication address is used to locate the service endpoint of the target adapter unit.

[0085] Optionally, the standardized service request is routed to the target adaptation unit, which converts the standardized request into a specific protocol and data format (such as XML format) supported by the external service provider (i.e., the target service object), adds the authentication information required by the service provider, and then calls the API (Application Programming Interface) of the target service object.

[0086] For example, the listening communication address "vm:cti-vendor-x" of the target adaptation unit CTIADaptorVendorA receives a standardized service request, converts the service request into the XML format required by Vendor X's API, adds an authentication token, and calls Vendor X's "Create Outbound Call Task" API through the HTTP component.

[0087] S205. Receive the response data returned by the target service object and return the response data to the business module.

[0088] Optionally, after the target service object performs the service, response data (such as call session ID, execution status, etc.) is returned to the target adaptation unit.

[0089] Optionally, the target adaptation unit converts the response data from the specific format of the external service provider into a standardized format unified by the platform, and then returns it to the business module that initiated the request through the service object determination device of the communication platform, thus completing the entire service call process.

[0090] For example, vendor X returns an XML response containing a call session ID, which CTIADAptorVendorA converts into a unified UnifiedMakeCallResponse format and returns to the intelligent outbound calling module for the business module to update the call status.

[0091] This application provides a method for determining a communication platform service object. It receives a service request from a business module containing a tenant identifier and business requirement parameters. First, it filters a preset adapter list based on the business requirement parameters to determine a list of candidate adaptation units. Then, it matches the tenant identifier with a preset policy mapping table to obtain the target routing policy. Finally, it filters the target adaptation unit and its corresponding communication address from the candidate adaptation units according to the target routing policy, calls the target service object, and returns response data to the business module. This effectively avoids the high coupling caused by point-to-point direct connections when integrating existing SaaS communication platforms with external heterogeneous services. It reduces maintenance costs caused by changes in external service providers, API version upgrades, or service failures. It eliminates the need to modify business code or reconfigure integration logic. Furthermore, it enables tenants to select external services on demand, improving the system's flexibility, scalability, and adaptability to external services. It also solves the problem of difficulty in achieving dynamic service selection at the tenant level in multi-tenant architectures.

[0092] Figure 3 A flowchart illustrating a method for determining a communication platform service object, as provided in another embodiment of this application, is shown below. Figure 3 As shown in the illustration, as an optional implementation, in addition to any of the above embodiments, the following steps are included before receiving the service request sent by the service module:

[0093] S301. Receive registration requests from multiple service objects corresponding to their corresponding adapter units.

[0094] The adapter unit serves as the adapter between external service objects (such as CTI vendors and ASR vendors) and the SaaS communication platform. Each service object corresponds to a dedicated adapter unit. After deployment and startup, the adapter unit proactively sends a registration request to the service registration module of the designated device of the communication platform service object. The registration request incorporates itself into the service management system of the communication platform.

[0095] Optionally, the registration request can be triggered when the adaptation unit is first deployed and started, the service is restarted, or the configuration is updated. It can also be dynamically initiated at runtime without interrupting the existing services of the communication platform.

[0096] For example, after deployment and startup, the adapter unit CTIAdaptorVendorA corresponding to CTI vendor A and the adapter unit CTIAdaptorVendorB corresponding to CTI vendor B send registration requests to the service registration module to apply to become an adapter resource that can be called by the communication platform.

[0097] S302. Obtain the metadata of each adapter unit, including service type, capability description, communication address and health status.

[0098] Optionally, after receiving the registration request, the service registration module extracts the metadata carried by the adaptation unit. The metadata is a comprehensive description of the capabilities and status of the adaptation unit, providing a core basis for subsequent filtering and routing.

[0099] Specifically, metadata includes service type, capability description, communication address, and health status.

[0100] Among them, the service type identifies the external service category corresponding to the adaptation unit, such as CTI (Call Center), ASR (Speech Recognition), TTS (Text-to-Speech), NLP (Natural Language Processing), etc., and is used to quickly match the service type requirements of business modules; the capability description details the business capabilities supported by the adaptation unit, including but not limited to supported operations (such as MakeCall, AnswerCall), service regions (such as Asia, North-America), maximum concurrency, cost parameters (such as price per minute), and functional characteristics (such as whether recording is supported); the communication address is the service endpoint identifier of the adaptation unit, used to locate the adaptation unit when the platform routes requests, such as Camel endpoint URI "vm:cti-vendor-x", HTTP interface address, etc.; the health status is the current running status of the adaptation unit, such as "HEALTHY", "UNHEALTHY", "STARTING", etc., which is reported by the adaptation unit after self-checking.

[0101] For example, in the metadata reported by CTIAdaptorVendorA, the service type is "CTI", the capability description includes information such as supported operations, service region, maximum concurrency of 10,000, cost of 0.015 yuan / minute, communication address is "vm:cti-vendor-x", and health status is "HEALTHY".

[0102] S303. Verify the metadata of each adapter unit and store the verified adapter units in the preset adapter list.

[0103] Optionally, the service registration module performs multi-dimensional validity checks on metadata to ensure that the adapter units included in the preset adapter list have the conditions for being invoked.

[0104] Optionally, validation can include integrity validation, format validation, validity validation, and availability pre-validation. Integrity validation checks whether the metadata contains fields such as service type, communication address, core capability descriptions (e.g., supported operations, service regions), and health status; validation fails if any required field is missing. Format validation verifies whether the communication address format conforms to platform conventions (e.g., Camel endpoint URI format, HTTP address format), whether numerical parameters in the capability description (e.g., maximum concurrency, cost) are valid, and whether enumerated parameters (e.g., service type, health status) are within the platform's preset enumeration range. Validity validation verifies whether the service type of the adapter unit belongs to the service category supported by the platform (e.g., CTI, ASR, TTS), preventing the registration of adapter units with illegal service types. Availability pre-validation sends lightweight probe requests (e.g., connection tests, null request response tests) to the adapter unit's communication address to verify whether the adapter unit is in a communicable state; if the probe fails, the health status is deemed abnormal, and validation fails.

[0105] Optionally, for adapters that pass verification, their metadata will be fully stored in the preset adapter list and synchronized to the service capability directory, and maintained by the service registration module; for adapters that fail verification, the service registration module will return a verification failure response to them, explaining the reason for the failure (such as "missing service region field"), and the adapter can correct the metadata and re-initiate the registration request.

[0106] For example, if the metadata fields of CTIADaptorVendorA are complete and the format is valid, and the communication address can be detected normally, it will be stored in the preset adapter list after verification. If the communication address reported by a certain adapter unit is in the wrong format (such as "vm:cti-vendor-" missing a suffix), the verification will fail and it will not be included in the list.

[0107] This application provides a method for determining service objects of a communication platform. The adaptation unit actively initiates a registration request and reports its own metadata to the communication platform, thereby achieving automatic access to service resources without manual configuration and improving the access efficiency of the adaptation unit. In addition, by supporting dynamic registration at runtime, it can meet the needs of service providers for flexible access and deactivation, and enhance the scalability of the system.

[0108] By validating the metadata of the adapter units and excluding invalid or illegal adapter units, the metadata in the preset adapter list is ensured to be accurate and reliable, effectively guaranteeing the quality of subsequent service calls and improving system stability and accuracy.

[0109] As an optional implementation method, based on any of the above embodiments, the business requirement parameters include functional requirements, geographical requirements, and service quality requirements.

[0110] Among them, functional requirements are the specific functional support required for a business module to initiate a service, such as the recording function in a call service, the real-time transcription function and dialect support in a speech recognition service, etc., which can be presented in the form of Boolean values, enumeration values ​​or function lists.

[0111] Among them, geographical requirements refer to the target coverage area of ​​the service or the area where the business occurs, such as the calling region of the call service (Asia, North-America).

[0112] Service quality requirements are the business's requirements for service performance, stability, etc., including but not limited to numerical or threshold parameters such as maximum concurrency, response time threshold, service availability SLA (e.g., 99.9%), and error rate limit.

[0113] Specifically, the candidate adapter list is determined by filtering based on business requirement parameters, including the following steps:

[0114] First, filter the adapters whose health status is available from the preset adapter list to obtain the initial filter list.

[0115] Optionally, each adapter unit stored in the preset adapter list contains metadata about its "health status". When filtering the preset adapter list based on business requirement parameters, the status of all adapter units in the preset adapter list is first filtered, and only adapter units with a health status of "available", that is, adapter units with a status marked as "HEALTHY" (normal operation) are retained, while adapter units that are in the state of failure (UNHEALTHY), starting (STARTING), or maintenance (MAINTENANCE) are excluded, forming an initial filter list.

[0116] It should be noted that the purpose of status filtering is to exclude adapter units that cannot currently provide effective services, thereby avoiding service failures due to call failures or unready adapters.

[0117] Secondly, based on functional requirements, regional requirements, and service quality requirements, matching is performed on the initial screening list to identify multiple candidate adaptation units that match all three requirements.

[0118] Optionally, for each adaptation unit in the initial filtering list, the capability description information in its metadata is extracted and matched sequentially with the functional requirements, regional requirements, and service quality requirements in the business requirement parameters, and only adaptation units that meet all the requirements are retained.

[0119] Optionally, when matching functional requirements, it can be verified whether the "supported Operations" of the adapter unit include the operations required by the business, and whether the functional characteristics in the "capabilities" (such as supportRecording) are consistent with the business functional requirements. If the business requirement includes a certain essential function (such as the need for recording), and the adapter unit does not support this function, then the adapter unit is directly excluded.

[0120] Optionally, when matching regional requirements, it can be verified whether the "supportedRegions" of the adaptation unit include the target region in the business requirements, or whether the service coverage of the adaptation unit can meet the relevant regional compliance requirements (such as data residence requirements). If the business regional requirement is "Asia", then only adaptation units whose supportedRegions include "Asia" will be retained.

[0121] Optionally, when matching service quality requirements, it can be verified whether the service quality-related parameters of the adaptation unit meet the business requirement thresholds. For example, the maximum concurrency of the adaptation unit must be greater than or equal to the concurrency requirement of the business requirement; the historical average response time of the adaptation unit must be less than or equal to the response time threshold of the business requirement (if the parameter is included in the metadata, or obtained through statistical data from the service registry); and the historical error rate of the adaptation unit must be lower than the upper limit of the error rate of the business requirement.

[0122] It should be noted that after the above three rounds of matching, only the adaptation units that fully match the functional requirements, regional requirements, and service quality requirements are retained, forming multiple candidate adaptation units.

[0123] Finally, a list of candidate adapter units is determined based on multiple candidate adapter units.

[0124] Optionally, if at least one candidate adaptation unit is obtained after multi-dimensional matching, all candidate adaptation units are integrated to form a candidate adaptation unit list; if no candidate adaptation unit that meets the conditions is obtained, a degradation mechanism can be triggered (such as returning a prompt that no matching adaptation unit is found, enabling the default adaptation unit, or adjusting the requirement threshold for secondary filtering) to ensure the continuity of business processes.

[0125] This application provides a method for determining communication platform service objects. Based on multi-dimensional filtering of business requirement parameters, it can accurately locate suitable units and meet the needs of complex business scenarios. First, it filters units with healthy and available status to ensure basic stability of service calls and reduce invalid attempts. Then, it comprehensively matches functional requirements, regional requirements, and service quality requirements to ensure that the selected suitable units meet business expectations. Finally, it determines a list of candidate suitable units, providing a reliable basis for accurate routing of subsequent calls to target service objects.

[0126] As an optional implementation, based on any of the above embodiments, the routing strategy includes a cost-first strategy.

[0127] The cost-first strategy refers to a routing rule that prioritizes the adaptation unit with the lowest service cost as the target adaptation unit, provided that all candidate adaptation units meet the core business requirements (function, region, service quality, etc.). It is suitable for tenants who are sensitive to service costs (such as small and medium-sized enterprises and large-scale low-profit business scenarios).

[0128] Specifically, the candidate adapter list is filtered based on the target routing policy to determine the matching target adapter and the corresponding communication address of the target adapter, including the following steps:

[0129] First, when the target routing strategy is a cost-first strategy, extract the cost parameters of each candidate adaptation unit from the candidate adaptation unit list.

[0130] Cost parameters refer to service pricing-related metrics recorded in the metadata of the adaptation unit, including but not limited to the service price per minute (such as the service price per minute for call center services), the price per call (such as the per-call billing for ASR services), and the monthly package price. The specific metric type is related to the service type corresponding to the adaptation unit.

[0131] Optionally, preset cost parameters can be extracted from the metadata of each candidate adapter unit by traversing the list of candidate adapter units.

[0132] Optionally, the extraction of cost parameters should follow the principle of comparison within the same dimension. If the service pricing dimensions of the candidate adaptation units are different (e.g., some are billed by minute and some by instance), they should be converted to a unified billing dimension first (e.g., converting the instance billing to an equivalent price per minute based on the average call duration of the business) to ensure the fairness and accuracy of the cost comparison. If the adaptation unit has tiered pricing (e.g., the pricing is different for low-concurrency intervals and high-concurrency intervals), the cost parameters of the corresponding tier should be extracted based on the estimated call volume of the current business request.

[0133] Secondly, the candidate adapter unit with the lowest cost parameter among all candidate adapter units is selected as the target adapter unit.

[0134] Optionally, the extracted uniform dimension cost parameters are numerically sorted, and the candidate adaptation unit with the smallest cost parameter value is determined as the target adaptation unit.

[0135] Optionally, if there are multiple adaptation units with the same and lowest cost parameters, supplementary filtering rules can be triggered, such as prioritizing adaptation units with better service quality parameters (e.g., higher maximum concurrency and shorter response time).

[0136] Finally, the communication address of the target adapter is extracted. The communication address includes the Uniform Resource Identifier and protocol type information.

[0137] The communication address is the service access identifier of the target adaptation unit, which includes a Uniform Resource Identifier (URI) and protocol type information, and is used to locate the adaptation unit and establish a communication connection.

[0138] The Uniform Resource Identifier (URI) is used to locate the specific service endpoint of the adapter unit, such as vm:cti-vendor-d in the Camel framework. The protocol type information is used to specify the communication protocol with the adapter unit, ensuring that requests can be correctly received and parsed by the adapter unit, such as VM protocol, HTTP / HTTPS protocol, gRPC protocol, Kafka message queue protocol, etc.

[0139] This application provides a method for determining communication platform service objects. By using a cost-first strategy to screen target adaptation units, it can accurately extract the cost parameters of each candidate unit and quickly locate the one with the lowest cost, effectively reducing service call costs. In addition, it clarifies the information contained in the communication address to ensure accurate subsequent calls.

[0140] As an optional implementation, based on any of the above embodiments, invoking the corresponding target service object based on the communication address includes the following steps:

[0141] First, the service request is converted into a target request that matches the protocol format of the target adapter.

[0142] The protocol format refers to the communication protocol and data format supported by the adapter unit and the corresponding external service object, including but not limited to XML format, JSON format, SOAP protocol, RESTful protocol, etc. The protocol formats of different external service objects have significant heterogeneity.

[0143] Among them, the target request is transformed from a standardized service request and is request data that conforms to the protocol format requirements of the target adaptation unit and the corresponding external service object. It is the carrier for realizing cross-protocol service calls.

[0144] It should be noted that the service requests received from the business modules are in a platform-standardized format (such as the UnifiedMakeCallRequest format), while the target adaptation unit and the corresponding external service object have their own proprietary protocol format. Therefore, it is necessary to complete the bidirectional conversion between the protocol and the format first.

[0145] Optionally, the built-in format parser of the target adaptation unit can be used to read the complete data of the standardized service request, including tenant identifier, business requirement parameters, request context, etc., and extract the key fields required to call the external service (such as calling number, called number, calling region, and functional requirement identifier). Then, according to the protocol requirements of the external service object corresponding to the target adaptation unit, the extracted key fields are mapped to the field structure of the target protocol format. If the external service object requires XML format, the standardized request data is encapsulated into a compliant XML document; if JSON format is required, it is converted into a JSON object for the corresponding fields.

[0146] Optionally, in response to the interface authentication requirements of external service objects, the target adaptation unit can also add a preset authentication token, key, or signature information to the target request to ensure that the target request has legitimate calling permissions.

[0147] Secondly, based on the Uniform Resource Identifier and Protocol Type information in the communication address, the target request is sent to the corresponding target service object through the target adaptation unit.

[0148] Optionally, after the target request is converted, a target request forwarding operation is performed based on the Uniform Resource Identifier and Protocol Type information in the communication address.

[0149] Optionally, based on the Uniform Resource Identifier (such as the Camel endpoint URI "vm:cti-vendor-x") in the communication address, the service listening endpoint of the target adapter unit is located, and a communication connection with the adapter unit is established.

[0150] Optionally, the target request can be sent to the target adapter unit using the corresponding protocol according to the protocol type information (such as VM protocol or HTTP protocol) in the communication address. If the protocol type is HTTP, it is sent using the HTTP POST / GET method; if it is VM protocol, intra-process communication is completed through Camel's VM component.

[0151] Optionally, after receiving the target request, the target adaptation unit can verify the validity of the request format and authentication information again. If it is correct, it can forward the target request to the API interface of the corresponding external target service object to complete the link transmission of service call.

[0152] This application provides a method for determining communication platform service objects. By converting the protocol format, it achieves seamless integration with the target adaptation unit, ensuring that heterogeneous interfaces of different external services are processed uniformly and reducing system coupling. By combining the URI and protocol type in the communication address, it accurately sends the target request, ensuring the accuracy of service calls.

[0153] As an optional implementation, based on any of the above embodiments, receiving response data returned by the target service object and returning the response data to the business module includes the following steps:

[0154] First, the target adaptation unit receives the response data returned by the target service object.

[0155] It should be noted that after the target service object completes the service call, it will send the response data to the corresponding target adaptation unit according to its own protocol format.

[0156] Among them, response data is the processing result data returned by the target service object in response to the target request. The format and protocol of the response data are determined by the external service object, and there is significant heterogeneity (such as session information in XML format, execution status in JSON format, audio and video data in binary format, etc.).

[0157] Optionally, the target adaptation unit continuously monitors the response callback endpoints of external service objects (such as the response chain of API interfaces and the Webhook receiving address). When the response data of the target service object is detected, the link validity is first verified (such as verifying the response signature and confirming the request session association). After the verification is passed, the target adaptation unit receives and temporarily stores the heterogeneous response data, and records the response reception time, service object identifier and other metadata for subsequent log tracing and problem investigation.

[0158] Secondly, the response data is converted into a standardized response format, which includes the response status code and business result data.

[0159] Optionally, the target adaptation unit has a built-in response format conversion processor, which is responsible for converting heterogeneous response data into a standardized response format that is unified by the platform.

[0160] The standardized response format is a unified response data format preset by the SaaS communication platform. It can include response status codes and business result data. The response status codes are used to identify the overall status of the service call (such as success, failure, timeout), and the business result data is the business information generated by the service call (such as call session ID, identification text, push receipt, etc.).

[0161] Optionally, the response format conversion processor parses the temporarily stored heterogeneous response data according to the protocol specifications of the external service object, extracting business fields (such as session ID and execution status) and status identifier fields (such as success / failure flags and error codes). Then, the response format conversion processor maps the parsed fields to preset fields in a standardized response format. The response status codes are uniformly converted according to platform specifications, and the business result data is encapsulated into a unified business object.

[0162] Optionally, if the target service object returns an error response, the target adaptation unit will map its error code and error description to the exception field of the standardized response to ensure that the business modules can uniformly identify and handle various service exceptions.

[0163] Next, the integrity of the converted response data is verified.

[0164] It should be noted that, to ensure the validity of the response data, the adaptation unit performs integrity checks on the converted standardized response data. This integrity check verifies the validity of fields and the logical rationality of the logic within the converted standardized response data, ensuring that the data can be correctly parsed and used by business modules, and preventing business process anomalies due to missing data or logical errors.

[0165] Optionally, integrity checks may include required field checks, field format checks, and logical consistency checks.

[0166] The validation of required fields includes: Required field validation checks whether core required fields in the standardized response format (such as the response status code and the primary key field of the business result data) exist and are not empty; if any are missing, the validation fails. Field format validation verifies the validity of numeric and enumerable fields; for example, the response status code must be a preset numeric code, and the session ID must conform to the platform's string format specifications. Logical consistency validation verifies the logical rationality of the response data; for example, when the response status code is "success," the business result data must contain a valid business primary key; when the status code is "failure," it must contain a detailed error description.

[0167] Finally, if the response data passes verification, the format-converted response data is returned to the business module.

[0168] Optionally, if the response data integrity verification passes, the standardized response data is routed to the business module that initiated the request; if the verification fails, a standardized exception response (such as status code 400, with the error description "response data incomplete") can be generated and returned to the business module.

[0169] This application provides a method for determining the service object of a communication platform. First, response data is received through a target adaptation unit, then converted into a standardized response format. The unified data structure facilitates processing, and integrity verification ensures that the data is error-free. Finally, after the verification is passed, the data is returned to the business module, which ensures the accuracy and reliability of data transmission and improves system stability.

[0170] As an optional implementation, based on any of the above embodiments, after invoking the corresponding target service object based on the communication address, the following steps are further included:

[0171] First, if no response data is received from the target service object within a preset time, the target service object is called again, and the number of retries to call the target service object is recorded.

[0172] The preset time is a timeout threshold set in advance for service call response. This preset time can be flexibly configured according to the service type (such as CTI, ASR) and business needs. For example, the preset response time for CTI outbound call service can be set to 3 seconds, 5 seconds, etc.

[0173] The retry count refers to the number of times the call to the target service object is re-initiated after the initial call times out, which is used to balance service reliability and call efficiency.

[0174] Optionally, after sending the target request to the target adaptation unit, a response timeout timer is started, and the system enters a response listening state. If no response data is received from the target service object through the adaptation unit within a preset time, it is determined that the response has timed out, and a retry mechanism is triggered. Then, based on the original communication address of the target adaptation unit, the target request is resent to the target service object, and the current retry count is recorded, incrementing the count by 1 for each retry. If response data is received from the target service object during the retry process, the retry process is terminated, and the system enters the response data standardization and return phase; if no response is received and the number of retryes has not exceeded a preset threshold, retries continue to be initiated.

[0175] Secondly, if the number of retries exceeds the preset threshold and no response data is received from the target service object, a backup adapter unit is selected from the candidate adapter unit list, and the corresponding backup service object is called based on the communication address of the backup adapter unit.

[0176] The preset number of retries threshold is the maximum number of retries allowed in advance. If the number of retries exceeds the preset number of retries threshold, it is determined that the target service object cannot respond normally, and the backup adaptation unit switching process is triggered. For example, the preset number of retries threshold can be set to 2 or 3 times.

[0177] Among them, the backup adaptation unit is an adaptation unit selected from the list of candidate adaptation units that meets the business requirements, in addition to the target adaptation unit. Its corresponding external service provider is the backup service object, which can be used as a fallback solution after the service call fails.

[0178] Optionally, when the number of retries exceeds a preset threshold and no response data is received from the target service object, the candidate adaptation unit list is retrieved again, the target adaptation unit that has failed to be called is removed, and the adaptation unit that meets the requirements of business function, region and service quality is selected from the remaining adaptation units as the backup adaptation unit; if there are multiple backup adaptation units, the optimal backup adaptation unit is determined according to the original target routing strategy (such as cost priority, performance priority).

[0179] Optionally, the communication address (including Uniform Resource Identifier and protocol type information) is extracted from the metadata of the backup adapter unit; the standardized service request is converted into a target request that matches the protocol format of the backup adapter unit; and the request is sent to the corresponding backup service object through the backup adapter unit based on the backup communication address to continue the service call process.

[0180] This application provides a method for determining the service object of a communication platform. By setting a retry mechanism, it can effectively deal with temporary failures in service calls and avoid call failures due to occasional problems. In addition, by setting a retry threshold, the backup adaptation unit is automatically switched after multiple unsuccessful retries, ensuring the continuity and availability of service calls.

[0181] Figure 4 This is a schematic diagram of the structure of a service interface determination device for a communication platform provided in an embodiment of this application, as shown below. Figure 4 As shown, the service interface determination device for a communication platform provided in this embodiment is located in an electronic device. The service interface determination device 40 for a communication platform provided in this embodiment includes: a request receiving module 41, an adaptation filtering and strategy matching module 42, a target adaptation decision module 43, a service invocation module 44, and a response receiving and feedback module 45.

[0182] Specifically, the request receiving module 41 is used to receive service requests sent by the business module; wherein the service request includes a tenant identifier and business requirement parameters; the adaptation filtering and policy matching module 42 is used to filter in a preset adapter list based on the business requirement parameters to determine a list of candidate adaptation units; and to match in a preset policy mapping table based on the tenant identifier to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies; the target adaptation decision module 43 is used to filter in the list of candidate adaptation units based on the target routing policy to determine the matching target adaptation unit and the communication address corresponding to the target adaptation unit; the service invocation module 44 is used to invoke the corresponding target service object based on the communication address; and the response receiving and feedback module 45 is used to receive the response data returned by the target service object and return the response data to the business module.

[0183] Optionally, before receiving the service request sent by the business module, the request receiving module 41 is further configured to: receive registration requests from multiple service objects corresponding to the adapter units; obtain the metadata of each adapter unit, wherein the metadata includes service type, capability description, communication address and health status; verify the metadata of each adapter unit, and store the verified adapter units in the preset adapter list.

[0184] Optionally, business requirements parameters include functional requirements, geographical requirements, and service quality requirements.

[0185] Optionally, the adaptation filtering and strategy matching module 42, when filtering the preset adapter list based on business requirement parameters to determine the candidate adaptation unit list, specifically performs the following: filtering the adaptation units with a health status of available from the preset adapter list to obtain an initial filtering list; matching the initial filtering list based on functional requirements, regional requirements, and service quality requirements to determine multiple candidate adaptation units that match all of the functional requirements, regional requirements, and service quality requirements; and determining the candidate adaptation unit list based on the multiple candidate adaptation units.

[0186] Optionally, the routing strategy includes a cost-first strategy.

[0187] Optionally, the target adaptation decision module 43, when filtering the candidate adaptation unit list based on the target routing strategy to determine the matching target adaptation unit and the communication address corresponding to the target adaptation unit, specifically performs the following: when the target routing strategy is a cost-first strategy, extracting the cost parameters of each candidate adaptation unit in the candidate adaptation unit list; selecting the candidate adaptation unit with the lowest cost parameter among all candidate adaptation units as the target adaptation unit; and extracting the communication address of the target adaptation unit, wherein the communication address includes a Uniform Resource Identifier and protocol type information.

[0188] Optionally, when the service invocation module 44 invokes the corresponding target service object based on the communication address, it is specifically used to: convert the service request into a target request that matches the protocol format of the target adaptation unit; and send the target request to the corresponding target service object through the target adaptation unit according to the Uniform Resource Identifier and protocol type information in the communication address.

[0189] Optionally, the response receiving and returning module 45, when receiving response data returned by the target service object and returning the response data to the business module, specifically performs the following: receiving the response data returned by the target service object through the target adaptation unit; converting the response data into a standardized response format; wherein the standardized response format includes a response status code and business result data; performing integrity verification on the format-converted response data; and returning the format-converted response data to the business module if the response data verification passes.

[0190] Optionally, the service interface determination device for a communication platform provided in this embodiment further includes a retry module.

[0191] Optionally, after calling the corresponding target service object based on the communication address, the retry module is used to: if no response data is received from the target service object within a preset time, re-call the target service object and record the number of retries to call the target service object; if the number of retries exceeds a preset threshold and no response data is received from the target service object, select a backup adapter unit from the candidate adapter unit list and call the corresponding backup service object based on the communication address of the backup adapter unit.

[0192] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, as shown below. Figure 5 As shown, the electronic device 50 provided in this embodiment includes: a processor 51 and a memory 52 communicatively connected to the processor 51.

[0193] The memory 52 stores computer-executable instructions; the processor 51 executes the computer-executable instructions stored in the memory 52 to implement the method provided in any of the above embodiments.

[0194] The program may include program code, which includes computer-executable instructions. Memory 52 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device.

[0195] In this embodiment, the memory 52 and the processor 51 are connected via a bus. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single straight line, but this does not mean that there is only one bus or one type of bus.

[0196] This application also provides a computer-readable storage medium, including computer-executable instructions stored in the computer-readable storage medium, which, when executed by a processor, are used to implement the method provided in any of the above embodiments.

[0197] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the above embodiments.

[0198] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.

[0199] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.

[0200] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.

[0201] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0202] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0203] The aforementioned storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0204] An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Alternatively, the storage medium can be an integral part of the processor. The processor and storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and storage medium can exist as discrete components in an electronic control unit or main control device.

[0205] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0206] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for determining the service object of a communication platform, characterized in that, include: Receive service requests sent by the business module; wherein the service request includes a tenant identifier and business requirement parameters; The system filters the preset adapter list based on the business requirement parameters to determine the candidate adaptation unit list; and matches the tenant identifier in the preset policy mapping table to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies. Based on the target routing strategy, the candidate adapter list is filtered to determine the matching target adapter and the communication address corresponding to the target adapter. Invoke the corresponding target service object based on the communication address; Receive the response data returned by the target service object and return the response data to the business module.

2. The method according to claim 1, characterized in that, Before receiving the service request sent by the service module, the method further includes: Receive registration requests from multiple service objects corresponding to their corresponding adaptation units; Obtain the metadata of each adaptation unit, wherein the metadata includes service type, capability description, communication address and health status; The metadata of each adapter unit is verified, and the adapter units that pass the verification are stored in the preset adapter list.

3. The method according to claim 2, characterized in that, The business requirement parameters include functional requirements, geographical requirements, and service quality requirements. The step of filtering the preset adapter list based on the business requirement parameters to determine the candidate adapter unit list includes: Filter the adapters whose health status is available from the preset adapter list to obtain an initial filter list; Based on the functional requirements, the regional requirements, and the service quality requirements, the initial filtering list is matched to determine multiple candidate adaptation units that match all three requirements. The list of candidate adapters is determined based on the multiple candidate adapters.

4. The method according to claim 1, characterized in that, The routing strategy includes a cost-first strategy; The step of filtering the candidate adapter list based on the target routing policy to determine the matching target adapter and the communication address corresponding to the target adapter includes: When the target routing strategy is a cost-first strategy, extract the cost parameters of each candidate adaptation unit in the candidate adaptation unit list; The candidate adaptation unit with the lowest cost parameter among all the candidate adaptation units is selected as the target adaptation unit. Extract the communication address of the target adapter unit, the communication address including a Uniform Resource Identifier and protocol type information.

5. The method according to claim 1, characterized in that, The step of invoking the corresponding target service object based on the communication address includes: The service request is converted into a target request that matches the protocol format of the target adaptation unit; Based on the Uniform Resource Identifier and Protocol Type information in the communication address, the target request is sent to the corresponding target service object through the target adaptation unit.

6. The method according to claim 5, characterized in that, The step of receiving the response data returned by the target service object and returning the response data to the business module includes: The target adaptation unit receives the response data returned by the target service object. The response data is converted into a standardized response format; wherein the standardized response format includes response status codes and business result data; Perform integrity verification on the format-converted response data; If the response data passes verification, the format-converted response data is returned to the business module.

7. The method according to any one of claims 1-6, characterized in that, After invoking the corresponding target service object based on the communication address, the method further includes: If no response data is received from the target service object within a preset time, the target service object is called again, and the number of retries to call the target service object is recorded. If the number of retries exceeds a preset threshold and no response data is received from the target service object, a backup adapter unit is selected from the candidate adapter unit list, and the corresponding backup service object is called based on the communication address of the backup adapter unit.

8. A service interface determination device for a communication platform, characterized in that, include: The request receiving module is used to receive service requests sent by the business module; wherein the service request includes a tenant identifier and business requirement parameters; The adaptation filtering and policy matching module is used to filter the candidate adaptation unit list based on the business requirement parameters to determine the candidate adaptation unit list; and to match the tenant identifier in the preset policy mapping table to determine the corresponding target routing policy; the preset policy mapping table includes the correspondence between multiple tenant identifiers and routing policies. The target adaptation decision module is used to filter the candidate adaptation unit list based on the target routing strategy to determine the matching target adaptation unit and the communication address corresponding to the target adaptation unit. The service invocation module is used to invoke the corresponding target service object based on the communication address; The response receiving and return module is used to receive the response data returned by the target service object and return the response data to the business module.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images