A marketing middle platform system adopting a gray hot deployment mode based on React Native

Abstract

The application discloses a marketing middle platform system adopting a gray hot deployment mode based on React Native, and specifically comprises the following steps: 101) a marketing scene analysis step, 102) a condition building step, and 103) a benefit confirmation step. The application expresses complex and changeable marketing rules by abstracting a group of serial hierarchical item expression concepts, and then realizes rule retrieval and verification based on hierarchical items, and applies the hierarchical item concept to the definition of applicable conditions in the marketing middle platform, thereby realizing the marketing middle platform system adopting the gray hot deployment mode based on React Native.

Description

[0001] This patent is a divisional application of application number 202110119991.5, "A Marketing Platform System Based on Hierarchical Connection Technology". Technical Field

[0002] This invention relates to the field of software development technology, and more specifically, to a hierarchical marketing platform system based on MQ distributed transactions. Background Technology

[0003] Large-scale SaaS software requires a robust marketing platform to support the flexible and diverse scenarios needed for merchants' integrated online and offline marketing. The software should allow merchants to establish custom rules and formulate different marketing incentive strategies for different scenarios. However, incentive strategies are diverse, and there is a lack of robust expression for the applicability definition of "what conditions must be met" to enjoy the incentive. Other drawbacks include difficulties in implementing gray-scale hot deployment for system upgrade management, challenges in achieving distributed processing in transaction processing, and the extremely high requirements for print statistics in marketing systems, currently hindering rapid mobile printing. The lack of robust expression is particularly prominent in these cases.

[0004] There are generally two approaches to implementing marketing functions in existing software:

[0005] One approach involves hardcoding rules for specific marketing scenarios. For example, it might define that only members of a certain level can enjoy discounts on certain types or brands of products. These configurations are stored in a database table, with fixed fields for members and product conditions, and their names and types are fixed. Other similar marketing scenarios require different tables and modules to implement them. Most similar software products on the market currently operate at this level. While this method is simple, fast, and easy to understand, it clearly has extremely poor scalability. If conditions need to be changed or additional conditions need to be introduced, modifications or rework are required, resulting in a lot of repetitive work. It cannot support the rapidly changing personalized needs of SaaS software in cross-industry, multi-tenant scenarios.

[0006] Another approach is to design marketing rules based on a general-purpose rule engine, such as the Drools rule engine. These rule engines are generally powerful and versatile, supporting complex arithmetic, logical, and comparative expressions, as well as their combinations and operational priorities. Therefore, they can support highly flexible marketing condition definitions and judgment logic. However, the rule engine itself is complex and requires scripting language support; correspondingly, the configuration and use of application-layer marketing rules are also very complex, making them difficult for merchants to learn. Furthermore, while rule engines are powerful, they have the following drawbacks:

[0007] First, it cannot provide a simple way to quickly filter out rules that meet the conditions from multiple rules; the only way to filter is to verify each rule one by one.

[0008] Second, while rule engines support arithmetic and logical expressions, they generally lack a tree-like representation. For example, if a nationwide merchant offers discounts on winter clothing to stores in North China, and a store in a city within Hebei Province (also in North China) places an order, does that store meet the regional criteria? This necessitates introducing hierarchical expressions to determine if hierarchical members have inclusion relationships. Furthermore, current rule engines consume significant computing resources, resulting in slow real-time computation response in high-concurrency SaaS scenarios, negatively impacting user experience. Summary of the Invention

[0009] This invention overcomes the shortcomings of the prior art and provides a marketing middle platform system based on hierarchical serial technology.

[0010] The technical solution of the present invention is as follows:

[0011] A marketing middle platform system based on hierarchical connection technology includes a marketing conditions module and a rights module, specifically including the following steps:

[0012] 101) Marketing scenario analysis steps: Based on the corresponding activities and link entry points, analyze the marketing conditions module and benefits module corresponding to the activities; analyze the applicable conditions of the corresponding activities in the marketing conditions module;

[0013] 102) Condition setup steps: Based on the applicable conditions of the activity analyzed by the marketing conditions module, confirm the number of hierarchical items required for the activity, use hierarchical description to describe the internal hierarchy of the hierarchical items, and realize the calling of the marketing conditions module for this activity by setting the corresponding interface;

[0014] 103) Rights Confirmation Steps: Based on the activity conditions established in step 102) Marketing Conditions, the Rights Module will provide corresponding discount rights or give away appropriate gift packages.

[0015] Furthermore, at least one level is set from high to low within the hierarchical item; each level includes at least one corresponding member, and the members are discrete and hierarchical. When there are multiple members, a full-range special member is also set, which represents all members of that level.

[0016] Furthermore, lower-level members within the same level are within the scope of higher-level members; members between different levels are independent of each other.

[0017] Furthermore, the data of members at each level under the hierarchical item is stored in a relational table in the database, and the data structure type of the stored data adopts hierarchical relationship and / or parent-child relationship.

[0018] Furthermore, the corresponding interface includes the hierarchical item name, the definition of the hierarchy, the top-level member, the parent member of a given member, the list of child members of a given member, and a translation of the given member to facilitate reading the members and their relationships; taking Java as an example, the definition is as follows:

[0019]

[0020] The reference definition of Member is as follows:

[0021]

[0022] The reference definition of level is as follows:

[0023]

[0024]

[0025] Furthermore, in step 102), multiple hierarchical items are concatenated to generate expressions representing different rules.

[0026] Furthermore, the relational tables in the database include an index module, which includes a rule metadata definition table and a rule definition table;

[0027] The rule metadata definition table has no more than ten hierarchical items corresponding to the marketing campaign. Each hierarchical item is stored. If there are fewer than ten items, the remaining hierarchical items are empty.

[0028] The rule definition table stores specific rules, including key fields, weight fields, and related fields. The weight field is used to determine which rule to use when two or more rules simultaneously meet the activity conditions. Each level item stores one or more member data, separated by commas when multiple members are stored.

[0029] Furthermore, it also includes a rule retrieval module. The rule retrieval module extracts the corresponding members as parameters for each level item of the activity conditions. It then searches the rule definition table based on these parameter members. If all level item members of a rule contain or are equal to the passed parameter members, then the rule is matched. After retrieving all matching rules, the business layer decides to select the rule with the highest weight or to combine all rules based on their weights. Finally, it performs subsequent processing based on the discount information defined in the benefits module.

[0030] Furthermore, it also includes a rule verification module, which, in contrast to the rule retrieval module, uses a pre-given set of parameter members to compare with a specified hierarchical item rule to verify whether it satisfies the rule.

[0031] The advantages of this invention compared to existing technologies are as follows: This invention expresses complex and ever-changing marketing rules by abstracting a set of concatenated hierarchical item expressions, thereby achieving rule retrieval and verification based on hierarchical items. The hierarchical item concept is applied to the definition of applicable conditions in the marketing platform.

[0032] This invention introduces the concept of hierarchical items to structure complex information in the business domain, simplifying it and making it easier for application developers and marketing rule configuration personnel to understand and operate.

[0033] Given a conceptual model and interface definition constraints, application developers can easily and consistently identify specific hierarchical item objects and quickly develop them. Once defined, hierarchical items can be uniformly registered in a hierarchical item repository, allowing for reuse in various business scenarios. Ultimately, this significantly improves development efficiency and effectively meets ever-changing marketing needs.

[0034] Once developers model and register the hierarchical items, operations staff can configure marketing campaigns independently without relying on developers. Operations staff can freely use different combinations of hierarchical items as needed, freely combining a set of hierarchical item member values ​​into specific campaign rules; furthermore, because hierarchical items inherently possess hierarchical characteristics, introducing hierarchical expressions can provide greater expressiveness. The entire configuration process can be made intuitive, visual, easy to understand, and easy to operate.

[0035] The rule engine of this invention is relatively lightweight. With the help of mature data retrieval technology of relational databases and a small amount of memory computing, it can achieve linear, millisecond-level response even under the ultra-high concurrency of multi-tenant SaaS software. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the automated packaging process for grayscale hot deployment of the present invention;

[0037] Figure 2 This is a schematic diagram of the grayscale hot deployment check and update process of the present invention;

[0038] Figure 3 This is a schematic diagram illustrating an example of the optimal path for grayscale hot deployment according to the present invention;

[0039] Figure 4 This is a schematic diagram illustrating an example of the shortest path selection for grayscale hot deployment according to the present invention;

[0040] Figure 5 This is a schematic diagram of the hierarchical items within the marketing platform of this invention;

[0041] Figure 6 This is a schematic diagram of the hierarchy within the hierarchical items of the present invention;

[0042] Figure 7This is a schematic diagram illustrating the hierarchical relationship of the present invention.

[0043] Figure 8 This is a schematic diagram illustrating the parent-child relationship hierarchy of the present invention;

[0044] Figure 9 This is a flowchart of the rule verification process of the present invention;

[0045] Figure 10 This is a flowchart of the distributed transaction processing of the present invention;

[0046] Figure 11 This is a diagram illustrating a distributed transaction example of the present invention. Detailed Implementation

[0047] Embodiments of the present invention are described in detail below, wherein the same or similar reference numerals denote the same or similar elements or elements with similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention and should not be construed as limiting the present invention.

[0048] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0049] The numbering of steps mentioned in the various embodiments is merely for descriptive convenience and does not imply a sequential relationship. Different steps in various specific embodiments can be combined in different orders to achieve the inventive objective of this invention.

[0050] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0051] Example 1:

[0052] like Figures 4 to 9 As shown, a marketing middleware system based on hierarchical linkage technology includes a marketing conditions module and a benefits module. Because there are many activities and link entry points, such as limited-time discounts, holiday promotions, and member care, as long as they involve the same type and number of hierarchical items, these marketing rules can be considered to be of the same category. For example... Figure 1 The examples in the marketing rules section each have two marketing rules with three levels of items. Therefore, when applying the level items to the marketing middle platform's discount strategy, the specific steps include:

[0053] 101) Marketing scenario analysis steps: Based on the corresponding activities and link entry points, analyze the marketing conditions module and benefits module corresponding to the activities; analyze the applicable conditions of the corresponding activities in the marketing conditions module.

[0054] 102) Condition setup steps: Based on the applicable conditions of the activity analyzed by the marketing conditions module, confirm the number of hierarchical items required for the activity. Specific hierarchical items can be represented by starting with the keyword "hier". Use "hierarchy" to describe the hierarchy within the hierarchical items, and implement the calling of the marketing conditions module for this activity by setting the corresponding interface.

[0055] Within a hierarchy item, at least one level is set from high to low. For example, a product hierarchy item could be set from high to low as "Level 1 Category", "Level 2 Category", and "Product"; a region hierarchy item could be set from high to low as needed as "City", "District / County", and "Township"; a time dimension could be set from high to low as "Year", "Month", and "Day", or it could be set as "Year", "Month", and "Week", etc. Figure 2 As shown.

[0056] Each level includes at least one corresponding member. Members are discrete and hierarchical. When there are multiple members, a special member representing the entire range is also defined, representing all members at that level. Sub-members within the same level are within the scope of their parent members; conversely, parent members contain sub-members. Members between different levels are independent of each other. For example, the region level might have:

[0057] [hierArea]. [Ningbo City]

[0058] [hierArea]. [Hangzhou City]

[0059] [hierArea]. [Hangzhou City]. [Xihu District]

[0060] There is also a special type of member that represents all possible values ​​for that layer, referred to as the "all" value. For example, "[hierArea].[Hangzhou].[all]" represents all districts and counties under Hangzhou.

[0061] 103) Rights Confirmation Steps: Based on the activity conditions established in step 102) Marketing Conditions, the Rights Module will provide corresponding discount rights or give away appropriate gift packages.

[0062] Within each hierarchical item, the data for members at each level is stored in a relational table within the database. The stored data structure uses hierarchical relationships and / or parent-child relationships. Taking the regional hierarchy as an example, the hierarchical relationship is as follows: Figure 3 As shown, each Level occupies one table field. The parent-child relationship is as follows: Figure 4As shown, two fixed fields, code and pcode, express the hierarchical relationship. The parent-child relationship is a level.

[0063] The corresponding interface includes the hierarchical item name, the definition of the hierarchy, the top-level member, the parent member of a given member, the list of subordinate members of a given member, and a translation of a given member to facilitate reading members and member relationships. It implements the hierarchical item model, containing a set of interfaces and base classes for the hierarchy. When the business layer identifies and defines a new hierarchical item, it can quickly implement a new class through secondary development. The specific interfaces and base classes for the included hierarchy, using Java as an example, are defined as follows:

[0064]

[0065] The reference definition of Member is as follows:

[0066]

[0067] The reference definition of level is as follows:

[0068]

[0069]

[0070] Naturally, corresponding toolkits can be encapsulated for hierarchical and parent-child storage structure types to facilitate the application layer in reading members and relationships from the table.

[0071] In step 102), multiple hierarchical items are concatenated to generate expressions representing different rules. Specifically, for a marketing scenario, several hierarchical items are identified, and each item is assigned a member value. These member values ​​are then combined to form an expression. The hierarchical expression also defines a rule; by setting different combinations of member values, expressions representing different rules can be generated.

[0072] For example, suppose a merchant's membership discount program involves the following three levels and their level definitions (in descending order):

[0073] There are two levels of members:

[0074] levelCustomer (Member Level)

[0075] levelMember (Individual Member)

[0076] HierShop has three levels:

[0077] levelArea (region)

[0078] levelCity

[0079] levelShop (storefront)

[0080] The product (hierSpu) has two levels:

[0081] levelBrand (product brand)

[0082] levelSpu (product)

[0083] Based on the above hierarchical structure, the following set of rules are defined:

[0084] Rule 1 indicates that Diamond-level members can enjoy a certain discount when purchasing Seven Wolves and Youngor brand clothing at the Wulin store. The tiered expression is:

[0085] {[hierMember].[Diamond Member],[hierShop].[East China].[Hangzhou].[Wulin Store],{[hierSpu].[Seven Wolves],[hierSpu].[Youngor]}}

[0086] Rule 2: If a Silver-level member is entitled to a discount on all brand clothing purchases at the Wulin store, the tier expression is:

[0087] {[hierMember].[Silver Member],[hierShop].[East China].[Hangzhou].[Wulin Store],[hierSpu].[All Brands]}

[0088] The relational tables in the database include an index module, which contains a rule metadata definition table and a rule definition table; creating an index module makes querying convenient and efficient.

[0089] The rule metadata definition table contains no more than ten hierarchical items corresponding to the marketing campaign. Each hierarchical item is stored. If there are fewer than ten items, the remaining hierarchical items are empty, meaning that unused multi-defined hierarchical items can be left empty.

[0090] The rule definition table stores specific rules, including key fields, weight fields, and related fields. The weight field is used to determine which rule to use when two or more rules simultaneously meet the activity conditions. Each level item stores one or more member data, separated by commas when multiple members are stored.

[0091] It also includes a rule retrieval module, which extracts the corresponding members as parameters for each level item of the activity conditions, and searches the rule definition table based on these parameter members. If all level item members of a rule contain or are equal to the passed parameter members, then the rule is matched. After retrieving all matching rules, the business layer decides to select the rule with the highest weight or to combine all rules based on the weight, and finally performs subsequent processing based on the preferential information defined in the benefits module.

[0092] The following is an example of the rules for defining hierarchical item expressions. When a customer places an order in a store, the software application layer can know "who the customer is" (e.g., Zhang San, with a silver membership level), "which store the order was placed at" (e.g., Wulin store), and "what product was purchased" (e.g., model JB002) in the current context. Based on this contextual information, it assembles a member parameter group, the structure of which is as follows:

[0093] {[hierMember].[Silver Member].[Zhang San],[hierShop].[East China Region].[Hangzhou City].[Wulin Store],[hierSpu].[Jiumu Brand].[2020 Summer Casual Men's Pants JB002]}

[0094] Using this parameter to search the "Rule Definition Table" reveals "Rule Two" that matches the above. Because it's a relational database, the rule retrieval algorithm can be implemented directly using SQL statements. The core SQL statement snippet is as follows:

[0095]

[0096] If the `hiern_value` field stores multiple member values ​​separated by commas, it means that satisfying any one of the member values ​​is acceptable. Taking MySQL as an example, you can use the database's `find_in_set` function instead of the "=" expression, such as:

[0097]

[0098]

[0099] It also includes a rule validation module, such as Figure 9 As shown, in contrast to the rule retrieval module, the rule verification module uses a pre-given set of parameter members to compare with a specified hierarchical item rule to verify whether it satisfies the rule.

[0100] Example 2:

[0101] like Figures 1 to 11As shown, a new management system applied to marketing is presented. The system setup for marketing includes marketing condition modules and benefits modules. Because there are many activities and link entry points, such as limited-time discounts, holiday promotions, and member care, these marketing rules can be considered of the same type as long as they involve the same hierarchical item types and number. For example... Figure 1 The examples in the marketing rules section each have two marketing rules with three levels of items. Therefore, when applying the level items to the marketing middle platform's discount strategy, the specific steps include:

[0102] 101) Marketing scenario analysis steps: Based on the corresponding activities and link entry points, analyze the marketing conditions module and benefits module corresponding to the activities; analyze the applicable conditions of the corresponding activities in the marketing conditions module.

[0103] 102) Condition setup steps: Based on the applicable conditions of the activity analyzed by the marketing conditions module, confirm the number of hierarchical items required for the activity. Specific hierarchical items can be represented by starting with the keyword "hier". Use "hierarchy" to describe the hierarchy within the hierarchical items, and implement the calling of the marketing conditions module for this activity by setting the corresponding interface.

[0104] Within a hierarchy item, at least one level is set from high to low. For example, a product hierarchy item could be set from high to low as "Level 1 Category", "Level 2 Category", and "Product"; a region hierarchy item could be set from high to low as needed as "City", "District / County", and "Township"; a time dimension could be set from high to low as "Year", "Month", and "Day", or it could be set as "Year", "Month", and "Week", etc. Figure 2 As shown.

[0105] Each level includes at least one corresponding member. Members are discrete and hierarchical. When there are multiple members, a special member representing the entire range is also defined, representing all members at that level. Sub-members within the same level are within the scope of their parent members; conversely, parent members contain sub-members. Members between different levels are independent of each other. For example, the region level might have:

[0106] [hierArea]. [Ningbo City]

[0107] [hierArea]. [Hangzhou City]

[0108] [hierArea]. [Hangzhou City]. [Xihu District]

[0109] There is also a special type of member that represents all possible values ​​for that layer, referred to as the "all" value. For example, "[hierArea].[Hangzhou].[all]" represents all districts and counties under Hangzhou.

[0110] 103) Rights Confirmation Steps: Based on the activity conditions established in step 102) Marketing Conditions, the Rights Module will provide corresponding discount rights or give away appropriate gift packages.

[0111] Within each hierarchical item, the data for members at each level is stored in a relational table within the database. The stored data structure uses hierarchical relationships and / or parent-child relationships. Taking the regional hierarchy as an example, the hierarchical relationship is as follows: Figure 3 As shown, each Level occupies one table field. The parent-child relationship is as follows: Figure 8 As shown, two fixed fields, code and pcode, express the hierarchical relationship. The parent-child relationship is a level.

[0112] The corresponding interface includes the hierarchical item name, the definition of the hierarchy, the top-level member, the parent member of a given member, the list of subordinate members of a given member, and a translation of a given member to facilitate reading members and member relationships. It implements the hierarchical item model, containing a set of interfaces and base classes for the hierarchy. When the business layer identifies and defines a new hierarchical item, it can quickly implement a new class through secondary development. The specific interfaces and base classes for the included hierarchy, using Java as an example, are defined as follows:

[0113]

[0114]

[0115] The reference definition of Member is as follows:

[0116]

[0117] The reference definition of level is as follows:

[0118]

[0119] Naturally, corresponding toolkits can be encapsulated for hierarchical and parent-child storage structure types to facilitate the application layer in reading members and relationships from the table.

[0120] In step 102), multiple hierarchical items are concatenated to generate expressions representing different rules. Specifically, for a marketing scenario, several hierarchical items are identified, and each item is assigned a member value. These member values ​​are then combined to form an expression. The hierarchical expression also defines a rule; by setting different combinations of member values, expressions representing different rules can be generated.

[0121] For example, suppose a merchant's membership discount program involves the following three levels and their level definitions (in descending order):

[0122] There are two levels of members:

[0123] levelCustomer (Member Level)

[0124] levelMember (Individual Member)

[0125] HierShop has three levels:

[0126] levelArea (region)

[0127] levelCity

[0128] levelShop (storefront)

[0129] The product (hierSpu) has two levels:

[0130] levelBrand (product brand)

[0131] levelSpu (product)

[0132] Based on the above hierarchical structure, the following set of rules are defined:

[0133] Rule 1 indicates that Diamond-level members can enjoy a certain discount when purchasing Seven Wolves and Youngor brand clothing at the Wulin store. The tiered expression is:

[0134] {[hierMember].[Diamond Member],[hierShop].[East China].[Hangzhou].[Wulin Store],{[hierSpu].[Seven Wolves],[hierSpu].[Youngor]}}

[0135] Rule 2: If a Silver-level member is entitled to a discount on all brand clothing purchases at the Wulin store, the tier expression is:

[0136] {[hierMember].[Silver Member],[hierShop].[East China].[Hangzhou].[Wulin Store],[hierSpu].[All Brands]}

[0137] The relational tables in the database include an index module, which contains a rule metadata definition table and a rule definition table; creating an index module makes querying convenient and efficient.

[0138] The rule metadata definition table contains no more than ten hierarchical items corresponding to the marketing campaign. Each hierarchical item is stored. If there are fewer than ten items, the remaining hierarchical items are empty, meaning that unused multi-defined hierarchical items can be left empty.

[0139] The rule definition table stores specific rules, including key fields, weight fields, and related fields. The weight field is used to determine which rule to use when two or more rules simultaneously meet the activity conditions. Each level item stores one or more member data, separated by commas when multiple members are stored.

[0140] It also includes a rule retrieval module, which extracts the corresponding members as parameters for each level item of the activity conditions, and searches the rule definition table based on these parameter members. If all level item members of a rule contain or are equal to the passed parameter members, then the rule is matched. After retrieving all matching rules, the business layer decides to select the rule with the highest weight or to combine all rules based on the weight, and finally performs subsequent processing based on the preferential information defined in the benefits module.

[0141] The following is an example of the rules for defining hierarchical item expressions. When a customer places an order in a store, the software application layer can know "who the customer is" (e.g., Zhang San, with a silver membership level), "which store the order was placed at" (e.g., Wulin store), and "what product was purchased" (e.g., model JB002) in the current context. Based on this contextual information, it assembles a member parameter group, the structure of which is as follows:

[0142] {[hierMember].[Silver Member].[Zhang San],[hierShop].[East China Region].[Hangzhou City].[Wulin Store],[hierSpu].[Jiumu Brand].[2020 Summer Casual Men's Pants JB002]}

[0143] Using this parameter to search the "Rule Definition Table" reveals "Rule Two" that matches the above. Because it's a relational database, the rule retrieval algorithm can be implemented directly using SQL statements. The core SQL statement snippet is as follows:

[0144]

[0145] If the `hiern_value` field stores multiple member values ​​separated by commas, it means that satisfying any one of the member values ​​is acceptable. Taking MySQL as an example, you can use the database's `find_in_set` function instead of the "=" expression, such as:

[0146]

[0147] It also includes a rule validation module, such as Figure 9 As shown, in contrast to the rule retrieval module, the rule verification module uses a pre-given set of parameter members to compare with a specified hierarchical item rule to verify whether it satisfies the rule.

[0148] The system implements transactions using a message queue (MQ)-based distributed transaction method, which includes a transaction message service module and a transaction message client plugin module.

[0149] The transaction message service module includes message receiving, commit / rollback message processing, and message inspection and processing.

[0150] The message receiving interface is provided by the transaction message service module and is called by the transaction initiator of the transaction message service module. After the transaction initiator calls the message receiving interface, the transaction message service module will cache the message data in the cache server.

[0151] The commit / rollback message service provides the commit / rollback message interface, which can be called by the transaction initiator of the transaction message service module. After the transaction initiator calls the commit message interface, the transaction message service retrieves the message data from the cache server, sends the data to the MQ server, and deletes the message data from the cache server after successful sending. After the transaction initiator calls the rollback message interface, the transaction message service deletes the message data from the cache server.

[0152] Message inspection and processing: If the transaction initiator fails to call the transaction message service's message receiving interface due to an unexpected failure to call the transaction message commit / rollback interface, the message data will not be forwarded or deleted. To avoid data inconsistency caused by this situation, the transaction message service starts a scheduled task to periodically check messages that have not been forwarded or deleted in time. If a timed-out unprocessed transaction message is detected, the transaction initiator's interface is called back to confirm whether the initiator's local transaction has been successfully completed. If successful, the message is committed; otherwise, the message is rolled back.

[0153] The transaction message client plugin module enables the embedding of transaction message client plugins into the transaction initiator and transaction receiver.

[0154] The transaction message client plugin module intercepts Spring local transaction operations at the transaction initiation end and performs transaction message processing before and after Spring local transaction commit or rollback operations.

[0155] Before the Spring local transaction is committed: The transaction initiator calls the transaction message service to receive messages asynchronously. The transaction message client plugin checks whether the message receiving interface was called successfully before the Spring local transaction is committed. If it is successful, the transaction is committed normally; if the message receiving interface fails, the local transaction is rolled back.

[0156] After the Spring local transaction is committed: call the transaction message service to commit the message interface;

[0157] After a Spring local transaction is rolled back: the transaction message service rollback message interface is called.

[0158] The transaction message client plugin module assists the transaction receiver in checking whether a message has been processed to avoid duplicate message processing. If a message cannot be consumed repeatedly, the transaction message client plugin writes the transaction message ID to the local table when it receives the message, and checks whether the transaction message ID exists to ensure that the message is consumed only once.

[0159] like Figure 11 As shown, taking the membership recharge bonus points service as an example:

[0160] The business requirement is that for every 1 yuan recharged by a member, 1 point will be awarded. When a user enters the recharge subsystem, the system receives messages, submits / rolls back messages, and performs message checks to ensure accurate message delivery. Multiple message confirmations are performed to guarantee the accuracy of the information.

[0161] The deployment and subsequent upgrade management of this system adopts a canary hot deployment method based on React Native, which includes the GitLab Runner module, web module, server module, and client module.

[0162] The GitLab Runner module is used to execute packaging tasks. It deploys a runtime service based on an open-source code hosting platform. This service operates through corresponding task files, which execute tasks including dependency downloading and packaging. These tasks are triggered through the platform's external API. GitLab is a free open-source code hosting platform that can be privately deployed. The Runner is a GitLab-based runtime service that executes tasks through the `.gitlab-ci.yml` file in the project. This file can contain various tasks, such as downloading npm dependencies and packaging. When the Runner is triggered, it checks the `.gitlab-ci.yml` file in the project and executes the relevant tasks. There are several ways to trigger the Runner, such as monitoring code changes on a specific branch or triggering via the GitLab API, which is the most common method.

[0163] The web module is used for canary releases, triggering the packaging function of the GitLab Runner module. After packaging is complete, the package is uploaded to the server, completing a packaging task. After receiving the packaged file, the server stores the version and canary release method in the database, completing an application release.

[0164] For example, consider a coupon feature located in the `release / coupon` branch. To release this feature, on the web interface, select the `release / coupon` branch, fill in the release version, choose the canary release method (by percentage: e.g., 30%; by system version: e.g., Android 8; by network environment, etc.), and click "Release." This calls the GitLab API: `https: / / gitlab.example.com / api / v3 / projects / 1 / pipeline?ref=release / coupon`. This triggers GitLab Runner to check the `.gitlab-ci.yml` configuration file in the project, execute the packaging task, and upload the package to the server module after packaging. The server module, upon receiving the packaged file, stores the release version and canary release method in the database, completing the application release.

[0165] The server-side module stores and distributes the packaged JavaScript execution task files. It includes two database tables: `packages` and `packages_diff`. The `packages` table records each version release, including information such as the package download link, version number, canary release method, existence of the diff package, and download availability. The `packages_diff` table records the diffed file information (if any) for each release, i.e., the difference package. When the server receives a package uploaded by the GitLab Runner module, it checks if the same version already exists in the `packages` table. If not, it records the corresponding information for this release in the `packages` table. If it exists, it generates the difference using a text-based diffing method, saves the difference to the old package for replacement, and records it in the `packages_diff` table, completing one diffing process.

[0166] When a client module's request arrives (the client module's request includes information such as version number, system version, network conditions, and region), the server module checks the packages table based on the version number carried in the request. If the corresponding version number does not exist, it returns no update package. If the corresponding version number exists, it checks whether the gray-scale conditions are met (for example, the gray-scale condition is that the Android system version is greater than 8; if the request carries information indicating an Android system version of 7, the gray-scale condition is not met, but if the Android system version is 9, the gray-scale condition is met). If the gray-scale condition is not met, it returns no update package. If the gray-scale condition is met, it checks whether a difference package exists. If it does not exist, it sends the complete package download link; if it exists, it retrieves the download link from the packages_diff table and returns it.

[0167] When a canary release is paused from the web module, the server module will mark the downloadable field of the corresponding release record in the packages table as no. At this time, when the client module makes a request, it will return no update package.

[0168] The client module requests an interface to check for updates each time it starts. The server module returns relevant results based on the interface parameters. After receiving the results, the client module terminates the process if no update package is found. If an update package is found, it downloads it. After downloading, it determines whether it is a difference package. If not, it saves the package locally and marks it as `current_package`, while marking the currently running package as `previous_package`. If it is a difference package, it merges the difference package content into the existing package using a text-based difference method and saves it locally, marking the saved package as `current_package` and the currently running package as `previous_package`. The difference package information includes unique identifiers indicating whether it is a difference package.

[0169] The package marked "current_package" will be retrieved and run on the next startup. If the "current_package" package crashes on the first run, the package marked "current_package" will be deleted, and the package marked "previous_package" will be changed to "current_package" for the next startup.

[0170] In summary, all React Native product lines (such as Chain Diary, Xiaopu Diary, Shanglu Microstore, etc.) can be integrated into this solution system. When new features or bugs need to be released, they can be deployed quickly using this solution system. If users report bugs after a new feature is released, the release can be paused to minimize the impact on a large number of users.

[0171] Specifically, the text difference method involves fewer processing steps, and the number of deletions followed by additions is greater than the number of additions followed by deletions. It uses a graph shortest path search problem to determine the optimal choice. Specifically, it removes the longest common substring at the beginning of the file; for the end, it finds the longest substring based on the shorter string, removes the longest substring, and then processes the remaining part of the file using a diff packet.

[0172] Text difference methods include three operations: delete, insert, and equal. delete represents deletion, insert represents insertion, and equal retains identical text. The processing is based on the principle of minimizing processing steps and ensuring that the number of deletions followed by additions is greater than the number of additions followed by deletions. Specifically, if the source text is src = ABCABBA and the target text is dst = CBABAC, there are several ways to convert the source text to the target text:

[0173] Method 1: -A, -B, C, -A, B, +A, B, A, +C (- represents delete, + represents insert, no symbol indicates equal);

[0174] Method 2: -A, +C, B, -C, A, B, -B, A, +C;

[0175] Method three: +C, -A, B, -C, A, B, -B, -A, +A, +C;

[0176] Method 1 can be represented by a set as follows:

[0177] Steps = ["deleteA", "deleteB", "equalC", "deleteA", "equalB", "insertA", "equalB", "equalA", "insertC"], a total of nine steps to complete the conversion.

[0178] Method two can represent the set as:

[0179] Steps = ["deleteA", "insertC", "equalB", "deleteC", "equalA", "equalB", "deleteB", "equalA", "insertC"], a total of nine steps to complete the conversion.

[0180] Method 3 can represent the set as:

[0181] Steps = ["insertC", "deleteA", "equalB", "deleteC", "equalA", "equalB", "deleteB", "deleteA", "insertA", "insertC"], a total of ten steps to complete the conversion.

[0182] Clearly, Method 1 is more intuitive than Method 2; that is, deleting and then adding is better than adding and then deleting, and it involves the fewest transformation steps. Therefore, it aligns with the text difference method. The judgment between Method 1 and Method 3, finding the shortest transformation steps, is obviously a typical shortest path search problem. Using the above transformation as an example, we construct... Figure 3As shown, the horizontal axis represents the src content, and the vertical axis represents the dst content. Each path from the top left to the bottom right corner in the graph represents a diff step. Moving to the right represents delete, moving downwards represents insert, and the diagonal represents equal (keeping the original content unchanged).

[0183] Choose the following path:

[0184] (0,0)->(1,0)

[0185] (1,0)->(2,0)->(3,1)

[0186] (3,1)->(3,2)->(4,3)->(5,4)

[0187] (5,4)->(6,4)->(7,5)

[0188] (7,5)->(7,6)

[0189] The path represents the following diff steps: -A, -B, C, +B, A, B, -B, A, +C.

[0190] The above path successfully converts src to dst, but it may not be the path with the fewest steps. Therefore, it is necessary to use dynamic programming and Myers' algorithm to find a new path, as follows:

[0191] First, define parameters d and k, where d represents the path length and k represents the current x and y coordinates. Define an optimal coordinate, which is the coordinate with the largest x value given fixed d and k values. A larger x value indicates more rightward movement and more priority deletion operations.

[0192] Specifically, starting from coordinates (0,0), at this point, d = 0 and k = 0, then gradually increase d and calculate the optimal coordinates for each k value. Since each step is either to the right (x+1) or down (y+1), and the diagonal does not affect the path length, when d = 1, k can only have two values: either 1 or -1.

[0193] When d=1 and k=1, the optimal coordinates are (1,0).

[0194] When d = 1 and k = -1, the optimal coordinates are (0, 1).

[0195] When d = 1, k is either 1 or -1. When d = 2, it means taking another step based on d = 1, and k has only three possible values: -2, 0, and 2.

[0196] When d = 2 and k = -2, the optimal coordinates are (2, 4).

[0197] When d = 2 and k = 0, the optimal coordinates are (2, 2).

[0198] When d = 2 and k = 2, the optimal coordinates are (3, 1).

[0199] This process continues until we find a value for d and k that reaches the final target coordinates (7,6). Establishment is as follows... Figure 4 The horizontal axis represents d, the vertical axis represents k, and the middle represents the optimal coordinates. From this, we can see that when d = 5 and k = 1, the target coordinates (7, 6) are reached. Therefore, the shortest intuitive path is (0, 0) -> (1, 0) -> (3, 1) -> (5, 4) -> (7, 5) -> (7, 6), and the corresponding diff packages are as follows: -A, -B, C, +B, A, B, -B, A, +C. As mentioned above, to find the optimal coordinates for all k when d = 5, we must first know the optimal coordinates for all k when d = 4. To find the answer for d = 4, we must first solve for d = 3, and so on, to obtain the shortest path.

[0200] In the specific process of software canary release, since the JavaScript code string packaged for hot deployment is largely the same in the two hot deployments with only minor modifications, a head-and-tail removal operation is first performed to remove the longest substring with the same beginning. For the tail, the longest substring is calculated based on the shorter string, and then the longest substring is removed. The remaining substring is then diffed, which can speed up the diffing process.

[0201] If the previous hot deployment JavaScript code is as follows:

[0202] yr=v.create({app:{marginHorizontal:"auto",width:500}}),br=vr;Un.registerComponent("App",(function(){return br})),Un.runApplication("App",{rootTag:document.getElementById("react-root")})}]);

[0203] Later, due to changes in product requirements, the width was changed from 500 to 308. The modified JavaScript code is as follows:

[0204] yr=v.create({app:{marginHorizontal:"auto",width:308}}),br=vr;Un.registerComponent("App",(function(){return br})),Un.runApplication("App",{rootTag:document.getElementById("react-root")})}]);

[0205] Because there are many repeated strings at the beginning and end, to speed up the operation, the process where the beginning and end are equal is denoted as equal. Let's assume the transformation of the beginning is denoted as Step 1, the transformation of the unequal parts in the middle is denoted as Step 2, and the transformation of the equal parts at the end is denoted as Step 3.

[0206] Step1 equal(0,48). Where 0 and 48 represent that the two code segments are equal from the starting position to the position where the string length is 48.

[0207] Step 2

[0208] Step3 equal(51,300) where 51 and 300 represent that the two code segments are equal from position 51 to the end (assuming the string length is 300).

[0209] Now we need to find the minimum number of transformation steps for Step 2, which is from src=500 to dst=308. Using the dynamic programming approach described above, the minimum number of steps is: -5, +3, 0, -0, +8. This can be denoted as Step2 = [delete(49,'5'), insert(49,'3'), equal(50,50,'0'), delete(51,'0'), insert(51,'8')]. The entire transformation process is then: Step = [equal(0,48), delete(49,'5'), insert(49,'3'), equal(50,50,'0'), delete(51,'0'), insert(51,'8'), equal(51,300)]. Here, the first parameter of delete and insert represents the character position in the string being operated on, and the second parameter represents the character being operated on. The first and second parameters of `equals` represent the start and end positions of the substring to be operated on, and the third parameter is the specific character to be operated on (optional). The package diff table file records these change steps. The client does not need to download the complete hot deployment code every time; it can download such a diff package file and obtain the complete code based on the diff package file.

[0210] Printing is an essential function in the entire marketing process. Currently, different terminals (iOS, Android, etc.) require separate implementations of the logic to parse data into print instructions, resulting in repetitive work and high maintenance costs. Therefore, to facilitate printing, this system also integrates a visual editing method for print templates. Especially for customer-side applications, to facilitate use and streamline the software, some functions of this system have been ported to WeChat Mini Programs, and the visual template editing function is implemented based on WeChat Mini Programs. This is because a complete printing implementation already exists on PCs, while effective and fast printing is difficult to achieve on mobile devices. In addition to allowing for custom template editing, the visual template editing function also includes a large number of pre-built standard templates. The technology for the visual editing function is implemented through React Hooks in conjunction with the WeChat MovableArea and MovableView components. The MovableArea and MovableView components provide basic mobility for materials, while ReactuseEffectHook enables two-way data binding, binding the view and data, laying a solid foundation for subsequent actual printing. Whether it's barcodes or plain text, both support custom input (static) and data reading (dynamic) methods, which can be selected as needed.

[0211] After the template is edited, the template data is stored on the print center's server. During subsequent printing, the front end only needs to send the template ID and the corresponding product data. Upon receiving the request, the print center pre-parses the template. When it encounters a section requiring data, it reads the product data from the request and fills the corresponding positions, ultimately parsing it into a print command and returning it to the front end. Once the front end receives the print command, it doesn't need any further action; it directly transmits the command to the printer for printing. The entire process is simple and fast.

[0212] The system's terminals also feature network optimization for optimal routes. Upon startup, multiple routes are retrieved from the service center and cached on the local server for speed testing. All primary entry points are checked first; if no route is selected, secondary entry points are considered. The main differences between primary and secondary entry points are bandwidth, stability, and reliability. Static variables and a protection time (4 seconds * 2 = 8 seconds) are added to the terminal to prevent repeated testing of the optimal route. Route testing is initiated concurrently, allowing connection, read, and write operations to be completed within 2 seconds, with a minimum of 4 seconds for optimal route selection. Once all speed testing threads have completed and the optimal route has been selected, the global variables are updated as quickly as possible. Optimal route testing is only triggered when a network instability warning appears in the foreground, and this asynchronous testing does not affect main business operations. It does not significantly increase the burden on the existing internet infrastructure and can be implemented using a simple, conventional client-side selection algorithm.

[0213] The above description is only a preferred embodiment of the present invention. It should be noted that those skilled in the art can make several improvements and modifications without departing from the concept of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A marketing middleware system employing a React Native-based canary hot deployment method, characterized in that: It includes a marketing conditions module and a benefits module, specifically including the following steps: 101) Marketing scenario analysis steps: Based on the corresponding activities and link entry points, analyze the marketing conditions module and benefits module corresponding to the activities; analyze the applicable conditions of the corresponding activities in the marketing conditions module; 102) Condition setup steps: Based on the applicable conditions of the activity analyzed by the marketing conditions module, confirm the number of hierarchical items required for the activity, use hierarchical description to describe the internal hierarchy of the hierarchical items, and realize the calling of the marketing conditions module for this activity by setting the corresponding interface; The hierarchy is set from high to low within the hierarchy item. Each level includes at least one member. The members are discrete and hierarchical. When there are multiple members, a full-range special member is also set, which represents all members of the level. 103) Benefits Confirmation Steps: Based on the activity conditions established in step 102) Marketing Conditions module, the benefits module provides corresponding discount benefits or gives away appropriate gift packages; It also includes message transaction processing, including a transaction message service module and a transaction message client plugin module; The transaction message service module includes message receiving, commit / rollback message processing, and message inspection and processing. The transaction message client plugin module enables the embedding of transaction message client plugins into the transaction initiator and transaction receiver. The upgrades to the transaction message service module and the transaction message client plugin module adopt a canary hot deployment method based on React Native; When the server receives the uploaded package, it checks if the same version of the package already exists in the packages table. If it does not exist, it records the corresponding information for this release in the packages table. If it does exist, it uses the text diffing method to generate the diffed content, saves the diffed content to the old package for replacement, and records it in the packages_diff table, completing one diffing process. The packages table records each version release, and the packages_diff table records the file information after each release diff. After the client downloads the returned update package, it determines whether it is a difference package. If it is not a difference package, the update package is saved locally, and the update package is marked as current_package, while the running package is marked as previous_package. If it is a difference package, the difference package content is merged into the existing package using the text difference method and saved locally. The saved package is marked as current_package, and the running package is marked as previous_package. Among them, the text difference method adopts the principle of fewer processing steps and more processing after deletion than after addition, and makes the optimal choice by searching the shortest path in the graph. Specifically, for the header, the longest substring with the same length at the beginning of the file is removed. For the tail, the longest substring is found based on the shorter string, and then the longest substring is removed. The remaining part of the file is then processed by diffing.

2. A marketing middleware system based on React Native with a canary hot deployment method as described in claim 1, characterized in that: Subordinate members within the same level of an item are within the scope of their superior members; members between items at different levels are independent of each other.

3. A marketing middleware system based on React Native with a canary hot deployment method as described in claim 1, characterized in that: The data of members at each level under a hierarchical item is stored in a relational table in the database, and the data structure type of the stored data adopts hierarchical relationship and / or parent-child relationship.

4. A marketing middleware system based on React Native with a canary hot deployment method as described in claim 1, characterized in that: The corresponding interface includes the hierarchical item name, the definition of the hierarchy, the top-level member, the parent member of a certain member, the list of the lower-level members of a certain member, and the translation of a certain member, which facilitates the reading of members and member relationships.

5. A marketing middleware system based on React Native with a canary hot deployment method as described in claim 1, characterized in that: The transaction message client plugin module intercepts Spring local transaction operations at the transaction initiation end and performs transaction message processing before and after Spring local transaction commit or rollback operations. The transaction message client plugin module assists the transaction receiver in checking whether a message has been processed to avoid duplicate message processing. If a message cannot be consumed repeatedly, the transaction message client plugin writes the transaction message ID to the local table when it receives the message, and checks whether the transaction message ID exists to ensure that the message is consumed only once.

Images