Disclosure of Invention
In the summary, a series of concepts in a simplified form are introduced, which will be further described in detail in the detailed description. The summary of the application is not intended to define the key features and essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
In a first aspect, the present application provides a method for managing eSIM operator and card writing data based on a decoupling architecture, where the method includes:
receiving an eSIM configuration task request sent by an operator through the unified access interface module, wherein the configuration task request comprises ICCID, EID, configuration type and target card writing platform prompt information;
analyzing the eSIM configuration task request into an intermediate protocol data model by the intermediate protocol conversion module, wherein the intermediate protocol data model is a data structure neutral in a platform;
Controlling the dispatching engine to select a matched target write card platform adapter from the platform adapter management module according to a predefined dispatching strategy;
the target card writing platform adapter is called, the intermediate protocol data model is converted into protocol data required by a target platform, and the protocol data is sent to the target card writing platform;
and receiving a response result returned by the target card writing platform, converting the response result into an intermediate response format by the adapter plug-in unit, and returning the intermediate response format to an operator.
In one possible implementation, the parsing process of the intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage and a structure assembly stage,
The parsing, by the intermediate protocol conversion module, the eSIM configuration task request into an intermediate protocol data model, and constructing a platform neutral data structure, including:
In the pre-analysis stage, carrying out format normalization processing on original parameters in the eSIM configuration task request to obtain normalized parameters;
invoking a predefined data semantic abstract template in the semantic abstract stage, and mapping the normalized parameters into standardized fields with platform-independent semantic tags;
And in the structure assembly stage, calling an intermediate protocol structure template based on the task type, filling semantic fields in the standardized fields, and generating the neutral data structure of the platform.
In a possible implementation manner, the predefined data semantic abstract template supports online incremental update operations, and the online incremental update operations specifically include:
under the condition that an incremental template change request is received, comparing a field to be updated with field identifiers in the existing semantic templates, and judging whether field names are repeated or not;
If the rename field exists, further judging whether the semantic tag is consistent with the data type, and marking the field and sending out first prompt information under the condition of conflict;
Detecting the field mapping relation between each semantic field in the updated template and the existing template on the same card writing platform, and judging whether the situation that the same platform field is mapped by a plurality of semantic tags exists or not;
if a plurality of semantic label mapping conditions exist, sending out second prompt information;
And correcting the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstract template.
In a possible implementation manner, the modifying the incremental template change request based on the first hint information and the second hint information to form an updated data semantic abstract template includes:
Constructing a semantic field map, wherein the semantic field map comprises a field name, a semantic label, a field type, a platform mapping relation and field history use information, and the semantic field map is used for representing semantic similarity, conflict paths and platform relations among fields;
based on the conflict between the field name repetition identified in the first prompt information and the semantic tag and the data type, generating a first candidate correction scheme comprising field renaming, semantic tag merging or field structure adjustment by combining the semantic field map;
Based on the fact that the same writing card platform field identified in the second prompt information is mapped by a plurality of semantic tags, mining a field mapping path from a semantic field map by combining the platform field priority and conflict severity, and generating a second candidate correction scheme comprising main tag setting, field alias assignment or platform template splitting;
Carrying out rule reasoning and confidence scoring on all candidate correction schemes according to field semantic consistency, historical use frequency and platform conflict level, and outputting a recommendation list according to score ranking;
And receiving a correction scheme confirmed by an administrator or selected by an automatic strategy, and applying the correction scheme to the incremental template change request to generate the updated data semantic abstract template.
In a possible embodiment, the method further includes:
When the task type is a Profile downloading task, a preset downloading protocol structure template is called, wherein the downloading protocol structure template comprises ICCID, EID, profile types and configuration URL fields;
when the task type is a Profile deletion task, a preset deletion protocol structure template is called, wherein the deletion protocol structure template comprises ICCID and EID fields;
When the task type is Profile enabling task, calling a preset enabling protocol structure template, wherein the enabling protocol structure template comprises ICCID and a target equipment identification field;
And when the task type is a state query task, calling a preset state query structure template, wherein the state query structure template comprises an ICCID field.
In a possible implementation manner, the controlling the scheduling engine to select a matched target write card platform adapter from the platform adapter management module according to a predefined scheduling policy includes:
Querying the adapter metadata registered in the platform adapter management module;
Grading and sorting all candidate adapters according to a predefined scheduling strategy;
Selecting a target adapter with the highest score as a binding platform of a card writing task, and recording a task adaptation path;
If the selected adapter is not available, automatically switching to the standby adapter according to the grading descending order to continue to schedule tasks.
In a possible implementation manner, the scheduling policies include a priority policy, a task type adaptation policy, a geographic adaptation policy, a performance driving policy and a disaster recovery policy.
In one possible implementation, the unified access interface module supports RESTful interfaces, webSocket interfaces, and MQTT protocol interfaces.
In one possible implementation, the above-described intermediate protocol data model is a structured JSON format or asn.1 abstract syntax structure.
In conclusion, the invention realizes the full-flow logic decoupling between the operator system and various card writing platforms by introducing an intermediate protocol mechanism and a plug-in type adaptive architecture. The operator only needs to submit a standardized configuration task request to the system, and does not need to perceive the protocol details and the calling interfaces of the target platform, so that the complexity of platform access and upgrading is greatly reduced. And secondly, a control scheduling engine arranged in the system has intelligent decision-making capability, supports multidimensional scheduling strategies such as task types, platform running states, load conditions, regional attributes and the like, dynamically selects the most suitable card writing platform to execute configuration tasks, and remarkably improves the platform resource utilization rate and the task success rate. In terms of protocol processing, the invention supports compatible processing of various data codes and protocol formats, the platform adapter module can convert an intermediate protocol data model into a JSON, ASN.1 or XML format according to the requirements of a target platform, has good universality and protocol adaptability, and meets the technical challenges brought by interface differences between different platforms. The whole operation flow of the system is highly transparent to operators, the operators only need to submit task core parameters, and the system can automatically complete platform selection, protocol encapsulation and result feedback, so that the service experience of 'one-point access and multi-platform execution' is realized. In addition, the system provides a plurality of access modes, is compatible with REST, webSocket and MQTT three main stream communication protocols, and is not only suitable for the access of the traditional enterprise information system, but also suitable for the light-weight access requirements of the terminal of the Internet of things, the mobile terminal and the edge platform. From the aspects of operation and maintenance and safety, the whole process of the system records all-link log data including task parameters, adaptation paths, platform responses and execution results, supports task traceability, abnormal positioning and safety audit, and further enhances the manageability of the system. Finally, the system has good expandability and maintainability, the newly added card writing platform can be on line only by registering new adapter plug-ins, the logic of a core system is not required to be changed, and the expansion and maintenance cost of the platform is effectively reduced. The invention has remarkable technical advantages in the aspects of architecture flexibility, platform adaptability, scheduling intelligence, safety controllability, deployment expandability and the like, is suitable for eSIM configuration management scenes under the environment of multiple operators and multiple platforms, and has wide application prospect and engineering value.
Additional advantages, objects, and features of the application will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the application.
Detailed Description
The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments.
Referring to fig. 1, a schematic flow chart of an eSIM operator and card writing data management method based on a decoupling architecture may specifically include:
S110, receiving an eSIM configuration task request sent by an operator through the unified access interface module, wherein the configuration task request comprises ICCID, EID, configuration type and target card writing platform prompt information;
an eSIM configuration task request initiated by an operator side is received, illustratively, through a unified access interface module. The module supports a plurality of communication protocols such as RESTful API, webSocket or MQTT and the like, and has the functions of identity authentication and interface permission verification.
The configuration task request includes, but is not limited to, the following fields:
ICCID, namely the configured eSIM card identifier;
EID, unique identifier of terminal equipment;
configuration types, including Profile downloading, deleting, activating and the like;
The target write card platform prompt information is an optional field used for guiding scheduling policy preference.
S120, analyzing the eSIM configuration task request into an intermediate protocol data model by the intermediate protocol conversion module, wherein the intermediate protocol data model is a data structure neutral in a platform;
Illustratively, the above requests are multi-stage converted by an intermediate protocol conversion module to generate a platform neutral intermediate protocol data model. The conversion process is divided into:
The pre-analysis stage is to perform format unification and field type verification on the input parameters;
A semantic abstraction stage, namely calling a semantic template to map the field into a standard semantic tag (such as SIM_ IDENTIFIER, DEVICE _IDENTIFIER);
and in the structure assembly stage, according to the task type (such as downlink), calling a corresponding intermediate protocol template, filling a semantic field, and generating a standard intermediate protocol data structure (JSON or ASN.1).
S130, controlling the dispatching engine to select a matched target write card platform adapter from the platform adapter management module according to a predefined dispatching strategy;
Illustratively, the target write card platform adapter is selected from the platform adapter management module by the control scheduling engine according to a predefined policy. The policies may include task type and platform capability matching, platform current load and availability, platform historical success rate, platform priority and geographic attribution, and disaster recovery backup mechanisms. And the system ranks all candidate platforms, and selects the highest scoring platform as the execution platform.
S140, calling the target card writing platform adapter, converting the intermediate protocol data model into protocol data required by a target platform, and sending the protocol data to the target card writing platform;
Illustratively, the adapter receives the intermediate protocol data model passed by the dispatch engine and converts it to a platform specific format, which may be a structured JSON, asn.1 code, XML structure, or a Base64 encapsulated instruction fragment, according to the protocol requirements of the target platform. The adapter can call built-in protocol templates and field mapping rules in the conversion process, so that the generated data structure is ensured to accord with the platform interface specification.
After protocol conversion is completed, the adapter constructs specific call parameters including, but not limited to, task instructions, authentication credentials, platform identification, device identification, etc., and issues a task request to the target card writing platform through a preset communication path (such as an HTTP interface, an HTTPs encryption channel, or a dedicated line API).
In the task issuing process, the adapter synchronously records the request log, invokes the time stamp, sends the state and the platform response timeout strategy, and prepares an automatic retry or failover mechanism for the abnormal situation.
S150, receiving a response result returned by the target card writing platform, converting the response result into an intermediate response format by the adapter plug-in unit, and returning the intermediate response format to the operator.
Illustratively, the adapter then waits for the return of platform response data, which may be provided in an asynchronous push, synchronous backhaul, or status poll manner. Upon receiving the platform response, the adapter parses it into an intermediate response structure in a unified format that indicates the task execution status (e.g., success, failure, in-line) and optionally error code, platform feedback information.
The system returns the intermediate response result returned by the adapter to the operator side along the original calling channel, for example, the task execution result is accurately transferred to the initiator through HTTP synchronous response, webSocket message pushing or MQTT theme message publishing mode. Meanwhile, the system records a complete task processing track in a platform log module for subsequent audit, state inquiry and performance analysis.
In conclusion, the invention realizes the full-flow logic decoupling between the operator system and various card writing platforms by introducing an intermediate protocol mechanism and a plug-in type adaptive architecture. The operator only needs to submit a standardized configuration task request to the system, and does not need to perceive the protocol details and the calling interfaces of the target platform, so that the complexity of platform access and upgrading is greatly reduced. And secondly, a control scheduling engine arranged in the system has intelligent decision-making capability, supports multidimensional scheduling strategies such as task types, platform running states, load conditions, regional attributes and the like, dynamically selects the most suitable card writing platform to execute configuration tasks, and remarkably improves the platform resource utilization rate and the task success rate. In terms of protocol processing, the invention supports compatible processing of various data codes and protocol formats, the platform adapter module can convert an intermediate protocol data model into a JSON, ASN.1 or XML format according to the requirements of a target platform, has good universality and protocol adaptability, and meets the technical challenges brought by interface differences between different platforms. The whole operation flow of the system is highly transparent to operators, the operators only need to submit task core parameters, and the system can automatically complete platform selection, protocol encapsulation and result feedback, so that the service experience of 'one-point access and multi-platform execution' is realized. In addition, the system provides a plurality of access modes, is compatible with REST, webSocket and MQTT three main stream communication protocols, and is not only suitable for the access of the traditional enterprise information system, but also suitable for the light-weight access requirements of the terminal of the Internet of things, the mobile terminal and the edge platform. From the aspects of operation and maintenance and safety, the whole process of the system records all-link log data including task parameters, adaptation paths, platform responses and execution results, supports task traceability, abnormal positioning and safety audit, and further enhances the manageability of the system. Finally, the system has good expandability and maintainability, the newly added card writing platform can be on line only by registering new adapter plug-ins, the logic of a core system is not required to be changed, and the expansion and maintenance cost of the platform is effectively reduced. The invention has remarkable technical advantages in the aspects of architecture flexibility, platform adaptability, scheduling intelligence, safety controllability, deployment expandability and the like, is suitable for eSIM configuration management scenes under the environment of multiple operators and multiple platforms, and has wide application prospect and engineering value.
In one possible implementation, the parsing process of the intermediate protocol conversion module includes a pre-parsing stage, a semantic abstraction stage and a structure assembly stage,
The parsing, by the intermediate protocol conversion module, the eSIM configuration task request into an intermediate protocol data model, and constructing a platform neutral data structure, including:
In the pre-analysis stage, carrying out format normalization processing on original parameters in the eSIM configuration task request to obtain normalized parameters;
invoking a predefined data semantic abstract template in the semantic abstract stage, and mapping the normalized parameters into standardized fields with platform-independent semantic tags;
And in the structure assembly stage, calling an intermediate protocol structure template based on the task type, filling semantic fields in the standardized fields, and generating the neutral data structure of the platform.
Illustratively, first, in the pre-parsing phase, the system receives raw eSIM configuration task requests from the unified access interface module, which may come from different operators, with some differences in field naming, format type, or transport encoding. In order to ensure the consistency of system processing, the stage performs unified processing on all original parameters, including field name standardization, data type standardization, default value filling, structure flattening and other operations, so as to generate a group of unified normalized parameter sets. For example, for fields sim_id, iccid_num, and iccid submitted by different operators, respectively, the system maps normalized to standard internal field iccid.
The semantic abstraction phase is entered next. At this stage, the system calls a predefined data semantic abstract template library to make semantic labeling and label mapping for the normalized parameters. Each field is assigned a platform-independent semantic tag (e.g., sim_ IDENTIFIER, DEVICE _ IDENTIFIER, PROFILE _type, etc.) and records its data TYPE, constraints, and adaptation platform mapping. The abstract process not only endows the fields with uniform semantics, but also lays a foundation for subsequent cross-platform mapping and protocol generation. Taking field profileType as an example, whether the source data is "Primary", "P", "01", the source data can be converted into a unified semantic tag file_type through a template and standardized as "Primary".
After field abstraction is completed, the system enters the structure assembly phase. The core task at this stage is to call the corresponding intermediate protocol structure template from the structure template library according to the task type (such as Profile download, deletion, activation or status query). Templates define field structure, field order, nesting level, and necessity constraints. The system fills the fields after semantic abstraction into the structure one by one according to the template requirement, and finally builds a data structure model which accords with the internal standard of the system. The structure generally adopts JSON or ASN.1 format, and can be directly called by a subsequent adapter module for protocol conversion and task issuing.
Through the continuous processing of the three stages, the system converts complex and nonstandard operator requests into a clear, uniform and structured intermediate protocol data model, has high platform independence and provides a stable data base for subsequent task scheduling and platform adaptation.
In a possible implementation manner, the predefined data semantic abstract template supports online incremental update operations, and the online incremental update operations specifically include:
under the condition that an incremental template change request is received, comparing a field to be updated with field identifiers in the existing semantic templates, and judging whether field names are repeated or not;
If the rename field exists, further judging whether the semantic tag is consistent with the data type, and marking the field and sending out first prompt information under the condition of conflict;
Detecting the field mapping relation between each semantic field in the updated template and the existing template on the same card writing platform, and judging whether the situation that the same platform field is mapped by a plurality of semantic tags exists or not;
if a plurality of semantic label mapping conditions exist, sending out second prompt information;
And correcting the incremental template change request based on the first prompt information and the second prompt information to form an updated data semantic abstract template.
Illustratively, to accommodate the evolving requirements of multiple carrier and card writing platform interface specifications in an eSIM carrier and card writing platform data docking control system, predefined data semantic abstraction templates used in the system support online incremental update operations. The mechanism allows the field semantic mapping relation, the data structure standard and the platform field adaptation logic to be dynamically adjusted on the premise of not interrupting the operation of the main system, so that the system is guaranteed to have good maintainability and expansion capability.
First, when the system receives the incremental template change request, the system loads the request content into the semantic sandbox environment and performs comparative analysis with the currently activated semantic abstract template. The change request typically contains one or more field definition updates, such as newly added fields, field aliases, data type modifications, or platform mapping relation adjustments, etc.
After the preliminary comparison, the system first determines whether there is a case where the field names are repeated. I.e. whether the field names defined in the template to be updated have already appeared in the current template. If the field with the same name exists, the system further judges whether the semantic tags (SEMANTICTAG) of the field in the new template and the old template are consistent and whether the data types are compatible. If a semantic tag conflict (such as original device_identifier, new order_code) or inconsistent data type (such as original string, new integer) is identified, the field is marked as a conflict field, and a first prompt message is automatically generated for prompting a manager that the field definition is inconsistent.
The system then proceeds to verify the field mapping relationship of the fields involved in the update template to the write card platform. Specifically, the system traverses the registered field mapping tables in all the platform adapters to determine whether the same platform field name is mapped by multiple semantic tags at the same time. For example, if the field sim_id in the plat_a platform is mapped to sim_identifier and device_identifier simultaneously, the system identifies the sim_identifier as a potential semantic conflict, and automatically generates a second hint information to hint that there is a mapping overlap problem across semantic tag fields.
After the first prompt message and the second prompt message are generated, the system enters a template correction stage. The system provides a plurality of correction suggestions based on the field conflict situation identified in the prompt information, wherein the correction suggestions comprise, but are not limited to, field renaming (such as the new field renaming is profileTypeV < 2 >), setting semantic main labels and auxiliary aliases, splitting a field mapping range of a platform, and defining the binding relation between a field effective range and a task type.
Finally, the corrected template content is verified again through the semantic sandbox, and if the corrected template content passes the consistency verification, the corrected template content is used as an updated data semantic abstract template to be written into a formal template library, and the corresponding version number is updated. After the update takes effect, the system can perform intermediate protocol construction and field semantic mapping based on the new template, and ensure old task compatibility and new task support.
In a possible implementation manner, the modifying the incremental template change request based on the first hint information and the second hint information to form an updated data semantic abstract template includes:
Constructing a semantic field map, wherein the semantic field map comprises a field name, a semantic label, a field type, a platform mapping relation and field history use information, and the semantic field map is used for representing semantic similarity, conflict paths and platform relations among fields;
based on the conflict between the field name repetition identified in the first prompt information and the semantic tag and the data type, generating a first candidate correction scheme comprising field renaming, semantic tag merging or field structure adjustment by combining the semantic field map;
Based on the fact that the same writing card platform field identified in the second prompt information is mapped by a plurality of semantic tags, mining a field mapping path from a semantic field map by combining the platform field priority and conflict severity, and generating a second candidate correction scheme comprising main tag setting, field alias assignment or platform template splitting;
Carrying out rule reasoning and confidence scoring on all candidate correction schemes according to field semantic consistency, historical use frequency and platform conflict level, and outputting a recommendation list according to score ranking;
And receiving a correction scheme confirmed by an administrator or selected by an automatic strategy, and applying the correction scheme to the incremental template change request to generate the updated data semantic abstract template.
For example, in order to promote the intellectualization and controllability of the template updating process, when the system processes the incremental template changing request, after conflict recognition is carried out based on the first prompt information and the second prompt information, a semantic map auxiliary correction mechanism is introduced to form a structured decision support flow so as to realize high-quality evolution and automatic treatment of the incremental template.
First, the system builds and maintains a set of semantic field patterns for modeling the structure of the graph of the history and current state of all fields in the template. The semantic field map contains core attribute information of each field, including field names (such as profileType), semantic tags (such as PROFILE_TYPE), field data TYPEs (such as enum, string), platform mapping relations (mapping paths of record fields on different platforms, such as PLAT_A- & gtconfig_type), and field history use information (such as use frequency, task context, change record, etc.).
The atlas establishes semantic similarity between fields, a field conflict path and a platform use relation through the relation between the nodes and the edges, and provides a context basis for subsequent reasoning.
Next, the system processes the field name repetition problem identified in the first hint information. Specifically, the system generates a group of first candidate correction schemes based on semantic tag similarity and data type compatibility among fields in a semantic graph, wherein a correction strategy comprises field renaming, namely renaming conflict fields (such as profileTypeV) to keep historical compatibility, semantic tag merging, namely suggesting tag unification if new and old field semantic tags have similarity or merger logic (such as device_ID and HARDWARE_ID), and field structure adjustment, namely splitting a complex field into a plurality of subfields or expanding enumerated fields into structural fields.
The system then further processes a second hint information that identifies a conflict situation where the same write card platform field is mapped by multiple semantic tags. The system combines the priority rules of the platform fields (such as non-remappable main platform fields) with the historical conflict records, dynamically analyzes the many-to-many mapping relation between the fields and the platform from the semantic graph to generate a second candidate correction scheme, including but not limited to main label setting, namely, establishing a unique semantic main label for the platform fields and using the rest of aliases or limited contexts, field aliases assignment, namely, solving multi-label conflict by setting semantic aliases mapping relation, platform template splitting, namely, splitting the conflict fields into a plurality of platform-specific sub-templates to isolate when the conflict is not resolvable.
After the candidate correction schemes are generated, the system introduces a rule reasoning mechanism and a confidence scoring system to comprehensively evaluate each scheme. The scoring dimension comprises factors such as field semantic consistency degree, field history use frequency (more field suggestions are used and reserved), platform conflict severity and the like, and a scoring ordered list is formed according to the weighted result.
And finally, outputting the correction schemes with the highest scores in a recommended form by the system, and providing the correction schemes for a template administrator to confirm. The administrator can choose to accept the recommended proposal, and can also finely adjust the merging strategy in the visual interface, and under the low risk changing scene, the system can also automatically choose the optimal correction proposal according to the preset strategy and execute the optimal correction proposal.
The confirmed correction scheme is formally applied to the original incremental template change request, a version of updated data semantic abstract template is generated, a new version number, a source identifier and an application range are given, and the new version number, the source identifier and the application range are written into a template version control system. The updating template is used as a field mapping basis when a follow-up configuration task builds an intermediate protocol data structure, so that the stability and consistency of system processing are ensured.
In a possible embodiment, the method further includes:
When the task type is a Profile downloading task, a preset downloading protocol structure template is called, wherein the downloading protocol structure template comprises ICCID, EID, profile types and configuration URL fields;
when the task type is a Profile deletion task, a preset deletion protocol structure template is called, wherein the deletion protocol structure template comprises ICCID and EID fields;
When the task type is Profile enabling task, calling a preset enabling protocol structure template, wherein the enabling protocol structure template comprises ICCID and a target equipment identification field;
And when the task type is a state query task, calling a preset state query structure template, wherein the state query structure template comprises an ICCID field.
In an exemplary embodiment, when the intermediate protocol conversion module performs the structure assembly phase, in order to ensure that different types of eSIM configuration tasks can correctly generate a data structure meeting the service semantics and platform requirements, the system predefines multiple types of intermediate protocol structure templates, and automatically invokes corresponding templates to perform structure filling according to different task types, so as to generate a data model neutral in the platform. The process realizes a task type driven structure template selection mechanism and ensures the structural integrity and the proper registration certainty of the issuing request.
Specifically, the mechanism supports the following structural templates of typical eSIM task types:
First, when the task type is a Profile Download task (i.e., download Profile), the system automatically invokes a preset Download protocol structure template. The template is used to carry the complete configuration data required to perform the card writing operation, and its structure includes, but is not limited to, the fields of ICCID (eSIM card identification), EID (terminal equipment unique identification), profile type (e.g., primary, secondary), and configuration URL (download address pointing to the configuration file). The system fills the corresponding semantic field (such as SIM_ IDENTIFIER, DEVICE _IDENTIFER) into the template field in the structure assembly stage to form a standard download request structure.
Secondly, when the task type is a Profile deletion task, the system calls a deletion protocol structure template which is relatively simple and only comprises ICCID and EID. The structure is used for issuing a command of 'cancellation/unbinding' operation to the card writing platform, and the uniqueness and the safety of the deleting operation target are ensured by the template design.
Again, when the task type is Profile enabled, the system invokes the enable protocol structure template. The template is used to specify that a particular eSIM configuration activation is to be bound to a particular device, and the main fields include an ICCID, a target device identification (typically an EID or local binding identifier, such as deviceId). The structure of the task template is used for guiding the platform to initiate the activation flow of the Profile inside the eUICC, and the effective state of the Profile on the equipment is ensured.
Finally, when the task type is a state query task, the system calls a state query structure template. The template structure is most compact and usually contains only ICCID. For initiating a query request to a target platform for the current status of an eSIM card (e.g., whether the card was written successfully, activated, available).
In actual system operation, the calling of the structural template is automatically completed by a template manager inside the intermediate protocol conversion module. After receiving the parameters of normalization and semantic abstraction completion, the system matches the corresponding templates according to the task type identification, and fills the standardized fields to the corresponding structure positions of the templates, thereby generating an intermediate protocol data model which accords with task semantics, has complete fields and uniform formats. By applying the mechanism, the system ensures the consistency of field definition and structural specification while supporting various service task types, and effectively improves the cross-platform adaptation capability and the configuration issuing accuracy.
In a possible implementation manner, the controlling the scheduling engine to select a matched target write card platform adapter from the platform adapter management module according to a predefined scheduling policy includes:
Querying the adapter metadata registered in the platform adapter management module;
Grading and sorting all candidate adapters according to a predefined scheduling strategy;
Selecting a target adapter with the highest score as a binding platform of a card writing task, and recording a task adaptation path;
If the selected adapter is not available, automatically switching to the standby adapter according to the grading descending order to continue to schedule tasks.
In a possible implementation manner, the scheduling policies include a priority policy, a task type adaptation policy, a geographic adaptation policy, a performance driving policy and a disaster recovery policy.
The process of selecting the matched target write card platform adapter from the platform adapter management module by the control scheduling engine according to the predefined scheduling policy is implemented by using a scoring-driven intelligent selection mechanism, so that the optimal matching between the task and the write card platform is realized, and the task success rate and the platform resource utilization efficiency are improved. The process mainly comprises four continuous steps of adapter metadata acquisition, grading and sorting, task binding and disaster recovery.
First, the system, upon receiving the intermediate protocol data model with complete structure, the scheduler engine immediately queries the platform adapter management module for all currently registered adapter metadata information. The adapter metadata includes, but is not limited to, task types supported by the adapter (such as whether Download, enable, delete is supported or not), the belonging platform identification and area coverage information, interface protocol types (such as HTTP, HTTPS and private line), current running state (Active/Active), historical task success rate and anomaly statistics, real-time performance indexes (such as response time delay, queuing length and latest available time), and policy preference matching degree with operator tasks.
The scheduling engine executes a predefined scheduling policy evaluation model for all candidate adapters based on the metadata and task context. The evaluation process forms a multi-dimensional adaptation Score (adaptation degree Score) by weighting and scoring each adapter, and specifically considers typical policy factors including a task type adaptation policy, a platform health policy, a regional priority policy, an operator preference policy, a load balancing policy, a scheduling engine tendency, a priority distribution, a geographic area and a service platform, wherein the task type adaptation policy comprises a task type if the adapter clearly marks and supports a current task type, the platform health policy comprises a fault mark, a short response time and a high latest success rate if the platform is not currently marked, the platform is marked, the regional priority policy comprises a geographic area consistent with a task appointed area, the operator preference policy comprises a platform matching policy comprising a target platform prompt if an operator interface is appointed, and a load balancing policy comprises a scheduling engine tendency, and the scheduling engine tends to be distributed preferentially if the current load of the platform is moderate.
Each adapter will output a composite Score value (e.g., score=0.92) and sort the list of adapters in descending order according to the Score result.
After grading is completed, the scheduling engine selects the adapter with the highest grading from the sorting result as a target platform adapter, and task binding is carried out on the current task and the adapter to form an adaptive path mapping record of 'task ID → adapter ID → platform ID', and the path information is recorded in a task scheduling log by the system so as to facilitate subsequent tracing and state tracking.
If the first-choice adapter is found to be unavailable due to network abnormality, platform fault or response overtime in the adapter calling process, the system immediately triggers a disaster recovery strategy, and sequentially tries to backup adapters according to the grading descending order automatically until the available platform is selected or the maximum retry threshold is exceeded. The disaster recovery mechanism ensures that the system has high available scheduling capability when facing single-point platform faults, and task failure or long-time blocking is avoided.
By the scoring and matching and disaster recovery mechanism of the scheduling engine, the system realizes the dynamic optimal adaptation between tasks and platforms, and adapts to the platform performance fluctuation and the differentiated scheduling requirements of multiple operator scenes in a complex environment.
In one possible implementation, the unified access interface module supports RESTful interfaces, webSocket interfaces, and MQTT protocol interfaces.
Illustratively, the unified access interface module has multi-protocol access capabilities to adapt to system integration environments of different types of operators. The module supports RESTful interface, webSocket interface and MQTT protocol interface, and realizes flexible access, state feedback and task event notification.
The RESTful interface is mainly used for a traditional IT system or an operation platform to initiate synchronous call of a configuration task, supports submitting an eSIM configuration task (such as ordering Profile and deleting Profile) in an HTTPS POST mode, and returns a standard HTTP state code and JSON structure response.
The WebSocket interface is suitable for the scene requiring two-way communication, such as real-time back transmission of configuration state, pushing of task queues and the like, and an operator system can receive the task execution state (Pending, success, failure and the like) after establishing long connection.
The MQTT protocol interface is oriented to an operator of the Internet of things equipment, a lightweight message publishing/subscribing model is adopted, the method is suitable for low-bandwidth and high-concurrency scenes, and the operator receives task result pushing through subscribing subjects, so that data circulation efficiency is improved.
The multi-protocol supporting mechanism not only improves the compatibility of the system, but also supports multi-tenant and multi-service concurrent processing, and can configure access authority, rate limit and task signature checking mechanism according to access types, thereby ensuring safety and stability.
In one possible implementation, the above-described intermediate protocol data model is a structured JSON format or asn.1 abstract syntax structure.
The intermediate protocol data model adopts a platform neutral data structure, specifically a structured JSON format or an asn.1 abstract syntax structure, so as to meet the requirements of different platform docking protocol differentiation.
When the target card writing platform supports a standard HTTP/JSON interface, the intermediate protocol data model adopts a JSON format, has clear field structure and strong expansibility, and is suitable for dynamic generation and debugging. For example:
When the target platform requires strict structure definition or security encapsulation (e.g., using SM-dp+ protocol), the intermediate protocol data model may employ an asn.1 structure, supporting binary encapsulation, BER/DER encoding, and signature verification. The structure may be transcoded in the adapter by a predefined template, automatically generating an ASN.1 representation from the semantic field.
By providing dual-format support, the intermediate protocol model achieves a high level of protocol abstraction capability. The JSON structure is processed in the system uniformly, and format switching is completed by the adapter module before the JSON structure is sent to different platforms, so that the adaptation flexibility and expansibility of the system are ensured.
In summary, in the method provided by the invention, through the combination of the multi-protocol access interface and the multi-format intermediate protocol model, not only the access requirements of multi-type operators and platforms are met, but also a data transfer mechanism with neutral and high compatibility of the platforms is constructed, and a technical foundation is provided for system expansion, internationalization deployment and card writing platform capability integration.
The foregoing embodiments are merely for illustrating the technical solution of the present application, but not for limiting the same, and although the present application has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that modifications may be made to the technical solution described in the foregoing embodiments or equivalents may be substituted for parts of the technical features thereof, and that such modifications or substitutions do not depart from the spirit and scope of the technical solution of the embodiments of the present application in essence.